What is MCP Governance? A Guide to Govern MCPs (third-party and internal)
By Ankita Gupta, Oct 27, 2025
From model hallucination to agent compromise
In the early days of AI adoption 2 years ago, the biggest risk was model hallucination. Today, the greater threat is agent compromise.
In the last few months alone, Ankita Gupta has seen global banks, insurers, and tech companies quietly connect their AI agents to production systems using the Model Context Protocol (MCP)- a protocol that lets models execute actions through external "tools." As enterprises connect LLMs and AI agents to internal systems through the MCPs, they are effectively opening a new control plane inside corporate infrastructure.
Each MCP server a model connects to becomes a potential execution surface capable of making API calls, running code, reading files, or triggering automation.
Raji Vanninathan, Principal Engineering Manager, AI Security, Microsoft, at the MCP and Agentic Security conference, 2025, compared MCP servers to a third-party desktop plugin or extension: easy to install, easy to trust, until they are not.
Many enterprises Akto works with have spun up a new function called AI Governance. MCP Governance is the operational backbone that decides whether an enterprise's AI adoption stays secure and protected.
What Is MCP Governance?
MCP Governance is the set of technical and organizational controls that decide:
- Which MCP servers are running in the environment?
- Who approves them?
- Under what conditions are they approved?
- What happens when something goes wrong?
- What are guardrails on MCPs spun up in the cloud or on desktops?
Think of MCP governance as the "App Store + SOC" model for enterprise AI infrastructure. Every server is a "vendor app." The enterprise's job is to determine if it's safe, monitored, and revocable.
Unlike typical API integrations, MCP servers run executable tools. They are active components, not passive data consumers. So governance must blend elements of supply-chain security, zero-trust network control, and runtime enforcement.
MCP Governance applies to both third-party and internal MCP servers, but the focus areas differ:
- Third-party MCP servers require vetting, approval, and provenance checks before use.
- Internal MCP servers require runtime guardrails, access controls, and continuous monitoring to prevent privilege misuse or drift.
The Core Pillars of MCP Governance
1. Trusted MCP Registry
(Focus: Third-party MCPs) Start with an MCP registry - the enterprise's official allowlist of approved MCP servers. It's the single place that defines which servers can connect, under what conditions, and with what access.
How to implement:
- Keep a simple sheet or YAML file with approved servers that includes name, source, version, and owner.
- Pin the approved version or commit hash so automatic updates are blocked. If automatic updates are enabled, the team must trigger a re-approval workflow.
- Have a quick approval flow where the developer submits, security reviews, and adds it to the list.
- Configure the MCP host to reject any connection not on the list.
- Review and clean up the registry every quarter to remove outdated or unused entries.
Why it matters:
Most issues come from shadow MCP servers that developers connect to from public repos. A trusted registry ensures only vetted and reviewed servers make it to production.
Without MCP, an AI app calls GitHub, AWS and Slack through unique APIs; with MCP, an AI app reaches GitHub, AWS and Slack through a GitHub MCP server, an AWS MCP server and a Slack MCP server.
2. Policy Enforcement at Runtime
(Applies to both internal and third-party MCPs) Once servers are approved, enforce controls when they run.
Practical steps:
- Limit what each server can access, restrict APIs and tools to specific OAuth scopes.
- Run untrusted servers in isolated containers or sandboxed environments.
- Apply system-level restrictions to prevent risky actions.
- Log every tool execution capture parameters, timestamps, and responses for monitoring.
Define these rules in simple config files or policies so they're applied automatically for every new server, not decided ad hoc.
3. Continuous Re-validation
(Applies differently for internal and third-party MCPs)
MCP servers evolve, and their risk posture changes over time.
For third-party MCPs:
- Monitor for new releases or security advisories.
- Verify signatures or hashes before upgrading.
- Re-run the approval process when versions change.
- Confirm registry entries match what's deployed in production.
For internal MCPs:
- Integrate automated scans in CI/CD pipelines (e.g., Akto).
- Track dependency and permission changes in every build.
- Test in staging before production rollout.
- Continuously monitor runtime behavior for anomalies.
Regular re-validation ensures both internal and third-party MCPs remain secure as they evolve.
4. Audit and Evidence
(Applies to both internal and third-party MCPs) Every approval, version change, or connection should leave a trace.
Recommended actions:
- Store logs in the SIEM.
- Include the server name, version, and who approved it.
- Review audit logs quarterly to confirm all connections came from approved servers.
When auditors or executives ask, "Which MCP servers accessed production last quarter?" - the team will have the answer ready.
5. Defining Roles and Responsibilities
In enterprises, governance fails when ownership is unclear. A mature model distributes accountability across these roles:
| Role in MCP governance | Responsibility |
|---|---|
| Submitter (Developer) | The Submitter (Developer) requests onboarding of a new third-party MCP server with documentation and hashes. |
| Security Reviewer | The Security Reviewer performs static/dynamic scans, reviews tool code, and verifies supply-chain integrity. |
| Domain Owner | The Domain Owner confirms functional need and ensures least-privilege scopes. |
| Approver (CISO delegate) | The Approver (CISO delegate) gives final authorization combining domain and security review. |
| Operator (SRE) | The Operator (SRE) handles deployment, monitoring, and kill-switch actions. |
6. Integrating Governance into the MCP Lifecycle
To make governance part of the development, integrate it into the MCP lifecycle:
- Submission → Developer submits manifest + documentation.
- Scanning → Automated pipeline analyzes the server.
- Review & Sign-off → Manual review by security and domain owners.
- Staging Deployment → Limited rollout with telemetry.
- Production Approval → Added to registry after probation.
- Monitoring & Re-validation → Continuous scanning and runtime observability.
Final Thoughts
MCPs are quickly becoming the connective tissue of enterprise AI - linking models, agents, and systems. Without governance, these connections can silently erode security boundaries built over decades.
CIOs and CISOs often ask:
"How do we let AI move fast without losing control?"
MCP governance provides the control plane: a blend of registries, policies, automation, and oversight that lets enterprises scale AI safely.
Enterprises today are treating third-party MCP servers as first-class citizens in their risk program.
If an AI agent can execute actions, it deserves governance equal to a human with admin rights.
Akto believes that in the next phase, enterprises will pair MCP Governance with runtime guardrails to detect and contain agent behavior in real time.
Akto is an MCP and AI agent Security Platform. Recordings from the biggest Agentic AI Conference hosted by Akto in 2025 include Akto's approach to securing AI agents and MCPs, an inside look at how Akto secures agentic assets, from the MCP and Agentic Security conference, 2025.
Akto posts updates on X and LinkedIn. The Akto blog post before this one is AI Agent Red Teaming: A Practical Guide to Security Testing.