{"slug": "why-agent-to-agent-chains-need-per-hop-delegated-tokens", "title": "Why agent-to-agent chains need per-hop delegated tokens", "summary": "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.", "body_md": "# Why agent-to-agent chains need per-hop delegated tokens\n\nShared credentials turn one manipulated agent into a compromised chain. Narrow, audience-bound tokens at every hop shrink the blast radius.\n\nEarlier 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.\n\nMohiuddin 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.\"\n\nThat 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.\n\n## The pattern that makes chains dangerous\n\nA 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.\n\nIt causes three problems.\n\nThis 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.\n\n## The fix: authority that narrows at every hop\n\nStop 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.\n\nOAuth 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.\n\n### Before and after\n\n## What this does and doesn't buy you\n\n**It does not stop prompt injection.** A manipulated agent will still try the wrong thing. What changes is the blast radius.\n\n**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.\n\n**It does give you:**\n\n- Least privilege that holds under compromise: each hop has only what it was explicitly granted.\n- Attributable actions: the final API sees the full chain.\n- A handle for revocation: revoke one user's or one agent's delegation without rotating a shared secret.\n- Policy at the boundary, for example \"Agent B may never request billing scopes on behalf of any user.\"\n\n## What to do this quarter\n\n- **Inventory your chains.** List every MCP server and agent-to-agent path, including vendor-managed ones.\n- **Find the shared credentials.** Any long-lived secret reachable by more than one agent is your biggest exposure.\n- M**ove to exchange, not passthrough.** Servers obtain downstream tokens through token exchange, scoped to the specific call.\n- **Bind audiences and shorten lifetimes.** One token, one resource, minutes not days.\n- **Log the delegation chain.** If logs cannot show user, agent, agent, resource, you cannot investigate an incident.\n- **Gate sensitive actions explicitly.** High-risk calls between agents need their own authorization decision, not trust inherited from position in the chain.\n\n## Where WorkOS fits\n\nWorkOS applies the same principles, with different mechanisms than a general RFC 8693 exchange between hops.\n\n**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).\n\n**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).\n\n**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).\n\n## The takeaway\n\nThe 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.", "url": "https://wpnews.pro/news/why-agent-to-agent-chains-need-per-hop-delegated-tokens", "canonical_source": "https://workos.com/blog/agent-to-agent-delegated-tokens", "published_at": "2026-10-29 00:00:00+00:00", "updated_at": "2026-10-29 18:18:39.137294+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "agent-protocols", "ai-tools"], "entities": ["Syed Anas Mohiuddin", "Google", "JPMorgan Chase", "Weaviate", "MCP Toolbox for Databases", "CVE-2026-14540", "Google A2A", "Douglas McKee"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/why-agent-to-agent-chains-need-per-hop-delegated-tokens", "markdown": "https://wpnews.pro/news/why-agent-to-agent-chains-need-per-hop-delegated-tokens.md", "text": "https://wpnews.pro/news/why-agent-to-agent-chains-need-per-hop-delegated-tokens.txt", "jsonld": "https://wpnews.pro/news/why-agent-to-agent-chains-need-per-hop-delegated-tokens.jsonld"}}