Agent Protocols Fail at the Seams

The agent protocols are becoming integrated into normal software infrastructure, making integration easier. And this is making ownership blurrier.

These all make integration easier, so that’s great for product teams that want agents working together quickly. But then this becomes another failure surface in addition to specification. In this case, content flows quickly, and so do the different standards for delegation and state and all the rest. Meanwhile, ownership has traditionally moved more slowly through the org chart than that, so the mismatch becomes a problem for everybody.

Research is emerging around the integration of different agent protocols and the security of their composition. A 2026 paper, Formal Security Analysis of Agent Protocol Composition, investigates five agent protocols, finds 35 specification-level findings, backs them with 80 detailed implementation tests, and adds 30 failures found when the protocols were composed together as part of a larger system.

Finally, the years of pressuring AI agent vendors to connect together are starting to bear fruit. Work that can be done by isolated ‘agents’ is child’s play. The work of an enterprise is to cross boundaries in every direction. It has to traverse files, work items, schedules, databases, customer records in CRM systems, web pages viewed in browsers, software repositories, and APIs for internal services.

Clean locally. Sketchy globally.

Protocols standardize communication, not responsibility

Note to buyers: IBM’s useful definition says AI agent protocols standardize communication among AI agents and between agents and other system components; they do not standardize workflow coordination, execution, or optimization. Don’t make the stupid mistake of believing protocol support automatically includes control plane functionality.

MCP (Model Context Protocol) allows agents to discover tools and call them. A2A (Agent to Agent) allows independent agents to interact with each other using a standard interface. ACP (Agent Communication Protocol) allows agents to interact with each other using a REST interface (synchronous and asynchronous, streaming, stateful and stateless, online and offline, long running etc). It describes a thick grammar layer.

Grammar does not decide who can touch payroll.

The A2A 1.0 specification describes A2A in terms of three layers: the canonical data model, abstract operations, and bindings to specific protocols. Appendix A gives the enterprise pattern in miniature. An A2A client agent asks an A2A server agent to perform work. The server agent can then use tools and APIs supported by MCP. The architecture is useful for enterprise work and is exactly the direction people are moving AI agents.

ACP explicitly states the quiet part. The Agent Communication Protocol docs pitch interoperability between different frameworks, teams, and infrastructures. ACP exposes a REST API and is therefore opaque to the method calling the API. It supports long-running tasks, cancellation, streaming messages, and discovery. But as always: what looks valid as a method call can still be wrong when executed at runtime as part of a longer composed path of actions.

This is why MCP security starts after tool approval. Approving a server, registering its tools, and checking schemas only proves that a local component has a shape the client recognizes. Runtime security starts when the system asks a set of questions: What changed? What authority is being carried forward? What content entered the model’s context? What evidence will there be after the action is taken?

The failure moves through content, delegation, and authority

The AgentThread paper includes an example that is simple but should make security teams squint. One MCP server fetches attacker-controlled web content. Hidden instructions enter the model context. A second MCP server has file access. The agent reads local data and sends it back out through the first server. The paper describes the unsafe behavior as composition, implicit authority transfer, missing consent, and weak audit visibility across the agent runtime.

No single action needs to be out of the ordinary. Get a web page. Read a local file. Send the result of that.

The failure is the path.

The old framing of mcp security as a checklist around one server is too small. CoSAI’s Model Context Protocol Security whitepaper maps MCP to twelve threat categories and almost forty threats, including identity, access control, input and data boundaries, trust boundaries, lifecycle governance, logging, monitoring, and auditability. That taxonomy belongs in deployment design.

This is related to the prior post on the tool-call boundary. AI agent security happens at the tool call. But now that the tool call is a node in a larger composed route, the runtime must remember the content and the delegation that happened before calling that tool. A runtime that only checks the tool call is doing the bouncer’s work at one door, while there are tunnels in the building.

SDK conformance is not runtime safety

I like standards. I want fewer custom connectors. I want agents to connect to tools, agents, and servers without six months of mapping fields between corresponding data objects.

The AgentThread authors break down security failures at the protocol level to describe separate problems: unsafe behavior within a single protocol, missing SDK recommendations, missing deployment hardening, and unassigned responsibilities in cross-protocol cases. Ultimately, the authors find that agent-protocol insecurity stems from responsibility gaps across protocols, SDKs, and deployments, failures that occur when semantic content, delegated authority, and tool access cross protocol boundaries.

When a set of features required for securing agent-protocol interactions is distributed across three SDKs and documented in a wiki, no one ends up owning the seam.

Multi-agent systems already expose this kind of problem without the added complexity of security. We have written about how multi-agent systems break at the collaboration plane, at the claims, findings, handoffs, and shared-state level between agents. In the worst case, a lost finding turns into a security incident, and a lost authority boundary turns into a breach report.

Own the seam above the protocol stack

The fix starts by treating protocol composition as a runtime surface.

Standards committees can improve the grammar. Vendors can ship nicer SDKs. Security teams can review popular servers. Good. The runtime that joins MCP, A2A, ACP, AG-UI, browser tools, file tools, and internal APIs still has to own composition policy.

First, every step across protocol boundaries should leave an execution record: the principal, user or sponsor, original objective, delegated objective, source-content classification, requested tool or action, target resource, credential scope, policy decision, and resulting artifact. Call it a “ledger,” a “receipt chain,” or a “protocol-composition record.” The important thing is that the record exists for the entire composition path and is preserved for the duration of the execution.

As cross-protocol actions are executed, the authority granted to the previous step in the protocol should be restricted, such that subsequent steps in the protocol require additional justification or authorization, in line with the authority narrowdowns identified above. In particular, A2A delegation should not transfer the ambient authority of the calling principal to subsequent agents, MCP tool calls should be executed with credentials scoped to the task at hand as opposed to the human’s session, and browser-side agents should not silently inherit backend privileges as a result of a convenient protocol bridge.

Third, untrusted content needs to be labelled by the runtime as to its origin. This will allow policy to determine if later content can be used to justify actions that involve model processing of that untrusted content. A simple prompt-injection defense that only scans new text as it is injected into a model will not be effective if the injected text consists of, for example, web pages, ticket comments, email bodies, etc. Simply labelling such content as originating from the “user” will be insufficient to control its usage, since it would be allowed to be used to justify virtually any subsequent action.

Fourth, we need to carry trace context with us across protocol boundaries. As we said before, agent traces need to cross the MCP boundary because otherwise we would be left with planner traces with no tool/service spans, a useful story with a missing crime scene. But when protocol composition is involved, the downstream calls made by A2A or ACP can also cross MCP boundaries, and thus the traces they produce need to cross boundaries as well. If instead each of the different protocols produced a separate trace with no correlation between them, then any post-incident review would be pure archaeology.

Fifth, tracking of what to undo in case of failure (rollback) has to be attached to the composed path as well. The number of steps to undo can easily exceed the number of steps to complete a task already. If a tool creates a ticket, updates a file, sends out an email to customers, updates a CRM like Salesforce, and stores something in memory, then all of these steps have to be undoable as a whole. Otherwise the only thing to do in case of failure is to manually clean up the mess, which is what happens in enterprises already (classic).

The runtime is the security boundary buyers actually get

The protocol ecosystem is moving in the right direction. MCP lowered tool integration friction. A2A gives independent agents a shared way to delegate and report task state. ACP gives teams a simple HTTP path for agent interoperability. These are good tools for building useful workflows.

They are also incomplete by design.

A protocol specification describes messages, the state through which an agent goes, how an agent is authenticated, and the semantics of the operations that the agent can perform. But, the specific enterprise data structures, human rules for approval, scope of particular credentials, rules for handling an incident, and rules for rolling back actions that have been performed, all of these are outside of the scope of a protocol specification. They live in the runtime and application architecture around it.

So the procurement question should change.

Don’t just ask if the vendor supports MCP or A2A, because everybody supports the hot acronym eventually. Ask what happens when an agent delegates across A2A, calls an MCP tool, consumes untrusted content, accesses internal data, and returns an artifact to a user. Ask where the runtime’s ledger is. Ask how A2A-delegated credentials are minted for the task at hand. Ask how trace context is propagated throughout the composed protocol chain. Ask how policy sees the origin of new content introduced into a model. Ask how a system would roll back the damage done by a four-step process where each step seemed rational inside the bounds of the current protocol.

That is the AI agent security boundary now.

A protocol makes the path easier to build. The team running the system still owns what happens when authority crosses the seam.