What Is Actually Happening to MCP Users Right Now the Real Security Risks

The threat is not theoretical. Real users have experienced real harm across 2025 and 2026.

Developer environments: Claude Code users had remote code execution delivered through poisoned repository configuration files in January and February 2026. No interaction was required beyond opening the project.

Enterprise SaaS users: Asana disabled its MCP feature entirely for two weeks in June 2025 after a cross-tenant data leak exposed one organization’s data to another organization’s agents.

Email-integrated workflows: The Postmark MCP supply chain incident silently BCC’d every email processed by the agent to an attacker-controlled server. Every email, including confidential documents.

Cloud-connected workflows: Microsoft’s MarkItDown MCP server exposed AWS IAM access keys, secret keys, and session tokens via an SSRF vulnerability. A single misconfigured server became a gateway to an entire cloud account.

Financial impact: Four AI agents entered an infinite retry loop and generated a $47,000 API bill in 11 days. No malicious intent was required, just a missing cost boundary.

Agentic coding environments: Cursor AI was manipulated via a malicious user ticket (the Lethal Trifecta) to write proprietary information into a public pull request, bypassing standard enterprise security posture.

The Pentagon designated Anthropic a supply chain risk in February 2026, the first time any American AI company has received that classification. This is the operating environment.

The Protocol-Platform Mismatch: Why Risk Is Systematically Underestimated

The most dangerous aspect of the current MCP risk environment is a structural mismatch between how protocol designers think about MCP and how users and organizations experience it.

The protocol designer’s view: the developer is responsible for sanitizing inputs. STDIO is explicitly local and trusted. Servers are community artifacts. Tool metadata is configuration data. User reality: users assume the platform is secure by default. IDEs, SaaS, and enterprise tools deploy STDIO to thousands of users via cloud. Users install servers like App Store apps, expecting vetting. Tool descriptions execute as instructions inside the LLM.

This mismatch is not an opinion. It is the structural cause of every major MCP security incident of 2025 and 2026. When Anthropic responds to the OX disclosure by saying the flaw is expected behavior and shifts responsibility to developers, users who are neither Anthropic nor developers are left without guidance.

The User Risk Decision Matrix

The following threat priorities are organized by documented probability and impact severity. Probability is derived from the empirical incident record. Impact severity is based on documented incident outcomes.

Supply chain and rug pull via malicious server update: Probability HIGH (nine of eleven registries poisoned in OX testing; real Postmark incident in 2025). Impact Critical (data exfiltration, credential theft, RCE). User-visible signal: none. Recommended action: use only servers from vetted private registry; enable schema-change alerting.

Prompt injection via tool output: Probability HIGH (documented in GitHub PAT, Cursor, and Claude Code incidents). Impact High (unauthorized actions, data exfiltration). Signal: agent behaves unexpectedly. Action: restrict tools to read-only; implement output sanitization.

SSRF via MCP server: Probability HIGH (36.7% of analyzed servers vulnerable). Impact Critical (cloud credential theft, internal network access). Signal: none. Action: block cloud metadata URLs at gateway; patch all servers to listed CVEs.

Unauthenticated server access: Probability HIGH (492 servers confirmed unauthenticated). Impact High (tool invocation by any network actor). Signal: none visible to user. Action: require OAuth 2.1 for all remote servers.

STDIO command injection (OX CVE class): Probability HIGH (root architecture of all official SDKs). Impact Critical (RCE on host machine, full credential access). Signal: none. Action: never allow user or AI input to reach STDIO launch command; implement MCP-1.

API billing amplification (Phantom attack): Probability MEDIUM-HIGH (empirically demonstrated, 658x amplification). Impact High ($47,000 or more financial loss, service disruption). Signal: unusually high API bill. Action: set per-session token budget; enable cost anomaly alerting.

Tool poisoning (TPA, ATPA, FSP): Probability MEDIUM-HIGH (MCPTox benchmark shows high success rate, OWASP top risk). Impact High (silent behavior manipulation, data theft). Signal: agent takes unexpected actions. Action: treat all tool descriptions as executable content; review new server schemas.

OAuth confused deputy and consent bypass: Probability MEDIUM (FastMCP and Square incidents documented). Impact High (account takeover, one-click token theft). Signal: no user-visible signal. Action: enforce strict redirect_uri allowlisting; require PKCE.

Persistent memory injection: Probability MEDIUM (architectural confirmation in Claude Code March 2026). Impact High (long-horizon behavioral manipulation). Signal: agent behavior drifts over sessions. Action: regularly clear agent memory; audit what persists across sessions.

Multi-agent lateral movement: Probability LOW-MEDIUM (ARMO research 2026). Impact Critical (compromise propagates invisibly through delegation chain). Signal: per-agent behavior appears normal. Action: monitor delegation edges; implement provenance chains.

Model Context Protocol (MCP): Short, Medium, and Long-Term Risk Trajectory

Near-Term (Now through Q3 2026)

Current risk posture: ELEVATED. This is the most dangerous MCP environment yet. The OX April 2026 disclosure has seeded public awareness of the STDIO architectural flaw, which means exploit code and attack tooling is now widely available. The window between vulnerability disclosure and commodity exploitation in AI agent tooling is compressing dramatically. AI-accelerated exploit generation means disclosure-to-weaponization windows that took months in 2022 now take days in 2026.

Users running unpatched CVEs from the OX advisory face immediate, active exploitation risk. Probability of harm for unprotected users in Q2 and Q3 2026: credential theft via SSRF or supply chain greater than 60% for users with cloud-connected MCP servers and no egress filtering; prompt injection behavioral manipulation greater than 70% for users processing untrusted external content via file, web, or email MCPs; API billing amplification 30 to 50% for users without session cost budgets, rising as attack tooling matures.

The servers installed before April 14, 2026 have potentially already been compromised through supply chain poisoning. Any IDE-integrated MCP server running a pre-patch version of affected software carries live RCE risk. The threat landscape will worsen before it improves because Anthropic has not committed to a protocol-level fix.

Medium-Term (Q4 2026 through Q2 2027)

Trajectory: bifurcation between hardened and unhardened deployments. The ecosystem is developing compensating infrastructure including MCP gateways (Zuplo, Kong, Operant AI), vetted private registries, schema signing proposals at the Linux Foundation, and OWASP’s Secure MCP Server Development guide. Enterprise registry consolidation is emerging. FedRAMP and CMMC are beginning to develop MCP-specific guidance.

The medium-term risk environment will be defined by a security gap between organizations that have implemented the controls in this report and those that have not. Supply chain poisoning risk is decreasing for vetted-registry users and increasing for public-registry users. Billing amplification attacks are increasing as attack tooling matures and commoditizes. Protocol-level fix from Anthropic or AAIF has a low probability before Q4 2026 based on current public position.

Long-Term (2027 and Beyond)

Two divergent scenarios exist.

Scenario A (probability approximately 55%): The AAIF under the Linux Foundation adopts mandatory security specifications, the ecosystem converges on a small number of enterprise-audited registries, and MCP becomes a mature trusted integration layer analogous to OAuth or TLS. This scenario requires either a major catastrophic incident driving regulatory mandate or voluntary industry leadership from major platform vendors.

Scenario B (probability approximately 45%): Protocol governance remains slow, the public registry ecosystem stays fragmented and largely unvetted, attackers develop persistent MCP-specific toolkits analogous to web application attack frameworks, and enterprises face ongoing elevated risk as the protocol’s deployment scale grows faster than its security posture. This scenario produces periodic major incidents larger than anything in the 2025 to 2026 record.

Probabilistic Risk Forecast

Annual probability estimates for an organization with average security posture and moderate MCP deployment: supply chain compromise via MCP 55 to 65%; credential theft via SSRF 40 to 50%; prompt injection behavioral manipulation 60 to 75%; API billing amplification 20 to 30%; RCE via STDIO post-disclosure 45 to 55% for unpatched systems; multi-agent lateral movement 10 to 20%; Swarm C2 exploitation 5 to 10%; persistent memory injection 15 to 25%; regulatory or compliance breach via MCP 15 to 25%; $10,000 or more API billing event 10 to 15%.

The protocol-platform mismatch amplifies every probability. When Platform A deploys MCP with auth optional, users assume auth is present. When Platform B updates MCP servers dynamically, users have no schema diff visibility. When Platform C enables multi-tenant MCP, users assume per-tenant isolation. Until the protocol mandates security controls rather than recommending them, every platform adoption of MCP is a potential security externality imposed on its users.

User MCP Security Playbook: Security Easy Enough to Actually Do

Tier 1: Zero-Friction Controls (Under 30 Minutes)

1. Audit your MCP configuration file right now. Claude Desktop: check ~/.config/claude/claude_desktop_config.json (macOS/Linux) or %APPDATA%\Claude\claude_desktop_config.json (Windows). Cursor/Windsurf: check .mcp.json in your project root and global MCP settings. Remove any server you did not explicitly install and do not actively use. For any server you do not recognize, remove it immediately and rotate any credentials it could access.
2. Rotate credentials that MCP servers could have accessed. If you have used MCP with GitHub, Slack, email, Jira, a database, or any cloud service since January 2026, rotate those credentials now. Multiple supply chain incidents in 2026 demonstrate that stored credentials in MCP configuration files are a primary harvest target.
3. Update all MCP servers and clients. Apply available patches for all CVEs: LiteLLM (CVE-2026-30623), Windsurf (CVE-2026-30615), mcp-server-kubernetes (CVE-2026-39884), FastMCP (CVE-2026-27124 and CVE-2025-69196), Azure MCP (CVE-2026-26118), Azure DevOps MCP (CVE-2026-32211, CVSS 9.1).
4. Set API cost alerts at your cloud provider and LLM API vendor. Set a daily and session cost alert at 2x your expected daily spend. This is free to configure and is your only defense against the billing amplification attack class.

Tier 2: Low-Effort Controls (Under 2 Hours Each)

5. Use a private, curated server list, not the public registry. Maintain an internal allowlist of MCP servers your team has verified. The public registries (Smithery, glama.ai, and others) are currently unvetted marketplaces. Treat them like npm circa 2015.
6. Default to read-only tool permissions. When configuring MCP connectors to enterprise systems (GitHub, Slack, Jira, databases), request read-only access scopes unless write access is explicitly required for the workflow.
7. Never process untrusted external content with a write-capable agent. If an agent can send emails, write to a database, post to Slack, or commit code, do not also have it read external documents, web pages, or user-submitted content in the same session. This directly prevents the Lethal Trifecta attack.
8. Enable credential file read-blocking. If you use a filesystem MCP server, explicitly exclude: ~/.ssh/, ~/.aws/, ~/.config/, .env files, and any directory containing credentials.
9. Periodically clear agent memory. If your AI agent has persistent memory, review and clear accumulated memory on a regular schedule. Monthly is reasonable for most users. This prevents persistent memory injection from establishing long-horizon behavioral manipulation.

Tier 3: Team-Level Controls (1 to 2 Weeks for Adoption)

10. Deploy an MCP gateway for shared team servers. Implement a protocol-aware proxy (Operant AI, Rapidclaw, Kong with MCP plugin) that centralizes authentication, rate limiting, output scanning, and audit logging. A gateway turns a distributed security problem into a centralized one.
11. Implement schema-change alerting. Script a check that calls tools/list on each MCP server at deployment and stores a hash of the response. Alert when the hash changes unexpectedly between sessions. This is the minimum viable rug-pull defense.
12. Assign an owner to every MCP server Consistent with AI SAFE2 v3.0 CP.4 and CP.10: every deployed MCP server must have a named individual who is responsible for its security posture, receives alerts, and has the authority to disable it.
13. Classify agents by ACT tier before deploying. ACT-1 (human reviews all outputs): standard controls adequate. ACT-2 (agent acts with human checkpoints): MCP-1, MCP-2, MCP-5 mandatory. ACT-3 (autonomous post-hoc review): all seven MCP controls mandatory plus CP.2 threat model plus designated owner_of_record. ACT-4 (orchestrates other agents): all ACT-3 requirements plus CP.4, CP.8, CP.9, and CP.10 HEAR.
14. Never run ACT-3 or ACT-4 agents without a defined kill-switch owner (HEAR). For any autonomous or orchestrator-level agent deployment, designate a specific named individual with unilateral authority to halt the deployment. This person must be reachable in real time and must have direct access to the deployment’s stop controls.

Tier 4: Enterprise Architecture Controls (1 to 3 Months)

15. Build a private, vetted MCP registry with signed containers. For federal (DoD/CMMC/FedRAMP) and enterprise environments processing sensitive data, all MCP servers must originate from a private catalog with agency or enterprise-controlled signing keys, SBOM generation, and periodic vulnerability scanning.
16. Implement CP.8 Catastrophic Risk Threshold Controls before ACT-3/ACT-4 approval. Document the specific behavioral indicators that would trigger immediate suspension of any autonomous agent: irreversible financial or data deletion action without authorization; evidence of MCP supply chain compromise; multi-agent system entering an escalating loop.
17. Implement CP.9 Agent Replication Governance for orchestrator deployments. If any deployed agent can spawn sub-agents via MCP, implement AI SAFE2 v3.0 CP.9: every spawned sub-agent receives a new ephemeral credential with scope narrowing at each delegation hop; a cryptographic lineage token travels with every agent; maximum delegation depth is 3 hops for ACT-4; kill switch severs the full delegation tree within 500ms.
18. Deploy CP.7 Deception and Active Defense assets. Place canary documents in RAG corpora and honeypot tool endpoints (tools that should never be called in normal operation). Any invocation of these assets is an immediate security alert, indicating either adversarial probing or successful compromise. This is the only proactive early warning system against the MCP-UPD parasitic toolchain attack class.

Key urls:

Cross-Pillar Controls – https://github.com/CyberStrategyInstitute/ai-safe2-framework/blob/main/00-cross-pillar/cp5_mcp_sever_security.md

MCP Specific Controls – https://github.com/CyberStrategyInstitute/ai-safe2-framework/blob/main/00-cross-pillar/cp5_mcp_sever_security.md

MCP Research Notes 023 – https://github.com/CyberStrategyInstitute/ai-safe2-framework/blob/main/research/023_mcp-server-security-profile.md 

MCP Research Note 024 – https://github.com/CyberStrategyInstitute/ai-safe2-framework/blob/main/research/024_mcp_consumer_protection.md

MCP Security Toolkit – https://github.com/CyberStrategyInstitute/ai-safe2-framework/tree/main/examples/mcp-security-toolkit