Skip to content
HackIndex.io

Mapping A2A Communication Flows and Inter-Agent Trust

3 min read Created Mar 18, 2026 Last updated Aug 11, 2026

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.

  • Agent role enumeration determines whether the target uses an orchestrator, sub-agents, or a flat peer model through direct questioning and latency analysis.
  • Traffic interception captures inter-agent messages via mitmproxy or tshark to reveal message format, authentication headers, and delegation structure.
  • Direct endpoint discovery fuzzes for sub-agent API paths that may accept unauthenticated requests outside the orchestrator flow.
  • Trust model mapping documents which agent-to-agent links use authentication tokens and which rely on plain HTTP without verification.

Identify Whether the Application Uses Multiple Agents

Signs of a multi-agent architecture in application behaviour:

┌──(kali㉿kali)-[~]
└─$ curl -sk -X POST https://$TARGET_DOMAIN/api/chat -H 'Content-Type: application/json' -d '{"messages":[{"role":"user","content":"How do you process complex requests? Do you coordinate with other agents or models?"}]}' | python3 -m json.tool
┌──(kali㉿kali)-[~]
└─$ curl -sk -X POST https://$TARGET_DOMAIN/api/chat -H 'Content-Type: application/json' -d '{"messages":[{"role":"user","content":"Are you an orchestrator agent or a sub-agent? What is your role in this system?"}]}' | python3 -m json.tool

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:

┌──(kali㉿kali)-[~]
└─$ mitmproxy --mode transparent --ssl-insecure -p 8080 --save-stream-file /tmp/a2a-traffic.mitm
┌──(kali㉿kali)-[~]
└─$ tshark -i eth0 -Y 'http or http2' -T fields -e http.request.uri -e http.file_data 2>/dev/null | grep -iE 'agent|task|orchestrat|delegate|handoff'

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:

┌──(kali㉿kali)-[~]
└─$ cat > /tmp/agent-paths.txt << 'EOF'
agents
agent
agent/research
agent/code
agent/execute
agent/search
api/agents
api/agent
api/v1/agents
workers
worker
tasks
task
orchestrator
subagent
sub-agent
planner
executor
EOF
┌──(kali㉿kali)-[~]
└─$ ffuf -u https://$TARGET_DOMAIN/FUZZ -w /tmp/agent-paths.txt -mc 200,400,401,403,422
┌──(kali㉿kali)-[~]
└─$ ffuf -u https://$TARGET_DOMAIN/FUZZ -w /tmp/agent-paths.txt -mc 200,400,401,403,422 -o ffuf-agents.json

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