Notifications
Clear all
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.
NHIMG editorial — based on content published by Pomerium: MCP Governance: What the OWASP Framework Requires, and Where Enforcement Has to Live
By the numbers:
- 91.8% of 414 audited production servers lacked OAuth authentication in a July 2026 dynamic assessment of internet-facing MCP servers.
- 41.6% of confirmed MCP servers disappeared within three days between measurement runs, exposing an inventory problem as well as a security one.
- 687 tool instances exposed shell execution with no, access controls in the same July 2026 assessment.
Questions worth separating out
Q: How should security teams stop MCP servers from bypassing governance at runtime?
A: Security teams should place enforcement where the tool call happens, not only where the server is approved.
Q: Why do MCP servers create more NHI risk than ordinary API integrations?
A: MCP servers sit in the execution path of AI tools, so a compromised credential can become a control point for multiple downstream actions, not just one API call.
Q: What are the signs that MCP governance is failing?
A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose.
Practitioner guidance
- Inventory every MCP entry point Scan developer workstations, IDE settings, and configuration files for MCP definitions, then assign an owner and risk tier before allowing production use.
- Enforce denial at the request path Require a non-bypassable control point that can validate audience, block token passthrough, and reject unauthenticated write actions before the server executes.
- Move to per-tool policy and logging Define allow and deny rules at the tool level, then log identity, tool name, parameters, and outcome into the SIEM for every call.
What's in the full article
Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:
- The article’s full tier model for classifying MCP servers from Tier 0 through Tier 4 and assigning approval authority.
- The hard-gate conditions that reject a server outright, including token passthrough, missing audience validation, and unauthenticated write access.
- The request-path logging fields that must reach the SIEM, including identity, tool, parameters, and outcome.
- The 90-day rollout sequence for inventory, classification, gating, and instrumentation before enforcement.
👉 Read Pomerium's analysis of MCP governance and runtime enforcement →
MCP governance and runtime enforcement: where do controls live?
Explore further
14/09/2026 10:10 am
The real MCP governance gap is not policy design, it is enforcement placement. The OWASP framework is valuable because it names inventory, classification, and risk scoring, but those are only control intents until they are attached to a request path that can deny unsafe actions. In machine-speed environments, governance without runtime enforcement is a reporting exercise. Practitioners should treat the location of denial as the primary design question.
A few things that frame the scale:
- 91.8% of 414 audited production servers lacked OAuth authentication in a July 2026 dynamic assessment of internet-facing MCP servers, according to the State of Non-Human Identity Security.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is the same visibility problem that lets shadow MCP and delegated tool access go unnoticed.
A question worth separating out:
Q: What should teams do when an MCP server reaches privileged systems?
A: Treat privileged MCP servers as high-risk identity surfaces and require stronger approval, narrower scope, and auditable logging before connection. The key decision is not whether the server is convenient, but whether the control layer can still deny dangerous actions at the moment they occur.
👉 Read our full editorial: MCP governance requires enforcement in the request path
