A compromised AI agent doesn't need to break into a database: it can simply ask a digital colleague to do it on its behalf. That is the picture emerging from tests by independent researcher Syed Anas Mohiuddin, who examined behavior of agents used by Google, JP Morgan Chase, Weviate, Rapid7, the French government's interministerial digital directorate, and the US federal government. In the past five months, Google and four other organizations have acknowledged vulnerabilities that allow an agent inside a network to spread malicious instructions to other internal agents.

At the center is the Model Context Protocol, or MCP, a standard that defines how AI applications and agents exchange information and tools within a perimeter. The technique described is a particular form of prompt injection: it doesn't target the LLM itself, but a specific agent, such as one for translation or data analysis. If that agent's guardrails are weak or absent, the instruction is passed downstream. The next agent explicitly trusts the first one and follows the directions.

The structural problem isn't a single flaw, but the transitive trust model that MCP tends to enable. In many implementations, the identity of the sending agent is treated as a guarantee of reliability even when the message content comes from an untrusted source. Yet an agent can be authenticated and, at the same time, process text arriving from an email, a document, or an external web page. The separation between agent identity and message content becomes the real boundary to defend. Protections, when they exist, are often permissive: overly restricting an agent's actions reduces the perceived usefulness of the entire flow. So a data analysis agent can pass a request to the agent managing the database, and the latter executes it because the sender appears in the list of allowed tools.

For organizations running on-premise or self-hosted deployments, the risk doesn't disappear with simple network isolation. Agents live inside the perimeter, access corporate data, and have operational tools. Malicious content doesn't necessarily have to arrive from the outside: it can enter as unstructured data and become an instruction only after being interpreted by an agent. This shifts attention from protecting individual endpoints to controlling the flows between agent and agent. It's a change of perspective compared to traditional architectures, where internal service-to-service communications are often considered less risky than those exposed publicly. The point is not the physical location of the servers, but the degree of trust between components. For those evaluating on-premise deployments, there are trade-offs between control, complexity, and attack surface; AI-RADAR offers analytical frameworks on /llm-onpremise to weigh them.

The timeline is a strong signal. The fact that heterogeneous organizations acknowledged vulnerabilities in the same span of months indicates the problem doesn't stem from an isolated implementation, but from an overly trusting posture toward the protocol. Security teams accustomed to reasoning in terms of authentication and authorization must now ask what an agent can do with the instructions it receives, not just who sent them. MCP platform vendors will likely be pushed to introduce preview mechanisms, context signing, or stricter execution boundaries. In the short term, attackers gain: they obtain an internal path for exfiltration without compromising the network further. Organizations that continue to treat agents as simple endpoints, rather than actors with effective privileges over data, lose.

Mohiuddin's research, ultimately, offers an essential reminder: when an AI agent trusts another agent, it has already crossed the most difficult barrier to defend — implicit trust.