Agent governance so far has been an internal exercise. You decided which tools your agent could call, which credentials it held, which actions needed a human. All of it happened inside your perimeter, under one set of policies, with one legal entity on the hook. That assumption is about to break. The next thing your agent talks to will not be your tool. It will be somebody else's agent, on somebody else's infrastructure, representing somebody else's interests.
The protocols making this possible are real and shipping. Google's Agent2Agent protocol launched in April 2025 with more than 50 partners including Salesforce, ServiceNow, and MongoDB, and Google donated it to the Linux Foundation that June. It now sits at version 1.0 under a technical steering committee spanning AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow. When that many competitors agree on a wire format, the wire format wins. What none of them agreed on is who is responsible when the conversation goes wrong.
Interoperability protocols standardize how agents find each other, describe their capabilities, and exchange messages. They do not standardize authority, liability, dispute resolution, or evidence. A protocol carries a message, not a warranty. Before an agent you own transacts with an agent you do not own, the accountability layer has to be built by you, in contract and in architecture.
It helps to be precise, because vendor decks are not. A2A gives you four things. Discovery: a remote agent publishes a machine-readable Agent Card at a known URL describing its skills, endpoints, and accepted authentication schemes. Capability exchange: your client reads that card and decides what to ask for. Structured messaging: JSON-RPC 2.0 over HTTPS originally, with gRPC and HTTP+JSON/REST bindings added by v1.0, using conventional enterprise auth such as OAuth 2.0, bearer tokens, or API keys. Task lifecycle: handoff, status polling, and result retrieval for work that takes minutes or days. It is also opaque by design, so agents collaborate without exposing internal tools, memory, or reasoning. You get a result and a status, not a view of how the other side got there.
Notice what is absent. No notion of how much authority the remote agent holds from its owner. No way to express that a commitment above a certain value needs a human on their side. No dissent channel, no escalation primitive, no shared audit record. It is a carefully built transport layer that was never trying to be a governance layer.
The protocol landscape sorted itself out faster than expected, and it consolidated rather than fragmented. Anthropic's Model Context Protocol governs tool and data access. A2A governs agent-to-agent collaboration. IBM Research's Agent Communication Protocol, which contributed a RESTful multimodal messaging model, merged into A2A under the Linux Foundation in August 2025 specifically to avoid a standards split, with IBM taking a seat on the A2A technical steering committee. That leaves the community-driven Agent Network Protocol as the main remaining alternative, built on a more decentralized approach to identity and discovery.
Which is worth sitting with for a second, because it sharpens the problem rather than solving it. The industry looked at fragmentation, decided it was the risk worth eliminating, and merged the wire formats. Nobody ran the equivalent exercise on accountability. The transport converged. The liability model did not.
The useful distinction is not which is technically better. It is which ones stay inside your perimeter. MCP servers are usually things you run or approve, covered in our piece on governing the tool-access layer. Orchestration frameworks coordinate agents you own, covered in multi-agent orchestration governance. A2A is different in kind. It is the layer where the counterparty is a different company.
This is not just a practitioner complaint. A June 2026 paper from Richard Kang and Yudho Diponegoro, Governance Gaps in Agent Interoperability Protocols, evaluated five interoperability protocols including MCP, A2A, ACP, and ANP against six governance dimensions: membership, deliberation, voting, dissent preservation, human escalation, and audit or replay. Voting and dissent preservation are universally absent across every protocol examined, and deliberation is absent or only partially supported.
The authors separate extensible gaps, which a future spec version could close, from structural gaps, which need a new architectural layer above the protocol. Their conclusion is that governed agent communities are a missing layer, not a missing feature. If you are waiting for A2A 2.0 to solve accountability for you, you will be waiting through the transactions you are already running.
Inside your walls, identity is a solved-enough problem: you issue it, scope it, revoke it, as covered in our article on credential delegation for AI agents. Across a boundary you are trusting an assertion from an organization whose issuance practices you have not audited. TLS proves you reached the host you meant to reach. It does not prove the agent behind it is the agent your contract describes, or that it has not been reconfigured since Tuesday. Decide which counterparty identities you accept, pin them, and require notice on change.
Automatic discovery is the selling point and the risk in one breath. Any A2A server can publish an Agent Card at /.well-known/agent-card.json, and that card is a self-declaration written by its author. Nothing in the protocol validates that the agent performs those skills competently, safely, or within the regulatory constraints you operate under. Discovery can happen automatically. Nothing discovered gets to enter production automatically. Keep an allowlist keyed to specific agent-card URLs you have actually reviewed, pin the card version you approved, and refuse runtime-discovered skills nobody signed off on.
Your agent delegates to a partner's agent, which delegates a subtask to a third agent it uses as a subprocessor. You have a contract with party two, no relationship with party three, and under A2A's opacity model you may not know party three exists. If your data traveled that far, your obligations traveled with it. This is the subprocessor problem your privacy team knows from cloud contracts, now moving at machine speed without generating a procurement ticket.
Very little on its own. A captured protocol message shows that an endpoint sent a payload at a time. It does not show that the sender was authorized to commit its principal, that a human reviewed it, or that the content is true. An auditor asking why a remittance address changed wants an authority basis, and a machine-readable message is not one. Independent verification against your own system of record is what converts a claim into evidence.
Two agents transact and the output is wrong: a quantity, a price, a delivery commitment. Both behaved as designed. Neither company's staff saw the exchange. There is no shared log, no agreed reconciliation procedure, and no protocol primitive for either agent to formally object. You are then in a commercial dispute where both parties hold partial, unsynchronized records of an event neither witnessed. Write the reversal procedure before you need it.
Handle this as an interoperability rider to the master services agreement, not an appendix to an integration document. Six clauses do most of the work.
Agents shipped inside products you already license raise a related set of questions, covered in vendor-embedded AI agents. The difference is that an embedded agent acts within your tenant, while a counterparty agent acts across the line for someone whose incentives are not yours.
Contracts allocate loss after the fact. Architecture prevents it. Four requirements belong in any cross-boundary agent design.
Cross-boundary logging has a higher bar than internal logging, because the record has to stand up when the other party's version disagrees with yours. For every exchange, capture the verified counterparty identity and credential presented, a shared correlation identifier carried across the task lifecycle, the exact request and response payloads rather than a summary, the Agent Card version in effect, the authority basis you relied on, the internal validation result, the human approval record, and the final disposition including any reversal. Wiring that into your delivery pipeline is ordinary AI DevOps work, and far cheaper before the first disputed exchange than after.
The adoption pressure is real and the failure rate is documented. Gartner's 2026 CIO and Technology Executive Survey found only 17 percent of organizations have deployed AI agents while more than 60 percent expect to within two years, and Gartner projects that more than 40 percent of agentic AI projects will be canceled by the end of 2027 over escalating costs, unclear business value, and inadequate risk controls. It also expects 40 percent of enterprise applications to feature task-specific agents by the end of 2026. The counterparty agents will exist whether or not your governance does.
A workable sequence starts with a single named counterparty rather than an open network, on a workflow where errors are visible and cheap: status inquiries, availability checks, document retrieval. Run it in shadow mode first, where your agent asks and logs but your existing process still decides. Then move to a hard value ceiling with human approval above it, and only raise that ceiling for transaction types you now have evidence about. Tiering counterparties by verified identity, contract terms, and observed reliability, rather than treating all external agents as one trust class, keeps this manageable as the list grows.
The uncomfortable part is worth naming. Everyone on the other side of these exchanges is making the same optimistic assumptions you are, including the assumption that the counterparty governs its agents properly. Interoperability makes those assumptions transitive, and transitive trust in a network of agents is how a local error becomes an industry incident.
Ask one question at your next architecture review: which of our agents can currently receive a message from an agent outside this company, and what can it do as a result? For most organizations in 2026 the honest answer is none yet, which makes this the rare governance problem you can get in front of. Write the counterparty allowlist, the value ceiling, the log schema, and the contract rider now, while the cost is a few meetings.
Infonaligy designs custom AI agents and the boundary controls around them, and our AI consulting and AI security work increasingly starts at this exact line: what your agent may accept from an agent you do not own, and what evidence survives the exchange. We are based in Dallas–Fort Worth and deliver remotely nationwide, which suits work that is mostly architecture review, contract language, and logging design.
The protocols solved the hard engineering problem of making agents from different companies talk to each other. They left the organizational problem untouched, deliberately. That part is yours.
Agent2Agent (A2A) is an open standard, originally developed by Google and donated to the Linux Foundation, that lets AI agents built on different frameworks and owned by different organizations discover each other, exchange capability descriptions, send structured messages, and manage long-running delegated tasks. Remote agents publish a machine-readable Agent Card that advertises their skills, endpoints, and required authentication schemes, and the protocol is deliberately opaque, meaning agents collaborate without exposing their internal tools, memory, or logic.
What A2A does not cover is accountability. The specification standardizes transport, discovery, and task lifecycle. It does not define who is liable when a counterparty agent gives a wrong answer, what a claim from another company's agent is worth as evidence, how disputes are resolved, or what happens when an error propagates across an organizational boundary. Those remain contract and architecture problems, not protocol problems.
Treat it as an interoperability rider to the master services agreement and require six things in writing.
First, an authoritative identity: which cryptographic identity or credential represents the counterparty agent, and how a rotation or revocation is signaled to you. Second, an authority statement: which commitments that agent is empowered to make on its principal's behalf, and above what value or risk threshold a human on their side must approve. Third, capability change notice: advance written notice before the agent's advertised skills, model, or underlying subprocessors change materially. Fourth, mutual logging and evidence retention: both sides retain correlated transaction records for a defined period and produce them on request during a dispute. Fifth, an error and reversal procedure with a named response window and a defined path to unwind an erroneous transaction. Sixth, an explicit statement that output from their agent is not warranted as accurate unless the contract says otherwise, so you know whether you are relying on a warranty or on your own verification.
On its own, no. A protocol message proves that a party at a given endpoint sent a given payload at a given time, assuming you captured and retained the transport-layer evidence. It does not prove that the sending agent was authorized to make that commitment, that a human at the counterparty ever reviewed it, or that the claim inside it is true. Auditors and regulators still ask who authorized the transaction and on what basis.
To make cross-boundary agent activity defensible, log the counterparty's verified identity and credential, the exact request and response payloads, the authority basis you relied on such as a contract clause or a signed authority assertion, the internal control that validated the claim independently, and the human approval record where the value or risk crossed your threshold. If the only answer to why a payment changed is that the other side's agent said so, you do not have a control, you have a story.
We map every path by which an external agent could reach your systems, define the counterparty allowlist and value ceilings, design the boundary broker and the evidence log, and give your legal team the interoperability clauses to put in front of a vendor. You get an architecture and a contract position, not a protocol lecture.
Infonaligy