MCP and A2A Are Protocols, Not Governance

2026-09-01 · Engineering ·

You wired up an MCP server last month. Maybe three. Your agents can now reach your issue tracker, your database, your deploy pipeline — and somewhere in the back of your mind is the question you have not been able to answer with evidence: does any of this prove that your source code and business data stay private, and that the things calling your tools are the things you approved? This post is about why the protocols themselves will never answer that question for you — because in 2026, researchers measured what the protocols actually guarantee, and the answer is: message delivery, not governance.

The narrow waist, again

The Model Context Protocol standardizes how a model-driven application reaches tools and context (specification). The Agent2Agent protocol, a Linux Foundation project contributed by Google, standardizes how independent agents talk to each other (a2a-protocol.org). Both are genuinely useful — the same way IP was genuinely useful. The internet scaled because its middle contract stayed small, and the agent ecosystem is re-discovering that shape. The Koinessa white paper calls this the narrow waist, and the companion post on fifty years of systems lessons walks through why the pattern keeps repeating.

But the internet standardized packet delivery without solving identity, fraud, or trust. Agent protocols are repeating that pattern almost exactly.

Start with what the specifications actually commit to. MCP's HTTP authorization framework, in the 2026-07-28 revision, is OAuth 2.1-based — and optional at the protocol level (authorization spec). A conformant MCP deployment can expose tools with no authorization layer at all and still be conformant. A2A 1.0's Agent Cards may carry JSON Web Signatures; when a client verifies a signature against a trusted key, it establishes card integrity and provider origin (spec section 8.4). Note the load-bearing words: may, when verified, against a trusted key. Signing is optional, the signatures field is not required, and nothing in the spec constitutes a universal agent identity system. A signed card tells you the card wasn't tampered with and came from whoever holds that key. It does not tell you whether you should trust that key, what the agent is allowed to do on your behalf, or how to take that permission back.

What 7,973 live servers actually look like

That gap between "the protocol supports authentication" and "deployments enforce it" is not hypothetical. The first measurement study of authentication security in the remote MCP ecosystem identified 7,973 live remote MCP servers and found that 40.55% expose tools without any authentication at all (arXiv:2605.22333).

The more interesting finding is what happened on the authenticated half. OAuth is the dominant authorization mechanism for remote MCP servers, but MCP deployments differ from traditional OAuth in three ways: open client environments, dynamic client registration, and delegated authorization. The authors built a taxonomy of four flaw categories and nine concrete flaw types from those differences, then applied a semi-automated detection framework — passive traffic inspection plus active probing — to the 119 testable real-world OAuth-enabled servers. Every single one exhibited at least one flaw: 325 flaws in total, with dynamic-client-registration flaws affecting 96.6% of tested servers. Many of the flaws enable sensitive-information leakage or account takeover, and responsible disclosure produced nine CVE IDs.

Two qualifiers matter, and the white paper states them plainly. This is a May 2026 arXiv v1 snapshot of the servers the researchers could find and test — it does not establish a universal property of all MCP deployments. And "OAuth-enabled" means these were the servers that tried to do authorization correctly. The protocol gave them an optional framework; the ecosystem's implementations of it were, in this snapshot, uniformly flawed.

The protocol-level attacks

The second study goes deeper than deployment hygiene. "Breaking the Protocol" is the first rigorous security analysis of the MCP specification itself, and it scopes its findings to MCP v1.0 (arXiv:2601.17549). It identifies three protocol-level vulnerabilities:

The authors built MCPBench, a harness bridging existing agent-security benchmarks to MCP-compliant infrastructure, and ran 847 attack scenarios across five MCP server implementations. MCP's architectural choices amplified attack success rates by 23–41% compared to equivalent non-MCP integrations. Their proposed MCPSec extension — capability attestation plus message authentication, backward-compatible — cut attack success from 52.8% to 12.4% at 8.3ms median added latency per message. That proposal exists precisely because the base protocol does not include those mechanisms.

Fairness requires the other half of the sentence: the attack analysis scopes those risks to MCP v1.0, and the current specification drafts carry security mitigations and best-practice guidance (MCP security best practices, draft). Guidance is not enforcement. The white paper's summary is the one worth keeping: untrusted server and tool content still requires client-side validation, isolation, and authorization — which the protocol leaves to you.

Protocols carry messages; governance is a separate layer

The through-line across both studies and both specifications: MCP and A2A are connectivity layers. They define how a request reaches a tool, how an agent describes itself, how messages flow. What remains incompletely standardized is everything above that — the white paper lists it as delegated authority across agent chains: capability attenuation, work-item authority, policy inheritance, revocation, evidence provenance, replay protection, reputation, and end-to-end accountability from principal to agent to tool to outcome.

This is the same lesson as the 1974 internet protocols, restated for agents. Nobody expects TCP to decide who is allowed into your building. Expecting MCP's optional OAuth framework or A2A's optional card signing to decide which agent may touch which repository is the same category error — and it is exactly the error behind the privacy question at the top of this post. Your source code and business data stay private only if a layer above the protocol enforces membership, delegation, and revocation as structural properties, not as conventions each vendor implements differently — or, per the measurement study, implements with at least one flaw each.

How Koinessa applies it

Koinessa treats agent protocols as plumbing and builds the governance layer above them, on customer-controlled infrastructure. Three pieces matter here.

Everything external enters through one gated surface. Koinessa exposes 366 registered tools behind a single search contract, and every harness — Claude, Kimi, Grok, and the Devin CLI in a guarded sandbox — reaches that contract through the same local MCP surface (live). Tool invocation blocks are data: transport, command, arguments, endpoint. Nothing is inferred from a name, and nothing reaches the tool layer without crossing the boundary.

Authority and provenance are structural fields, not prose. Because anything that reaches a model's context can carry text the model misreads as instruction — the exact mechanism behind the Breaking the Protocol server-side injection finding — every context-packet source in Koinessa carries a typed authority class: operator, verified, evidence, agent, inferred, unknown (live). EGD-002 hardened this boundary with an external-untrusted class and compile-time rejection of packets whose untrusted content would land in an authoritative section (live, closed 2026-08-15). A poisoned tool result cannot launder itself into policy, because the distinction is checked by the compiler, not guessed by the model.

New providers are admitted disabled, then earn enablement. The unified provider layer holds six provider descriptors — all disabled, behind a fail-closed enabled flag (built-but-gated). The sixth descriptor's onboarding is the worked example: before any enablement, Koinessa committed a deny-all guard and proved it with an in-tree canary whose only tool call was refused. The data-governance precondition was verified rather than assumed — the vendor's terms state customer data may be used for model training with a paid-tier opt-out enabling zero-data retention with its model providers, and the operator moved to the paid tier and confirmed the opt-out before the first governed probe (operator-reported, 2026-08-23). That is what "proof that my data stays private" looks like in practice: not a protocol badge, but a sequence of gates with receipts. The broader Koinessa architecture post covers the surrounding planes, and the risk-tiered autonomy post covers why enablement stays an operator decision.

Agent-network governance above MCP/A2A — membership, delegation, revocation, replay — is on the public roadmap with an honest status label: the local substrate is live (EGD-002 done at 100%, 12/12 and review-approved), while cross-network membership remains planned. The limitations and status report keeps that distinction visible rather than aspirational.

The takeaway

The 2026 studies gave the agent ecosystem its first hard numbers: 40.55% of 7,973 probed live MCP servers expose tools without authentication, and all 119 testable OAuth-enabled servers in that May 2026 snapshot carried at least one flaw — while a protocol-level analysis of MCP v1.0 showed that the architecture itself, not just its implementations, amplifies injection attacks. Neither MCP's optional OAuth framework nor A2A's optional JWS card signing answers the question that opened this post. Protocols carry messages; governance — membership, delegation, revocation, replay protection, provenance — is what makes an agent network safe, and governance is a layer you build or adopt above the protocol, on infrastructure you control, with fail-closed verification at every boundary. The full argument, with every citation and its qualifiers, is in the Koinessa white paper.