OWASP MCP Governance & Risk: Should You Let That MCP Server Into Your Environment?

AI agents are being wired to real systems at speed. The connector doing the wiring is the Model Context Protocol (MCP) — and an MCP server can let an agent read your wikis, open pull requests, post to Slack and trigger production workflows, often without a human seeing every step. The new OWASP MCP Governance & Risk Project (on GitHub) exists to answer the one question that matters before you connect one: should this MCP server be allowed in our environment, and under what controls? Here's the framework, and a free tool that runs the check.

The four gates that come before any score

The framework's sharpest idea is that some things are non-negotiable. Before you weigh a single risk factor, four gates must pass — and any failure blocks approval on its own:

• No owner = no approval. Every server has a named, accountable owner or it does not ship.
• No logging = no production use. An audit trail of every action is mandatory in production.
• No scope definition = no access. The data it can read and the actions it can take are documented, or it gets no access.
• No review = no enterprise deployment. A periodic risk-tier review is scheduled; approval is not a one-time event.

These map directly onto the failures we keep seeing in agentic incidents — an agent that acted with no human in the loop, and the enter-evade-escape pattern that thrives when nothing is logged.

Classify: Tier 0 to Tier 4

Not every MCP server is the same risk, so the framework classifies each into one of five tiers, and the bar rises as you climb:

• Tier 0 — public data, read-only.
• Tier 1 — internal, non-sensitive read.
• Tier 2 — sensitive read.
• Tier 3 — write-capable.
• Tier 4 — privileged / critical.

A Tier 0 documentation-search server and a Tier 4 server that can deploy to production are governed by the same rules but held to very different thresholds. The tier is where "under what controls?" gets its answer.

The primary risk: tool chaining

Of all the ways an MCP deployment goes wrong, the framework names tool chaining as the primary risk — a server that can invoke other tools or trigger downstream workflows turns a single approved action into a chain the user never saw. Around it sit the familiar concerns: authorization and access scope, credential exposure and data leakage, audit-trail gaps, supply-chain and vendor trust, and shadow-IT deployment. The eight-factor risk model scores exactly these, so two servers at the same tier can still land at very different residual risk.

Six principles, and the one that makes it work

The framework rests on six governance principles: ownership, risk classification, least privilege, meaningful human approval, auditability — and the one most programs forget: make the approved path faster than shadow deployment. Governance that is slower than "just run the server yourself" doesn't get followed; it gets bypassed. The goal is an intake that is quick enough that doing it right is also the path of least resistance.

It maps to what your auditors already expect

This isn't a standard in a silo. The project's framework-mapping.md aligns it to the OWASP MCP Top 10, the OWASP LLM Top 10, NIST AI RMF, ISO/IEC 42001 and SOC 2. A decision you record against the MCP framework drops straight into the compliance evidence you already produce.

Run the check on a real server

We turned the framework into a free, browser-based tool. Answer the four gates, pick a tier, and score the eight risk factors, and the MCP Server Governance & Risk Check returns an approve / conditional / block verdict, a residual-risk score against the tier's bar, and the specific controls to add before the server is allowed in. Nothing you enter leaves your browser, and you can copy the result straight into an intake form or risk register.

Pair it with the config-level checks: audit the server's setup with MCP Guard (secrets, unpinned installs, over-broad filesystem roots), and screen forwarded content for injection with Prompt Scan.

Frequently asked questions

What is the OWASP MCP Governance & Risk Project?

It is an OWASP project that provides a practical governance framework for organizations adopting the Model Context Protocol (MCP). It answers one question — should this MCP server be allowed in our environment, and under what controls — through three layers of policy, controls and checklists, including four non-negotiable gates, a Tier 0-4 classification, and an eight-factor risk model. It is maintained by Vandana Verma Sehgal and released as v1.0.

What are the four non-negotiable MCP governance rules?

No owner = no approval (every server needs a named owner); no logging = no production use (audit trails are mandatory in production); no scope definition = no access (the data and actions a server can take must be documented); and no review = no enterprise deployment (periodic risk-tier reviews are required).

What are the MCP classification tiers?

Tier 0 is public data, read-only; Tier 1 is internal, non-sensitive read; Tier 2 is sensitive read; Tier 3 is write-capable; and Tier 4 is privileged or critical. Higher tiers demand stronger controls and meaningful human approval.

Why do MCP servers need governance?

MCP servers let AI agents read wikis, open pull requests, post to Slack and trigger production workflows at machine speed, often without a human seeing every intermediate step. Without ownership, scope, logging and review, an approved server can chain actions and reach data or systems nobody signed off on. Governance makes the safe path the fast path.

How does it map to other standards?

The framework aligns to the OWASP MCP Top 10, the OWASP LLM Top 10, NIST AI RMF, ISO/IEC 42001 and SOC 2, so a governance decision recorded against it drops into the compliance frameworks your auditors already expect.

This is an independent summary of the OWASP MCP Governance & Risk Project based on its public v1.0 materials; the project is maintained by its OWASP contributors and may evolve. PlayCISO's tool is an unofficial aid, not an OWASP product.