TL;DR
1. What it is: MCP governance controls which MCP servers run, who calls them, what they can do, and what gets logged.
2. Why it matters: Ungoverned MCP creates shadow servers, identity sprawl, tool poisoning, and audit gaps that break compliance.
3. The framework: Six pillars cover registry, identity, policy, observability, lifecycle, and compliance across every MCP deployment.
4. Where you stand: A five-level maturity model from Ungoverned to Optimized lets platform and security teams self-assess in an hour.
5. Compliance fit: MCP governance controls map cleanly to SOC 2, HIPAA, PCI-DSS, EU AI Act, NIST AI RMF, and ISO 27001.
6. How to roll out: A 90-day plan with RACI ownership delivers a working governance baseline before the next audit cycle.
See how DigitalAPI's MCP governance program shortens time-to-audit-evidence. Book a demo.
What is MCP governance, and how does it differ from API governance and AI governance?
MCP governance is the set of controls that decide which MCP servers your enterprise allows, who can call which tools, what those tools can do at runtime, and what gets logged for audit. It sits at the intersection of API governance and AI governance, but it is not the same as either. The protocol itself does not include enterprise governance primitives, so the controls have to live in the layers around it.
The Model Context Protocol shipped from Anthropic in November 2024 as a stateful, bidirectional spec for connecting LLM clients to tools, prompts, and resources. It standardized the connection format. It did not standardize who is allowed to connect, what they can do once connected, or how a CISO proves any of that to an auditor. Those questions are what MCP governance answers.
A working definition
MCP governance is the operating model that turns an open protocol into a controlled enterprise capability. Concretely, it covers six things at the same time:
- Server scope: Which MCP servers are approved, in which environments, for which business units.
- Identity scope: Who or what is calling, with which credentials, on whose behalf.
- Capability scope: Which tools, prompts, and resources a given call is allowed to touch.
- Runtime scope: What policies fire on each request, including rate limits, content filtering, and human-in-the-loop gates.
- Evidence scope: What gets logged, retained, and surfaced to auditors and security teams.
- Lifecycle scope: How servers and tools are onboarded, versioned, deprecated, and rolled back.
If your program covers all six, you have a governance program. If it covers two or three, you have a vendor pilot.
How MCP governance is different from API governance
API governance focuses on RESTful and gRPC traffic between deterministic clients and known endpoints. The client knows the path. The server knows the schema. The intent of every request is encoded in the URL.
MCP governance has to handle a much messier reality. The client is a non-deterministic LLM agent. The server publishes a list of tools whose semantics live in natural language descriptions. The "request" is sometimes a multi-turn negotiation. The agent may decide at runtime to call a tool the human never explicitly authorized.
The practical difference shows up in five places:
- Intent verification: API governance trusts the request shape. MCP governance has to verify intent because the agent picked the tool, not the user.
- Tool semantics: API governance verifies syntax against an OpenAPI spec. MCP governance has to evaluate the natural-language description for prompt injection and tool poisoning.
- Identity propagation: API governance often terminates identity at the gateway. MCP governance has to propagate per-user identity all the way through to the downstream tool to prevent confused-deputy attacks.
- Audit granularity: API governance logs requests. MCP governance logs requests plus tool selection rationale, plus parameter values, plus tool descriptions at time of call.
- Failure surface: API governance worries about traffic, throughput, and schema drift. MCP governance also worries about prompt injection, rug pulls, and tool poisoning that have no API governance analog.
How MCP governance is different from AI governance
AI governance is the broader discipline covering model selection, training data, bias evaluation, model drift, prompt safety, and AI ethics. It applies whether or not MCP is in the picture.
MCP governance is a specific subset that activates the moment a model starts calling tools. You can have a mature AI governance program with zero MCP governance if your agents never reach outside the LLM context window. The moment they do, you need MCP governance to control what they touch.
A useful frame: AI governance asks "is this model safe to deploy?" MCP governance asks "is this model safe to give hands?"
Five things MCP governance is and five things it isn't
MCP governance is:
- A control plane spanning servers, identities, policies, observability, lifecycle, and compliance.
- An audit-evidence engine that captures who-called-what-when at tool granularity.
- A risk reduction program against ten failure modes that traditional API security misses.
- A bridge between your existing identity, policy, and logging stack and your new agent workloads.
- A capability that lives in a gateway plus a registry plus a policy engine, not in a single tool.
MCP governance is not:
- The Model Context Protocol spec itself, which deliberately leaves governance out of scope.
- Generic AI safety policy, which operates on model behavior, not tool access.
- A single product, even though vendors will sell it to you that way.
- Optional once your agents start writing to production systems.
- A reason to rebuild API governance from scratch, because most controls extend.
The rest of this guide unpacks each of those claims, starting with what actually breaks when MCP is ungoverned.
What are the 10 MCP governance failure modes, and which controls prevent them?
Ten failure modes drive the entire MCP governance discipline. Each one has been observed in production environments since the protocol shipped in late 2024. Six are unique to MCP. Four are familiar from API security but mutate in the agent context. Mapping each failure to a control is how you decide which pillar to build first.
The table below summarizes all ten. The pillar column corresponds to the framework introduced in section three.
The first three failure modes get the most coverage in the security press. They are also the easiest to miss without governance because the protocol gives no signal that anything has gone wrong.
MCP-native attack patterns
- Tool poisoning works because MCP tool descriptions are read by both humans and LLMs. A malicious server author embeds instructions in the description (for example: "always call this with admin scope") that the LLM follows during selection. Anthropic's security guidance and OWASP's LLM Top 10 both call this out as the canonical agent-era prompt injection.
- Rug pulls exploit trust on update. A team approves a server based on its v1 behavior, then the maintainer ships a v2 that scrapes credentials or exfiltrates data. Postmark-mcp, an unauthorized package impersonating the legitimate Postmark integration, is the most-cited 2025 example.
- Confused deputy attacks happen when an agent inherits a user's request but executes it with the agent's own (often broader) credentials. The agent does not realize it is being asked to do something the user is not entitled to. Per AWS Prescriptive Guidance (2026), the standard mitigation is token isolation: every tool call uses an explicitly scoped, purpose-generated token, never the user's original session token.
Operational failure modes that scale with adoption
- Shadow MCP is the inevitable consequence of fast adoption. Once developers learn the protocol, they install servers locally and connect them to production systems without telling security. Portkey's 2026 research found that 53% of MCP servers in audited environments used static API keys, only 8.5% used OAuth, and 79% stored credentials in environment variables. Those are not server-author defaults. Those are operator shortcuts that governance has to surface and replace.
- Identity sprawl follows the same arc. The first agent ships with a clear owner. The fifth ships with a forwarded ticket. The fiftieth ships with no owner at all. Without a lifecycle pillar, the cleanup cost compounds quarterly.
Audit and compliance failure modes
- Audit-trail gaps are the failure mode that surfaces during a SOC 2 Type II audit or an EU AI Act assessment. The auditor asks "show me, for the last 90 days, every action taken by an autonomous agent on production data, with the identity of the responsible human." If the answer involves grepping container logs, the control is not operating effectively.
- Unbounded blast radius is the one finance discovers. An agent loops over a tool with no concurrency cap, racks up six figures of LLM and downstream API spend in a weekend, and the postmortem reveals nobody owned the budget guardrail.
Every one of these failure modes maps to a pillar. The next section defines the six.
What does the 6-pillar MCP governance framework cover?
Six pillars cover the full surface of MCP governance: Registry, Identity, Policy, Observability, Lifecycle, and Compliance. Together they answer the six scope questions from the definition (server, identity, capability, runtime, evidence, lifecycle). Each pillar is a capability set, not a single tool. Most organizations need at least one component per pillar before they can claim a working program.
Pillar 1: Registry
The registry is the authoritative answer to the question "which MCP servers exist in our organization, and which are approved." It is the foundation for everything else, because a control plane cannot enforce policy on servers it does not know about.
A working registry includes:
- Approved server catalog: the allowlist of MCP servers vetted for use, scoped by environment and tenant.
- Version pinning: the exact server version approved, with hash verification on install and update.
- Per-tenant scoping: which business units, teams, or regions can install a given server.
- Server metadata: owner, classification (data sensitivity), license, and last review date.
- Discovery surface: how developers find servers without going outside the catalog.
- Quarantine workflow: how a server moves from "submitted" to "approved" or "blocked."
- Deprecation flow: how a server is sunset without breaking dependent agents.
The registry is the only control that addresses shadow MCP head-on. Without it, every other pillar is operating on incomplete inventory.
Pillar 2: Identity
Identity propagation is the single most-cited differentiator between MCP and traditional API security. The pillar answers two questions: "who is calling?" and "on whose behalf?" Both have to be answered for every tool invocation.
A working identity layer includes:
- OAuth 2.1 with token isolation: per-user, per-tool tokens, never shared service accounts.
- Per-agent identity: every agent has a stable identity separate from any user it represents.
- Per-tool token scoping: the token issued for tool A cannot be replayed against tool B.
- Human-in-the-loop attribution: every tool call links to the responsible human, even when the agent invoked it.
- Workload identity for machine-to-machine: background agents have workload tokens, never user tokens.
- Token rotation and expiration: short-lived tokens by default, with automatic refresh.
- Audience validation: the
audclaim must match the receiving server, per AWS guidance.
Identity is the pillar that prevents confused-deputy attacks, blocks credential exposure, and contains identity sprawl.
Pillar 3: Policy
Policy is the runtime enforcement layer. It evaluates every tool call against a set of rules and either allows, blocks, modifies, or escalates the request. The pillar covers six policy categories.
A working policy layer includes:
- Tool-level RBAC and ABAC: decisions based on user, role, tool, parameters, and request context.
- Egress controls: which downstream services the tool is allowed to reach.
- Content filtering: PII redaction, secret detection, prompt injection screening on both directions.
- Rate and concurrency limits: per-user, per-tool, per-tenant, with cost-aware throttling.
- Human-in-the-loop gates: approval required for high-risk actions (writes, payments, deletions).
- Geofencing and residency: which jurisdictions a tool call may originate from or land in.
Policy is where most of the failure modes get blocked. It is also the pillar most enterprises underbuild, because policy-as-code is harder than policy-as-PDF.
Pillar 4: Observability
Observability turns runtime activity into evidence. The pillar covers logs, metrics, traces, and dashboards, but its design center is "what does an incident responder or auditor need to reconstruct what happened?"
A working observability layer includes:
- Per-call audit log: user, agent, server, tool, parameters, response, decision, latency.
- Tool selection rationale: which tools were considered, which was chosen, and why.
- Tool description snapshot at call time: so tool poisoning can be detected after the fact.
- Real-time dashboards: by user, agent, server, tool, error rate, latency, cost.
- Alerting on policy violations: especially on blocked calls, escalations, and anomalies.
- Trace correlation: linking the LLM turn to the MCP call to the downstream API to the data store.
- Retention aligned to compliance: 90 days minimum, longer for regulated workloads.
Observability is the pillar auditors look at first. It is also the pillar that turns security from reactive to proactive.
Pillar 5: Lifecycle
Lifecycle covers how servers and tools come into the registry, how they evolve, and how they leave. Without lifecycle controls, the registry becomes a snapshot that drifts within a quarter.
A working lifecycle layer includes:
- Submission workflow: the form, the review, the SLA from submission to decision.
- Vetting pipeline: static analysis, vulnerability scanning, license check, manual review.
- Staged promotion: dev to staging to production with separate approvals per stage.
- Version management: signed releases, pinned versions, rollback procedure.
- Continuous re-validation: monitor for updates, re-scan on every release, alert on signature change.
- Deprecation flow: end-of-life dates, migration support, agent dependency tracking.
- Tool-level lifecycle: new tools added to an approved server still require review.
Lifecycle is the pillar that prevents rug pulls and contains tool poisoning.
Pillar 6: Compliance
Compliance translates the operational program into audit-ready evidence. It is the pillar most platform teams underweight until the first audit cycle, then over-rotate to.
A working compliance layer includes:
- Control mapping: every governance control mapped to a control in SOC 2, HIPAA, PCI-DSS, EU AI Act, NIST AI RMF, ISO 27001.
- Evidence collection: automated pulls from observability into evidence stores.
- Policy-as-code documentation: policies as version-controlled artifacts, not Word docs.
- Auditor access patterns: read-only dashboards, signed exports, immutable logs.
- Periodic reviews: registry, policy, and access reviews on a defined cadence.
- Risk register: known risks, residual risks, accepted risks, with owners.
- Incident response runbooks: the steps from alert to containment to disclosure.
Compliance is what turns governance from "a thing we do" to "a thing we can prove."
How the pillars work together
The pillars are not independent. A registry without identity is a list. An identity layer without policy lets every authenticated request through. A policy engine without observability cannot show that it fired. The maturity model in the next section is what shows you how to sequence the build.
How mature is your MCP governance program right now?
Five maturity levels separate organizations from ungoverned (Level 0) through optimized (Level 4). The model lets you self-assess in under an hour, decide where to invest, and benchmark against peers. The 30-cell matrix below maps each level against each pillar.
The 5-level model
- Level 0: Ungoverned. MCP is in use but no central inventory exists. Servers run on developer laptops with shared credentials. No audit log. This is the default state in mid-2026 for most enterprises that have not yet built a program.
- Level 1: Reactive. Security learns about MCP because of an incident or audit finding. A blocklist exists but no allowlist. Policy is enforced through Slack messages. Logs exist somewhere but cannot be queried.
- Level 2: Managed. A registry exists. Approved servers are documented. Identity propagation works for OAuth-enabled servers. Policy is enforced at a single gateway. Logs are centralized but not standardized.
- Level 3: Defined. All six pillars have working components. Policies are version-controlled. Compliance mappings exist. The program covers all production agents. Incident response is documented.
- Level 4: Optimized. Governance is automated end-to-end. Policy changes flow through CI/CD. Compliance evidence is continuously generated. The program proactively reduces residual risk and improves agent reliability through telemetry feedback.
The 5x6 maturity matrix
12-question self-assessment
Score each question 0 (no), 1 (partial), or 2 (yes). Total 0-24.
- Can you list every MCP server running in production, including version, owner, and classification?
- Can you block a server from running in production through a single change, without coordinating across teams?
- Does every tool call carry a per-user, per-tool token that cannot be replayed elsewhere?
- Can you attribute every agent action in the last 90 days to a responsible human?
- Does your policy engine evaluate tool parameters, not just tool names?
- Are PII redaction and prompt injection screening enforced on both request and response payloads?
- Are high-risk tool calls gated by human approval before execution?
- Can you query "every tool call by user X to tool Y in the last 30 days" in under five minutes?
- Is your audit log immutable, retained for at least 90 days, and accessible to auditors directly?
- Does every new server go through a documented vetting pipeline before being approved?
- Are your governance controls mapped to at least three compliance frameworks?
- Do you have a documented incident response runbook for MCP-specific failures?
Scoring: 0-6 Ungoverned, 7-12 Reactive, 13-18 Managed, 19-22 Defined, 23-24 Optimized.
Most enterprises in mid-2026 score between 4 and 11. The fastest path forward is to identify the lowest-scoring pillar and invest there first. Maturity is not linear; one weak pillar invalidates the others during an incident or audit.
What changes at each level
- 0 to 1: the program exists as a concept. The cost is mostly meeting time.
- 1 to 2: the program ships its first tools (registry, gateway, identity). Most teams reach Level 2 in 90 days with focused effort.
- 2 to 3: the program becomes audit-ready. This is where most of the effort lives because compliance mapping and policy-as-code are slower than tool deployment.
- 3 to 4: the program becomes a competitive capability. Optimized organizations ship new agents faster because governance is automated, not slower.
Maturity matters because the cost of an incident scales with the gap between where you are and Level 3. If you are at Level 1 when the EU AI Act assessment lands, the remediation cost is measured in quarters, not weeks.
How does MCP governance map to SOC 2, HIPAA, PCI-DSS, EU AI Act, NIST AI RMF, and ISO 27001?
The six MCP governance pillars map cleanly to controls in all six major frameworks. The crosswalk below shows the dominant control families per pillar. Use it as a starting point for an auditor walkthrough, not as a substitute for a control-by-control mapping inside your GRC tool.
The mapping is intentionally specific. Vague claims like "supports SOC 2" do not survive an audit. Auditors want the control number, the evidence source, and the operating frequency.
The 6x6 crosswalk
How to assemble audit evidence per framework
The crosswalk identifies the controls. Evidence assembly is where most teams stall. The pattern that works:
- One evidence source per control: typically the observability layer for runtime evidence and the registry for configuration evidence.
- Automated pulls: evidence is exported on a cadence (daily, weekly, quarterly) into the GRC tool, not requested ad-hoc.
- Immutable storage: logs in WORM storage or hash-chained, so auditors can verify tamper-evidence.
- Sample queries: for each control, a saved query that returns the evidence. The auditor runs the query themselves during fieldwork.
- Control owner of record: each control has one named owner inside the organization, with a backup.
Framework-specific notes
- SOC 2 is the most common starting point because it covers the broadest surface with the fewest prescriptive requirements. CC6 and CC7 carry most of the MCP governance weight.
- HIPAA matters when agents touch PHI. The Security Rule's audit and access provisions translate directly. Business Associate Agreements need to be updated to cover agent-mediated access.
- PCI-DSS v4.0 matters when agents touch cardholder data. Requirement 10 (logging) and Requirement 8 (identification) are the dominant pillars. Inventory under Req 12.5.1 explicitly applies to MCP servers in scope.
- EU AI Act applies to any AI system that meets the high-risk classification. Article 12 (record-keeping) and Article 14 (human oversight) are the load-bearing articles for MCP governance. The Act takes phased effect through 2026 and 2027.
- NIST AI RMF is voluntary but increasingly referenced by US federal procurement. GOVERN and MEASURE functions map most directly to MCP governance pillars.
- ISO 27001:2022 is the international baseline. The 2022 update added controls (A.5.9, A.5.36, A.8.15, A.8.30) that align well with MCP governance.
A quarterly review of the crosswalk, joint between platform and GRC, prevents drift between operational controls and audit-ready evidence.
How do you extend an existing API governance program to cover MCP?
Most of your API governance controls extend to MCP, but four areas need new patterns: intent verification, tool description vetting, identity propagation to tools, and tool poisoning defense. Treating MCP as "another API protocol" misses the failure modes that are unique to agent-mediated calls. Treating it as a green-field rebuild wastes existing investment.
The bridge is to keep the API governance stack and extend it where the agent context breaks an assumption.
What extends from API governance
The following controls map directly from API governance to MCP governance:
What needs new patterns
Four areas require capabilities API governance did not need:
- Intent verification: API governance assumes the URL encodes intent. MCP governance has to evaluate whether the agent's chosen tool matches the user's stated goal. This requires policy that can reason about parameters, not just paths.
- Tool description vetting: Every MCP server publishes natural-language tool descriptions that the LLM reads. Those descriptions can carry prompt injection payloads. API governance has no equivalent control. The lifecycle pillar has to add description scanning to the vetting pipeline.
- Identity propagation to tools: API gateways often terminate identity at the edge. MCP governance requires the user identity to propagate all the way to the downstream tool to prevent confused-deputy attacks. Per AWS guidance, this means per-tool token issuance, not session token reuse.
- Tool poisoning and rug pull defense: Continuous re-validation on every server update, signature verification, and behavioral drift detection. None of these have direct API governance analogs.
Where to start if you already have API governance
The fastest path from a mature API governance program to MCP governance is:
- Treat the MCP gateway as a specialized API gateway. Extend, do not rebuild.
- Reuse identity, logging, and SIEM infrastructure. New collectors, same store.
- Add the registry first. Inventory always precedes control.
- Extend policy from path-level to tool-level and parameter-level. Many policy engines already support this.
- Add tool description vetting to the lifecycle pipeline. This is the cheapest new control with the highest risk reduction.
- Layer compliance mapping on top of existing SOC 2 / ISO controls. Most controls extend.
Teams that follow this path reach Level 2 maturity in roughly 60 days. Teams that try to rebuild governance from scratch take twice as long and produce more fragile programs.
What does a 90-day MCP governance rollout look like?
A focused 90-day plan delivers a working Level 2 governance baseline across all six pillars. The plan breaks into three 30-day phases (Discover, Establish, Operate) with named owners, milestones, and KPIs per phase. Most enterprises that follow this plan ship the first audit-ready evidence by day 90.
Days 1-30: Discover
The discover phase answers "what do we have?" Without an honest inventory, every later step is built on guesses.
Milestones:
- Day 7: Charter signed by CISO, CTO, and platform leadership.
- Day 14: Discovery sweep complete (network scan, source code scan, developer survey).
- Day 21: Draft registry with classification and ownership for every discovered server.
- Day 30: Risk assessment delivered with prioritized control gaps.
KPIs:
- Percentage of MCP servers in inventory with named owner (target: 100%).
- Percentage of servers classified by data sensitivity (target: 100%).
- Number of shadow servers identified versus expected (track delta).
Days 31-60: Establish
The establish phase answers "what controls do we deploy first?" The goal is a working gateway with registry, identity, policy, and observability live for at least one tenant.
Milestones:
- Day 35: MCP gateway selected (build vs buy decision made, see next section).
- Day 42: Gateway live in staging with registry and identity layers operational.
- Day 50: Policy baseline deployed (RBAC, rate limits, PII redaction, HITL for writes).
- Day 56: Observability dashboards live with per-call audit logging.
- Day 60: First tenant migrated from direct MCP access to gateway-mediated access.
KPIs:
- Percentage of approved production servers behind the gateway (target: 80%).
- Mean time to revoke a server (target: under 15 minutes).
- Percentage of calls with per-user identity attribution (target: 100%).
- Policy violations per 1,000 calls (track to establish baseline).
Days 61-90: Operate
The operate phase answers "how do we run this in production?" Compliance evidence, lifecycle workflows, and incident response runbooks are the load-bearing artifacts.
Milestones:
- Day 70: Submission workflow for new servers live with documented SLA.
- Day 75: Compliance crosswalk completed for primary framework (typically SOC 2).
- Day 80: Quarterly review cadence established for registry, policy, and access.
- Day 85: Incident response runbook tested with a tabletop exercise.
- Day 90: First evidence pull delivered to GRC for audit preparation.
KPIs:
- Mean time to detect a policy violation (target: under 5 minutes).
- Mean time to onboard a new approved server (target: under 5 business days).
- Audit findings open at day 90 (target: under 5).
RACI matrix
Governance fails when ownership is fuzzy. The matrix below assigns clear responsibility for each governance activity. R = Responsible, A = Accountable, C = Consulted, I = Informed.
The matrix is not negotiable in scope. It is negotiable in title because every organization names roles differently. The key is to have one accountable owner per activity.
Five forkable policy templates
The fastest way to skip the blank-page problem is to start from working policy text. The templates below are the most common starting points.
- Server allowlist policy. "Only MCP servers in the approved registry may be invoked from production agents. Servers must be pinned to a specific version. Version updates require re-approval through the submission workflow."
- Identity propagation policy. "Every tool call must include a token issued specifically for the calling agent and the receiving tool. User session tokens may not be forwarded to downstream tools. Token expiration may not exceed 60 minutes for high-sensitivity tools."
- Runtime egress policy. "MCP tool calls may only reach destinations on the approved egress list. PII detected in requests or responses must be redacted before logging. Calls exceeding the per-user, per-tool rate limit must be rejected with a 429."
- Audit retention policy. "Every tool call must be logged with user identity, agent identity, server, tool, parameters, response, decision, and latency. Logs must be retained for 90 days minimum, longer for workloads under regulatory retention requirements. Logs must be stored in immutable, tamper-evident storage."
- Change management policy. "New servers, new tools on existing servers, and version updates all require approval through the submission workflow. Vetting must include static analysis, vulnerability scan, license check, and description review. Production promotion requires a passing staging deployment of at least 7 days."
Treat the templates as starters, not finals. Every organization tunes them to risk tolerance and compliance scope.
Should you build or buy an MCP governance gateway?
Build if your platform team is large enough to own a control plane as a product. Buy if your goal is to reach Level 3 maturity within two quarters. The decision is less about cost and more about time-to-evidence. A working MCP governance gateway has six interlocking components. Most teams underestimate how long the integration alone takes.
Quantified TCO over 18 months
The numbers below are directional, based on observed 2026 implementations at mid-market and enterprise scale.
Cost driverDIY OSS pathCommercial gatewayInitial engineering (months 1-6)4-6 FTE1-2 FTE for integrationLicensing$0$80k-$300k/year depending on scaleCloud infrastructureSelf-managed, $15k-$40k/yearIncluded or pass-throughCompliance evidence toolingCustom-builtIncludedOperations (months 7-18)2-3 FTE ongoing0.5-1 FTE ongoingTime to Level 2 maturity4-6 months60-90 daysTime to Level 3 maturity9-12 months4-6 months
Total 18-month cost typically lands within 20% across paths. The deciding variable is rarely dollars. It is time to audit-ready evidence.
When build makes sense
- Your platform team already operates a control plane as a product.
- Your security posture requires bespoke integrations no vendor supports.
- Your compliance scope is narrow enough that the crosswalk is light.
- You have at least four months of runway before the next audit.
When buy makes sense
- Your roadmap pressure is "ship governance before the next audit."
- You need multi-cloud and multi-tenant deployment models out of the box.
- Your team would rather own application-layer differentiation than gateway plumbing.
- Your compliance scope spans three or more frameworks.
12-criterion vendor evaluation checklist
When evaluating commercial MCP governance gateways, score each vendor 0-2 across the criteria below. The same criteria appear in our deeper comparison piece, Best MCP Gateways 2026.
- Native OAuth 2.1 with token isolation and per-tool scoping
- Tool-level ABAC policy engine, not just path-level
- Registry with version pinning, classification, and tenant scoping
- Per-call audit log including selection rationale and parameter capture
- Lifecycle workflows (submission, vetting, staged promotion, deprecation)
- Compliance crosswalk for at least four frameworks out of the box
- Multi-gateway control plane for managing multiple gateway instances
- BYOMCP support (run any MCP server, not just vendor's catalog)
- SaaS, hybrid, and self-hosted deployment options
- AI agent control plane (govern agents, not only servers)
- OpenTelemetry-compatible observability, no proprietary lock-in
- Documented SLA, support model, and roadmap transparency
A vendor scoring 18+ out of 24 covers a mature program. Below 12 indicates a single-pillar tool, not a governance gateway.
How DigitalAPI delivers the six pillars
DigitalAPI ships an MCP gateway that addresses all six pillars natively. The registry pillar covers server allowlisting, version pinning, classification, and per-tenant scoping. The identity pillar uses OAuth 2.1 with token isolation, per-tool token scoping, and per-user identity propagation through to downstream tools. The policy pillar runs on Cedar with tool-level ABAC, content filtering, rate limiting, and human-in-the-loop gates.
The observability pillar is OpenTelemetry-native with per-call audit logging, selection rationale capture, and real-time dashboards. The lifecycle pillar includes a submission workflow, vetting pipeline, staged promotion across dev, staging, and production, and continuous re-validation on every server update. The compliance pillar maps each control to SOC 2, HIPAA, PCI-DSS, EU AI Act, NIST AI RMF, and ISO 27001 out of the box, with automated evidence pulls into the GRC tool of choice.
DigitalAPI deploys in SaaS, hybrid (data plane in your VPC, control plane managed), and fully self-hosted modes. The same control plane can manage multiple gateway instances across regions and business units, with a unified agent control plane for governing AI agents, not only MCP server traffic.
Teams using DigitalAPI reach Level 2 maturity in roughly 30 days from contract and Level 3 in roughly 90 days, compared to the 4-6 month and 9-12 month baselines for DIY OSS paths.
See how DigitalAPI's MCP governance program shortens time-to-audit-evidence. Book a demo.
FAQs
1. What is MCP governance?
MCP governance is the set of controls that decides which MCP servers an enterprise allows, who can call which tools, what those tools can do at runtime, and what gets logged for audit. It covers six pillars: registry, identity, policy, observability, lifecycle, and compliance. It exists because the Model Context Protocol specification deliberately leaves enterprise governance out of scope.
2. How does MCP governance differ from API governance?
MCP governance handles a non-deterministic client (the LLM agent) calling tools whose semantics live in natural-language descriptions. API governance handles deterministic clients calling endpoints with known schemas. The practical differences show up in intent verification, tool description vetting, identity propagation through to downstream tools, and defenses against tool poisoning and rug pulls that have no API governance analog.
3. How does MCP governance differ from AI governance?
AI governance is the broader discipline covering model selection, training data, bias evaluation, model drift, and AI ethics. MCP governance is the specific subset that activates when a model starts calling tools. You can have a mature AI governance program with no MCP governance if your agents never reach outside the LLM context window.
4. Do I need an MCP gateway to govern MCP?
A gateway is the most efficient enforcement point for policy, identity propagation, and audit logging, but governance is broader than a gateway. The registry, lifecycle, and compliance pillars require workflow tooling that lives outside the gateway. Most enterprises deploy a gateway plus a registry plus an identity layer plus a GRC integration.
5. Can I extend my existing API gateway to cover MCP?
Some controls extend (auth, rate limiting, TLS, schema validation, audit logging). Four areas need new patterns: intent verification at the parameter level, tool description vetting, per-tool token scoping, and tool poisoning defense. Most traditional API gateways need extensions or a sibling MCP gateway to cover the gap.
6. What is the minimum viable MCP governance setup?
The minimum viable setup is a registry, an identity layer with per-user OAuth tokens, a gateway enforcing tool-level RBAC, and a per-call audit log. That reaches Level 2 maturity per the model in this guide. Below that, you cannot answer "who called what when" for an auditor or an incident.
7. Which compliance frameworks apply to MCP?
SOC 2 applies to any service organization. HIPAA applies when agents touch PHI. PCI-DSS applies when agents touch cardholder data. EU AI Act applies to high-risk AI systems offered in the EU market. NIST AI RMF is voluntary but referenced by US federal procurement. ISO 27001 is the international baseline. The crosswalk in section five maps each pillar to control families in all six.
8. How do I audit MCP usage?
An audit-ready MCP governance program produces a per-call log containing user identity, agent identity, server, tool, parameters, response, decision, and latency, stored in immutable storage for at least 90 days. Auditors query the log directly through a saved query for each control. Continuous evidence pulls into the GRC tool reduce audit-prep time from weeks to hours.
9. What is the most common MCP governance mistake?
The most common mistake is treating shadow MCP as a future problem. Developers install servers fast. Without a registry and a discovery sweep in the first 30 days, the inventory gap compounds. Every other pillar is built on incomplete data until the registry catches up.
10. How long does an MCP governance program take to roll out?
A focused 90-day plan delivers Level 2 maturity (working registry, identity, policy, observability) across all six pillars. Reaching Level 3 (audit-ready, all six pillars defined) typically takes another 3-6 months. Teams using a commercial gateway compress these timelines by roughly 50% compared to DIY OSS paths.
.svg)
.avif)
