MCP security is closing fast on the enterprise risk window

At a glance

What this is: MCP is moving from experiment to enterprise programme, but most organisations are still building the security controls after the fact.

Why it matters: IAM, PAM, SOC, and AI security teams need to treat MCP as a governance problem now, because exposed servers and weak authorization can create direct paths into downstream systems before production hardening exists.

By the numbers:

• Only 11% have reached production, according to Obot.

Context

Model Context Protocol, or MCP, is a control layer that lets AI agents invoke tools and data sources at runtime. The core governance problem is that the protocol collapses the boundary between instructions and execution, so security teams have to govern model-to-tool trust rather than just protect a standard API surface.

Obot’s analysis shows a market and control gap opening at the same time: organisations are funding MCP work while the security model is still being assembled. That matters for IAM, PAM, and SOC teams because pre-production servers, shadow deployments, and weak authorization wrappers can expose downstream systems long before a formal production rollout.

The article frames this as an early-2026 risk window, not a future concern. That starting position is now typical for organisations moving quickly on AI integration, and atypical only in the degree to which they have already reached for production-like use without production-like governance.

Key questions

Q: What breaks when MCP servers are exposed without identity controls?

A: Without identity controls, anyone with a link, key, or copied credential can reach tools and data outside policy. That breaks visibility, weakens compliance evidence, and makes it difficult to separate approved use from shadow AI activity across SaaS and internal systems.

Q: Why do MCP deployments create risk before production rollout?

A: Because the highest-risk controls are often still being designed when teams start experimenting. Pre-production servers tend to lack formal review, consistent authorization, and logging, so the organisation is already extending trust to model-driven access before it has established the rules that govern that access.

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: Should teams centralize MCP controls or manage each server separately?

A: Centralization is the more defensible model when multiple servers, tools, and data sources are involved. Per-server controls fragment policy, while a gateway or shared control layer can enforce authentication, authorization, logging, and inventory management consistently across the whole MCP estate.

Technical breakdown

Why MCP turns tool access into a control plane problem

MCP is not just another integration protocol. It lets a model choose tools, pass parameters, and trigger actions based on runtime context, which means the trust boundary sits at the decision layer, not only at the network edge. In practice, the client, server, and model form a chain where each step can expand or narrow what the agent can do. That is why conventional API security alone is insufficient. If the server is trusted to broker access to databases, SaaS, or internal systems, then the server is effectively part of the access control plane.

Practical implication: govern MCP as an authorization surface, not as a simple integration endpoint.

How exposed and shadow MCP servers become open proxies

An MCP server that accepts a connection without a proper authorization wrapper behaves like an open proxy to every downstream system it can reach. Because the protocol produces a predictable initialization response, automated discovery can confirm exposure with a single request. That makes early-stage deployments especially risky when teams spin up test servers, expose them over HTTP, and leave them running without central review. The issue is not only the server itself but the downstream trust chain it unlocks. Once discovered, the server can be used to reach tools that were never meant to be broadly available.

Practical implication: inventory remote MCP endpoints and block unauthenticated exposure before they become routable paths.

Why prompt injection and configuration poisoning bypass traditional testing

MCP vulnerabilities often emerge from how the model interprets context, not from a broken line of code. Tool metadata, retrieved content, and configuration state can all carry instructions that the model treats as legitimate runtime input. That means a CSV, a tool description, or a hidden configuration change can alter behaviour without triggering ordinary application scanning. Security teams need to inspect both directions of traffic and separate trusted instructions from untrusted content. The operational lesson is that model input hygiene is part of the control surface, not an afterthought.

Practical implication: add runtime inspection and content sanitization around tool inputs, outputs, and server configuration.

Threat narrative

Attacker objective: The attacker’s objective is to turn a trusted MCP broker into a path for unauthorized access, manipulation, or exfiltration across downstream systems.

1. Entry begins when an attacker discovers an exposed or shadow MCP server that accepts initialization without meaningful authorization.
2. Credential and control abuse follow when the attacker uses tool metadata, configuration weaknesses, or permissive invocation paths to steer the model’s actions.
3. Escalation occurs as the compromised server brokers access to downstream services such as databases, SaaS tools, code repositories, or security systems.
4. Impact is unauthorized actions or data exposure across every system the server was allowed to touch.

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.
• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

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

MCP security has already become a governance problem, not a sandbox problem. The market moved faster than the control model, so security teams now have to manage model-to-tool trust, authorization boundaries, and auditability at the same time. That shift puts IAM and SOC teams in the same operating conversation as AI engineering, and practitioners should treat MCP as a governed access plane.

Pre-production MCP environments are the highest-probability failure zone. The article’s 11% production figure is less important than the sequencing problem it reveals: teams are building before the security wrapper exists. That is the classic pattern behind shadow deployments, inconsistent authorization, and unmanaged downstream reach, so the control question is who can initialize a server at all.

Model-driven access requires a named trust boundary, not ad hoc approval. Once the model can choose tools at runtime, the old assumption that developers can review every authorized action after the fact stops working. The governance concept here is a model-to-tool trust gap, meaning the organisation has not yet defined which runtime decisions the model may make independently. Practitioners should close that gap before tool inventories spread.

Centralized governance is becoming the only scalable way to manage MCP risk. The more servers, tools, and data sources teams add, the less viable per-server security decisions become. That pushes the market toward gateway-based policy enforcement, centralized logging, and catalogued approvals, which should accelerate identity and access governance across agentic environments rather than fragment it.

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

MCP is creating a new governance layer above traditional API security. The practical issue is not whether teams can connect models to tools, but whether they can define who may initialize those connections and what the model may reach once connected. That pushes identity, authorization, and logging controls to the front of the design, not the cleanup phase.

Shadow MCP is the early warning sign that governance has not caught up. If development teams can stand up servers faster than security can inventory and approve them, the organisation has already lost the control plane. Practitioners should watch for that pattern in pilot environments, because it usually precedes broader exposure rather than staying contained.

Model Context Protocol trust gap: this is the gap between what a server can technically access and what the organisation has actually authorized it to do. Closing it requires policy enforcement at issuance time, not just review after deployment.

For practitioners

• Audit every remote MCP endpoint Find unauthenticated or weakly protected servers, especially HTTP-exposed instances created for testing or demos, and remove them from the reachable path before they broker downstream access.
• Centralize authorization at the gateway layer Enforce request-level policy, tool inventory control, and audit logging before any model request reaches downstream databases, SaaS tools, or internal services.
• Separate trusted instructions from untrusted content Inspect tool metadata, retrieved documents, and returned data for hidden directives, and treat model input sanitization as part of runtime security control.
• Apply least privilege to every agent tool scope Limit each agent to the minimum tools and actions required for the task, then review role scopes regularly for privilege creep and stale access.
• Log every MCP request and decision Capture authentication attempts, tool invocations, policy outcomes, and anomalous access patterns in a central SIEM so exposure is visible before abuse becomes widespread.

Key takeaways

• MCP changes AI integration into an access-governance problem because the protocol decides what tools and data sources a model can reach at runtime.
• The main exposure sits in pre-production and shadow deployments, where unauthenticated endpoints and incomplete logging are most likely to persist.
• Teams that centralize authorization, scope tools tightly, and inspect runtime inputs and outputs will have a much better chance of governing MCP before the estate sprawls.

Key terms

• 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.
• 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.
• Tool Invocation: Tool invocation is an action where an AI agent calls an external system such as a database, API, or file service. Each invocation should be treated as an auditable identity action because it is the point where the agent can move data, trigger changes, or widen its reach across the environment.
• Model-to-Tool Trust: The security assumption that a model can safely choose and call external tools within its intended limits. When that trust is not explicitly governed, the model may reach systems, data, or actions that were never meant to be available at runtime.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners managing access to AI-connected systems. It gives identity and security teams a common control language for governing non-human access across modern estates.