MCP governance requires enforcement in the request path

At a glance

What this is: This is an analysis of the OWASP MCP Governance & Risk Framework and its central claim that governance only works when enforcement sits in the request path.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern machine-speed tool access, auditability, and delegated identity with controls that can actually stop unsafe MCP calls.

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.

👉 Read Pomerium's analysis of MCP governance and runtime enforcement

Context

MCP governance is the discipline of deciding which Model Context Protocol servers are allowed in an environment, what data and actions they can reach, and where enforcement can block unsafe tool calls. For MCP security, the key failure is that policy can be written long before a request path exists to enforce it, which leaves agentic access effectively governed on paper only.

That gap is material for NHI and agentic AI programmes because MCP servers act with delegated identity, machine speed, and changing tool scope. The article’s central point is that runtime enforcement, not documentation, determines whether governance survives contact with production usage.

The framework therefore shifts the question from "What policy do we have?" to "Where can the environment actually deny, log, and constrain tool use?" That is a typical gap in early MCP adoption, not an edge case.

Key questions

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. That means validating audience, blocking token passthrough, and denying unauthenticated write paths before execution. If the control cannot return a real deny, it is documentation, not governance.

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. The risk is amplified when the server uses long-lived secrets, because the same identity can persist across sessions, users, and tool invocations.

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. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.

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.

Technical breakdown

MCP governance as a runtime control problem

MCP governance is not just inventory and approval. It is the combination of identity checks, scope limits, logging, and denial points that decide whether an MCP server can read data, write changes, or call downstream tools. Because MCP servers can query internal systems, open pull requests, and post to collaboration tools, the risk is not only access but action. The article’s key technical insight is that a written classification model does nothing unless it is backed by a non-bypassable control in the request path.

Practical implication: Place enforcement where tool calls are made, not only where servers are approved.

Why token passthrough and audience validation matter

The framework treats token passthrough, missing audience validation, and overly broad scopes as hard failures because they let a client credential travel beyond the context it was issued for. In MCP environments, that means a tool server can inherit authority it should never see, or present credentials to downstream APIs that exceed the documented scope. This is an identity problem as much as a transport problem, because delegated trust becomes indistinguishable from direct user authority unless the server is constrained.

Practical implication: Block downstream token reuse and require audience-bound authentication at the enforcement point.

Per-tool authorisation and telemetry versus server-level trust

A server-level allowlist is too coarse when one MCP server can expose read-only lookup, write actions, and privileged operations in the same session. The framework’s per-tool allow and deny model reflects that the true unit of control is the action, not the server container. Logging also has to be per call, with identity, tool, parameters, and outcome preserved for review. Without that granularity, the organisation can neither prove control nor reconstruct misuse after the fact.

Practical implication: Use per-tool policy and per-call telemetry so review and denial operate at the same level as the action.

Threat narrative

Attacker objective: The objective is to turn delegated tool access into unauthorized data access or operational change without triggering a meaningful denial point.

1. Entry occurs when an MCP server is connected through a local config or approved integration without a non-bypassable authentication and scope check.
2. Escalation follows when token passthrough, broad scopes, or unauthenticated write paths let the server inherit more authority than the operator intended.
3. Impact is achieved when the server reads sensitive sources, opens pull requests, posts to collaboration tools, or triggers privileged downstream actions at machine speed.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Runtime delegation changes the identity problem from access approval to action containment. MCP servers do not merely hold access, they execute it across read, write, and chained tool operations. That means conventional IAM assumptions about stable scope and reviewable sessions become brittle when the tool can change state faster than a human can intervene. The implication is that tool-level authority, not just server enrollment, becomes the meaningful governance boundary.

Shadow MCP is the natural outcome when engineers can deploy integrations faster than security can classify them. The article’s tier model recognises that one unmanaged local config can create the same governance exposure as a formal production service. This is why inventory quality, owner attribution, and approval evidence must be treated as operational controls, not administrative chores. Security teams should assume unmanaged MCP will appear unless discovery is continuous.

Identity-aware proxying becomes a control pattern, not a product preference. The important issue is whether an enforcement layer can validate audience, prevent token passthrough, and log each tool call with enough fidelity to support review. That aligns cleanly with OWASP NHI concepts around delegated authority and least privilege, even though the subject is agentic tooling rather than classic service accounts. Practitioners should align MCP controls to the same governance discipline they use for high-risk NHI access.

Answering the MCP question well now requires bridging NHI governance and agentic AI behaviour. The article shows that machine identities and autonomous tool use are converging at the same enforcement boundary. Teams that still separate NHI policy, proxy policy, and AI tooling policy will miss the combined failure mode. The practical conclusion is to govern the tool chain as one identity surface, not three disconnected ones.

From our research:

• 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.
• That is why Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the next step for teams that need inventory, ownership, and offboarding discipline.

What this signals

Shadow MCP is best understood as an NHI lifecycle problem with an agentic edge. Once engineers can add a server through a config file, the programme needs continuous discovery, owner attribution, and offboarding discipline rather than one-time approval. The relevant standard posture is closer to NHI lifecycle governance than to classic software onboarding, and teams should anchor that thinking in the OWASP Non-Human Identity Top 10.

Governance teams should expect MCP control failures to show up first as missing runtime evidence, not as failed policy documents. If identity, tool, and outcome are not logged together, the environment cannot support review, investigation, or accountable denial. That operational gap is exactly where request-path enforcement and auditability have to meet.

Identity blast radius: Once tool access can chain into write actions, the relevant question becomes how far a single delegated identity can move before a human review cycle can even begin. That is a Zero Trust problem as much as an MCP problem, and it aligns with the request-bound control model in the NIST Cybersecurity Framework 2.0 and the enforcement posture described in NIST SP 800-53 Rev 5 Security and Privacy Controls.

For practitioners

• 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.
• Gate privileged servers more tightly Apply higher approval thresholds to servers that can write, deploy, or reach production systems, and require documented scope before connection.
• Treat shadow MCP as a recurring control failure Reconcile approved servers against runtime observations on a fixed cadence and remove any server that appears without owner, logging, or classification evidence.

Key takeaways

• MCP governance fails when approval exists without runtime denial, because policy alone cannot stop unsafe tool calls.
• The strongest evidence in the article points to missing authentication, incomplete inventory, and excessive tool reach as the real control gaps.
• Practitioners should move MCP controls into the request path, where audience checks, per-tool policy, and auditable logging can actually constrain action.

Key terms

• MCP Governance: MCP governance is the set of policies and enforcement points that decide which Model Context Protocol servers can run, what they can reach, and how their actions are reviewed. In practice, it only works when approval, scope, logging, and denial happen where tool calls are executed.
• Request-Path Enforcement: Request-path enforcement means the system that understands a security event also makes the blocking or step-up decision at runtime. In practice, this keeps detection context and action together, which is critical when abuse depends on correlation across sessions, identities, or behaviours.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Audience Validation: Audience validation checks that a token was issued for the exact service receiving it. In MCP, this prevents a valid token for one server from being reused elsewhere, which is critical because agent-driven workflows often move across multiple tools and trust domains.

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.

👉 Pomerium's full post covers the tier model, hard gates, and request-path controls in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.