The setup
Enterprises do not fear MCP—they fear unowned tools with data exfil superpowers and no one who remembers why deploy_everything exists.
Governance is how you make MCP legible to security, legal, and the engineer who joins in six months and inherits your chaos. If your governance lives only in a wiki page, congratulations: you built a single pane of glass for attackers and auditors alike. I prefer you win against attackers.
Picture this
Mental model
Governance is continuous, not a checkbox before launch. Catalog what you run, policy what you allow, audit what happened, loop into incidents when you were wrong—and you will be wrong; I have seen your PR descriptions.
Third-party MCP servers are dependencies with supply-chain risk. Pin them, review them, allowlist them. "It was on the marketplace" is not a data classification.
Walkthrough
MCP server catalog (minimum viable adulthood)
Every approved server gets a catalog row:
| Field | Why it exists |
|---|---|
| Owner | Human accountable when things break at 2 a.m. |
| Data classes | PII, secrets, regulated—drives approval path |
| Risk tier | dev / prod / regulated; maps to host enablement |
| Last review date | Stale entries rot; rug-pulls love stale entries |
| Version pin | What is actually deployed vs "latest" fantasy |
| Blast radius | What systems one compromised tool touches |
GitHub stars are not a field. README length is not a field. I am magnificent; your catalog should be useful, not decorative.
Policy at host and gateway
Policy engines need context, not vibes:
- Who — user, service account, host app identity
- What — tool name, args (structured), mutating vs read
- Where from — server id, provenance, risk tier
Enforce at host (what servers/tools are enabled) and gateway (HTTP MCP authZ, rate limits, egress). Splitting responsibility avoids "the model was allowed to ask" becoming "the model was allowed to do."
Risk tiers and reviews
- Dev tier — experimental servers, synthetic data, loose tools.
- Prod tier — reviewed schemas, owners, monitoring, change control.
- Regulated tier — extra approvals, data residency, retention, break-glass logging.
Mandatory reviewers for tool schema changes—not just code changes. A one-line description edit can be an injection attack.
Automated checks where possible: secret patterns in repos, network egress declarations, filesystem scope, dependency CVEs on server packages.
Audit → incident loop
Audit logs are useless in stdout purgatory. They belong in your SIEM with:
- Append-only storage where policy requires it
- Structured fields: identity, tool, server version, outcome, correlation id
- Runbooks linking log queries to disable server, revoke token, notify owner
When something breaks, the catalog tells you who to call; the audit tells you what happened; the policy tells you what should have blocked it. All three. Not one wiki link.
Hall of Shame
Hall of shame: Rubber-stamp PRgovernance
"+420 tools lgtm"
Fix: require justification, owner, blast radius, and rollback. "lgtm" is not governance; it is a coping mechanism.
Why this matters in production
Regulators do not care that "the model did it." They care what your controls were—catalog, policy, audit, review cadence. MCP without governance is speed running a compliance finding. I would rather you ship slower and keep your job.
Mini challenge
Draft a governance checklist for approving a new third-party MCP server: owner, data classes, risk tier, pin strategy, review cadence, incident contact, disable path. If any box is "TBD," the answer is no until it is not TBD.
Reflection
Which team owns MCP catalog entries when engineering rotates? If the answer is "whoever remembers," you do not have governance—you have folklore.
You can now brag that…
You can say "data classification" in the same sentence as "stdio" without blacking out. Growth. Terrifying, necessary growth.