Mapping A2A Communication Flows and Inter-Agent Trust
Multi-agent systems distribute work across multiple AI agents that communicate with each other to complete complex tasks. The trust relationships between these agents are rarely explicitly enforced — an orchestrator agent typically sends instructions to sub-agents as plain text messages with no authentication or signing. A sub-agent receiving a message has no reliable way to verify it came from a legitimate orchestrator rather than an attacker who has injected a message into the communication channel. Mapping these flows before attacking reveals where trust is assumed rather than enforced.
Identify Whether the Application Uses Multiple Agents
Signs of a multi-agent architecture in application behaviour:
Response latency is also an indicator — multi-agent systems with sequential agent calls produce longer response times than single-agent systems. A simple query that takes 10+ seconds to respond suggests multiple sequential LLM calls in the backend. Streaming responses that pause mid-generation often indicate a handoff between agents.
Intercept Agent-to-Agent Traffic
In an internal assessment where you have network access between agent components, capture the traffic between agents to map the communication protocol and message format:
Captured agent-to-agent messages reveal the message format, authentication headers (or lack thereof), task delegation structure, and what context is passed between agents. A message from orchestrator to sub-agent that contains no authentication token or signature is vulnerable to impersonation — you can send the same format message directly to the sub-agent while claiming to be the orchestrator.
Identify Agent Endpoints Directly
Sub-agents in multi-agent systems often have their own API endpoints that the orchestrator calls. These are sometimes reachable directly from outside the application:
A directly accessible sub-agent endpoint that expects to receive instructions only from an internal orchestrator is a high-value target. If it accepts unauthenticated requests, you can send it arbitrary task instructions without going through the orchestrator's validation logic.
Map the Agent Role Hierarchy
Document the agent topology from gathered information:
# Agent topology map — fill from recon and traffic analysis
ORCHESTRATOR: /api/chat — receives user input, delegates tasks
-> RESEARCH_AGENT: /agents/research — web search, document retrieval
-> CODE_AGENT: /agents/code — code generation and execution
-> MEMORY_AGENT: /agents/memory — stores and retrieves user context
TRUST_MODEL:
- Orchestrator -> Sub-agents: plain HTTP POST, no auth token
- Sub-agents -> Orchestrator: response only, no callback auth
- User -> Orchestrator: session cookie only
EXPOSED_DIRECTLY:
- /agents/research — responds to unauthenticated POST
- /agents/code — requires internal header X-Agent-Token (weak)
References
-
Google — Agent2Agent Protocol specificationgoogle.github.io/A2A (opens in new tab)
A2A protocol design including authentication and trust model reference
-
Anthropic — Building Effective Agentswww.anthropic.com/research/building-effective-agents (opens in new tab)
Multi-agent architecture patterns and orchestration design reference
Was this helpful?
Your feedback helps improve this page.