When an organization deploys its first serious AI agent, the integration team reaches for the tool it knows: a service account. Broad credential, long expiry, named after the agent. It works on day one.
It also makes a structural decision most teams do not realize they are making. A service account asserts that the agent acts on its own authority. It does not. An agent acts on behalf of a human, and the service account erases that fact at exactly the moment the infrastructure should be recording it.
Six months later the questions arrive. Which agent actions were taken with whose authority? Why does the agent still have access after its owner left? Can we prove to an auditor that the agent never exceeded what the human could do? With service accounts, the honest answer to all three is that nobody can say.
The position we hold is simple. Agent access should never mean service accounts. It should mean a delegation chain, and every link in the chain should be expressed in the token.
The chain
The architecture has five parts, and naming them precisely keeps the design honest.
Human: the principal. Authority originates here and nowhere else.
IdP: the authority. It authenticates the human, issues the delegated tokens, and remains the single place where access is granted and revoked.
Agent: the actor. It holds no standing credentials of its own. It acts under authority delegated from a specific human, for a specific scope, for a bounded time.
MCP proxy: the control plane. Agent tool calls flow through it, and it enforces the identity context on every call rather than trusting the agent to police itself.
Tool: the resource. It sees a verifiable token stating who is acting and on whose behalf, not an anonymous key.
The failure mode of service accounts is now easy to state. They collapse the first three links into one. Human, authority, and actor all blur into a single static credential, and everything downstream loses the ability to distinguish them.
The standards already exist
None of this requires inventing new protocol. It requires using two existing pieces of OAuth correctly.
OAuth Actor Tokens (RFC 8693) carry delegation natively. The token's sub claim identifies the human principal. The act claim identifies the agent acting on their behalf. A tool receiving this token knows both parties to the delegation.
{
"sub": "user:priya@example.com",
"act": { "sub": "agent:expense-copilot" },
"scope": "expenses:read expenses:submit",
"aud": "https://api.example.com/expenses",
"exp": 1772150400
}Read that payload as a sentence: the expense copilot is acting for Priya, on the expenses API only, with two permissions, until the token expires. Every claim is an audit answer.
Resource indicators (RFC 8707) supply the second discipline. Each token is scoped to a single audience, so a token minted for the expenses API cannot be replayed against the HR system. Agents touch many tools, which is precisely why each delegation must be narrow. One token per audience turns a stolen credential from a master key into a single door.
For operations that deserve a human in the loop, phishing-resistant step-up using FIDO2 or CIBA adds an explicit approval. The agent pauses, the human confirms with a credential that cannot be phished out of them, and the approval is recorded in the chain.
The enforcement point sits between agents and MCP servers and evaluates the identity context on every tool call. Who is the human principal? Is the agent's act claim valid? Is this audience in scope, and does this operation require step-up? Existing agents and downstream tools do not change. The enforcement point does.
Lifecycle is the argument that ends the debate
Suppose you accept everything above as theoretically right but operationally optional. One scenario settles it.
An employee with an AI agent leaves the company.
Under the delegation chain, the outcome is automatic. The human's identity is suspended in the IdP, the IdP stops issuing tokens with their sub, and every delegation that flowed from them dies with the next expiry. The agent's access ends because the authority behind it ended. No runbook required.
Under service accounts, the outcome is a ticket. Someone must remember the agent exists, know which human it really served, and revoke a credential that was deliberately built to be independent of any human. Organizations are reliably bad at this with ordinary service accounts. Agent sprawl makes it worse, because agents multiply faster than the inventory tracking them.
Joiners and movers follow the same logic. When a person's role changes, their delegations should narrow or widen with it, automatically, because the delegations are derived from their identity. A service account knows nothing about the human's role and so cannot follow it.
Where to start
If agents are already running in your environment on static credentials, the path back is incremental. Inventory which human each agent actually serves. Route agent tool calls through a control plane that can enforce identity context. Replace standing credentials with delegated tokens one audience at a time, starting with the tools that touch money, code, or customer data.
The pre-SSO era taught this lesson once: application-by-application credentials feel fine until the day you need to answer for all of them at once. Agents are arriving faster than SSO did. Build the chain now, while the agent count is still small enough to inventory in an afternoon.