Most enterprises did not decide to adopt the Model Context Protocol. Engineers did, one mcp.json file at a time. The result is a class of asset that reads internal wikis, opens pull requests, queries production databases, and posts to Slack — at machine speed, often without a human seeing the intermediate steps.
MCP governance is the discipline of answering one question before that happens: should this MCP server be allowed in our environment, and under what controls? In 2026, that question finally has a structured answer. The OWASP MCP Governance & Risk Project published v1.0 of its framework — inventory, classification, risk scoring, six governance principles, and mappings to NIST AI RMF, ISO/IEC 42001, and SOC 2.
It is the most complete governance model the ecosystem has. It is also, by design, a policy document. The gap between a written tier model and a tool call that actually gets denied is where most programs will fail.
MCP governance is the set of policies, controls, and enforcement mechanisms that determine which MCP servers an organization allows, what data and actions each one may reach, who is accountable for it, and how every tool call is logged and reviewed.
The framework's spine is four rules it treats as non-negotiable — bypassing any one requires a formal, documented risk acceptance:
No owner = no approval. Every server needs a named accountable person.
No logging = no production use. Audit trails are a deployment gate, not a nice-to-have.
No scope definition = no access. Data and action scope documented before connection.
No review = no enterprise deployment. Approval decays; tools change under you.
On top of that sits a five-tier classification model, applied before connection and set by the highest-risk tool on the server:
Tier | Profile | Example | Approval authority |
0 | Public data, read-only | Weather API | Lightweight review |
1 | Internal, non-sensitive read | Wiki search | Security + business owner |
2 | Sensitive read | CRM, HR records | Security + data owner + privacy |
3 | Write-capable | Merge a PR, post to Slack | Security architecture + platform owner |
4 | Privileged / critical | Cloud admin, IAM, prod deploy | CISO or risk board |
Then come the hard gates: conditions that reject a server outright, regardless of score. Token passthrough to downstream APIs. Missing audience validation. Accepting tokens broader than the documented scope. An HTTP endpoint exposing non-public data or any write action without authentication at the server or a non-bypassable gateway. A local server that relies on loopback binding instead of authenticating the caller. Production credentials sitting in a local STDIO config.
Only after the gates pass does the eight-factor score apply — data sensitivity, action capability, identity scope, exposure, vendor trust, auditability, reversibility, and blast radius, each 1–5, for a total of 8 to 40. There is a critical-factor floor: any single factor at 5 makes the rating High at minimum, even if everything else is a 1.
Read those gates closely and a pattern emerges. Almost every one is a statement about runtime behavior, not paperwork. "Does not forward client tokens." "Validates audience." "Authenticates the caller." "Logs user, tool, action, and outcome." Those are properties of a request path — and today most MCP deployments have no request path anyone controls.
The scale of that is measurable. A July 2026 dynamic assessment of internet-facing MCP servers found that 91.8% of 414 audited production servers lacked OAuth authentication, identified 687 tool instances exposing shell execution with no access controls, and reported 68 vulnerabilities via GitHub Security Advisories. The same study found 41.6% of confirmed servers disappeared within three days between measurement runs — an inventory problem as much as a security one.
The incident records follow the same shape, private repository exfiltration through a poisoned public GitHub issue; a malicious support ticket that got a Cursor agent to leak Supabase tokens; a trojanized MCP server distributed an infostealer through registry poisoning. The common thread was that traditional monitoring caught none of them.
Client-side allowlists do not close this. Neither does a spreadsheet. The framework itself is explicit that developer-only controls are insufficient — and that a governance program must publish evidence, not intentions.
The useful exercise is to take the OWASP MCP Top 10 risks the framework maps to and ask, for each, what component actually enforces this? Enforcement splits across four layers, and only some of it belongs in a proxy.
OWASP MCP risk | What enforcement requires | Where it lives |
MCP01 — Token mismanagement | Clients never hold upstream credentials; tokens injected server-side | Identity-aware proxy / gateway |
MCP02 — Scope creep | Per-tool allow/deny, not per-server access | Policy engine at the request path |
MCP04 — Supply chain | SBOM review, version pinning, CVE scanning | Registry + build pipeline |
MCP07 — Insufficient authN/authZ | OAuth 2.1 with audience validation; no bypassable endpoint | Non-bypassable enforcement point |
MCP08 — No audit or telemetry | Per-call logs with identity, tool, parameters, outcome → SIEM | Proxy or platform layer |
MCP09 — Shadow MCP | Allowlisting plus config-to-runtime correlation | Endpoint + network monitoring |
Pomerium sits in the third and fifth rows of that table. It fronts MCP servers as an identity-aware proxy: users authenticate through your existing IdP over downstream OAuth 2.1, Pomerium handles upstream OAuth flows and injects tokens into proxied requests so clients never see the credentials, the mcp_tool criterion in Pomerium Policy Language expresses per-tool allow and deny lists that compose with identity-based policy, and every tool call is logged with method, tool name, and parameters. In OWASP terms, that turns MCP01, MCP02, MCP07, and MCP08 from written policy into a deny you can point an auditor at.
It does not cover the whole framework, and no proxy does. Supply-chain review, SBOM evidence, and vendor questionnaires stay with procurement and your build pipeline. Local STDIO servers running on a laptop need local hardening requirements instead of network controls. And no gateway resolves the semantic problem: a tool call triggered by prompt injection can be perfectly authorized. That is what tier-based human-in-the-loop requirements and read/write server separation exist for.
The framework's own 90-day plan is the right sequence, and the first 30 days are entirely about visibility:
Inventory. Scan for .cursor/mcp.json, Claude Desktop configs, and IDE settings. Run a self-disclosure amnesty window.
Classify. Assign Tier 0–4 by highest-risk tool. Record the rationale.
Gate the obvious failures. Token passthrough, unauthenticated write access, production credentials in local configs.
Instrument before you enforce. Define the SIEM fields — timestamp, identity, server, tool, sanitized parameters, outcome, authorization result — and confirm a test call produces a log entry with all of them.
Publish a paved road. Governance loses whenever unofficial install is faster than official approval.
What is the OWASP MCP Governance & Risk Framework? It is an OWASP project publishing a governance framework (v1.0) for enterprise MCP adoption. It covers asset inventory, a Tier 0–4 classification model, an eight-factor risk score, six governance principles, hard gates, and control mappings to the OWASP MCP Top 10, OWASP LLM Top 10, NIST AI RMF, ISO/IEC 42001, and SOC 2.
How is MCP governance different from normal API governance? Three properties change the threat model: agents act with delegated human identity, they operate at machine speed, and tool outputs become instructions. A malicious wiki page can steer an agent into a legitimate, fully authorized write. API governance assumes a deterministic caller; MCP governance cannot.
Do I need a gateway to comply with the framework? Not literally — the framework is vendor-neutral. But its hard gates require authentication at "the server or a non-bypassable gateway," per-tool least privilege, and production audit logging with identity attribution. If your MCP servers cannot do those things natively, an enforcement point in front of them is the practical answer.
What is a shadow MCP server? An MCP server running in your environment without approval, inventory entry, or owner — often installed locally with hardcoded credentials. It is MCP09 in the OWASP MCP Top 10, and the framework treats reducing its count as a monthly reported metric.
Governance that exists only in a document produces exception logs, not evidence. The OWASP framework gives security teams the taxonomy they were missing — tiers, gates, scores, minimum audit fields — and every one of those artifacts eventually needs a component in the request path that can say no and write it down.
If you are mapping the framework's hard gates to your own stack, start with the ones that are pure runtime: audience validation, no token passthrough, per-tool scope, and a log line for every call. See Pomerium's MCP support for what that looks like in configuration, or read why the MCP spec leaves enforcement to the implementer.
OWASP MCP Governance & Risk Project — Framework mapping appendix
Padilla, N. — Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale (arXiv:2608.00150, July 2026)
Stay up to date with Pomerium news and announcements.
Embrace Seamless Resource Access, Robust Zero Trust Integration, and Streamlined Compliance with Our App.
Use Cases
Quicklinks
Stay Connected
Stay up to date with Pomerium news and announcements.
