MCP and Agent Interoperability: The Integration Layer Enterprises Need

MCP has strong reported momentum as a socket for connecting agents to enterprise tools, and the controls around it have matured more slowly. The specification says it cannot enforce its own security principles at the protocol level ^[1], authorization is optional ^[2], and in a study of open-source MCP applications mined from GitHub only 37.2% put a blocking approval step in front of tool execution ^[3]. That study does not measure enterprise deployments.

The integration layer enterprises need is therefore not another protocol. It is the control plane around the protocols: discovery, identity, authorization, mediation and audit. This article sets out where the standards stand on 13 October 2026 (the current MCP revision is 2026-07-28 ^[4]), what has gone wrong in real deployments, and three NKK models for building that layer. The models are NKK's opinion, built on the cited material. They are not measured results.

Who steers the standards now

MCP's stewardship changed in December 2025. Its technical governance did not. Anthropic donated MCP to the Agentic AI Foundation (AAIF), which its announcement describes as a directed fund under the Linux Foundation, and said MCP's governance model would remain unchanged ^[7]. The project's governance page now names it "Model Context Protocol a Series of LF Projects, LLC" and says technical decisions sit with individual maintainers, with no seats reserved for specific companies, and Lead Maintainers hold final authority ^[8]. Changes go through Specification Enhancement Proposals ^[8].

A2A took a parallel path. Google created it, the Linux Foundation began hosting it in June 2025 ^[9], v1.0.0 was tagged on 12 March 2026 ^[10], and in August 2026 the project announced its acceptance as a Growth Stage project of AAIF ^[11]. IBM's Agent Communication Protocol has merged into A2A ^[12]. AAIF grew from 146 members in February to 247 in August 2026 ^[13][5].

What the evidence does not show. Membership measures sponsorship, not production use. Server counts are self-reported and defined differently, from over 10,000 active public servers ^[7] to about two thousand registry entries ^[14] to a 64,611-server research crawl ^[15], and close to half a billion monthly downloads of the Tier 1 SDKs ^[16] do not count users.

MCP and A2A solve different problems

The projects' own positioning is consistent: MCP connects an agent to its tools and context, A2A connects agents to one another ^[18]. The 2026-07-28 MCP revision changes which one carries a given interaction. The protocol became stateless: protocol-level sessions were removed, every request carries its protocol version and client capabilities, and long-running Tasks moved out of the core into an official extension ^[17]. The maintainers say this brings migration cost for teams that relied on session identifiers ^[16].

So conversational state and task lifecycle are now an extension or an application concern in MCP, and a native concept in A2A, which defines a Task with a lifecycle ^[19]. The only direct comparison we found is a University of York experience report that built one multi-agent task on both. MCP was lighter to implement but left state to the application; A2A supported stateful multi-turn work at substantially greater implementation complexity ^[20]. It is a single experience report on one task and one model, and reports implementation effort, not performance: 1,255 lines of code for MCP against 1,898 for A2A ^[20].

Trust works differently too. A2A Agent Cards may be signed with JSON Web Signatures and clients should verify a signature before trusting a signed card ^[19], while the foundation's release highlights signed cards as a v1.0 feature ^[6]. Signing is optional, so it is a capability, not a guarantee. AGNTCY, a separate project, provides a directory, secure messaging (SLIM) and identity components ^[21]; SLIM documents integrations for both A2A and MCP ^[22].

NKK Protocol Fit Matrix

Our default rule is to use the lightest surface that fits. Ask two questions of each integration. Is the counterparty outside your control? Does the work outlive a single call?

• No, no: use MCP through your gateway.
• No, yes: use the MCP Tasks extension or in-house orchestration.
• Yes, no: use remote MCP with OAuth and audience binding, or a plain API.
• Yes, yes: use A2A with verified Agent Cards, so the counterparty's agent keeps its own state and identity.

Where it breaks: it rests on official positioning and one experience report ^[20]. Real systems mix both, and gateways can bridge them. Amazon Bedrock AgentCore Gateway, for example, supports passthrough targets that include A2A traffic ^[23]. Use the matrix for a default, then challenge it.

What goes wrong in real MCP deployments

Public evidence consists of incident reports and measurement studies. There are no published incident rates. The reported incidents fall into four classes.

1. The client is compromised. The mcp-remote package was exposed to OS command injection when connecting to untrusted servers (CVSS 9.6, fixed in 0.1.16) ^[24]. MCP Inspector, the project's developer tool, allowed remote code execution before 0.14.1 because it lacked authentication ^[25].
2. A legitimate server meets an over-permissioned agent. Invariant Labs showed that a malicious issue in a public repository could steer an agent connected to the GitHub MCP server into leaking private repository data. They describe an architectural problem that server-side patches cannot fix ^[26]. This is one demonstration by a security vendor, not a prevalence measure.
3. The supply chain is poisoned. A fake postmark-mcp npm package built trust over 15 versions before version 1.0.16 began blind-copying email to an external server; Postmark says it had nothing to do with it ^[27].
4. Tenant isolation fails. Asana found a bug in its MCP server on 4 June 2025, took the feature offline from 5 to 17 June and warned that information could have been exposed to other MCP users. No exploitation was reported ^[28].

Static analysis of 1,899 open-source servers found 7.2% with general vulnerabilities and 5.5% with MCP-specific tool poisoning, in a 2025 snapshot ^[29]. Scanner headlines deserve suspicion: scanners flagged 96.89% of the 37,288 interactable servers (from a 64,611-server crawl) as risky, counting a server if at least one of eight scanners flagged it. Manual validation of a 100-server sample found fewer than half of sampled alerts were true positives (mean per-scanner precision 45.53%, with five of the nine scanner configurations below 50%) ^[15]. The MCPTox benchmark ran 1,348 malicious cases against 45 live servers and 20 agents; attack success reached 72.8% for o1-mini and no tested agent refused more than 3% of attacks ^[30]. Those are 2025-era models; current ones may differ.

The OWASP MCP Top 10, still in beta, lists shadow MCP servers and missing audit telemetry among its categories ^[31].

The authorization profile MCP now expects

Authorization is optional in MCP. HTTP transports should follow the specification; stdio should take credentials from the environment ^[2]. When used, the profile is demanding. MCP servers act as OAuth 2.1 resource servers and must publish Protected Resource Metadata ^[2][32]. Clients must send an RFC 8707 resource parameter, servers must validate that tokens were issued for them, and token passthrough is forbidden ^[2]. Clients should use pre-registered credentials where they have them, then Client ID Metadata Documents where the authorization server supports them, ahead of Dynamic Client Registration, which is deprecated ^[2][48]. The security guidance adds per-client consent for proxies, against the confused deputy problem, and warns that malicious servers can point discovery URLs at internal addresses ^[33].

Forrester's 2026 predictions make a conditional point: with an MCP server working with a platform's APIs, "AI agents can only access and act on authorized data, just like a human user" ^[34]. That holds only if the platform's API enforces the user's permissions, and the MCP authorization profile is itself optional ^[2].

For enterprises the notable piece is Enterprise-Managed Authorization. It lets the corporate identity provider decide which MCP servers employees can reach, using an Identity Assertion JWT Authorization Grant (ID-JAG), with revocation at the identity provider. It is opt-in and client support varies ^[35].

The open item is agent identity. MCP's own roadmap concedes that current authorization assumes a person with a browser:

The roadmap plans work on DPoP, workload identity federation and token exchange ^[36], the last being the RFC 8693 delegation model in which one party acts on behalf of another ^[37]. Standards bodies are earlier still. NIST launched an AI Agent Standards Initiative ^[38], and the NCCoE project on agent identity and authorization received more than 600 responses to its concept paper; its planned output is an SP 1800-series practice guide ^[39].

Gateways and registries: the enterprise pattern

The three vendors converge on a gateway as policy point with identity-provider authentication and telemetry; Azure and Google add a registry or catalogue for discovery. Azure API Management can expose REST APIs as MCP servers or front existing ones, applying JWT validation and rate limits, with Azure API Center as a private registry; it supports tools but not MCP resources or prompts ^[40]. AgentCore Gateway offers inbound and outbound authentication, semantic tool selection and auditing ^[23]. Google pairs Apigee and an API registry with IAM, audit logging and Model Armor ^[41]. This is our reading of vendor documentation.

The specification now makes this pattern practical. Method and tool names travel in HTTP headers so gateways can route and authorize without parsing bodies ^[16], and OpenTelemetry trace context is documented for tracing ^[17]. Tool names are unique only within a server, so aggregators should prefix them ^[42].

Registries need care. The official MCP Registry is a preview, holds only public servers, is not designed for self-hosting and delegates security scanning downstream ^[43]. Treat it as an upstream metadata source, not a trust decision.

What the evidence does not show. We found no independent measurement of enterprise gateway adoption or MCP-specific return on investment. Forrester predicted that 30% of enterprise application vendors would launch their own MCP servers in 2026 ^[34]; that is a forecast, and we found no evidence it was realised. Thoughtworks placed MCP in Trial in November 2025 and advised looking past the hype and adding security checks such as mitigating toxic flows, but the entry is not on the current edition, so the present ring is unconfirmed ^[44].

NKK Five-Control Integration Plane

For each integration, ask whether five controls exist and who owns them. A control without an owner is a gap. Mapped to the four incident classes, a compromised client is a Discover and Authenticate failure, an over-permissioned agent is an Authorize and Mediate failure, and a poisoned package is a Discover failure. Tenant isolation failure at a vendor, as at Asana, is prevented by none of the five apart from vendor selection under Discover: a residual gap needing vendor due diligence. The mapping is NKK's judgment.

Where it breaks: the controls are necessary, not sufficient. In NKK's inference, a gateway would not catch prompt injection through a legitimate server, the scenario Invariant Labs demonstrated ^[26]. Nor does the plane make the underlying model robust: in MCPTox, no tested agent refused more than 3% of attacks using poisoned tool descriptions ^[30].

The NKK Agent Integration Maturity Model

The plane describes controls; the maturity model describes how far an organisation has come in applying them. It is NKK's framework, not validated against incident data.

Use the ladder per domain, not per enterprise: finance integrations may sit at L2 while a developer sandbox stays at L0, if that is deliberate. L0 to L1 needs policy, not technology; L2 is mostly platform work. L3 depends on delegation standards such as RFC 8693 ^[37], on identity products such as Microsoft Entra Agent ID, which treats agents as distinct identities ^[45], and on MCP roadmap items not yet shipped ^[36]. L4 relies on optional signed cards ^[19] and on open research: one 2026 visionary paper argues that safety depends on trajectories, because individually permitted actions can collectively violate system constraints ^[46].

Where it breaks: levels can be skipped or worked in parallel, L3 and L4 depend on unfinished standards, and no evidence shows that higher levels predict fewer incidents. It is a planning aid, not a certification.

The scorecard below diagnoses each of the five controls; the ladder describes the overall posture of a domain. As an NKK rule, read the lowest-scoring control, not the average, against the ladder. A lowest score of 1 means L0; a lowest score of 2 means L1; all five at 3 means at least L2. L3 and L4 also need the agent-identity and cross-organisation signals above.

What to do next

1. Score and inventory (platform and security leads). Score each domain on the scorecard and set a target ladder level. Find every MCP server in use, including local and unsanctioned ones; shadow servers are an OWASP MCP Top 10 category ^[31].
2. Require the authorization profile for remote servers (security and identity). Audience validation and no token passthrough ^[2]; treat pasted API keys as debt.
3. Put a gateway and private registry in front (platform). Pin versions, treat tool annotations from untrusted servers as untrusted ^[42], and re-review tool descriptions when they change.
4. Gate consequential tools (security). Require blocking approval for tools that modify data, as OpenAI's documentation advises ^[47], and scope tools per role.
5. Plan the migration (platform). Deprecated features such as Dynamic Client Registration stay for at least twelve months (or at least ninety days under the expedited-removal exception) before removal ^[4]. Stateless MCP is a new revision, not a deprecation, and servers may support several protocol versions at once ^[4], so stage the move ^[16].
6. Pilot agent identity (identity). Give one internal agent its own identity in your identity provider, require delegated tokens (the RFC 8693 pattern ^[37]), and check that the audit log records both agent and user. Watch the NCCoE and MCP roadmap work ^[36][39].

Conclusion

The protocols are converging, though MCP and A2A still differ in state and trust models. The specification leaves authorization optional, agent identity is still a roadmap item, and the one measurement of approval gating we found, covering open-source applications, shows blocking approval in only 37.2% of them ^[3]. The layer enterprises need is the gateway, registry, identity and audit around the protocols, which NKK frames as three models plus a scorecard. Start by scoring each domain and naming an owner for its lowest control.