Why AI Agents Need First-Class Identities

It usually starts innocently. A team wires their new support agent to a shared inbox using the ops lead's OAuth token, because that was the account everyone had access to. It works great for months. Then the ops lead changes roles, IT deactivates her account during the access review, and the agent goes dark on a Friday night — along with any clear record of which of the 4,000 messages in that mailbox were sent by a human and which by the bot. Nobody did anything wrong, exactly. The agent just never had an identity of its own, so it died with someone else's.

I think this failure mode is going to define the next couple of years of agent infrastructure, and the fix is conceptually old: agents need first-class identities, the same way services got service accounts instead of running under an engineer's login.

Borrowed credentials are a category error

When an agent operates through a human's credentials, three properties break at once.

Addressability. Nobody can reach the agent. Replies to "its" messages land in a human's inbox, mixed with that human's actual mail. Other systems — and increasingly, other agents — have no address for it.

Accountability. Every action the agent takes is attributed to a person who didn't take it. When something goes wrong, your audit trail says Karen sent this, and Karen has to prove a negative.

Blast radius. The agent inherits everything the human can do. An agent that needed to send follow-up emails can also read the salary negotiation thread, because the token doesn't know the difference. The security guidance for agents is blunt about the adjacent risk: email-connected agents face prompt injection — instructions buried in a message body that the model might follow. Injection against a borrowed identity exposes a person's entire account. Injection against a scoped, dedicated identity exposes that identity's mailbox and nothing else.

None of this is hypothetical creativity; it's the same reasoning that gave us service accounts, robot users in CI, and per-service API keys. We just haven't consistently applied it to agents yet.

What a first-class agent identity looks like

Concretely, it's an identity that's reachable, persistent, and accountable — the way the Agent Accounts docs frame it: think of the agent the way you'd think of any other user in your organization. That implies:

• Its own address. [e-mail], not a human's inbox with a filter.
• Its own data boundary. Every API call scoped to the agent's grant; the agent can only touch what belongs to it.
• Its own audit trail. The agent's sent folder is the log of what it did. Webhooks give you a server-side record of every send and change, independent of the agent's own logging — which matters, because an agent compromised by injection can't be trusted to log honestly about itself.
• Its own limits. A quota that applies to the agent, not to a person. On the hosted version of this idea (Agent Accounts, currently in beta), the send cap is 200 messages per account per day on the free plan, with 30-day inbox retention — and a policy can set stricter caps per account. A runaway loop hits the agent's ceiling, not a human's reputation.

Provisioning one is a single API call, which is itself part of the argument — identities this cheap remove the main excuse for borrowing:

curl --request POST \
  --url "https://api.us.nylas.com/v3/connect/custom" \
  --header "Authorization: Bearer $NYLAS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{ "provider": "nylas", "settings": { "email": "[e-mail]" } }'

The counterarguments, taken seriously

"My agent acts on behalf of a user — it should use their identity." Sometimes true! An assistant that drafts replies in your voice, in your inbox, with your relationships genuinely is acting as you, and a delegated OAuth grant is the honest model for that. The distinction worth drawing: is the agent acting as a person or as itself? Summarizing my inbox is the former. Running the support queue is the latter. Most teams currently use delegated identity for both, and it's the second category where it breaks.

"More identities, more management overhead." Yes — accounts to provision, credentials to rotate, lifecycles to manage. But the overhead exists either way; borrowed credentials just hide it until an offboarding event detonates it. Managed explicitly, agent identity becomes ordinary infrastructure: provision at deploy, tear down at decommission.

"Scoped permissions solve this without separate identities." Scoping helps a lot — an agent that only drafts replies for human review needs no send permission at all, and you should absolutely narrow tools to match the job. But scoping a human's token still leaves attribution and addressability broken. You've shrunk the blast radius while keeping the wrong name on every action.

"Identity doesn't stop prompt injection, so what's the point?" Correct, and important to get right: a dedicated identity does nothing to prevent an agent from reading a malicious instruction. The injection defenses are orthogonal — treat every message body and calendar description as untrusted input (the white-on-white text trick works in event descriptions too), strip hidden HTML before it reaches the model, and gate sends behind explicit confirmation. The security docs are emphatic that two-step send confirmation exists specifically for this and shouldn't be worked around. What identity changes is the bound on a defense failure. Every mitigation list eventually loses a round; when it does, "the agent's own mailbox" is a recoverable incident and "the CFO's mailbox" is a disclosure. Prevention and containment are different layers, and you need both.

"Won't people be deceived by bot email addresses?" Only if you name them deceptively. scheduling-agent@ is more honest than mail that quietly came from a bot wearing an employee's address — which is the status quo being defended.

There's also a quieter version of the borrowing problem one level up: the API key. A platform key grants access to every connected account, and the security guidance says to treat it like a database root password — environment variables or a secrets manager, never in code, and never in a system prompt or rules file where it could be logged, cached, or coaxed out of the model. An agent identity scopes what one actor can touch; key hygiene decides whether the scoping matters at all.

The directional bet

Agents are becoming long-lived coworkers rather than scripts: they hold multi-day conversations, attend meetings, get escalated to. Long-lived actors with no identity of their own are an accounting hole — in the security sense and the organizational one. Identity is also the prerequisite for everything we'll want next: per-agent permissions, per-agent reputations, agent-to-agent communication that doesn't impersonate anyone.

So here's the audit worth doing this week: list every agent or automation you run that touches email or calendars, and for each one, write down whose credentials it actually holds. If any answer is "a person who didn't sign up to be a bot's alibi" — that's the one to migrate first. Whose name is your agent borrowing right now?