# Mapping A2A Communication Flows and Inter-Agent Trust

> Analyzes agent-to-agent communication patterns, trust boundaries, and authentication mechanisms to identify attack surfaces in multi-agent AI architectures.

- **URL:** https://hackindex.io/platforms/ai/threat-modeling/mapping-a2a-communication-flows
- **Path:** AI Platforms > Threat Modeling
- **Up:** [Threat Modeling](https://hackindex.io/platforms/ai/threat-modeling.md)
- **Published:** 2026-03-18
- **Updated:** 2026-08-11

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:

```bash
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
```

```bash
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:

```bash
mitmproxy --mode transparent --ssl-insecure -p 8080 --save-stream-file /tmp/a2a-traffic.mitm
```

```bash
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:

```bash
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
ffuf -u https://$TARGET_DOMAIN/FUZZ -w /tmp/agent-paths.txt -mc 200,400,401,403,422
```

```bash
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:

```markdown
# 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 specification](https://google.github.io/A2A/) - A2A protocol design including authentication and trust model reference
- [Anthropic: Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) - Multi-agent architecture patterns and orchestration design reference