Fixing Auth for Personal AI Agents
Agentic browsers and AI assistants are shipping, but they’re all built on a broken identity foundation. They either run with limited API-only access or they force users into the insane practice of handing over raw credentials. For agents to act on our behalf without creating a security and audit nightmare, we need to fix auth at a more fundamental level.
This isn’t an application-layer problem. This is an identity-layer problem.
The Core Problem: Impersonation vs. Delegation
Right now, an AI agent has two bad options for accessing your accounts:
- Scoped API Access: The agent gets an OAuth token with a limited scope (e.g., calendar.read). This is a sandbox, and a pretty small one at that. The agent can’t browse the web as you; it can only hit pre-approved endpoints. This neuters the whole concept of a general-purpose agent.
- Credential Handover: You give the agent your literal username and password. This is catastrophically insecure. It makes auditing impossible and turns every agent into a potential supply chain attack vector for your personal accounts. Every action the agent takes is logged as an action you took.
We have robust protocols for a user authenticating themselves, and for an application acting on its own behalf. We have no standard for an application acting as a delegate for a user, especially for today’s use-cases of AI agents needing to work as the signed-in user.
No, Service Accounts Are Not the Answer
Let’s get this out of the way: service-accounts are the wrong abstraction. A service account is an impersonal, non-human principal. It’s for a CI/CD pipeline or a backend cron job.
A personal AI agent is the opposite: it’s a delegate for a specific human, operating on that human’s personal data. Tying its actions to billing-reporter@gserviceaccount.com is useless. We need to tie its actions to jane.doe@gmail.com but with a clear, auditable asterisk.
The Fix: Delegated Auth with an actor Claim
The fix has to happen at the identity layer to be universal and widely applicable. The major identity providers—Google, Microsoft etc—need to extend their auth protocols (think OAuth/OIDC) to support agent delegation.
When a user authorizes an agent, the IdP should issue a standard access token with one crucial addition: a claim that specifies the actor. Something like:
“actor”: { “type”: “delegated_agent”, “id”: “agent_id_xyz” }
When an agent presents this token to a resource server (like the Gmail API), the server can see two critical pieces of information:
- The Subject (sub): The action is for jane.doe@gmail.com.
- The Actor (actor): The action was performed by agent_id_xyz on Jane’s behalf.
This creates an audit trail for actions performed by an agent on behalf of a user. It also allows us to build policy around the actor. The IdP or the resource server could enforce rules like actor.type: ‘agent’ cannot perform destructive actions like account.delete or password.reset.
Why doing this at the app layer doesn’t work
Trying to solve this at the app layer is a non-starter. You’ll get a thousand different, incompatible implementations, and no one will trust anyone else’s X-Agent-ID header. The IdP is the only trustworthy source of truth for who is acting. It’s the only entity that can cryptographically certify that a given request was performed by a legitimate, user-sanctioned delegate.
Immediate use-case: Agentic Browser Support
The need for something like this is already apparent in today’s agentic browsers, like Comet, or Google’s upcoming Mariner.
The ideal implementation is native to the browser itself. Imagine Chrome’s profile manager having a concept of “delegated agent sessions.” An agentic browser like Mariner would be able to clearly distinguish actions performed by the human user from those performed by the browser agent carrying out its own plans and tasks.
The benefits are clear:
- Users: Get to delegate tasks without handing over the keys to the kingdom. You get a real audit log and systemic guardrails.
- Developers: Can finally build powerful agents without resorting to janky screen scraping or insecure credential storage.
- Identity Providers: Unlock a new ecosystem of trusted third-party agents, making their platforms stickier and more powerful.
Without a proper identity layer for delegation, personal AI agents will remain stuck between being glorified toys and unacceptable security risks. It’s time to build the auth protocols for the agentic era.