The agent needs its own login.

Last weekend a messaging account I run through a browser logged itself out. Twice.

Nothing was hacked. Nobody guessed a password. Several of my agents share one machine and one set of browser logins, and more than one of them opened the same signed-in session at roughly the same time. The service saw a confusing pattern from what looked like one person, and it did what a careful service should do. It dropped the session.

This morning a different agent finished a review job and tidied up after itself. It closed every browser tab on the way out, including the ones other agents depend on. The job itself was done correctly. The cleanup was carried out with my authority, because as far as that browser was concerned, there was only ever one user: me.

That is the whole essay. An AI agent should not use your login. It should have its own identity, act on your behalf with a narrow and short-lived grant, and leave a trail that says "this agent, for this person, did this." If your agents all borrow your session, you cannot scope them, you cannot revoke one without logging yourself out, and you cannot answer the first question anyone asks after something goes wrong.

Should an AI agent use your login?

No, not for anything that matters. Borrowing a human session is the fastest way to get a demo working, and it's the reason most agent incidents are hard to untangle.

When an agent acts through your cookies, your password manager or your personal API key, three things happen at once. It gets every permission you have, not just the ones the task needs. Every service it touches records the action as yours. And the only way to cut it off is to cut yourself off too.

OWASP's list of LLM risks calls this out directly. LLM06:2025 Excessive Agency names three root causes: excessive functionality, excessive permissions and excessive autonomy. One of its examples is an extension meant to act for one user that instead connects with a high-privilege identity that can see everyone's files. The recommended fix is to run actions "in the context of that specific user, and with the minimum privileges necessary," authenticated via OAuth with the minimum scope.

What "agent identity" actually means

Agent identity is the idea that an agent is a first-class principal in your systems, like a user or a service, with its own name, its own credentials and its own permissions. When it acts for a person, the record carries both: the person it acts for and the agent that acted.

This isn't a new invention. OAuth has had the building block since 2020. RFC 8693, OAuth 2.0 Token Exchange defines delegation, where one party acts for another, and an act (actor) claim that records who is actually making the call. The user stays the subject. The agent shows up as the actor.

What changed over the last two years is that the agent ecosystem started building on it.

The Model Context Protocol authorization spec (2025-06-18 revision) is the clearest example. MCP clients act as OAuth 2.1 clients. They must name the exact server a token is for, using resource indicators. Servers must reject tokens that weren't issued for them, and "MUST NOT pass through" a token they received to some other API. The spec also says authorization servers should issue short-lived access tokens, so a leaked one does less damage.

Microsoft went further and gave agents a place in the directory. Microsoft Entra Agent ID describes three ways an agent can authenticate: on behalf of a signed-in user, autonomously with its own service identity, or with a user account created specifically for the agent, such as one with its own mailbox. Interactive sign-in flows aren't supported for agent identities at all. The agent never types your password.

At the IETF, an internet-draft titled OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents proposes that the user consents to a specific named agent, the agent then proves its own identity when it collects the token, and the resulting token carries the user, the client app and the agent. It is a draft, not a standard. But the shape is the point.

An agent that borrows your login can do everything you can, and every log will say you did it. An agent with its own login can do only what you granted, and every log will say which agent did it.

Three ways an agent can hold access

Here is the model I now use when I decide how an agent should get into a system.

The third one surprised me most. One of my agents now has its own email address. When it writes to someone, the message comes from the agent, not from me, and anything it sends still needs my explicit go per message. Nobody on the other end is confused about who wrote it. If it misbehaves, I switch off one inbox, not my whole digital life.

How to give an AI agent access safely

If you are wiring agents into real accounts this year, this is the checklist I'd start with:

1. One identity per agent, not one per human. Give each agent its own client, service account or account. If two agents share a credential, you've already lost the ability to tell them apart.

2. Delegate, don't impersonate. When an agent acts for you, use a flow where you consent to that agent and the token records both of you. Your password, your cookies and your personal API keys stay with you.

3. Scope to the task and bind to the target. Read-only when the job is reading. One resource per token. The MCP spec's rule is a good default for everything: a token issued for one service is useless anywhere else.

4. Make it expire. Short-lived access tokens, rotated refresh tokens, and a grant that ends when the task ends. Standing access is how a forgotten agent becomes an incident.

5. Keep the human gate where it costs money or reputation. Sending, posting, paying and deleting stay behind an approval step, enforced in the system, not in the prompt. OWASP's wording is "complete mediation": the downstream system decides whether an action is allowed, not the model.

6. Log the actor, not just the user. Every action should answer "which agent, for whom, under which grant." That is the receipt.

The layer that moved

In The agent needs a wallet I wrote that spending is a bag of decisions, and each one wants a different owner. In The agent needs a memory I argued the context window is RAM, and memory is what you write on purpose. Identity is the layer underneath both. You can't put a limit on a wallet, or a receipt on a memory write, if you can't say which agent was holding it.

My logout loop wasn't a model problem or a prompt problem. The agents did roughly what they were told. The problem was that I had given all of them the same face, so the service couldn't tell them apart, and neither could I.

If you're building agents, stop asking which account they should log in with. Ask the better question: what is this agent's own identity, and what is the smallest grant it needs from me today?

Give it a badge. Keep your keys.