# Why AI Agents Need First-Class Identities > Source: > Published: 2026-06-16 17:06:46+00:00 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. 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](https://developer.nylas.com/docs/v3/getting-started/agent-security/) 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. Concretely, it's an identity that's *reachable, persistent, and accountable* — the way the [Agent Accounts docs](https://developer.nylas.com/docs/v3/agent-accounts/) frame it: think of the agent the way you'd think of any other user in your organization. That implies: `support-agent@yourcompany.com` , not a human's inbox with a filter.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": "support-agent@yourcompany.com" } }' ``` **"My agent acts on behalf of a user — it should use their identity."** Sometimes true! An assistant that drafts replies in **"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. 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?