AGENTIC FACTOR
Agent-to-Agent Communication
Agent-to-Agent Communication is the property that agents talk to each other directly, not just to users. The vocabulary for this is now standardizing. Google's A2A protocol and the Model Context Protocol (MCP) are the most prominent examples, and both describe richer-than-RPC patterns: discovering capabilities, sharing tools, delegating tasks, and negotiating consent.
At a glance
Agent-to-Agent Communication is the property that agents talk to each other directly, not just to users. The vocabulary for this is now standardizing. Google’s A2A protocol and the Model Context Protocol (MCP) are the most prominent examples, and both describe richer-than-RPC patterns: discovering capabilities, sharing tools, delegating tasks, and negotiating consent.
Why it matters for security: each inter-agent message is potentially treated as authoritative input by the receiving agent’s reasoning. Standard request/response authentication is necessary but not sufficient. The content of agent communication must also be defended against injection, replay, and manipulation, because the recipient agent will reason over it rather than just route it.
Agent-to-Agent Communication is the factor that lets every other threat scale. It turns Memory Poisoning into Inter-Agent Data Leakage Cascade; turns Tool Misuse into chain-of-command misuse where no individual delegation is anomalous; turns Identity Spoofing into trust network compromise. Most of MAESTRO’s Cross-Layer threat catalog exists because of this factor.
A concrete scenario
A logistics company builds a multi-agent pipeline using LangGraph. An orchestrator agent breaks incoming freight bookings into subtasks and delegates them to three specialist sub-agents: a routing agent (decides carrier), a pricing agent (quotes rates), and a compliance agent (checks export regulations). The routing agent fetches carrier availability from an external API; one API response contains a subtly malformed JSON field that the routing agent incorporates into its reasoning before passing a task summary to the pricing agent. The pricing agent, treating the routing agent’s output as authoritative, includes the malformed recommendation in its own output to the orchestrator. The orchestrator books the shipment. No individual agent’s action is obviously wrong; the malicious content propagated because each agent trusted the previous one’s output without independent validation. The external API was a supplier’s system that had been compromised three weeks earlier.
What this means for your system
Every inter-agent message is a trust boundary. The fact that a message arrives from an internal sub-agent does not make its content safe. Sub-agents can be compromised, their outputs can be poisoned by tool responses, and they can be deceived by indirect injection in the same way a user-facing agent can. Treat every agent-to-agent message with the same scepticism you would apply to a message from an unauthenticated external caller.
Delegation silently inherits and amplifies privilege. When an orchestrator delegates to a sub-agent, the sub-agent typically inherits the orchestrator’s authorisation context. If the orchestrator has access to payment APIs and user PII, so does every sub-agent it spins up. Privilege does not automatically narrow as tasks are decomposed; it propagates unless you explicitly constrain it at each delegation boundary.
Audit trails fragment across agent hops. A single user-initiated action may produce ten tool calls across four agents. If each agent logs independently and does not propagate a shared correlation ID, incident reconstruction requires manually stitching logs from multiple sources, a process that takes hours and is error-prone under time pressure.
What to do about it
Validate the content of inter-agent messages, not just their origin. An internal agent’s output should be treated as untrusted data: check it against a schema, a numeric range, or a classifier before acting on it, especially if the output was derived from an external tool call or a retrieved document.
Assign a shared trace ID at the start of each top-level user request and propagate it through every agent-to-agent message, tool call, and API invocation. Without this, correlated-log search during an incident is impractical. OpenTelemetry’s trace context propagation is a ready-made standard for this.
Apply explicit privilege downscoping at each delegation. When an orchestrator creates a sub-agent task, pass only the credentials and context scopes the sub-task actually needs. Do not pass the orchestrator’s full token to every sub-agent.
Use mutual authentication between agents, not just outbound authentication. Google’s A2A protocol supports agent card verification; for MCP-based systems, enforce TLS client certificates or signed JWT assertions on every server-to-server call so that a process cannot impersonate an agent by simply knowing the internal endpoint.
Rate-limit and budget each agent’s outbound calls independently. If the routing agent can make at most 20 external API calls per booking, a compromised supplier system cannot use it as a relay to exfiltrate data in bulk or pivot into other agents via crafted responses.
Related
ASI entries this factor most amplifies:
- ASI07 — Insecure Inter-Agent Communication: A2A communication is the direct substrate of this risk; the attack surface exists only because agents send messages to each other that other agents act on.
- ASI08 — Cascading Failures: multi-agent pipelines propagate failures across agent hops; a single bad output from one agent can corrupt the downstream chain because each agent treats its predecessor’s output as ground truth.
- ASI01 — Agent Goal Hijack: a goal-hijacking instruction injected into one agent’s context can propagate to subordinate agents via delegation, amplifying a single injection point into a system-wide goal change.
Example threats driven by this factor:
- T16 — Insecure Inter-Agent Protocol Abuse: this threat is definitionally about A2A communication: the attack vector is the protocol messages agents exchange, not any individual agent’s internal reasoning.
- T12 — Agent Communication Poisoning: poisoning the messages that flow between agents is only possible because agents treat inter-agent messages as authoritative input to their reasoning loops.
- T30 — Insecure Inter-Agent Communication Protocol: absent transport-layer controls (mutual TLS, message signing), inter-agent channels are vulnerable to interception and replay that is invisible to the individual agents.
Threats driven by this factor
Every threat in the catalog whose agenticFactors list includes Agent-to-Agent Communication.
- T12 Agent Communication Poisoning
- T13 Rogue Agents in Multi-Agent Systems
- T14 Human Attacks on Multi-Agent Systems
- T16 Insecure Inter-Agent Protocol Abuse
- T25 Workflow Disruption via Dependency Exploitation
- T27 Vector Database Poisoning with Malicious Smart Contract Data
- T30 Insecure Inter-Agent Communication Protocol
- T37 Cross-Chain Bridge Attack (Indirect)
- T38 Emergent Collusion on Blockchain
- T42 Cross-Client Interference via Shared Server