Why Agent Identity Needs More Than OAuth Delegation

In September 2025, a compromised GitHub Copilot coding agent injected a malicious configuration change into a connected Claude Code session, according to a security vendor’s incident writeup published the following year. Two months later, a research-assistant agent, manipulated through content it had been asked to summarize, steered a financial-assistant agent it was connected to into placing unauthorized trades.

No human approved either action in the moment. Both agents held valid, correctly-issued credentials the whole time. OAuth 2.0 was built for a browser, a person, and one visually-confirmed consent click. An agent runs unattended, calls other agents that call other services, and delegates in chains no single consent screen ever covers.

Where the old model runs out

OAuth’s delegation primitive is token exchange, defined in RFC 8693. One actor trades a subject token for a new token, optionally carrying an act claim naming who is acting on whose behalf. It works for one hop. It was not built for the chain human, agent A, agent B, service C.

• The RFC says so directly. A token consumer checks only the top-level claims. It never walks the chain a token traveled.
• Earlier hops turn informational. A downstream service cannot verify or enforce anything that happened before the most recent hand-off.
• Natural language hides the caller. A tool call phrased in text carries no caller identity the way a typed API call does. A manipulated agent can spend permissions that belonged to a different task entirely.

That is the confused deputy problem again: the model acts as both the reasoning engine and the authorization boundary. The two 2025 incidents above show that failure mode running in production.

Six primitives already exist

Teams building agent identity today are not starting from zero. Six OAuth-adjacent primitives already cover most of the mechanics, and identity platforms are wiring them together specifically for agents:

• On-behalf-of (OBO). Tracks delegation when an agent acts for a human or for another agent.
• Token exchange. RFC 8693 moves identity and trust across clouds, APIs, and trust domains.
• DPoP. Binds an access token to a cryptographic key. A stolen token stops working the moment it leaves the key that issued it.
• PKCE. Runs an authorization flow without a stored client secret an attacker could later extract.
• CAEP. Reevaluates or revokes access the moment risk conditions change, instead of waiting for a token to expire on its own.
• Attribute-based authorization. Decides access on claims like user, agent, purpose, task, and context, not on a flat scope string.

Stacked together, those six primitives answer most of the mechanical questions: who issued this token, what key does it require, how fast can it die. None of them answer the harder question a multi-agent chain raises: what was this token actually for, and does that purpose still hold three hops later.

What is actually shipping to close the rest

• MCP moved fastest. Its 2025-06-18 revision reclassified Model Context Protocol servers as resource servers only, ending the earlier setup where a server could act as both authorization server and resource server for the same request.
• Resource indicators became mandatory. RFC 8707 now binds a token to the one server it was issued for. That closes the specific confused-deputy hole and blocks token passthrough. The spec still changes every quarter.
• Agent-to-agent auth trails behind. Google’s A2A protocol, under the Linux Foundation since mid-2025, reached v1.0 in March 2026 with signed Agent Cards, but it leaves credential acquisition out of scope on purpose.
• The closest IETF draft to standardization is not agent-specific. draft-ietf-oauth-identity-chaining sits in the RFC Editor queue as a general cross-domain token-exchange mechanism. It punts on actor chains explicitly.
• Everything agent-specific stays fragmented. More than a dozen competing individual drafts, from cloud vendors and enterprise identity teams alike, each carry a hop count, an immutable originator, or a cryptographically-linked chain of narrowing permissions their own way. None has working-group consensus.

Where OAuth still has to change

Highly autonomous agents will keep outrunning what token exchange and the six primitives above were designed to handle. Five gaps stand out:

• Delegation chains need to be inspectable, not just chained. A reviewer should read who authorized what, at every hop, without reconstructing it from side logs.
• Tokens need to carry task purpose and intent, not only scope. A scope says an agent can call an API. It says nothing about why, on this task, right now.
• Revocation needs to happen in near real time. A token that stays valid for minutes after a compromise is detected is a token that already did the damage.
• Issuance needs to run at machine speed. Human-consent-paced flows do not scale to an agent that spins up sub-agents for a single task and tears them down seconds later.
• Multi-agent coordination needs a shared delegation model. Point-to-point patches between two agents do not compose once a task touches five.

What teams should do now

The draft landscape will not consolidate before your next agent ships. Build for delegation with what already exists, and track the rest as a moving target.

• Inventory agent credentials as their own class. A service account issued to an agent carries different risk than one issued to a cron job. Track which agents hold which tokens, issued for what task, for how long.
• Prefer short-lived, narrowly-scoped tokens over standing credentials. If your identity provider supports token exchange or an equivalent narrowing step per task, use it instead of handing an agent one broad, long-lived grant.
• If you run MCP servers, adopt the 2025-06-18 authorization revision or later. Resource-indicator binding alone closes the confused-deputy pattern the earlier spec left open.
• Do not treat a valid token as proof of correct intent. Both 2025 incidents involved agents that were fully authorized and still did the wrong thing. The compromise happened upstream of the credential, in the content the agent was manipulated by.
• Watch identity and enforce independently. A credential answers who an agent is allowed to act as. It says nothing about whether one specific tool call, in one specific session, with untrusted input already in context, should be allowed to happen. Prismor’s open-source runtime enforces that second question at the tool-call boundary itself, session-aware, so a correctly-authenticated agent still gets stopped from turning a summarization task into a trade order.

Agent identity will keep changing under you for years. Build the inventory and the runtime enforcement now, and whichever standard eventually wins becomes one more input to a system you already trust, not the only thing standing between a manipulated agent and the account it holds a token for.