AI Security Second Brain

Insecure Inter-Agent Protocol Abuse (T16)

Properties1
descriptionAttacks against MCP and A2A themselves — consent bypass, context hijacking via response injection, and tool-description exploitation. Added in v1.1 and the vault's primary MCP security page.

5 min read

⭐ Star on GitHub

Summary: Attacks against MCP and A2A themselves — consent bypass, context hijacking via response injection, and tool-description exploitation. Added in v1.1 and the vault’s primary MCP security page.

Sources: raw/Agentic/Agentic-AI-Threats-and-Mitigations-1.1.pdf

Last updated: 2026-07-29

New in v1.1

T16 does not appear in the February 2025 release. Its addition, alongside T17, is the substantive change in the December 2025 revision — and it tracks the year in which MCP went from a vendor protocol to infrastructure.

The threat

As protocols like MCP (Model Context Protocol) and A2A (Agent-to-Agent) gain adoption to enable agent collaboration, tool sharing, and delegation of tasks, they introduce a new attack surface rooted in inter-agent communication and coordination. This threat involves abusing the commands and trust embedded in these protocols, including manipulating server responses, injecting context, or misleading agents through poorly defined tool descriptions or ambiguous consent flows.

(source: Agentic-AI-Threats-and-Mitigations-1.1.pdf, p. 28)

The preconditions are named precisely: “when protocol specifications are loosely enforced or implementations lack input validation and strong identity binding.” Consequences — hijacked agent behaviour, privilege escalation, guardrails bypassed “entirely,” unintended tool execution, data leakage, “irreversible system actions.”

The phrase carrying the most weight is trust embedded in these protocols. MCP and A2A are designed for cooperation between components assumed to be benign. Where that assumption fails, the protocol is the exploit path.

Three scenarios

Pp. 28:

  1. Consent Flow Manipulation — a malicious agent joins an A2A exchange and manipulates the consent negotiation. “By exploiting missing validation checks, the agent auto-approves sensitive actions like data deletion without explicit user intent, bypassing normal safeguards.” The human is never asked.
  2. Context Hijacking via MCP Response Injection — an attacker intercepts or crafts a server-side MCP response injecting malicious context or tool metadata. “A cooperating agent interprets the injected response as trusted protocol context and executes unintended backend operations.” Protocol-framed content is trusted differently from user content — that asymmetry is the bug.
  3. Tool Misuse via Descriptive Exploitation — misleading or overly broad tool descriptions planted in a shared tool registry. “During agent collaboration, another agent accepts and calls the tool under false assumptions, unintentionally leaking sensitive data or triggering privileged API calls.”

Scenario 3 is the one commonly called tool poisoning: the tool description is model-facing text that the model treats as specification, so a registry entry is an injection surface. Scenario 2 covers what is often called MCP response / context injection.

The guardrail-bypass property

T16 shares a structural property with T9’s persistent-identity takeover, and it is the reason both matter more than their scenario counts suggest. Playbook 3 states it directly (p. 38):

Especially when tools are invoked through inter-agent protocols (e.g., A2A, MCP), enforce sandboxing and privilege isolation, as these tool calls may bypass user interfaces, consent flows, or direct human oversight.

Most defensive machinery in this document sits on the human-facing conversational path. Protocol-layer invocation is a second path with none of it. Any control described as “require user approval” or “human in the loop” is silently absent when the call arrives over MCP or A2A.

Mitigations

From the T16 table entry (p. 19):

  • Enforce strong authentication between agents
  • Sanitize and validate all protocol-level data, including context payloads and tool metadata, to prevent injection or misinterpretation
  • Restrict agent-to-agent delegation to tightly scoped functions
  • Log all inter-agent communications and tool invocations for anomaly detection and post-incident analysis
  • Encrypt communications to avoid adversary-in-the-middle attacks

Validating tool metadata is the control that addresses Scenario 3 and the one most often missing — implementations validate arguments and ignore descriptions, which is precisely backwards for a model-facing field.

Playbook coverage is ambiguous. The overview table (p. 34) assigns T16 to both Playbook 3 and Playbook 4; neither playbook’s own header lists it. In practice its controls are distributed: sandboxing and privilege isolation from Playbook 3, mutual AI-to-AI authentication from Playbook 4, and Playbook 4’s detective bullet on flagging “cascading or recursive tool execution patterns triggered across agents” with isolation of agents producing “a sudden spike in tool invocations via MCP” (p. 40).

Standing of this page

raw/MCP-security/ was created and then removed before any source landed, so this is currently the vault’s only MCP-specific coverage. It is protocol-threat coverage from a consumer perspective — OWASP describes what abuse looks like, not the MCP specification’s own authorisation model. Cross-references worth having if that collection is ever restored: the MCP specification’s security considerations, and ATLAS AML.CS0045 (data exfiltration via an MCP server used by Cursor) and AML.CS0054 (data exfiltration via remote poisoned MCP tool), both already present in raw/MITRE-ATLAS/.

Graph View

Backlinks