MCP governance: four decisions before a tool is available

Registering a server is not granting a capability

The Model Context Protocol makes it straightforward to expose tools to a model. That convenience is the point, and it is also where governance usually breaks down: a server gets registered for one team's use case and quietly becomes available to everything.

Availability should be the result of four separate decisions, each recorded independently.

Decision one: declare

Configuration names the server, its transport, a stable credential reference and the tool policy. Keeping this in Git means the addition of a new tool surface is a reviewed change with an author and a diff, not an afternoon's convenience.

Decision two: scope

Allowed scopes and team ownership constrain which pipelines, assistant conversations and operators can select the profile at all. A read-only Kubernetes profile scoped to staging is a different object from one scoped to production, even if the underlying server is the same.

Decisions three and four: authorize and audit

At call time, the platform evaluates the caller, the action, the resource and the runtime context before exposing or invoking a tool. Discovery itself is filtered — an agent should not be able to enumerate tools it may not use.

Afterwards, the selected profile, every tool call, each confirmation and the resulting outputs stay attached to the run. Configuration, scope, live authorization and evidence are four records, not one.

Why the four decisions have to stay separate

The temptation is to collapse them. Registration implies availability, availability implies permission, permission implies the call was fine. Each collapse is locally reasonable and collectively produces a system where nobody can say what a given agent may currently do.

Keeping them separate has a specific practical consequence: each decision has its own owner, its own review path and its own record. An admin registers a server. A team owner scopes a profile. The platform authorizes the call. The run holds the evidence. No single action moves a capability from "someone set this up" to "this ran against production".

That separation is also what makes the model auditable in the direction auditors actually ask. They rarely ask what a system can do. They ask what it did, under whose authority, and who agreed to it.

The registry belongs to the platform, not the pipeline

A rule worth adopting early: pipeline definitions may reference approved profiles but may not define servers. The moment a workflow file can point at an arbitrary endpoint, the reviewed tool surface stops being reviewed — anyone who can merge a pipeline can add a capability.

In practice this means the server registry is owned by system or global configuration, while team-level configuration consumes it. A team can build workflows freely on top of what has been approved. Adding to what has been approved is a different change with a different reviewer.

This is the same reasoning that keeps base images in a curated registry rather than letting each service pull from anywhere. The constraint is not about trust in colleagues; it is about keeping the surface enumerable.

What a server declaration should actually contain

A complete declaration names the transport, the endpoint, the authentication type, a credential reference and a timeout. The credential reference is the load-bearing part: the value lives in an encrypted registry with versioning and rotation, and the configuration carries only a pointer.

Timeouts deserve more attention than they usually get. An MCP server that hangs does not fail loudly; it holds a run open and consumes budget while producing nothing. A declared timeout converts that into a bounded, visible failure.

The endpoint field carries a common operational trap. Inside a container, localhost refers to the container itself, not the host — so a locally hosted MCP server generally needs a LAN address or the platform's host alias rather than the address that worked during development.

Profiles are the unit of approval

A profile is a named bundle of specific tools from a configured server, and it — not the server — is what a workflow references. This indirection is what lets one server support several genuinely different trust levels.

The same Git provider might back a read-only review profile available broadly and a narrower write-capable profile scoped to one team. The underlying connection is identical; the approved surfaces are not. Without profiles, that distinction has to be enforced by convention, which means it is not enforced.

It is also worth deciding deliberately where profiles apply. Attaching tool access to reasoning steps rather than to deterministic script steps keeps the surface aligned with where the non-determinism actually is — a script that needs an API can call it directly under its own authorization.

Scope is what stops sprawl

Scoping is the decision teams most often skip, and the one that most reliably causes trouble later. A profile approved for one team's staging work has a way of becoming the profile everyone references, because it exists and it works.

Allowed scopes and team ownership constrain which pipelines, conversations and operators can select a profile at all. The useful mental model is that a profile scoped to staging and the same profile scoped to production are different objects with different risk, even though the server behind them is the same.

A good hygiene check is to ask, for each profile, which scopes can select it and whether anyone remembers approving that. Profiles accumulate scope the way permissions accumulate anywhere else: quietly, one reasonable exception at a time.

Authorization happens at call time, not at configuration time

Configuration says a capability could be used. Authorization decides whether this caller may use it against this resource right now. Treating the first as if it were the second is the single most common governance failure in MCP deployments.

The check evaluates the caller, the action, the resource identified by the actual arguments, and the runtime context — every call, not once at session start. Arguments matter: a tool that reads a repository is not uniformly safe, because which repository is the entire question.

Discovery should be filtered by the same evaluation. If an agent can enumerate tools it may not use, it will eventually try, and the resulting denial is a worse outcome than the tool never having appeared — it tells a compromised reasoning step exactly what to aim at.

Confirmation as a first-class step

Read operations and mutations deserve different handling, and the difference should be structural rather than advisory. Requiring explicit confirmation before a mutating tool executes converts a class of accidents into a class of prompts.

Beyond ordinary mutations there is a category worth isolating further: operations with external or destructive side effects. Deleting stored data, sending mail, deciding an approval. These are better exposed through dedicated paths with their own confirmation semantics than reached through a general-purpose bridge.

The design goal is that no single tool call is simultaneously easy to reach, broad in effect and hard to reverse. Any two are manageable. All three is how incidents happen.

Exposing your own platform over MCP

The governance question runs in both directions. A platform that exposes its own MCP server to assistants and external clients has to answer the same questions it asks of others — and the answers are more consequential, because the surface is the platform itself.

The defensible posture is that the hosted server acts as the current authenticated user rather than as a privileged service. It does not elevate to admin. Each call re-checks the specific resource in its arguments, and the tool list a subject receives is already filtered to what that subject may use.

Write operations deserve a further constraint: returning validated proposals rather than mutating state directly. This keeps an assistant useful for drafting configuration while keeping the change on the same reviewed path as any other. A convenient interface to production should not be a second, quieter way into it.

Evidence that outlives the conversation

The fourth decision is the one that gets deferred, because it produces no immediate capability. It is also the one you cannot retrofit — evidence not captured at the time is simply gone.

What belongs in the record: which profile was selected, which tools were called with which arguments, what each returned, which confirmations were given and by whom, and how the run ended. Attached to the run, not scattered across provider dashboards with independent retention policies.

The test is temporal. Ask what a question about a run from six months ago costs to answer. If the answer depends on a log retention window you do not control, the evidence model has a gap regardless of how good the controls above it are.

Rolling this out without stopping the work

None of this requires a freeze. The workable sequence is to start with servers disabled by default, enable one profile for one team against a non-production scope, and let the reviewed path be the fast path rather than the obstacle.

Two habits keep it from decaying. Register examples and templates disabled, so a demonstration configuration never quietly becomes production capability. And commit the intended registry to the repository that owns it, so the reviewed state and the running state can be compared rather than assumed equal.

The measure of success is not how many tools are available. It is whether anyone can produce, on request, the current list of what can reach production and who approved each entry.

Ownership across teams

In any organisation past a certain size, the four decisions have different owners, and the model has to make that workable rather than merely correct. A platform team registers servers. Team owners scope profiles into their own boundaries. Individual engineers build workflows on top.

The arrangement that fails is the one where every profile request routes through a single overloaded team. The reviewed path becomes the slow path, and people work around it — usually by widening a profile that already exists rather than requesting a new one, which is the worst available outcome because it is invisible.

The arrangement that works gives teams real authority inside their own scope while keeping the registry central. A team can compose freely from what is approved and take responsibility for the workflows they build. Expanding the approved set is the only step that needs the platform team, and it is a genuinely less frequent event.

Drift between what was reviewed and what is running

Configuration in a repository describes intent. The running system describes reality. These diverge — through an urgent change made in the UI, a partial sync, or a rollback that restored one and not the other — and the gap is where governance quietly stops being true.

Ask for drift to be detectable rather than assumed absent. Knowing that the running registry differs from the reviewed one, and in which entries, is a routine operational signal. Discovering it during an audit is not.

The related question is which direction wins. Both answers are defensible; the failure is not having decided, because then the outcome depends on timing. It is also worth knowing what happens to a UI change made while a sync is pending — silent loss is a common and unpleasant surprise.

Questions worth asking a vendor

Can a pipeline author point at an arbitrary MCP endpoint, or only at approved profiles? If the former, the reviewed surface is decorative.

Is the tool list a caller sees filtered by their permissions, or filtered only at invocation? Filtering at invocation still denies the call, but it hands a compromised reasoning step a map of everything it might try next.

Do write-oriented operations mutate state directly, or return validated proposals? And if the vendor exposes its own MCP server, does it act as the calling user or as a privileged service — because the second answer means the assistant is a second, quieter path into production.

Finally: what does the run record contain about tool use six months later, and does answering that depend on a retention window the vendor controls rather than you?