Governing Citizen-Developed AI Agents

7 min read

MCP standardises how an agent reaches a firm’s systems and standardises nothing about whether it should: the protocol secures the pipe, not the counterparty, and hands server-controlled text to the model as instructions.

The mechanism

Anthropic published MCP in November 2024 to kill the M×N connector problem, where every agent framework needed a bespoke integration for every tool. It worked. By the end of 2025, 20 of the 30 systems in the AI Agent Index supported it, NIST’s control-overlay scenarios assume it as the data-access layer, and Anthropic counted more than 10,000 active public servers. Stewardship moved to the Linux Foundation’s Agentic AI Foundation in December 2025, so describing MCP as an Anthropic protocol in the present tense is now wrong.

Three roles. The host is the user-facing application. The client is the connector inside it. The server is a separate process exposing three things: tools, resources and prompts. One detail inverts the trust direction: a server can call back into the model through sampling/createMessage, requesting a completion from the client. The spec makes human review of that a SHOULD, not a MUST, and nowhere requires the host to disclose where the message originated, so a host that never warns anyone is fully compliant.

The transport decides the trust boundary, and this is what firms get wrong most often. stdio launches the server as a local subprocess: same machine, same trust boundary as the host, no network exposure. Streamable HTTP makes it a network service that inherits every authentication and access-control requirement of an ordinary web application. Those are a local plugin and a public API rather than two settings of one thing, and only one of them needs an identity story.

Tool descriptions are what make MCP a governance object rather than a plumbing detail. When a client calls tools/list, the server returns each tool’s name, description and input schema, and the client places that text in the model’s context window. No revision of the spec requires the client to validate it. Whoever writes the tool description is writing into the prompt, and nothing pins it: a server that behaved during review can return different text next week. The model is the only thing between a server’s text and a tool call. The sharpest phrase in this literature is the LLM as trust boundary, and it explains why patching servers cannot close the gap. Tool poisoning appears in 5.5% of 1,899 open-source servers studied, and a survey of 67,057 entries across six public registries found none of the six performing adequate vetting, identity or integrity checks.

Authentication arrived late and remains optional. The original November 2024 spec mandated nothing. OAuth 2.1 came in the 2025-03-26 revision, hardened in 2025-06-18 (servers as OAuth resource servers, RFC 8707 resource indicators), refined again in 2025-11-25. The current revision is 2026-07-28. That is four authorization models in twenty months, and the spec still only defines how authentication works if a server chooses to require it.

The field data follows. A May 2026 measurement of 7,973 live remote MCP servers found 40.55% exposing tools with no authentication at all, and every one of the 119 OAuth implementations tested carried at least one flaw. Knostic’s 2025 internet scan found 1,862 exposed servers and sampled 119, all unauthenticated. Microsoft’s own App Service team puts OAuth adoption at 8.5%.

The protocol carries no governance primitives: no enforceable action constraints, no audit-grade provenance, no message signing, no replay protection. TLS defends the channel against a network attacker and says nothing about a hostile counterparty at the far end. The 2025-11-25 release did add governance of the project (working groups, a proposals process), which is a different noun from governance in the protocol, and vendor decks conflate the two.

What to do

Treat the client configuration as the security decision, not the server list. Vetting servers is necessary and cannot fix a spec-level gap: patching the RCE in Anthropic’s MCP Inspector (CVE-2025-49596, CVSS 9.4) does nothing about unvalidated tool descriptions, and fixing a path traversal does nothing about sampling. Anthropic’s own filesystem server carried two sandbox escapes (CVE-2025-53109, CVE-2025-53110), which rules out first-party provenance as a vetting tier of its own.

Sort servers into three classes and demand different evidence from each. Databricks ships this taxonomy in product and it maps onto vetting cleanly: managed (the platform runs it under its own controls), external (a third party’s, reached over the network), custom (a firm’s own code against its own APIs). External is where the supply-chain exposure concentrates; see supply-chain vetting.

Ask where the stdio servers are running. The answer is usually employee laptops, because desktop assistants support local MCP servers while the cloud assistants generally accept remote connectors only. That asymmetry makes the desktop the citizen developer’s entry point into MCP and the place the inventory cannot see. Worse, endpoints now arrive bundled: agent plugin formats package MCP configuration alongside skills and hooks, so a server installs as a side effect of a plugin nobody reviewed as an integration.

Then count. In the most instrumented environments Snyk scanned in mid-2026, single environments ran 80 or more MCP servers at once. That number, not any adoption percentage, is the argument for agent inventory.

How you’d know it’s working

A firm can answer, for one named agent, which servers it reaches, over which transport and under which identity, from a system of record rather than by asking the person who built it.

Every remote server the firm connects to requires authentication, checked rather than assumed. Against 40.55% and 8.5%, assumption is indefensible.

The client configuration gates or disables sampling, or someone can say deliberately why it is on. Almost nobody has made this decision consciously, which makes it the cleanest single test of whether MCP was configured or merely enabled.

What this doesn’t solve

MCP is an integration standard, so nothing in it addresses what the agent does with the integration. A perfectly authenticated server still hands the model text and the model still acts on it. See prompt injection and goal hijack.

Fixing the protocol is not on offer. Research proposals exist for capability attestation and message authentication, with encouraging numbers from their own authors; none of it is in the spec and no vendor ships it. The repaired MCP is speculative, and one such proposal was even renamed between its published and circulated versions, so treat names in this area loosely.

Adoption metrics mislead in a specific direction. The AI Agent Index notes that platforms supporting MCP often promote proprietary connectors ahead of it, so “supports MCP” and “uses MCP” are different facts. Attach a date to any figure here: the same vendor’s telemetry moved by roughly a factor of two and a half in seven months.

MCP is also not the only protocol a firm will be asked about. A2A (Google, April 2025; Linux Foundation, June 2025) handles agent-to-agent coordination and ships identity without policy enforcement. AP2 (September 2025) covers agent payments under signed mandates. Both inherit the structural gap: transport and discovery are specified, enforcement is left to the adopter.

See also

Graph View

Backlinks