Why agent-to-agent chains need per-hop delegated tokens

Independent researcher Syed Anas Mohiuddin found the same server-side request forgery (SSRF) flaw in MCP servers run by Google, JPMorgan Chase, Weaviate, France's interministerial digital directorate and the city government of Tangerang, Indonesia, and all five fixed it, with Google's flaw tracked as CVE-2026-14540 and rated 8.0, affecting MCP Toolbox for Databases 0.3.0 to 1.4.0. Mohiuddin also described a wider "protocol pivoting" attack in which text planted in an MCP tool's output is shaped as a task for Google's A2A protocol and executed by a subagent that trusts its orchestrator. The analysis argues agent chains should issue a narrow, audience-bound OAuth delegated token at every hop instead of passing one shared long-lived credential, so a manipulated hop's blast radius is limited and actions stay attributable and revocable.

Why agent-to-agent chains need per-hop delegated tokens Shared credentials turn one manipulated agent into a compromised chain. Narrow, audience-bound tokens at every hop shrink the blast radius. Earlier this month, independent researcher Syed Anas Mohiuddin's work drew attention to how easily trust spreads through agent networks. He found the same SSRF flaw in MCP servers run by Google, JPMorgan Chase, Weaviate, France's interministerial digital directorate and the city government of Tangerang, Indonesia, and all five fixed it The Next Web https://thenextweb.com/news/mcp-flaw-ssrf-google-jpmorgan-dinum-protocol-pivoting . Google's flaw, CVE-2026-14540, was rated 8.0 and affected MCP Toolbox for Databases 0.3.0 to 1.4.0: the HTTP client had no restrictive redirect policy and no check on target IP addresses. Mohiuddin also describes a wider attack he calls protocol pivoting. An attacker plants text in content an MCP tool returns, shaped like a task for Google's A2A protocol. In The Next Web's words, "An orchestrating agent passes it to a subagent, which runs it because it trusts the orchestrator." Rapid7's Douglas McKee described the structural problem this way: "Every piece in that chain did exactly what it was designed to do, which is what makes this so tricky to catch." That research is about request forgery and trust between agents, not about stolen credentials. But it shows the shape of the problem authorization has to answer. When one hop has been manipulated, what is it still allowed to do? This post is about how to shrink that answer. The pattern that makes chains dangerous A common setup, and one to avoid, hands every hop the same long-lived credential, often held by the MCP server. This is an architecture pattern, not a finding of the research above. It causes three problems. This is a confused deputy problem in the general sense: a component with broad authority is tricked into using it on someone else's behalf. It is related to, but distinct from, the specific proxy-consent attack the MCP security guidance calls the confused deputy problem, which involves static client IDs, dynamic client registration and consent cookies. Agent chains make the general version worse because the chain is longer, the deputies follow natural-language instructions, and nobody watches the middle hops. The fix: authority that narrows at every hop Stop passing one credential down the chain. Give each hop its own token, issued for that hop, scoped as narrowly as possible, and carrying the identity of everyone upstream. OAuth already has the pieces. This is a recipe built from existing standards, not a new one. Note that the MCP authorization spec does not prescribe token exchange for downstream calls; it forbids passthrough and requires audience validation, and token exchange is the standard OAuth way to get a token for another resource without passing one through. Before and after What this does and doesn't buy you It does not stop prompt injection. A manipulated agent will still try the wrong thing. What changes is the blast radius. It does not fix SSRF. Google's fix added a DNS rebinding guard and allowed and blocked IP range lists. The MCP security guidance recommends the same class of control for OAuth URL fetching: block private and reserved IP ranges, validate redirect targets, and consider an egress proxy. Delegated tokens complement these controls and do not replace them. It does give you: - Least privilege that holds under compromise: each hop has only what it was explicitly granted. - Attributable actions: the final API sees the full chain. - A handle for revocation: revoke one user's or one agent's delegation without rotating a shared secret. - Policy at the boundary, for example "Agent B may never request billing scopes on behalf of any user." What to do this quarter - Inventory your chains. List every MCP server and agent-to-agent path, including vendor-managed ones. - Find the shared credentials. Any long-lived secret reachable by more than one agent is your biggest exposure. - M ove to exchange, not passthrough. Servers obtain downstream tokens through token exchange, scoped to the specific call. - Bind audiences and shorten lifetimes. One token, one resource, minutes not days. - Log the delegation chain. If logs cannot show user, agent, agent, resource, you cannot investigate an incident. - Gate sensitive actions explicitly. High-risk calls between agents need their own authorization decision, not trust inherited from position in the chain. Where WorkOS fits WorkOS applies the same principles, with different mechanisms than a general RFC 8693 exchange between hops. AuthKit as the authorization server for your MCP server. AuthKit issues access tokens with an aud claim that matches the requested resource , so a token is minted for one MCP server and not reusable at another. It supports Client ID Metadata Documents off by default, and recommended and Dynamic Client Registration for clients that don't support them yet. See the AuthKit MCP docs https://workos.com/docs/authkit/mcp . Agent Auth for delegated chains. In a delegated session, the agent acts on behalf of a specific user. An agent can present its own access token to mint a child session, and each hop re-derives permissions from current authority instead of trusting the token it was handed. Access tokens last at most one hour, and revoking a session also revokes every session chained under it. The act claim on a delegated session identifies the delegating user. It does not list every intermediate hop, and chaining uses Agent Auth's own minting API, not RFC 8693 token exchange. Agent Auth must be enabled for your environment, so contact your WorkOS account team. See the Agent Auth docs https://workos.com/docs/authkit/agent-blueprints . Keeping provider credentials out of the agent. For third-party APIs, Relay routes the agent's calls through WorkOS, which attaches the provider credential at that boundary and refreshes it, so the agent does not handle the provider token. See Keeping credentials out of an AI agent's context with Relay https://workos.com/blog/credentials-out-of-agent-context . For the on-behalf-of basics, see OAuth on-behalf-of for AI agents https://workos.com/blog/oauth-on-behalf-of-ai-agents . The takeaway The lesson is not that agent networks are hopeless. "Trusted because internal" is no longer a defensible authorization model when the things inside your network follow instructions from untrusted text. Agents need identities of their own, delegated and narrowed at every hop, so one manipulated agent cannot spend the whole chain's authority.