The hardest unsolved problem in AI agent security right now is not prompt injection or tool poisoning. It is a question that sounds like it should already have an answer: when an agent does something, can you prove which human authorized it? For a single hop, yes. OAuth 2.0 was built for exactly that case, and it works. The moment one agent delegates to another, and that one to a third, the cryptographic chain that ties the action back to a person comes apart. No protocol deployed today can prove, at the third or fourth hop of a delegation chain, that a specific human authorized a specific agent to take a specific action.
This is the anchor problem, and it is the reason agent identity has become the focus of standards work at the IETF, NIST, OWASP, and the Cloud Security Alliance all at once in 2026. An April 2026 survey of AI identity standards stated the failure plainly: OAuth and its extensions handle one-hop delegation well, but once delegation becomes recursive, the authorization chain loses its anchor. Determining which human principal bears responsibility for a delegated action, what the survey calls the multi-principal problem, remains unsolved.
The reason this matters now is that agents stopped being one-shot. They run for hours, spawn sub-agents, and call other agents as tools. Non-human identities already outnumber human identities in enterprise environments by ratios reported as high as 144 to 1. Every one of those machine identities can be granted authority, and every grant that cannot be traced back to a consenting human is an accountability gap and an attack surface. This piece explains the mechanism that breaks, what each competing 2026 standard can and cannot anchor, and why the honest answer to the central question is still no.
Why one hop works
Start with the case that is solved, because the failure only makes sense against it. In standard OAuth 2.0, a user grants a client scoped access to a resource. The user authenticates at an authorization server, consents to a specific scope, and the server issues the client an access token. When the client calls the resource server, the resource server validates the token and checks that its scope covers the request. The accountability is clean because three things are bound together: the user’s identity, the specific scope they consented to, and the client that received the grant. The resource server can verify all three from the token.
The Model Context Protocol, which standardizes how agents connect to tools and data, adopted this model for its HTTP transport in January 2026. The MCP profile mandates Proof Key for Code Exchange, the PKCE extension that stops an intercepted authorization code from being redeemed by an attacker, and it uses resource indicators so a token issued for one server cannot be replayed against another. For an agent acting directly on a user’s behalf against a single tool, this is solid. The token says who the user is, what they allowed, and which agent and which resource it is good for. Concretely, the access token, usually a signed JSON Web Token, carries claims a resource server can verify without calling anyone: a sub identifying the principal, a scope listing the granted permissions, an aud naming the intended resource, and an exp bounding its lifetime. The signature is the point. The resource server trusts these claims because the authorization server signed them, not because it trusts whoever presented the token. That one signed object is the anchor, and it is what the one-hop case gets right. Hold it in mind, because almost none of it survives the second hop.
What breaks at the second hop, and worse at the third
Now give the agent a sub-agent. Agent A is acting for user U. To finish its task, A needs Agent B to do a piece of work. A has two options, and both lose something.
The first option is to hand B its own token. B now presents U’s token to the resource server, which cannot tell B from A. The user’s context is preserved in the sense that the token still names U, but the distinction between the two agents is erased, and a stolen token is a full compromise of everything it can reach. This is impersonation, and it is what happens by default when developers pass credentials down a chain because it is the path of least resistance.
The second option is to mint a new token for B. OAuth has a mechanism for this, token exchange, defined in RFC 8693. It lets an authorization server issue a new token that carries actor claims, an act claim naming the current actor and a may_act claim describing who is permitted to act for whom. In principle this builds a delegation record: the token for B can say it is acting on behalf of A, which is acting on behalf of U. In practice the chain is a set of claims asserted and re-minted by intermediaries against policy, not a cryptographic proof that U consented to this particular delegation for this particular action. The authorization server issues the new token because policy allows it, not because U approved B touching this resource. At the second hop the record is still close to the user. At the third and fourth hop, the may_act chain is a list of assertions made by software, each trusting the one before it, with no element that cryptographically binds the whole sequence back to U’s original, specific consent.
That is the anchor loss, stated mechanically. Delegation semantics exist. What does not exist, in any deployed system, is a way to take an action at hop four and produce cryptographic evidence that the human at hop zero authorized exactly that. The chain degrades from proof to hearsay one link at a time.
Make it concrete. A user tells a coordinator agent to arrange a trip. The coordinator delegates flight search to a travel agent, which delegates the purchase to a payment agent, which calls the card network’s API. At the moment of purchase, four parties are in the chain and only the first is human. If the payment agent simply carried a token passed down the chain, the card API sees the coordinator’s identity, or the user’s, and cannot tell that a payment agent two hops removed initiated the charge. If instead each hop minted a fresh token with actor claims, the final token asserts a lineage back to the user, but nothing in it proves the user agreed to this specific amount, to this specific merchant, through this specific sub-agent. The user authorized arrange a trip. The system executed charge this card, and the distance between those two instructions is filled by software trusting software. When the charge is disputed, the record shows a sequence of delegations, each individually plausible, none of them a signed statement from the user approving the transaction that actually occurred.
This also resurrects the confused deputy, the classic vulnerability where a program with standing permissions is tricked into using them for someone else’s benefit. Per-user, per-scope OAuth delegation is the recommended fix for the one-hop confused deputy, and it works there. Recursion reintroduces the problem because a sub-agent inherits authority without re-binding it to the user’s intent. An agent three hops down, holding broad delegated scope, is a deputy waiting to be confused, and the cross-user data exfiltration that follows is the most common way agent systems leak.
What the workload-identity layer does and does not solve
A lot of the 2026 standards work leans on giving agents strong cryptographic identities. SPIFFE, with its SPIRE implementation, issues workloads short-lived cryptographic identity documents, and the Workload Identity in Multi-System Environments architecture, WIMSE, generalizes this across systems. These are real and useful. They answer the question is this actually Agent B with a cryptographic yes, replacing long-lived secrets with attested, rotating identities.
But workload identity answers a different question than authorization provenance. Knowing with certainty that a request comes from Agent B does not tell you whether human U authorized Agent B to act, or whether the authority B holds was legitimately delegated through A for this purpose. SPIFFE proves the runner. It does not prove the mandate. The IETF Internet-Draft on AI agent authentication and authorization, draft-klrc-aiagent-auth, authored by contributors from Defakto, AWS, Zscaler, Ping Identity, and OpenAI and updated in March 2026, is explicit that it is composing existing standards, WIMSE, SPIFFE, OAuth, and OpenID, rather than inventing new ones. It defines an Agent Identity Management System as a conceptual model and introduces dual-identity credentials that bind an agent to its human or organizational owner through three delegation flows it calls Agent-Mediate, Owner-Mediate, and Server-Mediate, each meant to produce an auditable chain back to a human principal.
Read that carefully. The draft produces an auditable chain, which is an audit trail you can inspect after the fact. It is not the same as a cryptographic proof that constrains what a downstream agent can do and binds each hop to the original consent before the action happens. The draft itself carries a notice that it is not endorsed by the IETF and has no formal standing in the standards process. It is the most developed proposal on the table, and it is still a proposal that documents the gap as much as it closes it.
Why it matters past the spec sheet
The practical stakes are accountability, security, and deployment. On accountability, the entire point of an authorization system in a regulated enterprise is that you can answer who approved this when something goes wrong. If an agent at the end of a delegation chain deletes records, moves money, or exposes data, and the chain back to a responsible human is a set of software assertions rather than provable consent, the audit fails at the moment it is needed. The same agentic systems whose oversight and liability questions are already being argued in front of regulators are running on an identity substrate that cannot yet support the accountability those regulators will demand.
On security, the anchor problem is a direct enabler of the most serious agent risks. The OWASP Top 10 for Agentic Applications, published in 2026, lists Identity and Privilege Abuse alongside Agent Goal Hijack and Tool Misuse, and the companion OWASP MCP Top 10 covers protocol-specific risks like model misbinding and context spoofing. A delegation chain that cannot prove its provenance is exactly where privilege abuse hides, because a sub-agent’s over-broad inherited scope looks, to the resource server, indistinguishable from legitimate authority.
On deployment, this is what is holding enterprises back. The same credential sprawl and access-control problems that plagued traditional IT now arrive at machine speed and machine scale, with non-human identities multiplying faster than anyone can govern them. Until the delegation question has an answer that survives audit, cautious organizations cap agent autonomy precisely where it would be most useful, at multi-step, multi-agent workflows that cross system boundaries. The agents that real work needs are the agents the identity gap most directly blocks. This is the same tension visible in how browser-resident agents expose structured tools to the page: capability is shipping faster than the controls that would make it safe to use widely.
The honest limits, including of the fixes
The strongest version of this story names what the proposed solutions cannot do, not just what today’s deployments lack.
The multi-principal attribution problem is unsolved at a definitional level, not merely an engineering backlog. The April 2026 survey notes that Know Your Agent frameworks, the most developed identity-lifecycle approach, fail here directly. Once Agent A has been assessed and credentialed, KYA gives no mechanism to constrain what Agent B does when A delegates to it, and no way to determine which human principal bears responsibility at depth. The Cloud Security Alliance’s October 2025 Addendum on Securing Agentic AI treats this as serious enough to designate identity spoofing and impersonation as a named threat, T9, and to recommend a trusted agent registry, verifiable credentials, short-lived OAuth and OIDC tokens, and an outright prohibition on cross-agent privilege delegation unless it is explicitly authorized. Notice the shape of that last recommendation. The safest current advice is to forbid the recursive delegation that the protocols cannot yet secure, which is a workaround dressed as a control.
The most-discussed cryptographic fix is to make each delegation a signed, verifiable statement rather than a policy decision. In this model the user issues a signed credential authorizing Agent A for a scope, A issues a further signed credential to B, and so on, so the chain becomes a sequence of verifiable signatures an auditor can check end to end. Verifiable credentials and signed delegation tokens move in this direction, and they are a real improvement over re-minted bearer tokens. They still fall short of the hard guarantee, for two reasons. The first is granularity. A credential that authorizes a scope is not consent to a specific action, so unless the user signs at the level of each consequential operation, which no usable system asks them to do, the chain proves authority over a category, not approval of the act. The second is revocation and freshness. A signed delegation issued an hour ago may have been revoked since, and checking revocation at every hop reintroduces the central dependency that signatures were meant to remove. A chain of signatures proves who delegated what to whom. It does not, on its own, prove the delegation was still valid and still intended at the instant the action fired.
Fragmentation is the second limit. Agent identity proposals are arriving from several directions at once, OAuth extensions, SPIFFE and WIMSE, the MCP profile, vendor systems that extend existing cloud identity, and governance frameworks like Singapore’s IMDA Model Governance Framework for Agentic AI launched at Davos in January 2026. Each is reasonable in isolation. Together they do not yet compose into one model an auditor or a resource server can rely on, and competing partial standards can be worse than none, because they create the appearance of a solution without interoperable substance.
The vendor approach makes the tradeoff visible. Rather than wait for an open standard, some platforms extend the cloud identity systems enterprises already run, adding agent-specific concepts like task-scoped permissions that expire when a workflow finishes and delegation records that track which agent authorized which other agent. Building on existing identity infrastructure is pragmatic and ships today. The cost is that the resulting accountability lives inside one vendor’s control plane. An agent operating across two clouds, or calling a tool outside the vendor’s perimeter, leaves the model in which the delegation can be reasoned about at all. Cross-boundary delegation, which is precisely the multi-agent case that motivates the whole effort, is where single-vendor solutions stop and the unsolved problem resumes.
Third, even the cleanest proposals stop short of the hard guarantee. A research direction described in a 2026 paper on deterministic pre-action authorization argues for checking an agent’s authority before the tool call rather than after, which is the right instinct. But pre-action checks still depend on the authorization state being correct, and the open question is precisely how that state proves a multi-hop mandate. Moving the check earlier does not by itself anchor the chain.
Fourth, none of this is settled enough to build against with confidence. The IETF draft has no standing. The NIST work is at the concept and demonstration stage. The OWASP lists are risk taxonomies, not protocols. Anyone claiming a finished answer to agent delegation in 2026 is selling the appearance of one.
What happens next
The most concrete near-term work is at NIST. In February 2026 its Center for AI Standards and Innovation announced an AI Agent Standards Initiative, structured around industry-led standards, community protocol development, and government research into agent authentication and identity. Its first deliverable, a concept paper titled Accelerating the Adoption of Software and AI Agent Identity and Authorization, asked a deliberately practical question, whether enterprises can use existing identity standards for agents or need to reinvent them, and its public comment period closed on April 2, 2026. The follow-on is a demonstration in the National Cybersecurity Center of Excellence labs using commercially available technology, which is where abstract delegation models meet implementations that either compose or do not.
In parallel, baseline security efforts are consolidating. SAFE-MCP, adopted by the Linux Foundation and the OpenID Foundation, aims to give MCP-enabled systems a common security floor, and the OWASP agentic and MCP lists give builders a shared vocabulary for the risks. None of these resolves the anchor problem. What they do is narrow the space of acceptable answers and force the competing identity proposals toward interoperability.
The realistic outcome for the next year is not a protocol that cryptographically proves a four-hop mandate. It is a combination of partial measures: short-lived credentials so a leaked token expires fast, agent registries so unknown agents are rejected, workload identity so the runner is always known, token-exchange actor claims so a delegation chain is at least recorded, and policy that simply forbids recursion where the stakes are high. That is defense in depth around a gap, not a closure of it. The closure, a way to take any action by any agent and produce proof that a named human authorized exactly that, is still a research problem. The agents are already shipping. The thing that would let you hold a person accountable for what they do is not. Until it is, the prudent assumption is that beyond the first hop, your agents are acting on authority no one can fully prove they were given. The systems that increasingly act on our behalf, including the ones whose misbehavior is now being catalogued in the wild, are running ahead of the one mechanism that would make them answerable.