Definition
Inter-agent communication protocols that lack encryption and authentication are vulnerable to eavesdropping, message tampering, and spoofing. The flaw is in the implementation, not the protocol specification. This threat applies in two contexts: in ElizaOS (an open-source multi-agent operating system) the risk sits with the framework’s native inter-agent protocol; in the Anthropic MCP context it sits with the MCP client-server communication channel (JSON-RPC over HTTP and Server-Sent Events (SSE)), which specific deployments may implement without proper encryption or mutual authentication.
What it looks like in practice
Two ElizaOS agents designed to collaborate on a token-trading strategy exchange state messages via the built-in inter-agent protocol. The messages are transmitted over an unencrypted channel within a shared network. An attacker on the same network intercepts a message instructing Agent B to execute a sell order, modifies the target token and quantity, and forwards the tampered message. Agent B executes the attacker’s trade rather than the intended one.
In the MCP context: an MCP client connects to a server over HTTP rather than HTTPS (Transport Layer Security) because the deployment was configured for a local-only environment and then promoted to a shared network without hardening. An attacker on the network eavesdrops on tool call parameters (which may include authentication tokens or sensitive query content) and injects a modified server response that redirects the agent to a different data source.
Why it’s dangerous in multi-agent context
Agents treat messages from peer agents and MCP servers as authoritative inputs that drive autonomous action. An attacker who can intercept or tamper with inter-agent messages redirects agent behaviour without touching either agent’s process. The attack surface grows linearly with the number of agent-to-agent and agent-to-server communication paths. T42 (Cross-Client Interference via Shared Server) can compound the effect: an attacker who compromises the shared MCP server channel can interfere with all clients connected to it simultaneously.
Detection signals
Tampering with unencrypted inter-agent messages leaves structural traces: unexpected field value changes between sender and receiver logs, TLS negotiation failures, and message authenticity check failures.
- A message field value that differs between the sending agent’s outbound log and the receiving agent’s inbound log for the same message ID: cross-correlate outbound and inbound message logs by
message_idand alert on any field-value mismatch. - A TLS handshake failure or certificate validation error on an MCP client-to-server connection: instrument the TLS layer to emit a structured log event on every validation failure and alert on any occurrence (these should be zero in a correctly configured deployment).
- An inbound JSON-RPC message whose signature or message authentication code (MAC) fails verification: log the verification outcome on every message and alert immediately on any failure.
- A replay event: a message with a
nonceor sequence identifier that has already been processed in the current session. Alert on any duplicate nonce within the session window. - Plaintext HTTP traffic detected on any port used for MCP client-server communication: implement a network-layer control (e.g. a firewall rule or a packet-capture alert) that fires on any non-TLS connection to the MCP server port.
Mitigations
- Serve all MCP client-server communication over TLS (Transport Layer Security) with certificate validation; reject plaintext HTTP connections.
- Enforce mutual authentication on both agent-to-agent and MCP client-to-server connections: both parties must present a verified identity.
- Implement JSON-RPC message integrity checks (signatures or message authentication codes) to detect tampering in transit.
- Replay-protect messages with per-session nonces or timestamps; reject messages with duplicate or out-of-window sequence identifiers.
Relation to base threat (T1–T17)
T30 extends T12 Agent Communication Poisoning. Where T12 focuses on the content of inter-agent messages being manipulated, T30 focuses on the transport layer as the attack surface: the absence of encryption and authentication that makes content manipulation feasible. T40 (MCP Client Impersonation) is the identity-layer complement: an attacker who cannot intercept in transit may instead impersonate a legitimate client.
OWASP Top 10 for Agentic Applications 2026
The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T30 is covered by the following Top 10 entries:
-
ASI07 Insecure Inter-Agent Communication primary Agents in a multi-agent system pass instructions, results, and context to one another across APIs, message buses, and shared state. Without per-message authentication and integrity controls, a single compromised peripheral agent becomes an injection source for every peer it can reach. One hop becomes n-hop, and the orchestrator is reachable from the outside.
Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.
Design principles at stake
When T30 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.
- Defence-in-Depth The attack works because the transport layer carries no authentication or encryption, making content manipulation feasible at the network level without touching either agent's process. A single control (adding TLS) is insufficient because certificate validation may be misconfigured, mutual authentication may be absent, and messages may still be replayed even over an encrypted channel. Depth means TLS with certificate validation as the confidentiality layer, mutual authentication so both parties present verified identities, JSON-RPC message integrity checks such as signatures or MACs to detect tampering that survives the transport, and replay protection via per-session nonces: each addressing a distinct failure mode that the others do not cover.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T30, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
-
An inter-agent message travels through channels and intermediate agents the receiver did not originate. If nothing binds the message cryptographically to its source, any intermediate hop can substitute or inject content that the receiving agent will treat as authoritative. Message signing closes that gap: the source agent signs each message payload with its private key, and the receiver verifies the signature against a distributed trust bundle before the content reaches the reasoning layer.
why it helps Insecure A2A protocol abuse depends on injecting or substituting messages inside the A2A channel without the receiver detecting it. Signing every A2A message to the originating agent's key means a tampered or injected message fails verification before it can influence the receiver's reasoning.
- Tier 2 Token TTL (Short-lived tokens — bounding the credential exploitation window for agent identities)
An agent identity backed by a long-lived bearer token grants access for as long as that token remains valid. If the token is stolen, logged, or extracted from a running process, the attacker holds working credentials for weeks or months without any further action. Short-lived tokens address this by issuing credentials with a time-to-live measured in minutes or hours, automated and renewed by the platform rather than a human. When a token expires, access ends: the attacker must win the renewal process as well, which requires compromising a harder target than the token itself.
why it helps Insecure inter-agent communication creates interception opportunities on agent-to-agent channels. A bearer token captured in transit grants impersonation access only until it expires; short TTL shrinks that window to the token's remaining lifetime, limiting what an attacker can do with a single interception before the credential becomes worthless.
Multi-agent variants: OWASP MAS Guide
The OWASP OWASP MAS Threat Modelling Guide v1.0 catalogues 1 named multi-agent variant of T30, anchored to specific MAESTRO layers. Each is a concrete attack pattern that emerges when this threat compounds across agents.
- CL Multi-Agent Trust Collapse via Rogue MCP + A2A extends T47, T30, T13
A rogue MCP server (T47) issues forged tool responses; downstream agents accept them on the basis of A2A delegated trust (T30); a rogue orchestrator agent (T13) amplifies the forged results across the MAS. All three conditions must co-occur for the cascade to trigger.
Source: OWASP MAS Threat Modelling Guide v1.0, §2 Overview of MAESTRO Framework — Extended Threat Scenarios + Cross-Layer table.
Red-team pivot: MITRE ATLAS techniques
MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.
AML.T0073 Impersonation view on ATLAS ↗ Adversary poses as a trusted entity (user, service, peer agent) to gain access or influence decisions.
AML.T0080 AI Agent Context Poisoning view on ATLAS ↗ Adversary contaminates an agent's context store (short-term scratchpad, vector memory, conversation history) so future reasoning is biased toward attacker goals.
Agentic angle: Persistent across sessions: a single successful poisoning influences every later decision until the memory is purged.
AML.T0051 LLM Prompt Injection view on ATLAS ↗ Adversary crafts prompt content (direct or indirect via documents, web pages, tool outputs) so the model interprets attacker text as instructions and acts on it.
Agentic angle: The single most common entry technique against agents, and often the first step that enables every other AML.T0##.
References
- OWASP MAS Threat Modelling Guide v1.0 (April 2025) §4 ElizaOS — Layer 3 Agent Frameworks; §5 Anthropic MCP — Layer 3 Agent Frameworks.
Sources
- OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §4 Eliza OS — Layer 3 Agent Frameworks; §5 Anthropic MCP — Layer 3 Agent Frameworks