The Model Context Protocol is where an agent finds out what it may touch. That makes it a control surface, not plumbing.
Discovery is not search. It is the moment an agent's autonomy meets the institution's boundaries, and learns where they are.
The Model Context Protocol is an open standard for how a model-driven application connects to external context and capabilities. It defines a common shape for the tools a server makes available, the resources it can expose, and the way a client negotiates with it. For a human, a capability catalogue is a web interface. For an agent, it has to be something the agent can speak to natively, and MCP is that something.
Exposing a catalogue as an MCP server is the decision that turns a registry into a gateway. An agent no longer needs a hardcoded address for a capability or a bespoke client written for it. It speaks the protocol, discovers what exists, and calls what it is permitted to call. Which is precisely why the protocol boundary is a governance boundary: whatever the prompt says, what an agent can actually do is decided here.
Where others see a protocol as plumbing, I see the membrane through which an institution decides what its agents are allowed to perceive.
Prompt Systems & Agent Orchestration · Chapter 7.2An agent is not a user, and treating it as one borrows a human's authority for a machine's actions. Agent identity has to be distinct, attributable and revocable.
Scope per agent, not per system. The catalogue an agent can see should already be the catalogue it is allowed to use, so discovery and permission do not disagree.
Capabilities change under the agents that call them. A version an agent was approved against is part of the approval, not an implementation detail.
Resources exposed over the protocol are data-protection surface. Residency, minimisation and purpose limitation apply here exactly as they do to any other access path.
Every discovery and every call, with the identity, the version, the arguments and the outcome. If the log cannot reconstruct what an agent did on a given day, the institution cannot answer for it.
The ability to withdraw a capability from a running agent, quickly, without redeploying it. Governance that requires a release to enforce is not enforcement.
None of this is exotic. It is the ordinary discipline of an integration boundary, applied to a boundary most institutions have not yet noticed they own. The failure mode is not a sophisticated attack; it is an agent quietly holding broader permission than anyone intended, because the permission was granted once to make a demo work.
It is the set of controls applied at the Model Context Protocol boundary: which agent identity is calling, what it is authorised to discover and invoke, which version of a capability it is approved against, what data the exposed resources reveal, what audit record each call leaves, and how a capability can be withdrawn from a running agent. MCP defines how a model-driven application connects to tools and resources; governance decides what that connection is permitted to reach.
Because it is where an agent learns the limits of its own autonomy. Whatever a prompt instructs, what an agent can actually do is determined by what the protocol exposes to it. That makes discovery a control point: the catalogue an agent can see should already be the catalogue it is permitted to use. Treating it as plumbing means the permission model lives in prompts, which are neither auditable nor enforceable.
An agent acting under a human user account borrows that human authority for machine-speed actions, which breaks attribution and usually over-grants. Agent identity should be distinct, attributable to the workflow it serves, scoped to the capabilities that workflow needs, and revocable independently of the human. When something goes wrong the question is which agent, under whose sponsorship, with what permission, and a shared account cannot answer it.
Enough to reconstruct behaviour without reading the model. At minimum the calling identity, the capability and version invoked, the arguments, the outcome, and the discovery events that preceded it. Discovery matters because it shows what the agent was offered, not only what it chose. The test is whether the log answers a question asked eighteen months later by someone who was not there.
Yes, and often more urgently, because a single vendor integration tends to be granted broad access early and narrowed later, if ever. The controls are the same regardless of how many servers exist: distinct identity, scoped authorisation, versioned approval, audited calls, and a revocation path that does not require a release.
The method is published in full. What an engagement adds is the examination, with the evidence attached.