MCP governance.
The Model Context Protocol is where an agent finds out what it may touch. That makes it a control surface, not plumbing.
A registry becomes a gateway.
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 and Agent Orchestration · Chapter 7.2Six questions an MCP boundary must answer.
Who is calling?
An 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.
What may it call?
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.
Which version does it trust?
Capabilities change under the agents that call them. A version an agent was approved against is part of the approval, not an implementation detail.
What may it perceive?
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.
What record survives?
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.
How is it stopped?
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.
The same six questions, answered in public.
This site runs an MCP server at mcp.nabeelkhan.com, open and without a key. Its answers to § 02 are below, including where they are deliberately nothing.
Nobody, and that is the answer.
There is no authentication. Ten of the twelve tools only read, and nothing they read is a secret: work already published on this site, open consultation slots, text the caller supplied and got back normalized. A credential in front of that protects nothing while adding a secret for both sides to manage. Identity earns its cost where an action has consequences, and only two of these tools act at all, booking a call and sending a message. Here the boundary is drawn around what a tool may do, not around who may call it.
Ten may read. Two may act.
Every tool publishes its read-only status in the server card at /.well-known/mcp/server-card.json, so a client learns the tool boundary by reading the catalogue rather than by attempting a call and being refused. Tool discovery and tool permissions cannot disagree here, because the catalogue is the permission.
Drift fails the build.
The corpus the tools answer from is derived from the published pages, and a sync check compares the server’s vendored copy against the canonical origin before it will build. It has caught a real divergence: the server served pre-normalisation book titles while the site served corrected ones. A stale answer is a failed build, not a quiet difference of opinion.
Nothing that is not already public.
There is no private store behind the interface. Every answer resolves to a page anyone can open, and returns the URL it came from so the reader can go and disagree with the source. Minimisation is not a policy applied to this surface; there is nothing else on it.
The call, not the payload.
One structured line per invocation: tool name, outcome, duration. The arguments are deliberately never recorded. That is a straight contradiction of § 02, and the paragraph below explains why the opposite answer is correct on this side of the boundary.
A ceiling, and an instruction.
Enforcement sits at the edge and is spent before any compute, so the thing that protects the bill cannot be reached by the traffic it is refusing. Inside it sits a lower courtesy threshold that answers with Retry-After, because a bare 429 teaches a client nothing and it retries straight back into the wall. Tool execution controls that only refuse produce worse behaviour than ones that instruct. The thresholds themselves are not published, for the ordinary reason.
On the contradiction. Section 02 says an institution should log the arguments, and it should. This server does not, and that is not an exception to the rule so much as the same rule read from the other side of the boundary. An agent operating inside your estate acts on your data under your sponsorship, and the argument list is the record of what it did on your behalf: you own both ends, and logging it is your audit duty. This server receives the confidential situation of whoever called it — the tool that routes a described problem to an engagement shape is handed exactly the sentence a firm would not want retained — and it is not our record to keep. Tool-level observability here answers the operational question, which is whether anything calls this and which tools, and stops there.
On what is not claimed. Two answers above are nothing, and they are only defensible because of what this surface is. A read-only public corpus can decline identity and minimisation honestly; an interface that reaches an institution’s own systems cannot, and would need every control in § 02 built properly. The value of a worked example is that it shows where a design earns its simplicity, not that it transfers.
What teams ask.
What is MCP governance?
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.
Why treat MCP as a security boundary rather than integration plumbing?
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.
How is agent identity different from user identity?
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.
What should be logged at the MCP boundary?
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.
Does this apply if we only use one vendor assistant?
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.
Find out where you actually stand.
The method is published in full. What an engagement adds is the examination, with the evidence attached.
Ask your AI assistant instead.
This page is a snapshot, accurate at the release it cites. The same corpus is callable, publicly and without a key, so an assistant can query it live and return an answer carrying the source it came from. For this page that is search_knowledge and identify_relevant_service, which search the published corpus behind this page and return matches with the URL each came from, then map a described problem to an engagement shape and show the routing rather than assert it. Useful when you have a specific situation rather than a general question, because the page cannot know yours and the tools can be told.
claude mcp add --transport http concylium https://mcp.nabeelkhan.com/api/mcpClaude Desktop, ChatGPT, Cursor, VS Code and Gemini CLI take the endpoint on its own: https://mcp.nabeelkhan.com/api/mcp. No key, no account, nothing to sign. Setup for every client.
“Using Concylium, search the corpus for what governs this, then tell me which engagement shape fits my situation and why.”
The page answers the general question. The tools can be told your specific one, and they show the reasoning behind the answer they give.