Your AI agents are only as secure as their weakest connection. And right now, that connection is MCP — the Model Context Protocol that’s rapidly becoming the backbone of enterprise AI.
MCP is brilliant in theory: a universal standard that lets AI agents connect to any tool, database, or service. It’s been adopted by 39% of enterprises, with 75% of gateway vendors expected to integrate it by end of 2026. Major players from Microsoft to Anthropic to AWS have built their agent strategies around it.
But there’s a problem nobody wants to talk about: the MCP supply chain is already compromised.
Four Confirmed Breaches. Not Theoretical — Real.
Forget hypothetical risk assessments. We now have four documented MCP-related security incidents:
1. The WhatsApp Exfiltration (April 2025) A malicious MCP server was deployed that exported a user’s entire WhatsApp message history. The server operated within standard MCP permissions — it just used them to exfiltrate everything it could access.
2. The GitHub Private Repo Leak (May 2025) Prompt injection through an MCP-connected GitHub integration pulled private repository data. The attack exploited the trust boundary between the AI agent and the MCP server, using the agent’s legitimate credentials to access data the user never intended to share.
3. The Asana Cross-Organization Leak (June 2025) A bug in Asana’s MCP integration leaked data across organizational boundaries. Information that should have been siloed by tenant was accessible to agents in other organizations. AuthZed documented the full incident.
4. ContextCrush — The Developer Attack (February 2026) This one changed the game. Context7, an MCP server with 50,000 GitHub stars and 8 million npm downloads, was found vulnerable to Custom Rules injection. Researchers at Noma Labs (presenting at RSAC 2026) demonstrated:
.envfile exfiltration (stealing API keys and credentials)- Arbitrary file deletion
- Credential theft from developer environments
The critical detail: MCP servers run as local subprocesses with the developer’s own permissions. This wasn’t an attack on end users — it was a supply chain attack targeting the developers who build AI systems.
The Numbers Are Damning
The AI Accelerator Institute analyzed 281 MCP servers and found that 92% carry high security risk. Not moderate. Not “something to watch.” High risk.
Zuplo’s MCP adoption survey adds more context:
- 50% cite security as the #1 challenge with MCP adoption
- 40% rely on API keys for authentication
- 32% use OAuth/JWT/SSO (better, but not universal)
- 24% use NO authentication at all
- 64% of servers have inadequate identity management
Let that sink in: nearly a quarter of MCP servers running in production have zero authentication. Any agent that connects to them is trusting a completely open door.
Why MCP Is Different from Traditional API Security
You might think, “We’ve dealt with API security before. Same playbook.” It’s not.
Traditional APIs are called by applications that developers control. MCP servers are called by AI agents that operate autonomously. The differences matter:
Agents make runtime decisions about which tools to call. Your security team can’t pre-approve every interaction because the agent decides what to call and when based on its reasoning process. A prompt injection can redirect those calls without anyone noticing.
MCP servers run with inherited permissions. Unlike sandboxed API calls, MCP servers often run as local processes with the same access as the host application. ContextCrush proved this — the malicious code had full access to the developer’s file system.
The attack surface scales with adoption. Every new MCP server your agents connect to is a new trust boundary. Every new connection is a potential entry point. With enterprises averaging dozens of MCP connections, the attack surface grows exponentially.
Supply chain attacks hit different. When a popular MCP server is compromised, the blast radius is massive. Context7 had 8 million npm downloads. One vulnerability, millions of potential victims.
The Governance Gap Is Widening
Here’s the uncomfortable truth: MCP adoption is accelerating faster than MCP governance.
RecordPoint shipped a GA MCP governance server in March 2026 — and went from announcement to product in three days. Guideline launched the first advertising-vertical MCP server. DANA deployed MCP agents via Microsoft Azure for 100 million users. Safe Software added MCP Server with OAuth 2.0 to FME, used by 20,000+ organizations.
All in a single week.
Meanwhile, the governance layer for all these connections barely exists. Red Hat has published MCP security reference architectures. Microsoft is building MCP policies into VS 2026. The NIST Identity and Authorization concept paper (April 2 deadline) references MCP specifically.
But these are frameworks and reference architectures. They’re not production governance.
Pillsbury, one of America’s largest law firms, published a detailed MCP connector risk analysis identifying seven distinct risk categories:
- Over-permissioned access
- Write-access hazards
- Cascading failures across connected systems
- Expanded attack surface
- Credential management risks
- Prompt injection via tool descriptions
- Accountability gaps when agents cause harm
When AmLaw 100 firms are publishing legal risk analyses of your protocol, enterprise legal teams are paying attention. And their conclusion is clear: the contracts, licensing, and governance frameworks for MCP don’t exist yet.
The Four Sub-Layers of MCP Governance
The market is fragmenting into four distinct governance sub-layers, each addressing a different piece of the puzzle:
1. API Gateway Layer (Tray.ai, Zuplo, Kong) Traffic routing, rate limiting, basic policy enforcement. The plumbing. Necessary but insufficient.
2. Identity Layer (Fior Group, Token Security, Vouched MCP-I/DIF, Silverfort) Agent identity verification, credential management, lifecycle governance. The “who are you?” layer. Vouched’s MCP-I, donated to the Decentralized Identity Foundation, is the first open standard using DIDs and Verifiable Credentials.
3. Runtime Enforcement Layer (OPAQUE, Zenity, API Stronghold) Real-time monitoring, cryptographic enforcement, behavioral detection. The “what are you doing right now?” layer.
4. Workforce Management Layer (iEnable) Cross-platform orchestration, agent lifecycle governance, policy management across all layers. The “who manages the whole workforce?” layer.
No single company covers all four. Most don’t even cover two. And that’s the problem.
What Enterprises Should Do Now
The MCP supply chain isn’t going to fix itself. Here’s what to do today:
Audit your MCP connections. You can’t govern what you can’t see. Catalog every MCP server your agents connect to. Most enterprises will be surprised by how many connections exist — especially developer-created ones running in shadow AI environments.
Enforce authentication everywhere. Zero tolerance for unauthenticated MCP servers. OAuth 2.1 with PKCE should be the baseline. If a server can’t authenticate, your agents shouldn’t connect to it.
Implement least-privilege for agent-tool interactions. Just because an agent CAN call a tool doesn’t mean it SHOULD. Scope permissions at the tool level, not the server level.
Monitor for behavioral drift. Agents connecting to compromised MCP servers don’t raise traditional security alerts. You need behavioral monitoring that detects when an agent’s tool-calling patterns change — a hallmark of prompt injection attacks.
Plan for the regulatory wave. NIST’s Identity and Authorization framework (April 2 deadline), the EU AI Act (August 2026 enforcement), and emerging state-level legislation all point toward mandatory MCP governance. Getting ahead of regulation is cheaper than catching up.
The Bottom Line
MCP is not optional. It’s becoming the standard protocol for AI agent connectivity, and that’s a good thing. Standardization beats fragmentation.
But standardization without governance is a disaster waiting to happen. Four confirmed breaches, 92% of servers at high risk, 24% with no authentication — these aren’t warning signs. They’re active failures.
Every enterprise deploying AI agents connected via MCP needs a governance layer that spans all four sub-categories: gateway, identity, runtime, and workforce management. Platform-native tools from AWS, Azure, and GCP each cover their own ecosystem. Nobody covers the full picture.
That’s the gap iEnable fills. Not another gateway. Not another identity provider. The AI Company OS that governs your entire agent workforce — including every MCP connection they make.
The supply chain is already compromised. The question is whether you’ll know about it before it costs you.
iEnable is the AI Company OS — hire AI employees that actually work, governed from day one. Learn more at ienable.ai.