Securing Agent-to-Agent Communication: The New Protocol Surface

By Taylor Thomas · 2026-08-30

Agents stopped being a single-model story when they began calling tools and each other, and the industry answered with protocols. MCP (Model Context Protocol) standardizes how an agent application connects to tools and data sources; A2A (Agent2Agent) standardizes how agents discover peers and delegate work to them. Both are open specifications over deliberately boring plumbing: MCP speaks JSON-RPC 2.0 over stdio locally or streamable HTTP remotely; A2A defines three bindings — JSON-RPC over HTTP, HTTP+JSON/REST, and gRPC. The security story is not the wire format but what rides on it: messages that become model input, exchanged between endpoints holding real credentials and real authority.

Protocol Content Is Model Input

A conventional API consumer typically parses a response into typed fields and ignores the rest. An agent system routinely does something structurally different: tool descriptions, tool results, and peer-agent messages are placed in model context, and the model extracts meaning from whatever it reads. That property creates this surface’s defining risk: indirect prompt injection through the protocol itself, the class OWASP’s current LLM Top 10 lists first. A tool server can embed instructions in a result; a compromised peer can phrase a task update as a directive. Prompt injection covers why no input filter reliably ends this. On an agent protocol the consequence is sharper: the injected text arrives over an authenticated channel, and authentication at best establishes which principal is speaking, never that what it sends is safe.

Injected content steers the model; it becomes an action when some downstream component holding credentials — the agent runtime, a gateway, a tool server — trusts and executes what the model proposes. Those components, not the model, are where containment lives.

Identity Before Delegation

A2A has agents advertise their capabilities in published descriptions — agent cards — that peers read before delegating. Delegating on that basis requires verified provenance: an authentic description, and the endpoint it names validated against that provenance. No single mechanism carries that alone. A registry must itself be authenticated; a signed card must verify back to a trusted signer; an allowlist grants permission rather than proving identity; and transport security authenticates where a card came from, not the endpoint it points to. The controls layer because each answers a different question; without verifiable provenance, discovery becomes an impersonation channel — a hostile endpoint advertises attractive capabilities and receives your tasks and their data. The specifications integrate the standard web mechanisms for this reason — TLS underneath, an OAuth-based authorization framework for HTTP-transport MCP servers, declared security schemes including mutual TLS for A2A endpoints — but declaring a scheme is not enforcing it: deployments must configure and require them, and a bearer token authorizes whoever presents it unless sender-constrained. A local stdio MCP server sits outside that machinery entirely: it commonly runs under the OS identity that launched it, and its trust rests on host security — launch controls, filesystem permissions, sandboxing, and executable provenance. Its content still needs the same containment as any remote server’s.

From the network’s side, this traffic is deliberately unremarkable — API calls inside HTTPS, indistinguishable at a glance from any other service-to-service exchange. That limits what content inspection alone can contribute and raises the value of placement: run agent runtimes and their tool servers in segmented zones, restrict their egress to approved endpoints, and log the protocol edges — which agent called which server, when, on whose task. The log will not show an injected instruction, but it turns “what did this agent talk to” from a forensic mystery into a query.

Authentication answers who; authority is the harder question. Each agent should hold per-agent workload identity rather than a shared service account, credentials scoped to its task and short-lived, and — the load-bearing control — authorization decided by deterministic policy the model cannot alter or bypass, so a steered model can propose but never self-approve. That is zero trust applied to a new identity class, and zero trust for AI agents develops it fully. The protocol surface adds one requirement: log the delegation chain, because when agent A tasks agent B to call tool C, an investigation must reconstruct on whose behalf the final action ran.

The Supply Chain You Just Adopted

Every tool server and peer agent wired into an agent system is a dependency that shapes model context and exercises whatever authority the deployment grants it — operationally closer to installing a plugin than to calling a typical REST API, an analogy about influence, not a technical boundary. A tool server’s descriptions can change after you adopt it; a peer agent’s behavior is only as trustworthy as its operator and its own supply chain. The discipline is familiar from software supply-chain security: an explicit registry of approved servers and agents instead of open-ended discovery, review before adoption, and monitoring for behavior change afterward. Nor is this niche on the certification track: the SCOR 350-701 blueprint’s AI/LLM vulnerability objective names supply chain among the classes engineers must describe.

Agent-to-agent protocols are not themselves a blueprint topic by name, but the foundations are what the current exams test: the AI vulnerability classes in SCOR, and the zero trust access architecture — identity, posture, least privilege, continuous verification — that the SCAZT 300-740 track teaches. The engineers who secured service-to-service traffic with workload identity and scoped tokens will recognize this surface; the protocols are new, the discipline is not.

Frequently Asked Questions

What is the difference between MCP and A2A?

They standardize different edges of the same graph. MCP (Model Context Protocol) connects an agent application to tools and data sources — the servers that expose capabilities like searching a repository or querying a database. A2A (Agent2Agent) connects agents to each other: one agent discovers a peer's advertised capabilities and delegates a task to it. An agent system can speak both — MCP downward to its tools, A2A sideways to its peers.

Why is prompt injection a protocol problem and not just an application problem?

Because much of the payload — tool descriptions, tool results, peer messages — is destined for a model. A conventional API consumer parses a response into typed fields and ignores what it did not ask for; an agent commonly feeds tool results and peer messages into a model that extracts meaning from all of it. That turns every connected tool server and every peer agent into a channel through which instructions can arrive, which is why the trust decision about who may connect matters as much as the parsing of what they send.

Do these protocols have security built in?

Their specifications integrate the standard web mechanisms — TLS, an OAuth-based authorization framework for HTTP-transport MCP servers, declared authentication schemes including mutual TLS for A2A endpoints — but the deployment must configure and enforce them; a local stdio MCP server sits outside that machinery and rests on host security instead. What they cannot decide for you is authority: what each authenticated agent is permitted to do, whether its credentials are scoped to its task, and whether a policy check outside the model's control gates consequential actions. Those controls are the deployment's responsibility, and they are where containment actually happens.