State of MCP Security 2026: Enterprise Risks, Vulnerabilities and Controls

MCP security Report: A Protocol That Won the Adoption War Before It Won the Security War

The Model Context Protocol has become genuine infrastructure in under two years, and that speed is exactly the problem this report documents. As of April 2026, 78 percent of enterprise AI teams run at least one MCP-backed agent in production, more than 10,000 public MCP servers are listed across major registries, and 75 percent of API gateway vendors are expected to ship MCP-specific features by the end of the year. Adoption outran governance, and the gap between those two curves is where every vulnerability in this report actually lives.

At Cybertize Technologies, we architect MCP security integrations for clients, and the honest state of this ecosystem in 2026 is that the protocol itself has matured considerably, July’s specification revision hardened several genuine weaknesses, but implementation has lagged the specification badly enough that the NSA and CISA jointly published a security advisory in May 2026 stating plainly that MCP cannot enforce consent, privacy, or tool-safety principles at the protocol level alone. That is the frame for everything that follows: MCP is not insecure by design, but most of what makes it secure in practice has to be built by whoever deploys it, and most deployments have not built it yet.

Also Read: State of Enterprise MCP Adoption 2026, Data, Architecture, Trends

Authentication Methods

This is the single widest gap between specification and reality in the entire MCP ecosystem. Since the November 2025 specification revision, any MCP server accessible over the internet is required to implement OAuth 2.1 with PKCE using the S256 method, with the server itself acting as an OAuth 2.1 resource server that delegates token issuance to a separate authorization server. In practice, only 8.5 percent of MCP servers currently implement OAuth 2.1 authentication despite this being the protocol’s mandatory security standard for remote deployments, and a broader 2025 scan of popular servers found many reachable with no authentication at all.

The specification has moved to close this gap faster than implementation has followed. Client ID Metadata Documents, CIMD, are now the preferred dynamic client-identification mechanism, and the Enterprise-Managed Authorization extension, sometimes called Cross App Access, was promoted to stable status in 2026, letting an organization’s existing identity provider issue tokens for MCP access directly rather than requiring per-user consent screens for every connection. That single change is what one current technical analysis describes as moving MCP security from “interesting for a hack week” to “defensible in an audit,” but it only closes the gap for organizations that have actually adopted it, which remains a minority of current deployments.

Authorization Methods and RBAC

MCP security: Authentication answers who is connecting. Authorization answers what they are allowed to do once connected, and this layer is, if anything, weaker than authentication across the current ecosystem. Separate research found only 18 percent of MCP server deployments implement any form of access scoping for tool permissions at all, meaning the large majority of deployed servers grant a connected agent effectively all-or-nothing access rather than scoping permissions to the specific task at hand. Privilege Escalation via Scope Creep appears as its own named category in the OWASP MCP Top 10 specifically because of how common this failure pattern has become, an agent granted broad access for one legitimate task retaining that same broad access indefinitely, available to be exploited by any subsequent compromise.

Role-based access control, RBAC, remains more aspiration than standard practice across public MCP server implementations. It appears consistently as a named enterprise gateway feature, something a centralized gateway adds on top of the servers behind it, rather than something most individual MCP servers implement natively. That distinction matters directly for architecture decisions: an organization relying on individual servers to self-enforce RBAC is relying on a capability most of the ecosystem does not actually have.

Gateway Usage

The enterprise MCP gateway has emerged in 2026 as the dominant architectural answer to the authentication and authorization gaps documented above, and gateway adoption itself has become a genuine product category with real competitive differentiation. A gateway sits between agents and the many individual MCP servers they connect to, terminating client connections, enforcing centralized authentication and RBAC, maintaining a server registry, and streaming execution logs to monitoring and SIEM platforms, letting individual servers behind it skip implementing their own full security stack.

Current leading options span a real range of approaches. Docker MCP Gateway runs each connected server in its own isolated container with defined resource limits and cryptographically signed images, security through isolation rather than policy enforcement, backed by a catalog of more than 300 verified, signed server images that functions as an approved-server allowlist. Bifrost, built by Maxim AI, unifies LLM and MCP gateway functions through a single binary with one shared audit log, virtual key system, and observability pipeline, and offers SOC 2 and HIPAA-compliant audit logging alongside HashiCorp Vault and AWS Secrets Manager integration at the enterprise tier. Microsoft MCP Gateway targets Kubernetes-native deployments with container-level isolation, and Kong AI Gateway extends its existing API gateway product into MCP traffic, positioning itself as an OAuth 2.0 resource server validating bearer tokens before traffic reaches an upstream server. The emergence of this many credible, differentiated options in a single year is itself a signal that gateway deployment is moving from an advanced pattern to a baseline enterprise expectation.

Also Read: AI-Powered Cybersecurity, Lessons From the OpenAI Security Incident

Audit Logging

Audit logging remains one of the clearest examples in this report of a capability the MCP specification itself has deferred, leaving it to individual implementations and vendors to build. As one 2026 technical analysis puts it plainly, SIEM export and comprehensive audit trails are currently something an organization has to build itself rather than something the protocol provides out of the box. The strongest current implementations go beyond basic invocation logging to immutable, often cryptographically signed audit trails spanning the full chain from user to agent to MCP server to the specific tool invoked, a level of traceability that matters enormously for any organization needing to explain after the fact exactly what an autonomous agent did and why. Open source gateway options vary meaningfully here: some ship only basic invocation logging in their free tier, reserving compliance-ready, tamper-evident audit trails for an enterprise license, which makes audit logging maturity one of the more reliable signals for distinguishing a genuinely production-ready MCP deployment from an early-stage one.

Prompt Injection Protection

Prompt injection remains, in the words of multiple 2026 security analyses, one of the most difficult vulnerabilities to fully prevent in any AI system, and MCP’s architecture specifically widens the attack surface rather than narrowing it. Because an MCP-connected agent treats tool descriptions, parameters, and external data sources as trusted context to reason over, any of those inputs becomes a potential injection vector, not just the user’s own typed prompt. Indirect prompt injection, where the malicious instruction arrives embedded in a document, a support ticket, or a GitHub issue the agent is asked to process rather than typed directly by an attacker, has become the dominant variant documented across real 2025 and 2026 incidents, including a case where a hidden payload in a GitHub issue redirected a connected agent to access and publicly post private repository contents.

Current defense-in-depth guidance converges on a consistent set of controls: input guardrails that inspect tool call inputs for injection patterns before a request reaches an MCP server, system prompt isolation that keeps untrusted retrieved content clearly separated from trusted system instructions, and role-based API design that limits what an agent can actually execute even if an injection attempt partially succeeds. No single control fully closes this gap, which is precisely why security researchers continue to treat prompt injection as a layered, ongoing risk-management problem rather than something a single patch resolves.

Tool Poisoning

If prompt injection is the most discussed AI-specific vulnerability generally, tool poisoning is its MCP-specific cousin, and multiple 2026 sources describe it as the single most discussed MCP vulnerability of the year. A tool poisoning attack manipulates the metadata, description, or stated behavior of a tool registered on an MCP server, content the agent reads and trusts to decide when and how to invoke that tool, but which the human user typically never sees directly. An attacker who can modify a tool’s description, whether through direct server compromise or a supply chain compromise of the underlying package, can embed hidden instructions that mislead an agent into taking unsafe or unintended actions using a tool that otherwise behaves completely normally and transparently for its stated purpose.

A documented real-world example makes this concrete: a malicious MCP server package functioning as a fully normal, correctly working email-sending tool, developers who installed it could send emails exactly as expected, while silently BCCing every single email sent through it to an attacker-controlled address. The tool poisoning category also includes related variants security researchers have named “rug pull” attacks, where a server’s declared capabilities change after initial review and approval, exploiting the fact that MCP lists server capabilities dynamically on each connection rather than as a fixed, one-time declaration, and “tool shadowing,” where a malicious server’s tool definition silently overrides or impersonates a legitimate, previously trusted tool with the same name.

Also Read: AI Agent Development Report for Business Market & Technology 2026-2027

Supply Chain Risks

This is where 2026’s most serious documented incident sits. In May 2026, security researchers at OX Security disclosed what they termed a systemic vulnerability across MCP implementations in Python, TypeScript, Java, and Rust, affecting a dependency chain with more than 150 million downloads and an estimated 200,000 vulnerable instances, a scale that earns the “mother of all AI supply chains” framing multiple outlets used to describe it. A week earlier, Microsoft’s Security Response Center had separately published research documenting how prompt injection could escalate into full remote code execution in popular agent frameworks, underlining that supply chain risk in this ecosystem compounds with, rather than sits separately from, the injection and tool poisoning risks covered above.

The structural reason supply chain risk runs this deep is straightforward: MCP servers are, at their core, software packages that users download and run, frequently from public, loosely curated repositories, making them a genuinely attractive target for the same class of attack that has plagued open-source package ecosystems for years, a malicious or compromised dependency silently introduced through a routine update rather than an initial, reviewable installation. Separate documented incidents include a February 2026 case where attackers cloned a legitimate, popular MCP server and distributed the clone through registry poisoning and social engineering, a pattern now explicitly named in the OWASP MCP Top 10 as Software Supply Chain Attacks and Dependency Tampering, and as Shadow MCP Servers, unauthorized servers operating inside an organization entirely outside any security team’s knowledge or review process.

Server Isolation

Isolation has emerged as a distinct and genuinely complementary control to authentication and authorization rather than a substitute for either, with current leading gateway implementations treating container-level isolation as a first-class architectural requirement rather than an afterthought. Docker’s MCP Gateway runs every connected server inside its own isolated container with defined resource limits and cryptographically signed images, a model multiple analysts describe accurately as security through isolation rather than through policy enforcement, meaning it limits the blast radius of a compromised server without necessarily preventing the compromise itself. Microsoft’s MCP Gateway applies a similar pattern at the Kubernetes pod level for cluster-native deployments. The practical value of this layer is specific: even where authentication and authorization both fail, as current adoption data above suggests they frequently do, strong isolation prevents a single compromised server from reaching other servers, other tenants, or the broader production environment it sits inside, which is precisely the containment layer missing from most of the real incidents documented in this report.

MCP Security & Secrets Management

Credential handling remains one of the more quietly severe gaps in current MCP deployments. The NSA and CISA’s joint May 2026 advisory specifically flagged that authorization and credential isolation are not yet standardized at the protocol level, leaving server-side secrets management as a pattern individual gateways and implementations have to build themselves rather than something MCP guarantees. Separate research found 53 percent of MCP servers expose credentials through hard-coded values in configuration files rather than a proper secrets management system, a basic security failure that predates MCP entirely but is reproduced at scale across this specific ecosystem simply because of how quickly new servers have been stood up without equivalent security review. The stronger current implementations integrate directly with established secrets infrastructure, HashiCorp Vault and AWS Secrets Manager integration now ship as standard enterprise gateway features specifically to close this gap, ensuring that a server’s own compromise does not automatically expose the credentials it was using, a meaningfully stronger posture than the hard-coded default still found across much of the ecosystem.

The OWASP MCP Top 10 and What It Signals

The emergence of a formal OWASP MCP Top 10, alongside a specific OWASP MCP Azure Security Guide, is itself a meaningful 2026 development worth noting, since a dedicated top-ten vulnerability list only gets published once an ecosystem’s risk patterns are well-documented and recurring enough to formally categorize. The named categories, spanning Token Mismanagement, Privilege Escalation via Scope Creep, Tool Poisoning, Software Supply Chain Attacks and Dependency Tampering, Shadow MCP Servers, and Context Injection, map closely onto every risk area covered in this report, confirming these are now recognized, named, recurring failure patterns rather than isolated incidents specific to any one vendor or implementation.

What This Means for Enterprises Deploying MCP & MCP Security in 2026-2027

Pull this data together and a consistent, practical conclusion holds. MCP’s & MCP security adoption curve and its security maturity curve are currently badly mismatched, and closing that gap is not primarily a protocol problem anymore, the July 2026 specification revision and the now-stable Enterprise-Managed Authorization extension have given the ecosystem the tools it needs. It is an implementation and procurement discipline problem. Any organization evaluating an MCP server, whether building one internally or adopting a third-party one, should treat OAuth 2.1 compliance, tool-level access scoping, signed and verified server images, and immutable audit logging as baseline requirements to verify directly rather than assumptions to take on faith, given how far current adoption of each of these controls still lags the specification’s own requirements.

At Cybertize Technologies, this is the exact discipline we bring to MCP architecture for clients, because the data in this report points to one clear conclusion above all others: the organizations avoiding the incidents documented here are not the ones with the most sophisticated AI strategy. They are the ones that treated an MCP server exactly like any other new front door into their systems, scoped permissions, verified images, isolated execution, and logged everything, from the very first server they deployed.