You've probably got an AI agent or two running in production already. One triages support tickets, another drafts pull requests, a third calls internal APIs. You've probably given each one credentials the way you give any other software: a service account, or a token that acts on behalf of a person.
That model holds until the first handoff. The moment one agent delegates to another, the acting instance drops out of the record. Delegation can name a client acting on a user's behalf, but nothing enforceable says which instance acted, for which user, at which hop. Once a second or third agent is involved, attribution collapses. Fixing it means rethinking the credential itself — part of the wider shift in AI agent identity and runtime authorisation.
Should enterprise agents use service accounts or first-class agent identities?
Most teams reach for a service account, because an agent calling an API looks a lot like a service account. That instinct causes most impersonation problems.
A service account is shared, durable and broadly privileged. When ten agents run under one service account, you cannot tell from the logs which agent touched which data, and rotating the credential means coordinating across every agent using it. When something goes wrong, the record shows "the service account did it," with no way to revoke one run.
A first-class agent identity is the opposite. It has four properties: a directory identifier distinct from any user or service account, permissions scoped in business terms, a delegation context recording the agent as actor and the user as subject, and a dedicated audit trail. SPIFFE assigns verifiable per-instance workload identities, and Federated Identity Credentials let a workload's OIDC or JWT stand in for a secret.
Non-human identities outnumber human ones by roughly 45 to 1, and the Cloud Security Alliance reports that only 28% of organisations can trace an agent's actions back to a human sponsor. That's the governance argument for treating each agent as its own principal, with Model Context Protocol tool credentials scoped per task.
Why can't OAuth 2.0 express which agent instance acts on behalf of which user?
OAuth was built for delegation between a client and a user, so it's natural to assume it covers agents. It doesn't. It can express a client acting for a resource owner under pre-registered scopes, but not the three things that matter in a multi-hop chain: which instance, for which user, at which hop. That's the missing on-behalf-of delegation.
The sub and act claims show the gap. sub names the human, act names the agent. In a naive token exchange, sub=alice survives while act gets dropped, and the terminal service sees nothing but "Alice's own transaction". RFC 8693 can nest act claims, but the spec treats prior actors as informational only, so OAuth's own standard admits it doesn't enforce the chain for multi-hop scenarios.
The Identity Assertion JWT Authorization Grant (ID-JAG) is the main attempt to patch this. It extends an identity provider's single sign-on trust into scoped API calls through an agent, preserving the actor more explicitly than classic OAuth. But it is a profile layered on top of the same grant model rather than a native primitive. Filling the gap are Transaction Tokens, which carry sub and act through a service chain, and Rich Authorization Requests, which carry structured intent rather than an opaque scope string. None of these has settled into the default, which is why the standards and vendor focus on agent identity is still a contest rather than a consensus.
Why must delegated authority narrow, never widen, as it passes between agents?
Agent-to-agent delegation is a chain, and a chain is only safe if every link is narrower than the one before it. That property is attenuation, a one-way rule: each hop may shed authority, never add it.
That rule exists because its absence produces the confused deputy: a delegating agent that hands downstream everything it was given becomes a privilege amplifier. The effective permission set at any tool call should be the intersection of the agent's permissions and the user's. Check only one and you get what Microsoft names inter-agent trust escalation, where a compromised agent inflates what it claims to hold.
Token exchange, RFC 8693, is how authority changes hands, and it permits attenuation without requiring it: an exchange can hand back a token as broad as the one it received. So narrowing has to be enforced as policy, not assumed. "Narrower" also isn't one thing, because scope spans action, resource and context: an agent that sheds a resource but keeps a broad action hasn't actually narrowed. Rich Authorization Requests carry declared intent so one hop can be compared against the one before it. Skip that and you get a research agent inheriting a financial assistant's trade tool, or an attacker splicing themselves between two hops.
What is an ephemeral agent credential, and how does it differ from a static API key or long-lived token?
The credential that enforces attenuation while shrinking the exposure window is the ephemeral agent credential.
An ephemeral agent credential is a short-lived, task-scoped token minted for a specific operation and discarded when it finishes. It's the opposite of a static API key, which sits around for months, is shareable and replayable, and doesn't record who delegated what or which agent did it.
The difference is measured across three factors: duration × scope × reachability. A static key valid for 90 days stays useful for nearly 7.8 million seconds, while a 15-minute token stays useful for 900. Scope is how much it can touch, reachability is where it can be replayed from. Reduce all three, not just the lifetime.
Short lifetimes alone don't close the replay path. A bearer token is accepted from anyone holding it, so theft equals impersonation. Proof-of-possession changes that: DPoP, RFC 9449, binds a token to a client key pair, so a stolen token is useless without the private key. That's why NIST points agents towards short-lived, verifiable identity credentials rather than standing secrets. On the identity plane, SPIFFE's SVIDs are the counterpart, rotated every hour or less.
Conclusion
The missing delegation primitive is a first-class, per-instance agent identity bound to ephemeral credentials that narrow at every hop and die with the task. Scopes and stronger tokens won't get you there; neither restores attribution nor caps exposure.
Service accounts and bearer tokens freeze consent into a durable secret. The correct primitive is a per-instance identity asserting a live, attenuated delegation context. Keep sub and act intact at every hop and the audit record can say "this agent, on behalf of this user, with this delegated authority." Shrink the credential's life to the task it was minted for, and a leak stops being an inherited chain.
Make the agent the principal and the credential a short-lived, attenuated proof of one action, and attribution returns at the same moment the blast radius collapses. That is the authority-mechanics layer of the cluster, and the bridge to the runtime enforcement and standards gaps that sit around it.
Frequently Asked Questions
Is agent delegation just OAuth 2.0 with extra scopes?
No. Adding scopes tells a service what a client may do, but it still cannot say which agent instance performed the action, for which user, at which hop. OAuth freezes consent into a bearer token rather than expressing a live delegation relationship, so a delegated action collapses into "the user did it." More scopes widen permitted actions; they do not restore attribution across an agent chain.
How does the Identity Assertion JWT Authorization Grant (ID-JAG) differ from classic OAuth for agent delegation?
ID-JAG extends an identity provider's single sign-on trust into scoped API calls, so an agent can present an IdP-issued assertion (RFC 7523) via token exchange (RFC 8693) and carry the acting agent more explicitly than a plain OAuth access token. It is a meaningful improvement, but it remains a profile layered on top of OAuth rather than a native primitive, so attribution and attenuation still depend on how you enforce those claims downstream.
How do I measure the exposure window created by long-lived agent tokens?
Model it as a product of three factors: duration, scope and reachability. Ask how long a leaked credential stays valid, how many actions and resources it can touch, and from where it can be replayed. A long-lived, broadly scoped token that any network location can use scores far worse than a token that expires in minutes, touches one resource and is bound to a single key pair. Reduce all three, not just the clock.
How do bearer tokens and key-bound, proof-of-possession tokens compare for agents?
A bearer token is accepted by anyone holding it, so theft equals immediate impersonation. A proof-of-possession token, such as DPoP (RFC 9449), is sender-constrained: the client must prove it holds the matching private key for every request, so a stolen token alone is useless. Mutual TLS (RFC 8705) achieves the same binding at the transport layer. For agents, proof-of-possession removes replay as an attack path.
What happens if an ephemeral agent credential is stolen before it expires?
The damage is bounded by design. Because the credential is short-lived, task-scoped and usually proof-of-possession bound, an attacker gains only the remaining lifetime of one narrowly scoped task, and only if they also hold the private key. Without proof-of-possession, a stolen bearer credential still works until it expires, which is the practical reason short lifetimes and key binding are deployed together rather than separately.
Do I need to rip out every service account to adopt this model?
No, and a big-bang replacement is the wrong move. Start where attribution and blast radius hurt most: agents that cross trust boundaries, delegate to other agents, or hold broad, standing permissions. Give those per-instance identities and ephemeral credentials first, then extend to the rest as your governance matures. The goal is to stop issuing shared, durable secrets to entities that need to be individually accountable.
What is the difference between the sub and act claims in a delegation chain?
sub is the subject the action is ultimately for, normally the human or resource owner, while act names the agent actually performing it. In naive token exchange, sub=alice survives but the act context is dropped, so downstream systems record the action as Alice's own. Keeping both intact at every hop is what lets a terminal service answer "this instance did it, on behalf of this user, at this hop."
Can agents delegate to other agents without a human in the loop?
Yes, and that is exactly where the model matters most. Nothing about a delegation chain requires a human at each hop, but every agent-to-agent hop must still attenuate authority and carry the sub/act context forward. Removing the human removes the last place where attribution is obvious, so unattended chains depend entirely on per-instance identity and enforced narrowing to stay attributable and auditable.
What is the confused deputy problem for AI agents?
A confused deputy is an agent that uses its own broader privileges to perform an action on behalf of a less privileged requester, granting more than the requester was ever allowed. With agents, this happens when a delegating hop does not check the intersection of the agent's permissions and the user's. Enforcing monotonic attenuation, so each hop may only shrink authority, prevents an agent from becoming a privilege amplifier for whoever asks.
Is it true that short-lived tokens alone solve agent delegation?
No. Short lifetimes shrink the exposure window but do nothing for attribution or widening. A minute-long token that still erases which instance acted, and that a downstream hop can broaden, leaves the core gap untouched. You need all three parts together: first-class per-instance identity, monotonic attenuation at every hop, and ephemeral, task-scoped credentials. Remove any one and the chain is either unattributable or amplifiable.
Does SPIFFE replace OAuth for agent authentication?
No, they operate on different planes. SPIFFE issues short-lived, cryptographically signed workload identities (SVIDs) that answer who a workload is, with no standing secret. OAuth and token exchange answer what that identity may do. The strongest agent deployments combine them: SPIFFE establishes per-instance identity at the workload layer, and OAuth-based authorisation carries the delegated, attenuated authority for each action.
How should MCP tool credentials be scoped for agents?
Treat every Model Context Protocol tool credential as a narrowly scoped, short-lived capability rather than a shared secret. Grant only the actions the current task needs, mint the credential just in time, and discard it when the task finishes. Do not let one tool token stand in for an agent's whole permission set. This keeps a compromised tool call from becoming a foothold that an attacker can reuse across the agent's other tools and resources.