Agent-to-agent security is the practice of inspecting and enforcing policy on the outbound calls one autonomous agent makes to another, including A2A protocol messages, delegated tool invocations, and cross-agent handoffs. Because these calls leave the process over HTTP, gRPC, or WebSocket, they are ordinary egress traffic that most prompt filters and posture tools never see, which makes the network boundary the only reliable place to control them.
Why agent-to-agent security is the next unmonitored egress surface
Single-agent deployments were already hard to observe. Multi-agent systems multiply the problem: an orchestrator agent delegates a subtask to a worker agent, the worker calls a third specialist agent, and each hop is a new outbound request carrying instructions, context, and sometimes credentials. The A2A protocol formalizes this with agent cards, task objects, and message parts, but the security posture around it is thin. Teams instrument token usage and prompt inputs, then assume the inter-agent mesh is trusted infrastructure.
It is not. Every A2A call is a chance for prompt injection to propagate, for private data to ride along in a message part, and for an over-scoped worker to reach a host it should never touch. The trust boundary you actually care about is not inside any single agent. It is the wire between them.
What A2A protocol security looks like on the wire
When an orchestrator hands a task to a worker over A2A, the payload is usually a JSON body posted to the worker's endpoint. A representative request looks like this:
- Method and path:
POST /a2a/tasks/sendto the worker's advertised URL. - Auth: a bearer token or mTLS client cert identifying the calling agent.
- Body: a task object with a
messagecontaining text parts, file parts, and structured data parts. - Streaming: often a Server-Sent Events or WebSocket channel that streams partial results back.
Three things make multi agent egress dangerous. First, the message parts can carry arbitrary retrieved content, so an injection planted upstream travels intact to the next agent. Second, file and data parts can smuggle secrets or PII that no one intended to share cross-agent. Third, the worker's outbound calls (its own tool invocations) are a separate egress surface entirely, so blocking only the orchestrator leaves the worker's actions unmonitored.
The gaps in typical agent to agent traffic inspection
Most controls sit in the wrong place to see A2A calls:
| Control layer | Sees the A2A call? | Why it falls short |
|---|---|---|
| Prompt classifier / input filter | No | Runs before the model decides to delegate; never observes the outbound POST. |
| LLM gateway (routing/metering) | Partial | Sees model API calls, not agent-to-agent tool traffic between services. |
| Service mesh egress (Istio/Envoy) | Partial | Sees host and port, not the task payload, message parts, or agent intent. |
| Cloud firewall / security groups | Partial | Allows the CIDR or domain, then is blind to content and per-agent identity. |
| Egress proxy with content inspection | Yes | Terminates TLS, parses the A2A body, and enforces per-agent policy on the wire. |
The pattern is consistent: layers that understand intent do not see the network, and layers that see the network do not understand intent. A2A traffic falls straight through the middle.
How Agent G brings A2A traffic under egress enforcement
Agent G is a zero-trust egress proxy that sits inline on the outbound path, so every A2A call routes through it before reaching another agent's endpoint. Because it terminates TLS and parses the payload, it can apply the same deterministic controls to inter-agent traffic that it applies to any other tool call.
- Default-deny destinations: a worker agent can only reach the specific A2A endpoints on its allowlist. An orchestrator that suddenly posts to an unknown agent URL is blocked, not logged after the fact.
- Per-agent identity binding: each agent's egress policy is tied to its identity, so the proxy knows which agent is calling which and can deny cross-agent calls that violate the delegation graph.
- Deep payload inspection: Agent G reads A2A message parts, file parts, and data parts, applies DLP normalization to catch encoded secrets and PII, and can strip or block a part that carries data it should not.
- Human-in-the-loop gating: a high-risk delegated action (a wire transfer, a destructive command, a call to a sensitive internal service) can be paused for approval instead of executing autonomously.
- Out-of-band action receipts: every A2A call is logged from outside the agents' trust boundary, giving you a tamper-resistant record of which agent asked which agent to do what.
A minimal rollout for multi-agent egress
- Route all agent egress through the proxy. Point every agent's outbound HTTP, gRPC, and WebSocket traffic at Agent G so no A2A hop bypasses inspection.
- Enumerate the delegation graph. List which agents legitimately call which, and turn that into a default-deny allowlist of A2A endpoints per agent identity.
- Enable payload DLP. Switch on normalization and secret/PII detection for A2A message and data parts so an injected or leaky part is caught before it leaves.
- Gate the irreversible. Mark destructive or high-value delegated actions as approval-required so a poisoned upstream cannot cascade into an autonomous action.
- Stream receipts to your SIEM. Forward the out-of-band logs so detection rules can flag anomalous cross-agent patterns.
Why the network boundary is the right place for agent-to-agent security
You cannot trust an agent to police its own outbound calls, because the same reasoning that gets hijacked by injection is the reasoning that would decide whether a call is safe. A2A traffic makes this worse by chaining that reasoning across independent agents. Enforcing agent-to-agent security at the egress boundary sidesteps the problem entirely: the proxy applies policy the agents cannot argue their way around, inspects the actual bytes leaving the process, and produces evidence no compromised agent can rewrite. That is the control surface Agent G already occupies for A2A, WebSocket, and every other outbound transport.
Frequently Asked Questions
What is A2A traffic and why is it a security risk?
A2A (agent-to-agent) traffic is the outbound calls agents make to delegate tasks to one another, usually as JSON task objects over HTTP or WebSocket. It is risky because injected instructions and sensitive data ride inside message parts across hops that most guardrails never inspect.
Can a service mesh handle agent-to-agent traffic inspection?
A service mesh like Istio or Envoy sees the host and port of an A2A call but not the task payload, message parts, or the calling agent's intent. It enforces network reachability, not content or per-agent policy, so it leaves the meaningful A2A risk unaddressed.
How does Agent G inspect encrypted A2A calls?
Agent G terminates TLS inline, parses the A2A body, applies allowlist and DLP policy per agent identity, and re-encrypts to the destination. This lets it read message parts and block leaks without breaking the connection. See the MCP gateway for how the same inspection applies to tool calls.
Where should agent-to-agent security controls live?
At the egress boundary. Prompt filters run too early and cloud firewalls see too little, so the only place that observes both the intent and the actual bytes of every A2A hop is an inline egress proxy that terminates and inspects the traffic.
Related reading: deep tool-argument inspection, discovering shadow MCP servers from egress logs, and the inference boundary versus network boundary framing. Compare approaches on our alternatives page or start at the Agent G overview.
Ready to bring A2A traffic under control? Agent G inspects and enforces policy on every agent-to-agent call on the wire. Request access to the Agent G private beta and put your multi-agent egress under a default-deny, fully audited boundary.