MCP’s trust gap: agents hand off instructions they never verify

MCP’s trust gap: agents hand off instructions they never verify

by

On 6 October 2026 Ars Technica reported a four-month investigation in which the same class of bug — server-side request forgery (SSRF) in Model Context Protocol (MCP) servers — was independently confirmed and fixed at five organisations that share nothing but the protocol: Google, JPMorgan Chase, Weaviate, France’s interministerial digital directorate, and the Tangerang City government in Indonesia. For anyone working on Know Your Agent, it is a concrete example of a failure that is about authorization between agents, not about weak cryptography.

What happened

MCP servers expose tools that agents call with arguments. When some of those arguments are URLs, paths, or endpoints, and the server builds an outbound request from that value without checking where it actually resolves, the agent — not the server — decides what the server’s network identity talks to. Agents read untrusted content and act on it, so an attacker who can get text in front of an agent can steer the request.

Independent researcher Syed Anas Mohiuddin calls the resulting attack class “protocol pivoting”: initial access through one protocol (MCP), then exploitation of the trust assumptions between protocols — for example Google’s Agent-to-Agent (A2A) protocol, used for inter-agent delegation, or newer efforts such as the Agent Network Protocol — to escalate to capabilities reachable only through a different protocol. The reason it works is that MCP servers store credentials for each agent, and agents are built to trust other internal agents. A malicious prompt handed from one agent to the next is executed as a normal delegated task, and “authorization gets effectively lost in translation.”

The two published CVEs from the work:

  • CVE-2026-14540 (CVSS 8.0) — Google’s MCP Toolbox for Databases (`googleapis/mcp-toolbox`) initialised its HTTP client without a `CheckRedirect` policy and without validating target IP addresses, so a crafted path parameter could make the toolbox follow a redirect to an internal endpoint and issue requests on the attacker’s behalf. Google’s fix (PR #3448) applies IP-range allow/block lists and rejects an unsafe base URL at startup.
  • CVE-2026-97228 (CVSS 2.7) — a related bug in Rapid7’s environment, fixed and published in September 2026.

The researcher also filed issues in five MCP servers built for the US federal government; as of the update those were still in triage and are not presented as confirmed outcomes.

Why it matters for KYA

Know Your Agent is usually framed around credentials and signatures, but this pattern shows the other half of the problem: even a correctly identified agent is dangerous if the authority it delegates onward is trusted by default. Every link in the chain here “did exactly what it was designed to do” — which is what makes it hard to catch. That is the KYA failure mode in one sentence: presence of a request is treated as proof it was authorised.

The practical takeaways, in the researcher’s and Rapid7’s words:

  • Treat anything passed from an LLM to a tool as input from a stranger on the internet. It is.
  • Validate the destination, not just the request. Check resolved IP addresses at connection time so DNS rebinding cannot swap the target between check and use, and reject unsafe base URLs at startup.
  • Require authorization between agents. Do not let an internal agent’s instructions carry implicit authority into the next agent or protocol; delegation should narrow authority, never launder it.
  • Scope and rotate credentials per agent. MCP servers holding standing credentials for each agent turn one steered request into an authenticated action.
  • Log and redact at the MCP boundary. A second, quieter failure mode in the same research is upstream data written whole into centralised logs — ordinary errors are enough to leak it.

None of this is exotic; the underlying bugs are injection and SSRF, whose fixes have not changed in twenty years. What is new is that agents now supply the input and carry the credentials. The report is a reminder that for KYA the question is never only “which agent is this?” but “was this action authorised for this agent?”

Sources

Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.