MCP exploded from an experimental integration concept into a foundational orchestration layer, while most organizations’ threat models stayed frozen in the plugin era.
At a glance:
- What happened: MCP grew from integration experiment to orchestration layer (97M+ monthly SDK downloads), with real exploitation incidents in the wild.
- What it exposes: Treating an orchestration layer with plugin-era controls leaves delegated execution, credential access, and cross-system workflows under-governed.
- What to examine: Whether your security model knows MCP is there. Inventory, ownership, and blast radius.
Key quote: “But while adoption accelerated, the threat model changed entirely.”
In plain language
MCP started as a simple way to plug AI assistants into other software, like adding apps to a phone. It has quietly become something much bigger: the switchboard connecting AI to your email, your cloud, your code, and your company data.
Most security teams still treat it like a phone app. That is like guarding a power plant with the same lock you put on a garden shed. The thing being guarded changed completely; the guarding did not.
The bottom line: you are defending last year’s architecture against this year’s reality, and the gap between the two is where the risk lives.
The key facts
| What | MCP adoption and threat-model analysis |
|---|---|
| Scale (Mar 2026) | 97M+ monthly SDK downloads; 10,000+ public MCP servers; spread across OpenAI, Microsoft, AWS, Google, major IDEs |
| The shift | From plugin framework (constrained, scoped) to orchestration layer (delegated execution, cross-system workflows) |
| What changed | Delegated execution, credential access, autonomous tool invocation, multi-step workflow chaining |
| The risk | An orchestration layer treated with plugin-era controls; the most connected layer is the least examined |
That misunderstanding is becoming a serious security problem.
Over the last year, the Model Context Protocol (MCP) exploded from an experimental integration concept into a foundational layer for AI tooling, autonomous workflows, developer environments, and enterprise orchestration. The adoption curve tells the story: by March 2026, MCP had crossed 97M monthly SDK downloads, more than 10,000 public MCP servers were online, and MCP workflows had spread across OpenAI, Microsoft, AWS, Google, and the major IDE ecosystems. A large percentage of Fortune 500 AI workflows now interact with MCP infrastructure in some form.
The productivity gains are real. Executives increasingly view AI-enabled employees as materially more productive, and enterprises are aggressively integrating AI agents deeper into operational environments. Nobody is suggesting the productivity was a mistake.
But while adoption accelerated, the threat model changed entirely. And most organizations have not adapted yet. That lag, between what MCP has become and what your security model still thinks it is, is where the risk lives now.
When did your organization last update its threat model for AI tooling? If the answer predates your MCP rollout, you’re defending last year’s architecture against this year’s reality.
An MCP hub radiating connections across enterprise infrastructure. Illustrative artwork, not a vendor diagram.
The Security Problem Nobody Wants to Admit
Key quote: “That dramatically expands blast radius.”
MCP is not simply a convenience layer. It is an orchestration layer. That distinction matters more than almost anything else in this article, so let’s be precise about it.
Traditional plugins usually operated inside relatively constrained trust boundaries, a defined scope, a limited API surface, a clear answer to “what can this touch?” MCP changes that by enabling delegated execution, cross-system interaction, autonomous tool invocation, credential access, external integrations, and multi-step workflow chaining. Read that list again slowly, because each item is a trust boundary dissolving:
- Delegated execution
- Cross-system interaction
- Autonomous tool invocation
- Credential access
- External integrations
- Multi-step workflow chaining
In practical terms, your AI stack is no longer isolated. It is increasingly connected directly to your repositories, your cloud infrastructure, your internal documentation, your email systems, your APIs, your CI/CD environments, your SaaS platforms, and your operational tooling.
That dramatically expands blast radius. And attackers are starting to notice, because attackers, unlike many security teams, read architecture diagrams for what they actually say.
The Shift From Experimental Risk → Active Exploitation
Key quote: “These are not isolated bugs. They are symptoms of a larger architectural issue.”
Over the last 18 months, the theoretical became operational. Multiple incidents exposed how fragile many MCP deployments actually are, and the pattern across them is more instructive than any single case:
| Incident type | What happened |
|---|---|
| Email exfiltration | MCP-linked integrations silently forwarded confidential email data to attacker-controlled infrastructure |
| Zero-click compromise | Vulnerabilities triggered through poisoned repositories, no user interaction needed |
| Cloud credential theft | SSRF vulnerabilities exposed cloud credentials and IAM tokens |
| Billing amplification | Autonomous agent loops caused catastrophic API spend |
| Supply chain erosion | Growing concerns around AI supply chain trust and protocol-level governance |
These are not isolated bugs. They are symptoms of a larger architectural issue. Each incident looks different on the surface, email here, billing there, but underneath, every one of them is the same story: an orchestration layer being treated with plugin-era controls, failing in exactly the way plugin-era controls fail.
Reported MCP exploitation patterns: email forwarding, poisoned repos, SSRF, billing amplification. Incident types from public reports.
The Core Structural Failure
Key quote: “AI agents frequently receive far more authority than organizations realize.”
The industry currently operates under two conflicting assumptions, and the collision between them is becoming one of the defining security failures of the MCP ecosystem:
| Protocol designers assume… | Developers assume… | Reality |
|---|---|---|
| Developers will sanitize inputs, enforce controls, and secure deployments correctly. | Platforms and protocols already handle security boundaries safely. | Each side believes the other is handling it. Neither side is. |
That protocol-platform trust gap, the space between “someone else’s responsibility” stated twice, is where real deployments live and real breaches happen.
The symptoms are visible in almost every environment we assess:
- Permissions are overly broad
- Trust boundaries are poorly defined
- Credential isolation is weak
- Execution pathways are insufficiently constrained
- Governance ownership is unclear
The result is predictable and consistently underestimated: AI agents frequently receive far more authority than organizations realize. Not because anyone made a reckless decision, but because no one made the decision at all.
The protocol-platform trust gap: each side assumes the other handles security. Conceptual diagram.
This week, the trust gap stopped being theoretical. OX Security’s “Welcome to the Jungle” report, published October 18, scanned 15,465 publicly indexed MCP servers across five registries and found the conditions this article describes, in production: servers running on home machines exposed through ngrok tunnels, servers still answering on expired domains anyone can register, and no vetting in the marketplaces that listed them.
The headline finding is not a bug. It is a position. When OX highlighted that MCP’s STDIO transport accepts a command parameter and executes it verbatim — a systemic command-injection path built into the transport itself — Anthropic confirmed the behavior is by design, declined protocol-level changes, and placed the entire sanitization burden on developers. OX’s earlier supply-chain advisory estimated roughly 200,000 vulnerable MCP server instances, more than 7,000 of them publicly accessible, across more than 150 million SDK downloads.
Read that against the two assumptions above. Protocol designers assume developers will sanitize. Developers assume the protocol handles the boundary. The protocol’s own maker has now stated, on the record, which side it believes is responsible — and it is not the protocol.
Why This Changes Enterprise Security
Key quote: “The orchestration layer itself becomes part of the attack surface.”
Historically, attackers often needed to compromise several layers before reaching operational systems. Defense in depth worked because depth existed. There was distance between the untrusted edge and the things that mattered.
Now that distance is collapsing. The gap between untrusted content and infrastructure interaction is shrinking to nearly nothing: a poisoned repository, a manipulated context window, a malicious MCP server, or a compromised tool chain can now influence execution flows far earlier than traditional architectures ever allowed.
This fundamentally changes containment assumptions. The orchestration layer itself becomes part of the attack surface, and in many enterprises, it is one of the least mature security domains currently deployed. Your most connected layer is your least examined one. Sit with that for a moment, because it inverts the usual security priority completely.
The New MCP Kill Chain
Key quote: “This is no longer optional for mature environments.”
Organizations need to stop thinking about MCP as a lightweight integration framework, because that mental model produces lightweight controls. MCP increasingly functions as an identity broker, a delegated execution plane, a workflow orchestrator, a trust-transit layer, and in some cases, an autonomous operational actor.
Read that list as what it is: a description of infrastructure, not accessories. And infrastructure-grade components require infrastructure-grade controls. MCP deployments now require:
- Governance
- Segmentation
- Execution restrictions
- Monitoring
- Ownership assignment
- Catastrophic-risk thresholds
- Credential isolation
- Replication controls
- Behavioral oversight
This is no longer optional for mature environments. It’s the baseline, the price of operating an orchestration layer that touches everything.
What Organizations Should Prioritize First
Key quote: “The goal is not eliminating AI adoption. The goal is preventing invisible trust expansion.”
Most teams do not need a massive enterprise AI security program on day one. But they do need foundational controls immediately, because every week of uncontrolled MCP expansion is trust being granted silently, and silent trust is the hardest kind to revoke later.
The highest-priority early actions usually include:
- Auditing MCP server configurations
- Restricting unnecessary scopes and permissions
- Rotating exposed or overprivileged credentials
- Separating untrusted content from write-capable agents
- Implementing API-spend monitoring
- Assigning explicit ownership for every MCP server
- Monitoring schema and permission changes
- Enforcing read-only defaults wherever possible
Work through that list against your own environment and notice how many items you can’t answer confidently today. That gap, between what the list requires and what you can verify, is your actual MCP risk posture.
The goal is not eliminating AI adoption. The goal is preventing invisible trust expansion: every permission granted deliberately, every boundary drawn on purpose, nothing accumulated by default.
Priority first actions for MCP deployments. Suggested starting checklist. Adapt to your environment.
The Bigger Reality
Key quote: “That assumption may not hold much longer.”
The industry is repeating a familiar pattern. Early SaaS adoption normalized excessive OAuth trust long before organizations understood the long-term security implications. We granted broad permissions because it was convenient, and spent the next decade clawing them back.
MCP appears to be following a similar trajectory, except this time the execution layer is increasingly autonomous. That raises the stakes significantly, because an over-permissioned SaaS app could leak your data, but an over-permissioned autonomous agent can act on it, at machine speed, while you’re asleep.
Once AI agents gain delegated authority across infrastructure, the orchestration layer itself becomes security-critical infrastructure. And many organizations are still treating it like a plugin ecosystem.
That assumption may not hold much longer. The question isn’t whether your teams will adopt MCP. They already have. The question is whether your security model knows it.
What to Do Next
1. Inspect. List every MCP server in your environment, its owner, its scopes, and its credentials. Flag any server without an owner.
2. Test. Attempt one over-permissioned action in a staging MCP deployment and check whether segmentation stops it.
3. Decide. Assign explicit ownership per server and enforce read-only defaults; expand controls to the highest-blast-radius servers first.
Find Your Exposure First
Free AI governance assessment, instant score, no sales call required.