Topic starter
14/09/2026 10:10 am
TL;DR: MCP governance fails when it stays at the policy layer, because enterprise controls must deny unsafe tool use at runtime, not merely document it, according to Pomerium. The framework’s real test is whether inventory, classification, logging, and per-tool scope are enforced in the request path before agents can act.
Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “MCP Governance: OWASP Framework & Enforcement”.
By the numbers:
- 91.8% of 414 audited production servers lacked OAuth authentication in a July 2026 assessment of internet-facing MCP servers, according to Pomerium.
Key questions
Q: What fails when MCP governance stays at the policy layer?
A: Policy-only governance fails because it cannot stop a machine-speed tool call once the server is reachable.
Q: Why do MCP servers need runtime denial instead of approval workflows alone?
A: Approval workflows answer whether a server should exist, not whether a specific action should proceed now.
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact.
Practitioner guidance
- Map every MCP server to a named owner and tier Require an accountable owner, assign a Tier 0-4 classification by the highest-risk tool, and refuse production use until scope and rationale are recorded.
- Block unsafe servers at the request path Deny token passthrough, missing audience validation, unauthenticated write access, and local configs that rely on loopback binding instead of caller authentication.
- Instrument per-call audit evidence Log identity, server, tool, parameters, authorization result, and outcome for every call, then verify a test request appears in SIEM with all fields.
Bottom line: MCP governance breaks down when policy does not reach the runtime path that authorises each tool call.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/09/2026 10:10 am
Request-path enforcement is the dividing line between MCP governance and MCP theatre: A policy that cannot deny a tool call at runtime is not governance, it is documentation. The article correctly shows that inventory, tiers, and risk scores only become meaningful when they are tied to a component that can block, log, and attribute the request. The practitioner conclusion is simple: if the request path is not controlled, the governance model is still advisory.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the difference between MCP inventory and MCP enforcement?
A: Inventory tells you what exists, who owns it, and how it is classified. Enforcement decides whether a particular request is allowed to proceed. MCP governance needs both, but they are not interchangeable: inventory without enforcement cannot stop a harmful call, and enforcement without inventory cannot sustain accountability or lifecycle control.
👉 Read our full editorial: MCP governance requires enforcement in the request path