An independent researcher, Syed Anas Mohiuddin, ran proof-of-concept attacks showing that a single compromised internal AI agent can hand malicious instructions to other agents over the Model Context Protocol (MCP). The attacks exploit trust gaps in the protocol, according to Ars Technica’s report and two outlets that restate it. The reporting is dated Oct. 5, 2026.
One caveat first. The sources available describe Mohiuddin’s work secondhand, and none links to a primary write-up, so the findings below are as reported, not independently confirmed.
What MCP is and where the trust gap sits
MCP is a standard that lets AI agents, meaning software that can take actions on a user’s behalf, reach tools and data through servers. In the agent-to-agent setup Mohiuddin tested, agents also pass requests to one another over the protocol.
According to the reporting, downstream agents explicitly trust upstream agents, and MCP servers store credentials for each agent. That combination means an exploit the underlying model would have rejected can still succeed.
The reported impact includes data exfiltration and server-side request forgery. Ars Technica describes the second as a vulnerability that makes a web server issue unauthorized network requests.
How the attack works, in plain terms
The technique is a form of prompt injection: text that smuggles instructions into content an AI system reads. In this case it targets a specific agent, such as a translation or data analysis agent, rather than the model itself.
Guardrails in those task-specific agents are often lax or absent, the reporting says. As a result, the instructions get relayed down the chain instead of stopping at the first hop.
The practical shift is that the weak point is no longer only the model. It is the assumption, built into how agents are wired together, that a message from another internal agent is safe to act on.
Who was tested
The reports say the tested agents were tied to Google, JP Morgan Chase, Weviate (one source spells it Weaviate), Rapid7, the French government’s interministerial digital directorate and the US federal government. Per the sources, each acknowledged vulnerabilities over about five months.
The sources do not detail what each organization changed in response, so readers should not assume fixes are in place.
A separate MCP flaw: the STDIO disclosure
A different problem in the same ecosystem should not be confused with Mohiuddin’s findings. On April 15, 2026, OX Security disclosed that Anthropic’s official MCP software development kits (SDKs) for Python, TypeScript, Java and Rust contain a STDIO design behavior. STDIO is the standard input and output channel a local process uses to communicate.
OX says the behavior enables arbitrary command execution on systems running vulnerable implementations. That is a flaw in how servers are launched, not in how agents trust one another.
OX Security reported a supply chain of more than 150 million downloads, more than 7,000 publicly accessible servers and up to 200,000 vulnerable instances. It also reported 10 or more High or Critical CVEs and more than 30 responsible disclosures.
Those figures are OX’s own and contested. The Cloud Security Alliance (CSA) note counts at least seven confirmed CVEs as of May 2026.
Anthropic reportedly declined to change the protocol architecture, calling the STDIO behavior expected and a secure default. It placed responsibility for sanitization on developers, and updated its SECURITY.md file to say STDIO adapters should be used with care. That account comes from the OX and CSA write-ups, not from an Anthropic statement in the material reviewed.
Gaps the specification itself leaves open
The CSA note says the MCP specification has no native defenses against tool poisoning, rug pulls or cross-server tool shadowing. Tool poisoning hides instructions in a tool’s description. A rug pull changes a tool’s behavior after a user has approved it.
Its authorization framework, OAuth 2.1, is optional. A July 2025 scan found 1,862 MCP servers answering unauthenticated requests, according to the CSA note.
What developers can do
For agent-to-agent risk, the advice in the reporting is to assume a compromised agent can reach anything its credentials allow. From there, audit and segment each agent’s permissions, and scrutinize agent-to-agent traffic the way you would user-to-server requests.
CSA goes further, advising teams to treat every MCP server as an untrusted third party and apply zero trust controls. Zero trust means no request is trusted by default, whatever its origin inside the network.
For the STDIO issue, OX Security’s list is more concrete:
- Do not expose sensitive services to the public internet.
- Treat external MCP configuration input as untrusted.
- Use only verified MCP registries.
- Sandbox MCP services.
- Monitor tool invocations.
- Update to patched versions.
Why it matters
Agents that implicitly trust each other and hold broad credentials turn one prompt injection into internal lateral movement, the term for an intruder hopping from one system to the next. Perimeter defenses do not stop it, because the malicious instruction arrives from inside.
The two disputes also show a split over who owns the fix. Anthropic, as reported, treats sanitization as the developer’s job, while researchers argue the specification leaves too much undefended.
What to watch
Three things would clarify the picture: a primary write-up of Mohiuddin’s work that can be checked, confirmation from the named organizations on what they changed, and any movement on making authorization or agent-to-agent trust controls part of the MCP specification. None of those appears in the sources reviewed.
Join the discussion