Generative AI Risk in Enterprise Environments

Anthropic released the Model Context Protocol in late 2024 to solve a real and specific problem: every time you wanted an AI agent to connect to a tool, a database, or an internal system, someone had to write custom integration code. Custom code is expensive, slow, and fundamentally doesn't scale across a sprawling enterprise stack. MCP standardizes that connection layer so the same protocol handles your CRM, your code repository, and your billing system. Build an agent once, point it at any MCP-compatible server, and it operates across all of them without a bespoke integration project for each one.

The public MCP server registry grew from roughly 1,200 entries in early 2025 to over 9,400 by mid-April 2026, more than a sevenfold increase in fourteen months. That number tells you something important about where we are: this is infrastructure now, not a developer experiment.

Here is the problem with that trajectory. MCP was designed to make agents capable. Enterprise security was not a first principle in that design. The original specification shipped without a mandatory authentication framework, operating on an implicit trust model that assumed MCP servers were benign. That assumption was reasonable when a handful of researchers were running local experiments in a controlled environment. It does not hold when agents are touching sensitive systems at scale, across teams and tenants, often without meaningful human review of what they are actually doing moment to moment.

The protocol solved the integration problem admirably. Think of it like building a highway system between every city in your enterprise — seamless travel, no checkpoints, and a standing invitation for anyone who finds an on-ramp.

The specific threats MCP introduces that traditional security tools weren't built to catch

Traditional security tooling was built to catch humans doing bad things, or known malware doing predictable things. MCP-enabled agents fit neither profile, and that mismatch is precisely where attackers have found purchase.

Tool poisoning is one of the more insidious variants. An MCP server misrepresents its own functionality through hidden malicious instructions embedded in its metadata. The agent reads those instructions, modifies its behavior accordingly, and the user sees nothing anomalous because the manipulation happens at a layer they have no visibility into. MCPTox benchmark testing found that o1-mini has a 72.8% attack success rate against tool poisoning. More capable models proved more susceptible, not less.

Context poisoning, sometimes called MCP-UPD, is a variation where the server itself isn't compromised. Instead, a legitimate server fetches an external document, a support ticket, a web page, a shared file, that contains embedded malicious instructions. The server faithfully processes and returns the content. The agent executes what it finds there. The Supabase Cursor agent incident in June 2025 demonstrated this precisely: an agent processing user-supplied support tickets was manipulated into leaking integration tokens. The server was working as designed. That was the whole problem.

Supply chain risk is structural to any ecosystem dependent on open-source packages. One trojanized package propagates across every environment that depends on it. Koi Security found that the postmark-mcp npm package had been backdoored in a way that granted attackers implicit privileged access inside AI workflows. An analysis of nearly 1,900 open-source MCP servers found that roughly 5.5% exhibit MCP-specific tool poisoning. One in eighteen servers carrying active compromise is not a rounding error.

The confused deputy problem is subtler. When an MCP server acts on a user's request, it executes with the server's own permissions rather than the user's. The user asks for something they're entitled to. The server, operating with broader access, does more than the user should be able to authorize. Access controls downstream miss it because the server is, technically, authorized. Nothing alerts. Nothing looks wrong from the outside. It is the digital equivalent of asking your assistant to grab a file from a cabinet they have a master key to — they are authorized, you are authorized, and yet somehow more happened than anyone intended.

Real CVEs confirm these aren't theoretical exposures. CVE-2025-6514 affected an OAuth proxy that trusted server-provided OAuth endpoints without verification, enabling a malicious server to inject shell commands and execute arbitrary code across more than 437,000 developer environments. CVE-2025-53967 was a remote code execution vulnerability via command injection in Figma's MCP server. CVE-2025-49596 carried a CVSS score of 9.4 and allowed unauthenticated exploitation of MCP Inspector instances for arbitrary command execution. These are production incidents, not research findings.

How risk compounds as MCP server counts grow

Research from Pynt found that a single MCP plugin carries a roughly 9% exploit probability. At three interconnected servers, that risk exceeds 50%. Deploy ten MCP plugins and the probability of exploitation reaches 92%.

That compounding is multiplicative, not additive, because each server introduces not just its own vulnerabilities but additional integration points, trust relationships, and potential paths for lateral movement between systems. Adding MCP servers to an enterprise stack is less like adding locks to a building and more like adding doors — each one is another way in.

Trend Micro found 492 internet-exposed MCP servers with zero authentication. An analysis of more than 5,000 open-source MCP server implementations found that roughly 88% require credentials to function, but 53% of those use insecure hard-coded credentials. Only 8.5% of MCP servers currently implement OAuth 2.1, which is the protocol's own mandatory security standard for remote deployments. Only 18% implement any form of access scoping for tool permissions.

The governance challenge this creates is not about securing each server in isolation. In a realistic enterprise deployment, where teams are independently connecting MCP servers to the tools they need, the aggregate risk grows with every addition. Visibility and control across that expanding surface require deliberate infrastructure; they do not emerge organically from per-team configuration choices made by people who are, reasonably, thinking about their own workflows rather than the cumulative exposure picture their decisions are building.

Why authentication and credential management have been the weakest point in MCP deployments

MCP's original specification shipped without mandatory authentication. OAuth 2.0 authorization wasn't added until March 2025, and the more robust OAuth 2.1 revision didn't arrive until June 2025. Thousands of MCP servers were deployed into production environments during that window. A significant portion remain in production today without meaningful authentication; the spec evolved, the deployments did not.

Even where authentication exists, implementation gaps create serious exposure. Token audience binding is frequently missing, which means a token issued for one MCP server can be replayed against any other server in the same environment. In a multi-server deployment, that is a substantial blast radius from a single compromised credential.

Credential sprawl is structural in the current ecosystem. API keys live in environment variables. OAuth tokens get stored in configuration files. Long-lived static secrets accumulate because rotating them requires locating every place they exist, and without centralized management, that location is often genuinely unknown. SpyCloud recaptured 18.1 million exposed API keys and tokens in 2025 alone.

Per KPMG's Cybersecurity Considerations 2026 report, non-human identities outnumber human identities by more than 80 to 1 in the average enterprise. Machine identities grew from roughly 50,000 per enterprise in 2021 to 250,000 by 2025. Seventy-eight percent of organizations lack formal policies for AI agent credentials.

Agents don't generate the signals that identity management systems were built to detect. There's no onboarding event, no offboarding event. Permissions and tokens accumulate without triggering the review cycles that would catch them. When an agent is replaced or decommissioned, its credentials often stay active, invisible to any formal review process because nothing in the system registered a change. The credential outlives the agent by months, sometimes indefinitely.

The architecture that addresses this is not complicated to describe: short-lived credentials with default expiration measured in hours rather than months, just-in-time access grants rather than persistent permissions, secrets managed through vault services rather than configuration files, automated attestation. Most current deployments have none of these controls, not because they're technically inaccessible, but because nobody built them in at the start.

What the MCP specification now requires, and how far most deployments lag behind it

The specification has moved fast, and that's worth acknowledging before cataloguing the gap. The June 2025 authorization spec revision was a meaningful upgrade, separating the MCP server from the authorization server role and building explicitly on OAuth 2.1. The November 2025 revision went further: any MCP server accessible over the internet must implement OAuth 2.1 with PKCE, no exceptions.

The July 2026 additions address some of the more specific attack vectors that earlier deployments left open. Dynamic Client Registration, Protected Resource Metadata under RFC 9728, Resource Indicators under RFC 8707, and Client ID Metadata Documents are now requirements. The Resource Indicators requirement directly closes the token replay vulnerability: the resource parameter must be included in both authorization and token requests, and it must identify the specific MCP server the token is for.

Enterprise-Managed Authorization, stable as of June 2026, is the most operationally significant addition for enterprise deployments. It makes the organization's identity provider the authoritative decision-maker for MCP access. Administrators define policy once. Users authenticate through existing identity infrastructure. Access is governed by group membership, role, and conditional access rules, the same machinery enterprises already use for SaaS and cloud access. Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase now support EMA; Slack is actively adding support.

Only 8.5% of MCP servers currently implement OAuth 2.1. Only 18% implement any tool-level access scoping. The specification has done the hard work of defining a secure architecture. Production deployments, many of them built during the protocol's less-specified early period, have not caught up. That gap is not theoretical. It is where attacks are happening now.

What enterprise AI governance needs to cover in an agentic environment

The governance model built for humans using AI tools has no coverage for agents acting autonomously across systems. Acceptable use policies, employee training, DLP rules: these were designed for a human-in-the-loop world. They do not address a system that can take hundreds of consequential actions without pausing for review.

Governance for agentic AI requires controls operating simultaneously at several layers.

Identity: every agent action must be tied to a verified identity, not just the identity of whoever deployed the agent, but the specific identity authorizing each individual tool call. Without that granularity, accountability is impossible to reconstruct after the fact. "After the fact" is not a comfortable position when a regulator is asking questions and your audit trail shows access events but not action traces.

Access: permissions scoped to the minimum required for a specific task, enforced at the tool-call level rather than just at provisioning. An agent provisioned with broad access is a liability every time it operates, even when it's functioning exactly as intended. Especially then, actually, because that's when nobody is watching.

Observability: a tamper-proof record of what each agent did, which tools it called, what data it accessed, in what sequence. Not access logs. Full action traces. The kind of artifact compliance and legal teams can use when they need to demonstrate what actually happened, not just that the agent had permission to be there.

Policy enforcement: runtime controls that can detect and stop anomalous behavior, intent drift, exfiltration attempts, prompt injection, before the damage is complete. Logging an incident after it finishes is a record of failure, not a control.

Shadow MCP usage is already occurring across enterprises. When governance infrastructure is absent or imposes real friction, teams connect MCP servers outside IT visibility. Per Rubrik Zero Labs, based on a survey of more than 1,600 IT security decision makers, 89% of respondents have fully or partially incorporated AI agents into their identity infrastructure. Governance frameworks are chasing adoption that has already happened.

Compliance obligations are not waiting for governance to catch up either. Agentic AI that touches regulated data, financial records, health data, personally identifiable information, carries the same audit and access control obligations as any other system with that access. Most current deployments have no mechanism to demonstrate compliance. That surfaces during audits and incidents, not before.

Why governance built after deployment is harder than governance built into deployment

This pattern has played out before. Cloud adoption spread through business units before security teams had frameworks to govern it. Mobile device management arrived years after employees were already using personal phones to access corporate systems. Security teams in both cases inherited a retrofit problem: too many integrations already in place, too many exceptions already granted, too much organizational momentum to enforce meaningful policy retroactively.

With agentic AI, the retrofit problem is structurally worse because the attack surface changes continuously. Every new MCP server added to a deployment expands the surface in ways a point-in-time security review won't catch. The review happens once; the server stays connected indefinitely, touching systems the reviewer never thought to ask about.

Fragmented stacks create gaps at the seams. When the agent builder, the gateway, and the security tool are separate products from separate vendors, they don't share context. The agent builder doesn't know what the security tool has flagged. The gateway lacks the identity context the audit tool needs. Coverage breaks down precisely at the integration points, which is also where the most consequential attack paths tend to run.

Stale non-human identity credentials are the clearest illustration of what retrofit failure looks like in practice. Without lifecycle management built into agent provisioning from the start, decommissioned agents leave active credentials behind. No review process catches them because no offboarding event was ever generated. The credentials are invisible to the processes designed to find them, because those processes were never wired into the agent provisioning workflow in the first place.

The economics are not ambiguous. Instrumenting an agent pipeline with identity binding, credential management, and audit logging at deployment time costs a fraction of what it costs to reconstruct that lineage after an incident, or after a regulator asks for documentation that doesn't exist. In practice, that means authentication and credential handling managed centrally before agents reach users, SSO and SCIM-tied identity attached to every agent action from the start, policies enforced at tool-call depth, and audit infrastructure capturing full action traces rather than access events.

The organizational conditions that make enterprise AI governance succeed or stall

The most common failure mode in enterprise AI governance programs is not technical. It is structural. Security teams get looped in after a deployment is already running, positioned as reviewers of decisions already made, which forces a reactive posture that produces friction rather than control. Business units, facing that friction, route around them. The result is shadow MCP usage, ungoverned agents, and exactly the risk profile the governance program was meant to prevent.

When security teams are seen as the function that blocks things, people find paths that avoid them. Governance built on obstruction doesn't govern anything; it pushes activity into less visible channels, which produces a measurably worse outcome than the problem it was ostensibly solving.

The 95% of employees who aren't developers or AI power users also belong in this picture, even though they rarely appear in governance discussions. Frameworks that only account for technical users leave the majority of the workforce without a sanctioned, supported path to agent-based tools. Unsanctioned paths are how shadow usage scales beyond any team's ability to track it. The governance problem is not only about what developers are building; it is about how agentic tools reach the broader organization and under what conditions they do it.

What makes governance programs actually work comes down to two organizational realities that are easy to state and difficult to execute. Security and platform teams must own the infrastructure layer, meaning authentication, credential management, and audit, so that every deployment inherits those controls rather than building them independently. And the sanctioned path must be the easy path. If governed deployment requires more friction than ungoverned deployment, adoption routes around governance. The controls have to be embedded in the path of least resistance, rather than erected beside it as an optional detour.

Neither condition is technically difficult to achieve. Both require organizational decisions about where security teams sit in the deployment process, and those decisions need to be made before agents are already running. That is precisely the moment most enterprises are in right now. What gets decided, and by whom, will determine how much retrofit work lands on security teams in two years and how tractable it is when it arrives.