A practical governance framework for organizations adopting the Model Context Protocol (MCP), the open standard that lets AI agents connect to external tools, data sources, and systems.
77
stars
21
commits
Sep 8, 2026
updated
A practical governance framework for organizations adopting the Model Context Protocol (MCP), the open standard that lets AI agents connect to external tools, data sources, and systems.
MCP adoption is accelerating across engineering teams. Agents can read wikis, open pull requests, post to Slack, and trigger production workflows often at machine speed and without the user seeing every intermediate step. This repository provides a structured way to answer the central governance question:
Should this MCP server be allowed in our environment, and under what controls?
| Document | Description |
|---|---|
| mcp-governance-risk-framework-v1.0.md | Main guide (v1.0): inventory, classification, risk scoring, governance principles, and rollout guidance |
| framework-mapping.md | Framework mapping: control mappings to OWASP MCP Top 10, OWASP LLM Top 10, NIST AI RMF, ISO 42001, and SOC 2 |
| reference.md | Reference links: curated external URLs for MCP security, threat modeling, vendor review, and standards |
The v1.0 guide covers six core chapters plus a closing appendix. Treat the content in three layers: policy (Chapters 1 and 3), controls (Chapters 2–6 and the appendix control catalog), and checklists (chapter-end and appendix practitioner checklists). Compliance framework mappings live in the companion framework-mapping.md document.
Not in v1.0 (planned for future releases): separate approval-workflow chapters, intake forms, risk register templates, and vendor questionnaires. Use the in-guide checklists and evidence pack until those artifacts ship.
Read Chapter 1: Executive Summary for the business case, four non-negotiable governance rules, and a 90-day rollout plan. Use the Ten Questions maturity check and Appendix Practitioner Checklist before presenting to a risk committee.
Start with Chapter 2 and Chapter 3, then implement Chapter 4: Asset Inventory and the Classification Model (Chapter 5). Review hard gates, tool chaining, and client and host governance. Use framework-mapping.md for OWASP and compliance control mappings; use reference.md for MCP authorization spec, OWASP MCP Top 10, and other external sources.
Start with framework-mapping.md for OWASP, NIST AI RMF, ISO 42001, and SOC 2 alignment. Use the Formal Control Catalog and Evidence Pack in the appendix for audit evidence requirements by tier.
Review the Tier 0–4 classification summary and Recommended First Steps. Understand that servers are classified by their highest-risk tool, not by server name alone. For faster adoption, use the Pre-Approved MCP Catalog. For local stdio servers, follow Local MCP Hardening Requirements.
Focus on data scope, third-party server review, and vendor trust factors in Chapter 5 and Chapter 6: Risk Scoring. Use framework-mapping.md for audit and compliance alignment; external policy references are in reference.md.
These four rules are designed to be adopted as organizational policy. They are a subset of the six governance principles in Chapter 3.
| Rule | Implication |
|---|---|
| No owner = No approval | Every MCP server requires a named owner before approval |
| No logging = No production use | Servers without audit trails cannot operate in production |
| No scope definition = No access | Data and action scope must be documented before connection |
| No review = No enterprise deployment | Periodic review is mandatory by risk tier |
| # | Principle | One-line rule |
|---|---|---|
| 1 | No MCP Without Ownership | No owner = no approval |
| 2 | Classify Before You Connect | Know the risk tier before connecting |
| 3 | Least Privilege for Tools | Minimum permissions per tool, not per server name |
| 4 | Human Approval Must Be Meaningful | HITL must show what, where, who, and impact |
| 5 | Auditability Requires Production Logging | No logging = no production use |
| 6 | The Approved Path Must Beat Shadow IT | Pre-approved patterns and SLAs must be faster than unofficial install |
| Tier | Description | Example | Approval authority |
|---|---|---|---|
| 0 | Public data, read-only | Public docs, weather API | Lightweight review |
| 1 | Internal, non-sensitive read | Internal wiki search | Security + business owner |
| 2 | Sensitive read | CRM, HR knowledge base | Security + data owner |
| 3 | Write-capable | GitHub PR merge, CI/CD trigger | Security architecture + platform owner |
| 4 | Privileged / critical | Cloud admin, IAM, production deploy | CISO or risk board |
This framework is intended to evolve with the MCP ecosystem. It is maintained as part of the MCP Security Project. If you use it in your organization or have feedback on classification, scoring, or policy language, open an issue or submit a pull request.
A practical governance framework for organizations adopting the Model Context Protocol (MCP), the open standard that lets AI agents connect to external tools, data sources, and systems.
77
stars
21
commits
Sep 8, 2026
updated
A practical governance framework for organizations adopting the Model Context Protocol (MCP), the open standard that lets AI agents connect to external tools, data sources, and systems.
MCP adoption is accelerating across engineering teams. Agents can read wikis, open pull requests, post to Slack, and trigger production workflows often at machine speed and without the user seeing every intermediate step. This repository provides a structured way to answer the central governance question:
Should this MCP server be allowed in our environment, and under what controls?
| Document | Description |
|---|---|
| mcp-governance-risk-framework-v1.0.md | Main guide (v1.0): inventory, classification, risk scoring, governance principles, and rollout guidance |
| framework-mapping.md | Framework mapping: control mappings to OWASP MCP Top 10, OWASP LLM Top 10, NIST AI RMF, ISO 42001, and SOC 2 |
| reference.md | Reference links: curated external URLs for MCP security, threat modeling, vendor review, and standards |
The v1.0 guide covers six core chapters plus a closing appendix. Treat the content in three layers: policy (Chapters 1 and 3), controls (Chapters 2–6 and the appendix control catalog), and checklists (chapter-end and appendix practitioner checklists). Compliance framework mappings live in the companion framework-mapping.md document.
Not in v1.0 (planned for future releases): separate approval-workflow chapters, intake forms, risk register templates, and vendor questionnaires. Use the in-guide checklists and evidence pack until those artifacts ship.
Read Chapter 1: Executive Summary for the business case, four non-negotiable governance rules, and a 90-day rollout plan. Use the Ten Questions maturity check and Appendix Practitioner Checklist before presenting to a risk committee.
Start with Chapter 2 and Chapter 3, then implement Chapter 4: Asset Inventory and the Classification Model (Chapter 5). Review hard gates, tool chaining, and client and host governance. Use framework-mapping.md for OWASP and compliance control mappings; use reference.md for MCP authorization spec, OWASP MCP Top 10, and other external sources.
Start with framework-mapping.md for OWASP, NIST AI RMF, ISO 42001, and SOC 2 alignment. Use the Formal Control Catalog and Evidence Pack in the appendix for audit evidence requirements by tier.
Review the Tier 0–4 classification summary and Recommended First Steps. Understand that servers are classified by their highest-risk tool, not by server name alone. For faster adoption, use the Pre-Approved MCP Catalog. For local stdio servers, follow Local MCP Hardening Requirements.
Focus on data scope, third-party server review, and vendor trust factors in Chapter 5 and Chapter 6: Risk Scoring. Use framework-mapping.md for audit and compliance alignment; external policy references are in reference.md.
These four rules are designed to be adopted as organizational policy. They are a subset of the six governance principles in Chapter 3.
| Rule | Implication |
|---|---|
| No owner = No approval | Every MCP server requires a named owner before approval |
| No logging = No production use | Servers without audit trails cannot operate in production |
| No scope definition = No access | Data and action scope must be documented before connection |
| No review = No enterprise deployment | Periodic review is mandatory by risk tier |
| # | Principle | One-line rule |
|---|---|---|
| 1 | No MCP Without Ownership | No owner = no approval |
| 2 | Classify Before You Connect | Know the risk tier before connecting |
| 3 | Least Privilege for Tools | Minimum permissions per tool, not per server name |
| 4 | Human Approval Must Be Meaningful | HITL must show what, where, who, and impact |
| 5 | Auditability Requires Production Logging | No logging = no production use |
| 6 | The Approved Path Must Beat Shadow IT | Pre-approved patterns and SLAs must be faster than unofficial install |
| Tier | Description | Example | Approval authority |
|---|---|---|---|
| 0 | Public data, read-only | Public docs, weather API | Lightweight review |
| 1 | Internal, non-sensitive read | Internal wiki search | Security + business owner |
| 2 | Sensitive read | CRM, HR knowledge base | Security + data owner |
| 3 | Write-capable | GitHub PR merge, CI/CD trigger | Security architecture + platform owner |
| 4 | Privileged / critical | Cloud admin, IAM, production deploy | CISO or risk board |
This framework is intended to evolve with the MCP ecosystem. It is maintained as part of the MCP Security Project. If you use it in your organization or have feedback on classification, scoring, or policy language, open an issue or submit a pull request.