A2A, MCP, and the Agent Standards Race: Why Interoperability Needs Governance

Interoperability became the new agent battleground

In August 2026, Axios reported that Google's Agent2Agent protocol, A2A, was moving under the Agentic AI Foundation. The point of A2A is straightforward: independent agents need a standard way to communicate across platforms.

That move sits next to the rapid adoption of the Model Context Protocol, MCP. MCP addresses a different layer: it gives AI applications and agents a common way to connect to tools, services, databases, file systems, and APIs.

Together, the pattern is clear:

• MCP: how an agent reaches tools and data
• A2A: how agents talk to other agents
• governance: how the enterprise decides what any of them are allowed to do

The first two are becoming standards conversations. The third is the enterprise control problem.

Standards make adoption easier and risk easier to spread

Interoperability is valuable because it reduces integration work. A team can plug an agent into a tool ecosystem without building every connector from scratch. Another team can let agents collaborate across boundaries instead of hard-coding one workflow.

But the same property creates risk. If a standard makes it easier to connect, it also makes it easier to over-connect. A poorly governed agent can inherit too many tools, trust too many descriptions, call too many endpoints, and pass data through too many hops.

Microsoft's June 2026 security research explains why this matters. As agents move from reading to acting, a prompt injection against an agent can trigger an action. Microsoft also walked through an MCP tool-poisoning pattern where a tool description change could redirect an agent's behavior and cause sensitive data to be sent through a tool call.

That is the real lesson of the standards race. The question is not whether MCP or A2A is good or bad. The question is whether the organization has a control plane around the capabilities those standards expose.

Agent authorization is becoming its own discipline

The World Economic Forum's May 2026 agent playbook framed the issue as authorization. Organizations need to define the conditions under which agents are authorized to act, and they need enforcement that keeps working as systems evolve.

That is a useful framing because agents do not map cleanly to old governance categories.

They are not only users. They may act on behalf of users, teams, services, or workflows.

They are not only applications. They may choose tools dynamically and compose actions at runtime.

They are not only models. Many agents may share a model while having very different scopes, data access, and allowed actions.

That is why governance has to move from "which model did we approve?" to "which agent identity can use which capability under which policy?"

MCP is the immediate control point

A2A matters because agent-to-agent workflows are coming. But for most enterprises, MCP is the immediate risk surface because it connects agents to systems that can read, write, spend, delete, create, search, and modify.

Odock's data room calls MCP governance the differentiator for exactly that reason. An MCP server is not just an integration. It is a bundle of capabilities. Some tools may be harmless, some may expose sensitive data, and some may be destructive. Treating the whole server as allowed or denied is too blunt for production.

Odock governs MCP at the tool-call level:

Server registry. Approved MCP servers are registered centrally instead of discovered informally by each agent team.

Grants. Access is scoped to virtual API keys, teams, or workloads.

Tool allowlists. A key can expose only the tools the agent actually needs.

Tool blocklists. Destructive or risky actions can be blocked explicitly.

Semantic payload filters. Tool-call payloads can be inspected for dangerous patterns before execution.

Upstream auth injection. Credentials stay in Odock, so agents do not handle secrets directly.

Usage records. Tool calls are attributed to key, team, server, tool, cost, status, and outcome.

That set of controls is what turns MCP from an open capability surface into governed infrastructure.

The next governance layer will span agent chains

As A2A adoption grows, the same principles will need to apply across chains of agents. The control plane will have to understand not only "agent A called tool X" but also "agent A delegated to agent B, which used tool X under policy Y."

The shape of the answer is already visible:

• every agent needs a non-human identity
• every delegation needs scope
• every tool call needs authorization
• every high-impact action needs a halt or approval path
• every cross-agent workflow needs traceability
• every policy decision needs to be reconstructable later

This is why agent interoperability and AI governance are becoming the same conversation. The standards define how agents connect. The governance layer defines whether they should.

What enterprises should do now

Do not wait for the agent standards ecosystem to settle before building controls. The direction is already clear enough.

Create an inventory of MCP servers and agent connectors. Identify which tools can read sensitive data, write to business systems, spend money, or change production state.

Replace shared provider keys with scoped virtual API keys. The key should carry owner, team, model access, MCP access, budget, quota, and policy context.

Move from server-level approval to tool-level approval. "This agent can use GitHub" is too broad. "This agent can read issues and open pull requests, but cannot delete repositories or modify secrets" is closer to production governance.

Inspect tool metadata and payloads. Tool descriptions are part of the agent context, and payloads are where sensitive data often leaves the boundary.

Record every action. If an incident involves an agent chain, an MCP tool, and a provider response, teams need one evidence trail.

A2A and MCP are making agentic AI more interoperable. That is good for adoption. It is also exactly why the governance layer now matters. The more agents can connect, the more enterprises need one place to decide, enforce, and prove what those agents are allowed to do.

Sources

• Axios, Google-backed agentic A2A protocol gets a new home, August 17, 2026
• Microsoft Security, Securing AI agents: When AI tools move from reading to acting, June 30, 2026
• World Economic Forum, AI Agents in Action: A Playbook for Trusted Adoption, Authorization and Scaling, May 26, 2026
• Microsoft for Developers, Securing MCP: A Control Plane for Agent Tool Execution, April 22, 2026
• Odock MCP Servers documentation
• Odock MCP Security documentation