MCP Is Becoming a Governance Surface.
A protocol is being adopted as plumbing. It behaves like an access policy, and almost nobody is reviewing it as one.
Every field is a decision
Look at what actually crosses an MCP boundary.
A tool definition tells the agent that a capability exists. That is a disclosure: the agent now knows the organisation can do this thing, and will reason about it.
A parameter schema tells the agent what it may vary, which is a permission expressed as a type.
A resource exposes data. What is included is disclosed. What is withheld is a control, and it is usually a control nobody realised they were exercising.
A tool description tells the agent when to reach for the capability. That is closer to policy than to documentation, and it is typically written by whoever implemented the tool, in an afternoon, without review.
None of those look like governance artifacts. All of them determine what the agent can perceive, reason about and attempt.
Why it slips through review
Governance review processes are shaped around things that look like decisions: a new system, a new data flow, a new vendor, a model change.
An MCP server does not look like any of those. It looks like an adapter. It ships in a pull request, it is reviewed by engineers on correctness rather than on disclosure, and the question "what does this now let an agent see" is not on anyone's checklist because the artifact is not on anyone's inventory.
So the reviewed surface is the model and the policy document, while the surface that actually determines agent perception is a set of tool definitions that no governance function has read.
Three things worth doing
Inventory the tool surface. Not the servers, the tools. What can each agent call, what does each call disclose, and who approved that. If this list does not exist, no statement about agent scope can be verified.
Treat descriptions as policy text. A tool description is an instruction to a reasoning system. It should be reviewed with the care given to a policy, because that is the function it performs, and because it is a natural target for anyone trying to influence agent behaviour through content.
Bind the boundary to identity. The same protocol serving two agents at different trust tiers should not expose the same surface. If it does, the tier is decorative.
The security dimension
Worth stating plainly, because it is where the two concerns meet.
An agent can be persuaded by the content it reads. That is not a defect to be patched out; it is what a system built to follow instructions in text does. So the useful question is not whether an agent can be talked into attempting something, but what happens when it succeeds.
That is a permissions question, and the protocol surface is where the permissions are effectively set. Hardening the model is worth doing and does not bound the outcome. Narrowing what the protocol exposes does.
The opportunity in it
This is not an argument against MCP. It is an argument for recognising what it has become.
A protocol layer that is explicit, inspectable and versioned is a far better place to enforce a boundary than a policy document, precisely because it is machine-readable and sits in the execution path. Governance that can be expressed as a diff is governance that can be reviewed, tested and audited.
The same property that makes the protocol a risk when it is unexamined makes it the most promising control point in the stack when it is. It is one of the few places where governance can genuinely stop being paperwork and become architecture.
The question is simply whether the organisation is reviewing it as plumbing or as policy. Right now, most are reviewing it as plumbing.
© 2026 Nabeel Khan. MCP Is Becoming a Governance Surface is published under CC BY-NC-ND 4.0. Quote it, cite it, do not repackage it.