← Back
Security Intelligence Briefing

The Hidden Risks of MCP: What Every Security Leader Must Understand

Model Context Protocol is transforming how AI connects to your infrastructure — and creating an attack surface most organizations are not prepared for.

A developer on your team connects an AI assistant to your company's GitHub repository, Slack workspace, and internal ticketing system — all in under ten minutes, using a configuration file smaller than a text message. No security review. No change ticket. No firewall rule. This is happening right now, in organizations everywhere. It is called MCP.

01 — Foundations

What Is MCP and Why Does It Matter?

Model Context Protocol (MCP) is an open standard, launched by Anthropic in November 2024, that allows AI assistants and agents to connect to external tools, data sources, and services through a universal interface. Think of it as USB-C for AI — one standard connector that lets any AI plug into any system.

Simple Analogy

Before MCP, connecting an AI to five different tools required five custom integrations — like needing a different charger for every device. MCP is the universal adapter. One protocol connects the AI to everything: your email, your code repositories, your security tools, your databases.

The architecture is straightforward: an AI application (the client) connects to one or more MCP servers, which act as bridges to external systems. Those servers expose their capabilities as tools. When you ask the AI to do something requiring external data, it calls the appropriate server, which executes the request and returns results.

# The MCP Architecture You (natural language) AI Client (Claude, Cursor, Copilot) ↓ MCP protocol MCP Server (Falcon, GitHub, Slack...) ↓ vendor API call Your live data and systems

Adoption has been explosive. Within months of its release, hundreds of vendors published MCP servers: CrowdStrike Falcon, Microsoft Sentinel, GitHub, Slack, Jira, AWS, Google Drive, Salesforce — and thousands of community-built servers for almost every tool imaginable.

9,000+
Public MCP servers scanned by BlueRock
9.2%
Found with critical vulnerabilities
36.7%
Have potential SSRF exposure allowing cloud credential theft

02 — Threat Landscape

The New Attack Surface

MCP does not introduce entirely new categories of vulnerability — but it dramatically amplifies the blast radius of existing ones, and introduces a few genuinely novel attack patterns that traditional security controls are not designed to catch.

"A gateway sees that a tool was called. MCP threat actors care about what the tool actually did — the query, the permission used, the system touched downstream. Those are two entirely different layers."

The Novel Risks: What's Genuinely New

Critical

Tool Poisoning

MCP tool descriptions — the text that tells the AI what a tool does — are injected directly into the AI's context as trusted instructions. An attacker who controls or compromises a tool description can hide malicious instructions inside it. The AI reads and follows them. The user never sees this happen. In a documented proof-of-concept, a poisoned "add two numbers" tool silently exfiltrated SSH keys and credential files while returning the correct math answer to the user.

Critical

Rug Pull Attacks

A clean, approved MCP server updates its tool definitions after initial review — injecting malicious behavior with no new package version, no checksum change, nothing for a package manager to flag. The attack payload lives in a runtime API response, not the package itself, bypassing every static analysis tool. Your security team approved it last week. It became dangerous this week. You would not know.

High

Cross-Server Escalation

When an agent has multiple MCP servers connected simultaneously, a malicious server can embed instructions targeting a different, legitimate server. Demonstrated live: a trivia game MCP server contained hidden instructions that caused the agent to exfiltrate data through a connected WhatsApp MCP server. One bad server poisons your entire agentic workflow.

High

Shadow MCP Servers

Developers and analysts spin up MCP servers locally — on laptops, dev machines, personal cloud accounts — connecting them to corporate systems with no security review, no inventory, no audit trail. Like Shadow IT, but these shadow deployments have AI agents taking real actions on corporate data. If you cannot list every MCP server in your environment right now, shadow deployments already exist.

The Amplified Risks: Familiar Problems, Bigger Blast Radius

High

Keys to the Kingdom — Credential Exposure

MCP servers store OAuth tokens for every connected service — Gmail, Google Drive, Slack, GitHub, Falcon — in a single configuration file. One compromised MCP server grants access to all connected services simultaneously. These tokens often survive password changes. A single breach equals access to everything the AI was permitted to touch.

High

Supply Chain Attacks

MCP packages install via npm or pip with no signature verification. The first confirmed in-the-wild malicious MCP package appeared in September 2025: the postmark-mcp email server pushed an update that exfiltrated message contents to an attacker-controlled domain. Thousands of installations were affected before discovery. Classic supply chain attack vector, now inside your AI infrastructure.

Medium

Command Injection

AI agents construct shell commands, database queries, and API calls from user inputs. When input validation is absent — which it frequently is — classic injection attacks follow. Between January and February 2026, researchers filed over 30 CVEs targeting MCP servers; 43% were shell injections. A vulnerability in Anthropic's own Git MCP server required three CVEs. The "Clinejection" attack demonstrated code execution triggered by a malicious GitHub issue title.

Medium

Privilege Creep and Scope Sprawl

MCP servers are granted API scopes at setup and those scopes rarely shrink. Developers request broad access for convenience. Over time, agents accumulate capabilities far exceeding what any single workflow requires. An attacker exploiting an agent can perform actions the original developer never intended — repository modification, data deletion, lateral movement into connected systems.


03 — Why It's Different

The CISO's Concern: Why This Is Different

Security leaders have navigated Shadow IT, API security, supply chain risks, and prompt injection before — so why does MCP warrant special attention? Three reasons.

1. The Speed-Autonomy Gap

Traditional integrations require code changes, testing, and deployment cycles that create natural checkpoints for security review. An MCP server can be connected to your corporate systems by a developer in minutes, with a twenty-line JSON configuration file, from their laptop, with zero involvement from security or IT. The speed of adoption is outpacing the speed of governance everywhere.

2. Actions, Not Just Information

Previous AI security concerns focused on what the AI might say — hallucinations, data leakage in responses, prompt injection in chatbots. MCP changes the threat model fundamentally. AI agents connected via MCP don't just provide information — they take actions: sending emails, committing code, modifying database records, executing commands on remote systems. The consequence of a compromised agent is not a bad answer. It is a real action in a real system.

3. Existing Controls Have a Coverage Gap

Your firewall can see that traffic went to api.crowdstrike.com. Your gateway can see that a tool was called. Neither can tell you what the tool actually did, whether the tool description contained hidden instructions, or whether an approved server was modified since last review. MCP attacks largely operate below the layer that traditional perimeter and gateway controls inspect.

Board-Level Questions to Prepare For

What Your Board Will Ask

  • How many AI agents are operating in our environment, and what systems can they access?
  • If an MCP server was compromised today, which credentials and data sources would be exposed?
  • Do we have an inventory of every MCP server our employees are running — including on personal laptops?
  • What is our process for vetting an MCP server before it connects to production systems?
  • Can we produce an audit log of every action an AI agent has taken in the last 30 days?
  • Have we assessed whether our existing EDR, SIEM, and DLP controls have visibility into agentic actions?

04 — Response

What Good Looks Like: The Security Architect's Response

The answer is not to block MCP adoption — developers will route around that, creating worse shadow problems. The answer is to build the governance structure that lets the organization adopt MCP safely and with visibility.

Layer 1: Know What You Have (Discovery)

Layer 2: Vet Before You Connect (Pre-Deployment)

Layer 3: Watch What Happens (Runtime Visibility)

Layer 4: Control What Can Happen (Enforcement)


05 — Tooling

Tools That Help Right Now

ToolWhat It DoesCost
mcp-scan
uvx mcp-scan@latest
Scans your machine for installed MCP configs; detects tool poisoning, rug pulls, cross-origin escalation Free / Open Source
BlueRock MCP Trust Registry
mcp-trust.com
Security scorecards for 9,000+ public MCP servers; 22 rules mapped to OWASP MCP Top 10; private repo scanning available Free (registry); Paid (private scanning)
BlueRock Agentic Platform
bluerock.io
Runtime observability, pre-execution guardrails, agent inventory, SIEM integration, BRACE sandbox Free tier on AWS; Enterprise pricing
OWASP MCP Top 10
owasp.org/www-project-mcp-top-10
Official threat taxonomy for MCP deployments; 10 risk categories; framework for vendor evaluation Free
Falcon MCP Server
github.com/CrowdStrike/falcon-mcp
Official CrowdStrike MCP — access Falcon detections, intel, hosts, RTR, CSPM via AI agents Free (requires Falcon license)

The Bottom Line

MCP is not going away. The productivity gains for developers and security analysts are real and significant — your teams are already using it, whether you know it or not. The organizations that will navigate this well are not the ones who block adoption. They are the ones who build the governance layer first: inventory, vetting, runtime visibility, and enforcement. The tools exist today. The frameworks exist. The question for every security leader is simply: how far behind are we, and how fast can we close the gap?