Note where the authorization decision belongs in a Zero Trust interaction. The agent, on the client side, presents a credential. The downstream service, on the server side, performs the authorization decision. That division matters. “Verify explicitly” is consistent with the architectural stance in NIST SP 800-207, not a feature any single vendor ships. If a product claims to deliver Zero Trust for agents in a box, that claim is worth reading skeptically, because the stance has to be enforced by the service holding the resource, not by the client asking for it.
Traditional service-account credentials are often long-lived, over-permissioned, and shared. That is the precise combination least privilege forbids. They were tolerable when the population was small and static: a handful of CI runners, a scheduled job, a database connector. Governing thousands of ephemeral agents is not the same problem scaled up. It is a different problem.
One pattern that holds up in practice has four properties:
Why Human-Centric Authentication Doesn’t Map Cleanly to Agents
OPA and Cedar operate at that policy layer, which is why per-action authorization sits there rather than baked into the agent. The agent should not be trusted to police itself.
Many implementations of Zero Trust assume a person is at the other end of the connection. That assumption is now the problem.
That gap is where enterprise identity architecture is quietly straining right now.
An agent does not fit that model. It does not log in the way a person does. It presents a machine credential, and the receiving service has to decide whether to trust it with no human in the loop. That is a different trust decision, made under different conditions, with a different failure mode.
The Service Account Trap
This is not merely an engineering inconvenience. Compliance frameworks require an accountable organization and effective controls. SOX-related auditing standards require evidence of effective internal control over financial reporting. The GDPR accountability principle makes the company or organization responsible for complying with data-processing principles and demonstrating that compliance. When the visible actor at the end of an investigation is a workload identity that existed for ninety seconds and no longer exists, those frameworks begin to strain against a reality they were never written for.
Those are two different things, and the industry keeps conflating them. Proving an agent is who it says it is tells you nothing about which human is answerable for what it did. You can have perfect authentication and no accountability at the same time.
This is the delegated-authority problem: the agent acting for a user. OAuth token exchange and the on-behalf-of flow support delegation, but agentic workloads can stretch real-world implementations past simpler designs. The OAuth 2.0 Token Exchange specification, RFC 8693, gives you a mechanism for swapping one token for another with adjusted scope. It does not, on its own, guarantee that the human who started the chain survives to the end of it.
Here is the judgment I will commit to: authenticating an agent is solvable, but attributing its actions to a responsible human is not consistently or cleanly solvable with today’s standards.
Delegated Authority Is Where the Protocols Bend
The near-term move is to stop provisioning agents like people or like legacy service accounts, adopt attested workload identities with short-lived credentials where you can, and build your logging around chain reconstruction before you need it in an incident. The accountability problem will not be fully closed by architecture alone, and pretending otherwise is how organizations discover, mid-audit, that their most autonomous systems are also their least attributable.
If you are running agents on service accounts today, you already know where the audit findings are going to land.
And the end of the chain is where things go wrong. In a delegation chain, the sub-agent-to-sub-agent hop is a place where the original human subject can get lost. There is sometimes an optional hop too, where a secrets manager or broker mints a short-lived credential mid-chain. Each hop is a place where identity can be re-issued, re-scoped, or silently dropped.
Look at how identity actually works in a modern enterprise. MFA, session tokens, conditional access in Entra ID: much of it still assumes a person authenticates once and stays accountable for what happens under that session. The mental model is continuity. One human, one identity, one accountable trail.
Authentication Is Not Accountability
The mechanisms available for that decision are not interchangeable. The OAuth 2.0 client credentials flow, mTLS with SPIFFE/SPIRE workload identities, and static API keys represent three distinct postures with three distinct blast radii. A static API key is typically a long-lived secret sitting in a config somewhere. A workload credential attested through SPIFFE is short-lived and cryptographically bound to the workload. Treating them as roughly equivalent because they all “authenticate the agent” is the kind of mistake that produces sprawl you will spend years cleaning up.
None of this is an argument for waiting. It is an argument for building deliberately, with the accountability gap held in view rather than assumed away.
Draw the distinction cleanly. A service account often uses a long-lived credential. A workload identity typically uses a short-lived, attested credential. The emerging non-human identity approaches worth building around are workload identity federation, SPIFFE SVIDs, and short-lived tokens. The direction of travel is away from the standing secret and toward an identity that exists only as long as the work does.
There is also the fan-out problem. A single agent may explode into dozens of downstream calls under one credential. If you provisioned that credential the way you provision a traditional shared service account, every one of those calls inherits more privilege than it needs.
What a Working Agent Access Pattern Looks Like
The hardest technical problem is not proving an agent is what it claims. It is representing what the agent is allowed to do on behalf of someone else.
Teams reach for service accounts because they already exist and the plumbing works. That instinct is exactly wrong here.
Consider what your logs actually show when an agent takes a destructive action three hops deep. They show the agent’s identity. They may not show the person whose intent set the chain in motion. The evidence you have at incident time points at a machine, and the machine cannot be held responsible.
The core principles still hold. Verify explicitly. Enforce least privilege. Assume breach. None of those are wrong, and none of them go away when autonomous agents enter the environment. What changes is the entity being verified. NIST SP 800-207, the Zero Trust Architecture publication, talks about subjects and access, including applications and other non-human entities. It does not have much to say about a subject that authenticates without a human present, spawns child processes, and takes destructive action three hops away from any person who could be held answerable.
Read that list as a system, not a menu. Short-lived scoped credentials, preserved delegation, per-action policy authorization, and chain-reconstructing logs each cover a weakness the others cannot. Scoped credentials limit blast radius. Preserved delegation keeps the human in the record. Per-action authorization moves the trust decision to where the context lives. Logging is what lets you answer the accountability question later, even imperfectly.
Where This Actually Stands
Be honest about the maturity here. Standards for agent identity are still forming. This is early, and anyone selling a settled solution is selling ahead of the field.
Hold two concepts apart, because collapsing them is how privilege leaks. Delegated authority means the agent carries a scoped, traceable token. Impersonation means the agent acts as the user without clearly preserving its separate identity. An agent acting on behalf of a user with a scoped token is not the same as an agent wearing the user’s entire identity, and any architecture that treats them as equivalent has already lost least privilege.
Zero Trust is not obsolete. Its identity layer is under-specified for non-human autonomous actors, which is a narrower and more actionable statement than declaring the whole model outdated. The principles survive. The subject definition already includes non-human entities, the delegation semantics need work, and the accountability mapping between a machine action and a responsible organization or person remains genuinely unsolved rather than merely unimplemented.
