MCP Governance: Connecting Agents Is Easy. Controlling What Happens Next Isn't.
MCP governance is the enterprise control layer that decides which agent may use which MCP tool, against which data, under what conditions, with what approvals, and with what audit trail. The Model Context Protocol solves connectivity. It does not decide whether a given agent should have been allowed to make a given call.
In this guide
- → What problem MCP actually solves
- → Why governance becomes necessary
- → Identity, not credentials
- → The three control layers
- → Read-only vs action tools
- → Where human approval sits
- → What the audit trail captures
- → How credentials should be handled
- → MCP security vs MCP governance
- → A governed MCP architecture
- → What usually fails
- → Governance checklist
Two different questions
MCP answers
Can the agent connect?
Governance answers
- Should it connect?
- Who is the agent?
- What can it access?
- What can it change?
- What requires approval?
- What happened?
- Can access be revoked?
What problem does MCP actually solve?
MCP standardizes how an AI agent discovers and invokes external tools and capabilities. Before it, every agent-to-system integration was bespoke: a custom function schema, a custom auth path, a custom result format, rewritten for each framework. MCP replaces that with one description of what a tool is, what arguments it takes, and how it is called.
That is a real and useful problem to solve. It removes integration cost, and it means a tool built once can be consumed by many agents.
It is also the limit of what the protocol claims. MCP gives agents a common way to use tools. It does not, by itself, define the enterprise operating model around those tools: who the agent is, whose authority it acts under, which subset of data it may touch, which actions need a human, and what record survives the call.
Connectivity is the first problem. Governance is the second one, and it is the one that decides whether agents get to stay in production.
Why does MCP governance become necessary in the enterprise?
Because the blast radius changes. A personal assistant querying a weather service can be wrong without consequence. An enterprise agent connected through MCP may be able to query customer records, create Jira tickets, issue refunds, change cloud configuration, approve workflows, retrieve internal documents, trigger deployments, and move money.
Once tools can cause consequences, connectivity needs controls around it. The interesting failure is not technical. It is explanatory.
The risk is not that an agent can call a tool. The risk is that the organisation cannot explain why that agent was allowed to call that tool, with those permissions, in that context.
This is not a speculative category. The OWASP Top 10 for LLM Applications lists excessive agency and insecure plugin or tool design as distinct risks, and both describe the same structural gap: an agent given more capability than the task requires, with nothing between the model and the system it can reach. The NIST Zero Trust Architecture answer to the equivalent problem in human and service access is per-request authorization, which is exactly what a tool call is.
That is the question an auditor, a regulator, a security review, or an incident postmortem will ask. An architecture that cannot answer it will be rolled back regardless of how well the agent performed.
Why should MCP access be governed around agent identity, not API credentials?
Most early MCP deployments treat possession of a credential as authorization. The agent holds a token, the token works, therefore the agent may act. That model collapses the moment more than one agent exists, because the credential says nothing about who is acting or why.
Governance needs answers that a credential cannot provide. Who or what is this agent? Which employee or service owns it? Which tenant or business unit does it operate for? What role does it have? Which tools is it authorized to use? Under whose authority is it acting right now?
The weak model is a straight line: agent possesses credential, therefore agent can act. The stronger model puts identity first and derives access from it: agent identity, then policy, then scoped authorization, then a temporary credential, then the tool invocation.
The practical difference shows up at revocation time. In the first model, revoking access means finding every copy of a secret. In the second, it is a configuration change against one identity.
How should enterprises control what an agent can do through MCP?
Three layers of control, applied together. Each one alone leaves an obvious gap.
Tool-level permissions come first. An agent should be allowed a named set of operations, not a server. A support agent may be permitted read_customer and get_invoice while refund_payment and delete_customer are not in its grant at all. This is stronger than instructing an agent to avoid dangerous actions, because it does not depend on the model complying.
Data-level permissions come next. A valid tool call still has to be scoped: to the right customer, tenant, geography, environment, account, or business unit. An agent authorized to read customer records is not thereby authorized to read every customer record. Without this layer, tool-level permissions produce lateral exposure inside an approved operation.
Contextual policy is the third layer. Some permissions depend on the situation rather than the identity: the amount involved, the environment, the time of day, the data classification, the model confidence, or the authority of the human who triggered the task. An agent may issue refunds below a set threshold and must request approval above it. The same tool, the same agent, a different answer.
Why should read-only tools and action tools not be treated the same?
Because they carry different consequences and should therefore carry different controls. A cloud-cost MCP server that only analyzes AWS usage has a very different risk profile from one permitted to terminate EC2 instances or modify route tables. Treating both as a generic tool grant flattens a distinction that governance depends on.
A useful ladder runs read, recommend, execute, destroy. Reading needs authentication and a scoped read grant. Recommending needs evidence and a stated confidence, so a human can judge the recommendation rather than trust it. Executing needs policy and often approval. Destroying needs strong approval, audit, and a rollback path.
| Capability | Governance requirement |
|---|---|
| Read AWS cost and usage metrics | Authentication plus a scoped read grant |
| Recommend removing an idle resource | Evidence and stated confidence, no execution |
| Stop an EC2 instance | Policy evaluation and approval for the environment |
| Delete infrastructure or modify routing | Strong approval, full audit, rollback control |
The cloud-cost example is not hypothetical. TomorrowCentral Cloud Cost Sentinel runs as a read-only MCP capability over AWS: it assumes a read-only cross-account role, so it can analyze spend and produce evidence-backed recommendations, and it physically cannot terminate or delete anything. The read-only boundary is enforced by the role, not by an instruction to the agent. See the read-only MCP capability in practice →
Where should human approval sit in an MCP workflow?
Between policy evaluation and tool invocation, and only for the classes of action where the business consequence justifies interrupting the work.
Human-in-the-loop is often implemented as a prompt before every tool call. That degrades quickly: reviewers approve reflexively, latency makes the agent useless, and the approval record stops carrying meaning. Approving everything is operationally identical to approving nothing.
Humans should approve the classes of decisions where business consequence justifies interruption. The useful dimensions are consistent across industries: a financial threshold, a destructive action, an external communication, a production change, sensitive data, or an irreversible decision. Everything outside those classes executes and is audited.
Agent determines an action is useful
|
Policy evaluates the action
|
+----------------+----------------+
| |
low-risk action high-risk action
| |
execute approval required
| |
+----------------+----------------+
|
Tool invocation via MCP
|
Audit record writtenWhat should an MCP audit trail capture?
Enough to reconstruct the decision, not just the call. A log line saying a tool was invoked tells you an event occurred. It does not tell you whether the event should have occurred.
A governed record covers the agent identity, the human or service that initiated the task, the MCP server involved, the tool invoked, the arguments passed, the policy that was evaluated, the approval if one was required, the credential reference that was granted, the result, the downstream changes, the timestamps, and any errors or retries.
An agent action that cannot later be reconstructed is difficult to govern, even if the action itself was technically authorized.
Two details matter in practice. The record should reference credentials by identifier and never store their values, so the trail is safe to export to a SIEM or hand to an auditor without a redaction step. And it should be written by a path that only appends, so the record of an incident cannot be edited by whatever caused the incident.
How should credentials be handled for agent tools?
The working rule: do not make agents long-lived holders of powerful secrets wherever it can be avoided.
Secrets that sit in prompts, environment variables, agent memory, or framework config become an exposure path the moment the agent processes untrusted content. A retrieved document, a support ticket, or a web page can carry instructions, and an agent that holds a secret is an agent that can be talked into using or revealing it.
The alternative is to resolve access at call time. The agent requests a capability, policy authorizes the request, the runtime obtains and injects a scoped credential, the tool call executes, and the access ends. The agent gets results, not secrets. Rotation and revocation become operations on the vault rather than a code change across every agent that held a copy.
Agent requests a capability
|
Policy authorizes the request
|
Runtime resolves and injects a scoped credential
|
Tool call executes
|
Credential expires, access endsWhat is the difference between MCP security and MCP governance?
MCP security asks whether the connection is safe. MCP governance asks whether the action was legitimate. The two are related, and teams routinely deliver the first while believing they have delivered the second.
Security is a component of governance, not the whole governance problem. A perfectly secured connection can still carry an action that no one authorized, no one reviewed, and no one can reconstruct afterwards.
MCP security asks
- Is the connection secure?
- Is authentication correct?
- Are credentials protected in transit and at rest?
- Can the MCP server itself be compromised?
MCP governance asks
- Should this agent have access at all?
- Under what policy, and whose authority?
- Who is accountable for the action?
- Does the action require approval?
- Can we prove what happened?
- Can access be revoked quickly?
What does a governed MCP architecture look like?
It looks like a chain where every hop between the business intent and the enterprise system is an explicit control point, rather than a direct line from an agent to a tool.
The important structural claim is that governance sits around the agent-to-tool interaction, not inside the prompt. Instructions in a system prompt are guidance to a model. Controls at the runtime layer are enforced whether or not the model cooperates, which is the property that matters when the input is untrusted.
Orchestrik approaches this at the runtime and control layer: agent identity, connector-level permissions, credential vaulting, approval gates, observability and a tamper-evident audit trail surround the agent's interaction with enterprise capabilities. The governance layer is deliberately separate from the agent framework, so existing agents built on LangChain, CrewAI, AutoGen, or custom code can be governed without being rewritten.
User / Business Process
|
AI Agent reasoning and tool selection
|
Agent Identity who is acting, for which tenant, under whose authority
|
Policy / Authorization which tool, which data, under which conditions
|
Approval Gate only where consequence justifies interruption
|
Scoped Credential resolved at call time, never held by the agent
|
MCP Client
|
MCP Server
|
Enterprise System CRM, cloud, database, ticketing, finance
|
Audit + Observability reconstructable record of the entire chainWhat usually fails when enterprises expose tools to agents?
The failures are consistent enough to be predicted. Seven of them account for most of what goes wrong.
- 01
Treating possession of a credential as authorization
The agent holds a token, so the agent may act. This removes identity, policy, and revocation from the model in one step.
- 02
Granting broad tool access for convenience
A whole MCP server is attached because scoping each operation is slower during a prototype. The prototype ships.
- 03
Using prompts as security controls
Instructions telling a model what not to do are guidance, not enforcement. Untrusted input can rewrite guidance.
- 04
Failing to distinguish read, recommend and execute
A single tool grant covers analysis and action, so a low-risk capability inherits the controls of a high-risk one, or the reverse.
- 05
Logging tool calls without enough context to reconstruct decisions
The record shows that a tool ran. It does not show which policy allowed it, who triggered it, or what changed downstream.
- 06
No revocation or lifecycle model
Access is granted at integration time and never reviewed. Nobody can say which agents still hold which grants.
- 07
Connecting MCP servers without evaluating the trust boundary
A third-party server is added to the agent runtime with no assessment of the provider, the tool descriptions it supplies, or the data it observes.
MCP governance checklist for enterprises
Run this before an agent is connected to a production MCP server. Unchecked items in the Authorization, Approvals and Audit groups are the ones that turn an agent incident into an unexplainable agent incident.
Frequently asked questions
What is MCP governance?
MCP governance is the enterprise control layer around Model Context Protocol tool access. It determines which agent may use which tool, against which data, under what conditions, with what approvals, and with what audit trail. MCP standardizes how agents connect to tools; governance determines whether a specific connection and a specific action should be permitted.
Does MCP include enterprise authorization?
No. MCP is a connectivity and capability-description protocol. It defines how tools are discovered and invoked, not which agent should be allowed to invoke them, which records they may touch, or which actions require human approval. Enterprise authorization is a separate policy layer that sits between the agent and the MCP client.
Should every MCP tool call require human approval?
No. Approval should be risk-based. Approving every call causes reflexive sign-off, destroys latency, and empties the approval record of meaning. Approval belongs on classes of action with real business consequence: financial thresholds, destructive operations, external communications, production changes, sensitive data access, and irreversible decisions.
How should agents authenticate to MCP servers?
Through an identity that is distinct from the credential. The agent should present its own identity, policy should authorize the specific capability requested, and the runtime should then resolve a scoped, short-lived credential for the call. Implementation varies by server and transport, but the ordering matters more than the mechanism: identity first, authorization second, credential last.
What is the difference between MCP security and MCP governance?
MCP security asks whether the connection, authentication, and credential handling are sound, and whether the server can be compromised. MCP governance asks whether this agent should have access, under what policy, who is accountable, whether approval was required, whether the action can be proven afterwards, and whether access can be revoked. Security is a component of governance, not the whole problem.
Are read-only MCP servers safer?
Lower blast radius, not zero risk. A read-only server cannot change or destroy state, which removes the most severe failure modes. It can still expose data beyond the intended scope, leak sensitive records into an agent context that is later sent elsewhere, and carry tool descriptions that influence agent behaviour. Read-only reduces the controls required; it does not remove the need for scoping and audit.
How should enterprises audit MCP tool calls?
By writing a structured record per call that captures agent identity, the human or service that initiated the task, the MCP server, the tool, the arguments, the policy evaluated, any approval, the credential reference, the result, downstream changes, timestamps, and errors or retries. Credentials should be referenced by identifier rather than value, and the write path should be append-only so records cannot be altered after the fact.
Where should MCP governance be implemented?
At the runtime layer around the agent-to-tool interaction, rather than inside prompts. Prompt instructions are guidance to a model and can be overridden by untrusted content the agent processes. Controls placed at the identity, policy, credential, and connector layer are enforced regardless of what the model decides to do. Orchestrik implements this layer as a control plane between agents and enterprise systems: agent identity, connector-level permissions, a credential vault that resolves secrets at execution time, approval gates, and a tamper-evident audit trail.
Key takeaways
- •MCP standardizes agent-to-tool connectivity. It does not remove the need for enterprise governance around those tools.
- •Agent identity should be separated from possession of credentials. Possession is not authorization.
- •Read, recommend and execute actions carry different consequences and should carry different control levels.
- •Approval should be risk-based rather than attached to every tool call. Approving everything is operationally identical to approving nothing.
- •Every consequential agent action should be attributable, reconstructable and revocable.
References
- [1] Model Context Protocol specification: how agents discover and invoke tools, and what the protocol does and does not define.
- [2] OWASP Top 10 for LLM Applications: excessive agency, insecure plugin design, and prompt injection as tool-access risks.
- [3] NIST Zero Trust Architecture (SP 800-207): per-request authorization and least privilege for enterprise resource access.
- [4] NIST AI Risk Management Framework: Govern, Map, Measure and Manage as the structure for AI risk controls.
- [5] Orchestrik Integrations: governed connectors, credential vault, and audited connector calls.
- [6] Orchestrik Security and Compliance: infrastructure-level access control, audit trail, isolation, and deployment modes.
Related reading
Governance around MCP is one instance of a wider problem: agent identity, and the record an agent action leaves behind.
Agent control plane
As agents gain access to more enterprise capabilities, the control plane around those interactions matters as much as the tools themselves.
Orchestrik is built for that layer: governed runtime infrastructure for enterprise agents, covering identity, connector permissions, credential vaulting, approval gates and audit.
Learn about Orchestrik →