For most of the last few years, the limit on what an AI system could do was its own knowledge. It could talk about the world, but it could not act in it. The Model Context Protocol, or MCP, changes that. MCP gives agents a standard way to discover and call tools: to query a database, file a ticket, send a message, trigger a workflow, reach into the systems that run the business. It is one of the most important shifts in enterprise AI, because it turns a system that talks into a system that does.
And the moment a system can do things, the question stops being "what might it say" and becomes "what might it do." A tool an agent discovers might expose sensitive data. A tool it calls might take an action that cannot be undone. A tool might run with credentials far broader than the user or agent behind the request should ever wield. MCP expands what agents can do, and in the same motion it expands the surface you have to control. MCP governance is the discipline of keeping that surface under control while still letting agents use tools.
The control surface MCP opens up
It helps to be concrete about what changes when you adopt MCP. Three new risks appear, and each one is a direct consequence of the capability that makes MCP valuable.
The first is discovery. MCP lets agents find tools dynamically, which is powerful, because you do not have to hard-wire every integration. It is also a risk, because an agent discovering a tool it should not use is the first step toward calling a tool it should not call. Discovery itself needs to be governed, not just invocation.
The second is invocation with consequences. A tool call is not a read-only act. It can write, delete, send, pay, or change a live system. Unlike a model generating text, a tool call can reach out and alter the world, and some of those alterations are irreversible. The stakes of getting tool access wrong are simply higher than the stakes of getting a chat answer wrong.
The third is credential scope. Tools connect to enterprise systems, and they do so with credentials. If a tool runs with broad standing credentials, then any agent that can call the tool effectively borrows that broad access, regardless of what the user behind the request was actually entitled to. The mismatch between the agent's borrowed power and the user's real entitlement is one of the most dangerous gaps MCP can open.
The foundation: an approved tool registry
You cannot govern tools you do not know about, so MCP governance starts with a registry of approved MCP servers and tools. The registry is the inventory: which servers exist, which tools they expose, who owns each one, what version is running, what scopes it requires, and how risky it is. Without this, "governing tools" is an aspiration with nothing to govern.
A good registry does more than list names. It classifies tools by risk, so that a read-only lookup and a fund transfer are not treated identically. It records ownership, so there is someone accountable for each tool. And it tracks versions and scopes, so you know what a tool can do and what it has changed. The registry is also the natural place to start building an AI bill of materials, a record of the components that make up your AI systems. We go deeper on building an approved tool registry.
Binding tool access to identity
A registry tells you which tools exist. The next question is who and what may use each one. This is where MCP governance leans on the same identity model that underpins agent governance. Access to a tool is bound to identity, both the human ultimately behind the request and the agent acting on their behalf, and policy decides whether that identity, for this purpose, may discover or invoke this tool.
This identity binding is what closes the credential-scope gap. The agent does not get to use the tool's broad credentials just because it can reach the tool. The policy engine evaluates the request against the user and agent identity, their role and purpose, and the tool's risk, and only then is the call allowed to proceed. The agent's reach is bounded by who is really behind it, not by the raw power of the tool it found. This depends on agents being registered identities, which is why MCP governance and agent governance are two views of the same problem.
Scoping the call itself, not just the access
Deciding that an agent may call a tool is not the same as deciding what it may do with that tool. A tool that can query customer records could, in principle, query all of them. A governed tool call is scoped: the credentials, the resources, and the parameters are limited to what the approved purpose actually requires. The agent gets to do the specific thing it was permitted to do, not everything the tool is technically capable of.
This is least privilege applied at the level of the individual call. It is also where MCP governance touches the LLM gateway, because both are about centralizing control over how AI reaches outside itself, one for models and one for tools, rather than scattering credentials and routing logic across every project. We cover the mechanics of scoped credentials, and the relationship to purpose lives in purpose-based access control.
Approvals for the actions that warrant them
Some tool calls are high enough impact that policy should not decide them alone. A transfer of money, a deletion of records, an external message to a customer: for these, the right control is to require a human approval before the call runs. MCP governance is where that approval is enforced, because the tool call is the action being approved. The decision to pause and ask a person sits naturally at the tool layer, and it connects directly to the broader design of human-in-the-loop approvals covered under agent governance.
Recording every call
The last piece is evidence. Every tool call an agent makes should leave a record: which tool was called, with what arguments, by which identity, what policy decided, what result came back, and why. This is not optional bookkeeping. Tool calls are where agents act on the world, so the record of tool calls is the record of what your AI actually did. When something goes wrong, this is the trail you follow, and when a regulator or auditor asks what an agent did, this is the answer. We detail what to capture when logging tool calls, and the platform capability that stores it is the AI audit trail.
Framework-agnostic, like the rest
As with agent governance, MCP governance cannot depend on everyone using the same agent framework or the same way of wiring up tools. Teams build on whatever fits their problem. The controls have to apply the same way whether the agent calling a tool was built with a mainstream framework or a custom in-house one. Governance wraps the tool layer rather than dictating how agents are constructed, which is the approach taken in MCP and tool governance.
The short version
MCP is what makes agents genuinely useful, because it lets them act. That same power is why tool access is the highest-stakes part of agent governance. The pattern that keeps it under control is consistent: know your tools through a registry, bind access to identity, scope each call to its purpose, require approval for high-impact actions, and record everything. The three posts in this series take the registry, the credential scoping, and the logging one at a time. The wider agent picture they sit inside is in the complete guide to agent governance.