MCP governance requires enforcement in the request path

At a glance

What this is: This is an analysis of MCP governance that argues enforcement must live in the request path, with hard gates, tiering, and logging applied before tool calls execute.

Why it matters: It matters because IAM, PAM, and NHI teams cannot govern machine-speed tool use with documentation alone; they need denial and audit controls that act at runtime.

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.

Context

MCP governance is the question of whether a machine can be allowed to call tools, read data, and take actions under an organisation's identity controls. The core problem is that MCP servers often arrive through developer-driven configuration files rather than central approval, which means the first control point may be the browser, IDE, or local runtime rather than a security gateway.

The governance gap is not the existence of policy language. It is the distance between a written control and the request path where the tool call actually happens. For NHI programmes, that means scope, logging, identity attribution, and approval need to be enforced where the credential is presented and the action is authorised.

OWASP's MCP Governance & Risk Project gives the field a structure for inventory, tiers, scoring, and hard gates, but the article argues that structure alone does not stop unsafe tool use. The operational question is where denial happens, because anything that cannot deny at runtime will be bypassed by machine-speed execution.

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. If inventory, classification, and scope exist only on paper, they may satisfy review but still leave token passthrough, unauthenticated writes, and unmanaged servers able to act. The control must be enforced where the request is made.

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. Runtime denial matters because MCP tools can read data, open pull requests, and post to systems at machine speed. Without a non-bypassable enforcement point, the organisation can document risk without actually containing it.

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. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

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.

Technical breakdown

Why request-path enforcement is the control point for MCP

MCP governance becomes real only when policy is evaluated where the request is made. In this model, the control point needs to inspect identity, audience, tool name, parameters, and outcome before a server can act, rather than trusting a checklist completed at onboarding. That is why the article draws a sharp line between governance documents and enforcement mechanisms. A document can record risk acceptance, but only a runtime component can refuse a call, log the attempt, and preserve evidence of the decision. For NHI programmes, this is the practical boundary between approval and control.

Practical implication: place denial, audit, and scope checks in front of the tool call, not only in policy or procurement workflows.

How tiering and hard gates constrain MCP server access

The framework described in the article uses a five-tier classification model and a set of hard gates before any scoring happens. Tiering assigns a server's risk posture based on its highest-risk tool, while the hard gates reject conditions such as token passthrough, missing audience validation, unauthenticated write access, or production credentials in local configs. This matters because some risks are not negotiable by score. If a server can forward broader tokens or expose a non-public write action without authentication, the governance model treats that as a denial condition, not a tuning parameter.

Practical implication: classify by the most dangerous tool and block any server that depends on token passthrough, broad scopes, or bypassable authentication.

Why logging and inventory are governance controls, not reporting extras

The article treats logging and inventory as deployment gates because the control only works if the organisation can prove what exists and what each call did. That includes owner assignment, scope definition, audit trails, and continuous correlation between configuration files and runtime behaviour. The problem is especially acute for shadow MCP deployments, where local configuration and unofficial installs outpace central approval. In NHI terms, this is a lifecycle problem as much as a security problem: if you cannot inventory the server, you cannot classify it, and if you cannot log the call, you cannot review it later.

Practical implication: require a complete inventory and per-call telemetry before allowing MCP servers into production.

Threat narrative

Attacker objective: The objective is to use a trusted MCP integration path to obtain data access and tool execution that looks legitimate to ordinary monitoring.

1. Entry occurs when an MCP server is added through local configuration or an unreviewed install path, often without central inventory or owner assignment.
2. Credential exposure follows when client tokens are forwarded, scopes are broader than documented, or authentication is missing at the server or gateway.
3. Escalation happens when the server can read internal data, open pull requests, post to collaboration tools, or reach production systems at machine speed.
4. Impact is unauthorised data access or unsafe action execution that traditional monitoring does not catch in time.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

The trust boundary in MCP shifts from application to delegation: Traditional API governance assumes a deterministic caller and a stable access path, but MCP introduces delegated machine action under human identity and machine speed. That makes per-tool scope, audience validation, and non-bypassable authentication materially more important than server-level approval alone. For identity teams, the real control question is who can authorise the action at the moment it is requested, not who approved the server last quarter.

MCP inventory is now a lifecycle control, not a discovery exercise: The moment engineers can add servers through local files and unofficial installs, the environment needs joiner-mover-leaver thinking for machine interfaces. Unowned servers, stale scopes, and unlogged calls are governance drift, not isolated misconfigurations. The practitioner implication is to treat MCP server lifecycle as part of NHI governance, with ownership, classification, and offboarding tied to runtime evidence.

Runtime denial becomes the defining capability for MCP governance maturity: The framework's tiering model is only as strong as the mechanism that enforces it. That makes request-path controls the named concept here: runtime governance gap: the distance between a policy decision and the enforced denial of a tool call. Teams that cannot close that gap will keep producing compliance artefacts while leaving machine-speed action untouched. The conclusion is that enforcement architecture is the programme, not an implementation detail.

Shadow MCP is an identity problem before it is a tooling problem: The article's examples show that local configuration, silent installs, and unauthenticated endpoints create a parallel control plane outside central governance. That is a familiar NHI pattern in a new form: unmanaged interfaces accumulate faster than approval workflows can absorb them. The practical conclusion is to treat discovery, ownership, and log evidence as identity controls for machine agents, not just as asset-management chores.

From our research library:

• 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.
• Read next: MCP Security Guide

What this signals

Runtime governance gap: MCP programmes fail when they treat approval as the control instead of the control's precondition. The environment changes the moment agents can read, write, and post through tools at machine speed, so governance has to move from documentation to denial at the point of request.

The same pattern now applies across NHI and agentic-adjacent systems: if identity is delegated into a tool chain, then ownership, auditability, and scope must be enforced where the chain executes. For teams building a control roadmap, the priority is to align inventory, logging, and scope with request-path enforcement rather than leaving them as post-event evidence.

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. That scale shows why local configuration discovery and offboarding cannot be treated as secondary hygiene.

For practitioners

• 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.
• Separate runtime enforcement from procurement review Keep supply-chain checks, SBOM review, and vendor assessment in the build and procurement flow, but do not treat them as substitutes for runtime denial controls.
• Create a shadow MCP discovery routine Scan .cursor/mcp.json, Claude Desktop settings, and IDE configuration files on a recurring basis, then reconcile discoveries against the approved inventory.

Key takeaways

• MCP governance breaks down when policy does not reach the runtime path that authorises each tool call.
• The article shows that auditability, ownership, and scope are meaningful only when they can be enforced before action executes.
• For practitioners, the decisive control is the ability to deny, log, and attribute requests in front of the MCP server.

Key terms

• MCP governance: MCP governance is the set of policies, controls, and oversight used to manage how AI agents use the Model Context Protocol to reach tools and data. It defines approved connections, authentication, authorization, logging, data handling, and change control so agent actions remain traceable, bounded, and aligned with security and compliance requirements.
• 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.
• Shadow MCP: Shadow MCP is an unauthorized or ungoverned use of the Model Context Protocol inside an organization. It appears when AI agents, scripts, or tools connect to data or actions through MCP servers without security review, inventory, policy control, or monitoring. This creates hidden access paths, data exposure, and weak accountability.
• Governance Gap: A governance gap is the distance between knowing an asset exists and being able to enforce policy on it. In identity programmes, it appears when discovery, review, and enforcement are split across different tools or teams, leaving access partially visible but not truly controlled.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.