What Is MCP Governance? A Framework for Securing MCP Servers at Scale

MCP governance is the structured set of policies, controls, and audit mechanisms an organization uses to manage every MCP server that its employees, agents, and assistants depend on. It covers four areas: which MCP servers are approved to run, what those servers can do at runtime, what content crosses the agent-server boundary, and how every decision is recorded for compliance and incident response. Done right, MCP governance gives security teams answers to questions auditors and incident responders actually ask. Done loosely, it produces a long list of unmaintained servers, no inventory, and no defensible audit trail.

This article lays out a working MCP governance framework, shows how it maps to existing security and compliance standards, and explains how to roll it out in stages without slowing the teams that depend on MCP servers every day.

What is MCP governance?

MCP governance is the practice of controlling and auditing MCP servers across their full lifecycle: discovery, curation, admission, runtime, and audit. It is the framework that turns a fast-growing collection of MCP servers into a managed asset class.

A complete framework should answer five questions:

Which MCP servers are approved to run, and how do we prove it?
Which tools is each MCP server allowed to expose, with which arguments?
Which agents are allowed to call which MCP server tools?
Which content (prompts, completions, tool arguments, responses) is allowed to cross the boundary?
How is every decision recorded so it can be verified later?

If the framework cannot answer all five, it has a gap.

Why MCP governance matters in 2026

MCP server adoption ran ahead of MCP server security. Most organizations now have:

Developers pointing IDEs (VS Code, Cursor, Claude Desktop) at MCP servers from public sources
Production agents using MCP servers to query databases, send email, file tickets, write code, and move money
No central inventory of what is running, no policy on what is allowed, and no audit trail of what has been done

The result is shadow MCP at a scale that surprises most CISOs when the inventory finally runs. At the same time, documented MCP attacks (Postmark, Smithery, GitHub MCP, mcp-remote CVE-2025-6514) have already affected hundreds of thousands of users. Regulators have noticed: NIST AI RMF, EU AI Act, CMMC, SR 11-7, and HIPAA all expect organizations to demonstrate provenance, access control, human oversight, and tamper-evident records for the AI artifacts in production. MCP servers are squarely in scope.

MCP governance is the structure that turns that pile of unknowns into something the organization can defend.

The four pillars of an MCP governance framework

Pillar 1: Curation (which MCP servers are allowed)

Curation is the work of deciding which MCP servers an organization trusts. The output is a curated internal registry of approved servers, each packaged as a signed OCI artifact with attached scan results, license information, and provenance.

Curation activities include:

Inventorying MCP servers already in use
Reviewing servers from public sources before they enter the internal registry
Scanning for known vulnerabilities, suspicious tool definitions, and license risks
Signing approved servers and pinning versions
Re-reviewing on a defined cadence as new versions ship

If the organization cannot point to a single, signed source of approved MCP servers, the rest of the framework has nothing to stand on.

Pillar 2: Admission (what loads into a runtime)

Admission is the moment when an MCP server moves from "approved" to "running." Artifact policy evaluates every server before it loads against:

Signature: was it signed by an approved key?
Provenance: did it come from the curated internal registry?
Scan results: did it pass required scans?
Attestations: is there a signed record of who reviewed it and when?

If any check fails, admission fails. Default-allow at admission is not governance.

The May 2026 Mini Shai-Hulud worm (CVE-2026-45321, CVSS 9.6) showed why admission checks need to go beyond signature and SLSA attestation. The attackers compromised legitimate build pipelines and produced valid signatures on malicious artifacts. A working admission policy expects attestations to describe artifact safety (scan results, behavioral checks, provenance of every component) and verifies them against policy that was signed by a different key chain than the artifact itself. Enforcement must happen outside the trust boundary of the system that produced the artifact. If the build pipeline can also produce the approved-by-policy attestation, an attacker who owns the pipeline owns both.

Pillar 3: Runtime enforcement (what the MCP server can do)

Once an MCP server is loaded, tool policy and guardrail policy govern what it can do.

Tool policy covers:

Which agents are allowed to call which tools on which MCP servers
Which arguments are permitted (for example, an MCP server's database.query may be allowed only for SELECT statements)
Which calls require destructive-operation confirmation or human approval
Which rate limits apply
Which agents are allowed to compose tools across MCP servers

Guardrail policy covers content that crosses the boundary:

Prompt content sent to the MCP server for injection attempts
Tool arguments for sensitive data leakage (PII, PHI, credentials)
MCP server responses for prompt injection attacks back into the agent
Regulated content that should be redacted or blocked

The runtime evaluates both policies on every tool invocation, locally, with no SaaS dependency.

Pillar 4: Audit (what happened)

The audit pillar produces a cryptographically chained log of every decision: admissions, denials, tool calls, human approvals, content events. The chain ensures past entries cannot be altered without detection. The log feeds compliance evidence, incident response, and ongoing policy tuning.

To be useful, the audit must be:

Complete (every decision captured)
Tamper-evident (cryptographic chaining)
Centralized (events from desktop, edge, on-prem, and air-gapped converge)
Exportable (compliance teams can produce evidence without manual effort)

A gap in any of those four characteristics breaks the framework.

How the four pillars work together

The pillars are connected, not parallel. A single MCP tool call flows through all of them.

Step	Pillar	Outcome
Developer requests a new MCP server	Curation	Server reviewed, scanned, signed, added to the internal registry
Agent loads the MCP server	Admission	ArtifactPolicy verifies signature, scan results, and provenance
Agent invokes a database tool	Runtime (tool policy)	Argument validated; query type allowed; logged
Agent attempts to pass customer SSNs into a search	Runtime (guardrail policy)	PII detected; call blocked
Agent requests a $25K refund through an MCP server	Runtime (tool policy + HIL)	Human approval required; captured as signed attestation
Compliance team requests evidence	Audit	Chained logs exported with every step above verifiable

This is the chain auditors look for. Each link must exist and each link must be tamper-evident.

MCP governance and existing standards

Standard	What an MCP governance framework supports
NIST AI RMF	Govern (registry, policy), Map (scanning, attestations, ArtifactPolicy gates), Measure (chained logs), Manage (tool and guardrail policy, HIL, fail-closed defaults)
NIST SP 800-53	SR-3/4/9/11 (scanning, signing, attestations); AU-2/3/9/10/12 (chained audit); AC-3/4/6 (least privilege via tool policy); CM-3/7/14 (versioned, integrity-blocked artifacts); SA-12 (supply chain risk management)
CMMC Level 2/3	Tamper-evident logging, supply chain scanning and signing, disconnected operation
EU AI Act	Supply chain transparency, risk documentation, access control, human oversight
HIPAA	Tool policy access controls, guardrail policy PHI detection, audit trails
SR 11-7	Tamper-evident versioning, audit trails, artifact policy promotion gates
21 CFR Part 11 / GxP	Cryptographic record integrity, versioned artifacts, access controls

MCP governance is not a certification. It is the infrastructure that makes certification work achievable.

Step-by-step: how to roll out MCP governance

Inventory. Sweep managed devices, CI/CD pipelines, agent runtimes, and IDEs for MCP servers in use. Most teams find more than they expected.
Stand up an internal MCP registry. Mirror approved servers from public sources into a private OCI registry with scanning, signing, and the MCP registry API endpoints IDEs and agents can point at.
Pick a shared policy language. YAML plus CEL (Common Expression Language) is a common choice. Pick one and stick with it across artifact, tool, and guardrail policy.
Write artifact policy. Define which signatures, scan results, and provenance properties are required before an MCP server can load.
Write tool policy for the top ten MCP servers. Start with the servers handling the highest-risk operations (payments, email, code commits, database writes). Expand from there as the program matures.
Deploy a secure runtime for AI. The runtime should evaluate policy locally on every MCP tool invocation, inspect content at the semantic level, capture human approvals as signed attestations, and write tamper-evident logs.
Define fail-closed defaults. Missing data or evaluation errors should deny, not allow.
Wire HIL into high-risk MCP tools. Define which tools require approval, which approver group, what the SLA is, and what happens on timeout.
Connect audit logs to compliance evidence. Chained logs should feed the same systems your security and audit teams already use.
Review policies on a defined cadence. Monthly is realistic. Static policy is stale policy within a quarter.

Implementation patterns by environment

Developer desktop. The runtime on the developer's laptop points the IDE at the internal MCP registry. ArtifactPolicy verifies signatures before any server loads. ToolPolicy enforces the same rules used in production. Audit events sync when the device is online.

Kubernetes. The runtime deploys as a workload alongside agents. Policies pull from the same OCI registry serving container images. Audit logs feed the cluster's logging stack.

On-premises. The same model, deployed inside the organization's data center. No SaaS dependency.

Air-gapped and DDIL. Policies and signed MCP artifacts ship as self-verifying OCI bundles. The runtime enforces locally with no connectivity. Audit logs sync when connection is restored.

Multi-vendor agent fleets. The framework is vendor-neutral. It governs MCP servers used by Anthropic-hosted agents, OpenAI-driven agents, locally hosted models, and IDE assistants, all under one policy language and one audit chain.

Common mistakes in MCP governance

Treating MCP servers like npm packages. They expose privileged tool surfaces. Their risk profile is much higher than typical dependencies.
Skipping curation. Letting agents load directly from public sources guarantees the inventory will drift and the audit trail will be missing entries.
Putting policy in the gateway. Most MCP communication is local over stdio. A gateway cannot govern what it cannot see.
Fail-open under uncertainty. Default-allow when evaluation errors is a security gap dressed as a feature.
No tamper-evident audit. A log that can be edited is not evidence.
Different policy languages in different layers. When the registry, gateway, and runtime each speak their own language, governance cannot be reasoned about consistently.

How Jozu maps to the framework

Jozu was built to cover all four pillars in one platform.

Pillar	Jozu component
Curation	Jozu Hub: curated internal registry for MCP servers packaged as signed OCI artifacts, with five integrated security scanners and signed Agent attestations. Implements the MCP registry API so VS Code, Cursor, and Claude Desktop can point directly at it
Admission	Jozu Hub + Jozu Agent Guard: ArtifactPolicy verifies signatures, scan results, and provenance before any MCP server loads
Runtime enforcement	Jozu Agent Guard: ToolPolicy at every MCP tool invocation, GuardrailPolicy via the integrated Bifrost gateway on prompts, completions, tool arguments, and responses, plus HIL with signed attestations
Audit	Jozu Hub + Agent Guard: cryptographically chained, tamper-evident logs spanning registry and runtime, exportable as compliance evidence

All four pillars share one policy language (YAML + CEL), one audit chain, and one platform. Policies travel as signed OCI artifacts and enforce locally, even in air-gapped and DDIL environments. There is no remote dependency for policy evaluation, and the runtime fails closed on missing data or evaluation errors.

Explore Jozu MCP Registry →
Explore Jozu Agent Guard →
Request a working session →

Frequently asked questions

Is MCP governance the same as MCP security?
MCP security is a set of technical controls. MCP governance is the broader framework that organizes those controls into policies, ownership, audit, and ongoing operations. The first prevents incidents; the second proves the program is working.

Do we need MCP governance if we already have AI agent governance?
MCP governance is part of AI agent governance. The agent governance framework covers models, agents, MCP servers, content, and audit. MCP-specific work focuses the framework on the MCP server lifecycle and the protocol's specific risks (prompt injection through responses, stdio traffic, tool poisoning).

Can we use our existing change management process for MCP servers?
Change management can cover curation and admission. It does not cover runtime enforcement or audit. You need a runtime control layer in addition to the process layer.

Does MCP governance require an internal MCP registry?
Effectively, yes. Without a curated source of truth for approved MCP servers, artifact policy has nothing consistent to evaluate and the audit trail lacks a provenance anchor.

Who owns MCP governance inside the organization?
Security architecture typically owns policy, platform engineering operates the registry and runtime, and GRC owns the audit outputs. AI security or AI center-of-excellence teams coordinate across them.

Can MCP governance work without Kubernetes?
Yes. A well-designed framework works the same way on Kubernetes, on-premises VMs, edge devices, developer laptops, and air-gapped environments. If a tool requires Kubernetes to enforce policy, it limits where MCP governance can operate.

What is the first thing to put in place?
Inventory and curation. Without an inventory of MCP servers currently running and a curated internal registry, none of the other pillars have a stable foundation.

Related reading:

Ready to put MCP governance into production? See Jozu MCP Registry or book a session.

Share this post