MCP Vulnerability: How AI Agent Trust Enables Attacks

The MCP vulnerability: how malicious instructions can spread between agents

The reported attack pattern begins with an attacker targeting one agent, potentially through indirect prompt injection. Malicious instructions may be placed in content that the agent is expected to process, such as a document, message, webpage, or database record.

If that agent passes the instructions to another agent through an MCP-connected workflow, the second system may treat them as trusted operational context rather than hostile input. The attack can then move from agent to agent - a specialized form of agent-to-agent prompt injection.

This malicious prompt propagation does not require every agent to be independently compromised. One manipulated agent may be enough to influence downstream systems, especially when agents share tools, credentials, or access to internal data.

Independent researcher Syed Anas Mohiuddin reportedly examined systems associated with Google, JPMorgan Chase, Weaviate, Rapid7, France's interministerial digital directorate, and the US federal government. The organizations represent different environments, but the reported concern is broader than any one vendor: implicit trust between connected agents can create a repeatable security weakness.

Why implicit agent-to-agent trust creates a wider security risk

Traditional application security assumes that systems can distinguish trusted services from untrusted input through identity, authorization, and validation controls. AI agents complicate that model because instructions and data often arrive in the same natural-language channel.

An agent may receive a message that looks like a legitimate request from another agent, while having limited ability to determine whether it reflects an authorized task, an injected instruction, or a compromised workflow. If the receiving agent accepts the message automatically, the network's trust model can turn one local attack into a broader compromise.

The risk increases when agents have broad permissions or when a single orchestration layer can call multiple services. A prompt injection that would otherwise affect one agent may instead spread across an entire workflow, increasing the blast radius and making the source of the action harder to identify.

This is why conventional guardrails may not be enough. Telling an agent to ignore malicious instructions does not establish a reliable security boundary. The system must also verify the sender, validate the instruction's provenance, and determine whether the requested action is authorized.

How organizations can reduce MCP security risks now

Organizations using MCP-connected agents should treat every agent message as untrusted input, even when it comes from an internal system. Immediate controls include:

• Verify provenance: Record which agent created each instruction and preserve the original context. Do not assume that internal messages are safe.
• Enforce agent-to-agent authorization: Require explicit identity and permission checks before one agent can direct another or access its tools.
• Restrict permissions: Apply least-privilege access to tools, databases, files, and outbound communication channels. Separate read and write capabilities wherever possible.
• Validate intent: Use policy checks to distinguish data from instructions and to block requests that fall outside the workflow's approved purpose.
• Require human approval: Add review before high-impact actions such as external data transfers, financial operations, account changes, or deletion of records.
• Monitor propagation: Log agent-to-agent messages and investigate unusual chains of requests, repeated refusals, or unexpected access patterns.

The immediate lesson from this MCP vulnerability is straightforward: an agent network is not automatically trustworthy because its participants are operated by the same organization. As autonomous workflows expand, communication, identity, authorization, and data-access boundaries must expand with them.

Audit every MCP-connected agent as an untrusted external actor. Verify message provenance, enforce agent-to-agent authorization, restrict tool and data permissions, and require human approval for high-impact actions.

Step-by-Step Guide

1. 1

   Treat agent messages as untrusted input

   Process every MCP instruction as potentially hostile, including messages from internal agents, and separate data from executable instructions.

2. 2

   Verify instruction provenance

   Record the originating agent, preserve relevant context, and validate that the message has not been altered or detached from its approved workflow.

3. 3

   Enforce agent-to-agent authorization

   Require authenticated identity checks and explicit permissions before one agent can direct another, access tools, or retrieve protected data.

4. 4

   Apply least-privilege access

   Limit each agent to the tools, databases, files, and communication channels required for its task, while separating read and write capabilities.

5. 5

   Validate intent and require approval

   Use policy checks to confirm that requested actions match the approved purpose, and require human review for external transfers, financial actions, account changes, and deletion.

6. 6

   Monitor message propagation

   Log agent-to-agent requests and investigate unusual chains, repeated refusals, unexpected tool calls, and abnormal data-access patterns.

Key Statistics

• The reported examination covered systems associated with six organizations: Google, JPMorgan Chase, Weaviate, Rapid7, France's interministerial digital directorate, and the US federal government.Attribution context: the article identifies independent researcher Syed Anas Mohiuddin as the reported examiner and presents the finding as a cross-environment security concern, not a vendor-specific defect.
• The article identifies six immediate defensive controls: provenance verification, agent-to-agent authorization, least-privilege access, intent validation, human approval, and propagation monitoring.Attribution context: these controls are derived from the article's recommended mitigation checklist for MCP-connected agent workflows.
• The reported attack pattern requires only one manipulated agent to potentially influence downstream systems in a connected workflow.Attribution context: the article describes this as a potential consequence of implicit trust, shared tools, shared credentials, and broad orchestration permissions rather than as a measured incident rate.

Frequently Asked Questions