# MCP: The Protocol Enabling Both Enterprise AI and AI-Powered Cyberattacks
## Key Takeaway
Model Context Protocol (MCP) is the TCP/IP of agentic AI—but unlike TCP/IP, it launched with no authentication, user context propagation, or abuse detection. The same protocol that connects enterprise AI to databases is now orchestrating offensive cyberattacks across 600+ devices in 55 countries. Until MCP adds security primitives to the protocol specification itself, every MCP integration is a potential attack vector with no governance standard to govern its risk.
## The Convergence: Three February 2026 Incidents Expose a Structural Problem
In a single month, the AI infrastructure industry encountered three critical security events that initially seemed unrelated. Cross-referenced, they reveal a deeper issue: MCP has become dual-use infrastructure with no built-in security distinctions between enterprise and offensive use.
Event 1: Claude Code's MCP Server Bypass (CVE-2025-59536)
[Check Point Research disclosed](https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/) three Claude Code vulnerabilities on February 25. The most critical: CVE-2025-59536 (CVSS 8.7) allowed MCP servers to execute automatically before any user consent dialog appeared. The vulnerability exploited `enableAllProjectMcpServers` configuration files—repository settings that enable an MCP server before the user even sees a trust prompt.
Event 2: FortiGate Threat Actor's Custom ARXON MCP Server
Simultaneously, [Amazon Threat Intelligence documented](https://aws.amazon.com/blogs/security/ai-augmented-threat-actor-accesses-fortigate-devices-at-scale/) a financially motivated threat actor who built ARXON—a custom MCP server that orchestrated DeepSeek for attack plan generation. This attacker compromised 600+ FortiGate devices across 55 countries in 38 days. ARXON's architecture is functionally identical to enterprise MCP integrations: it connects an AI model to external tools, orchestrates multi-step workflows, and manages operational state. The only difference is intent.
Event 3: Cline CLI Supply Chain Attack and Agent-to-Agent Propagation
[The Cline CLI supply chain compromise](https://thehackernews.com/2026/02/cline-cli-230-supply-chain-attack.html) silently installed OpenClaw—an autonomous AI agent with MCP server capabilities—on approximately 4,000 developer machines over an 8-hour window. This demonstrated agent-to-agent propagation, where one AI tool becomes the distribution vector for another. OpenClaw itself had CVE-2026-25253 (CVSS 8.8), enabling unauthenticated operator-level access via WebSocket—the same confused deputy pattern the MCP specification itself acknowledges.
## Why This Matters: MCP's Design Gap
The [official MCP specification](https://modelcontextprotocol.io/specification/draft/basic/security_best_practices) explicitly acknowledges the root cause: "The protocol doesn't inherently carry user context from the Host to the Server -- the server has no way to differentiate between users." This is not a bug in Claude Code or Cline; it is a design gap in the protocol itself.
- Developers control repository configurations
- Single-user development environments
- CI/CD pipelines with limited automation
- Shared workspaces with multiple developers
- CI/CD pipelines orchestrating autonomous agents
- Repositories from untrusted sources (open-source, vendor templates)
- AI tools with elevated permissions on developer machines
## The Security Readiness Gap
48% of cybersecurity professionals identified agentic AI as the top attack vector for 2026, according to Dark Reading's 2026 survey. Yet only 29% of organizations report being prepared to secure agentic AI deployments. Meanwhile, 85-90% of developers are already using AI coding tools with MCP integrations.
This creates a cascading vulnerability:
| Metric | Value | |--------|-------| | Developer AI Tool Adoption | 85-90% | | Security Professionals Identifying Agentic AI as Top Threat | 48% | | Organizations Prepared for Agentic Security | 29% | | Preparedness Gap | 56-61 percentage points | | MCP-Related CVEs (Feb 2026) | 5+ |
## How the FortiGate Attack Demonstrates MCP's Dual-Use Risk
The FortiGate attacker evolved from using HexStrike (December 2025) to custom ARXON/CHECKER2 orchestration (February 2026)—a 2-month maturation from semi-manual to fully automated offensive operations. This mirrors the legitimate DevOps automation curve, but compressed.
- Reconnaissance: ARXON MCP server ingests FortiGate backup configurations
- Analysis: DeepSeek (via ARXON) generates structured attack plans
- Exploitation: Claude (as coding agent) generates Impacket scripts, Metasploit modules
- Lateral Movement: CHECKER2 orchestrates multi-step intrusions with minimal human approval
When offensive tooling uses the same architecture as defensive tooling, every improvement to enterprise MCP infrastructure also improves offensive capability. The attacker achieved what AWS assessed would have "previously required a significantly larger and more skilled team" through the same protocol that enterprises use for productivity.
## The Temporal Maturation: From Protocol to Weaponized Infrastructure
The timeline reveals how quickly MCP matured from protocol specification to weaponized attack infrastructure:
- October 2025: CVE-2025-59536 (MCP server bypass) identified
- December 2025: First offensive use via HexStrike
- January 11, 2026: FortiGate campaign begins with ARXON
- February 9: Clinejection disclosed (prompt injection in AI triage bot)
- February 17: Cline supply chain attack installs OpenClaw on ~4,000 machines
- February 25: Check Point publishes full MCP vulnerability cluster
## What Enterprise Deployments Must Do Now
The practical implications for ML engineers are immediate:
- MCP servers are network endpoints: Every MCP integration should be treated with the same rigor as database access or API credentials
- Repository configuration files are executable: `.claude/settings.json`, `mcp.json`, and similar files should be reviewed as carefully as code
- Zero-trust for MCP: The current trust model (MCP servers approved once, trusted indefinitely) is incompatible with untrusted repository sources
- Audit trail requirement: Every MCP operation should be logged to detect abuse patterns
## The Path Forward: From Protocol Gaps to Governance Standards
The industry needs three concurrent changes:
Protocol Level (6-12 months): MCP v2 should include authentication, user context propagation, and rate limiting as mandatory primitives—similar to how HTTPS became mandatory for HTTP.
Tooling Level (3-6 months): Enterprise MCP auditing tools will emerge as vendors realize the market opportunity. Anthropic's rapid disclosure process for CVEs demonstrates this is achievable.
Governance Level (12-18 months): AI tool security will become a regulated compliance category similar to SOC 2, requiring audit trails equivalent to database access controls.
## What This Means for Practitioners
The MCP security crisis is not a vendor-specific problem—it is a structural protocol-level issue that will persist until the specification itself includes security primitives. For the next 12-18 months, treat every MCP integration as a potential attack vector that requires:
- Explicit allowlisting of approved MCP servers (no auto-approval)
- Credential isolation (MCP server access should not grant access to production credentials)
- Repository trust verification (never auto-execute MCP configs from untrusted sources)
- Audit logging of all MCP operations
The companies that ship MCP security governance tooling first will capture enormous enterprise value, much like how Okta and CrowdStrike built billion-dollar businesses solving security gaps in other infrastructure layers. But the foundational fix—MCP security primitives in the protocol specification—must come from the protocol authors.