Shadow MCP: The AI-Agent Blind Spot Your SOC Isn’t Watching Yet

In October 2025 we wrote an enthusiastic post about how agentic AI and MCP servers work together. The architecture still holds. What changed in the eleven months since is the security picture around it, and most SOCs have not caught up.

The Model Context Protocol (MCP) is how AI clients such as Cursor, Claude Desktop, VS Code, and a growing list of agent frameworks connect to tools: a database, a Git repository, a ticketing system, a shell. Each connection is an MCP server. And according to data compiled in mid-2026, 86% of MCP servers run locally on developer machines, and only 5% run in production environments. That is the whole problem in one line. The fastest-growing integration layer in the enterprise lives on endpoints your SOC treats as ordinary laptops, launched as child processes nobody inventoried, holding credentials nobody rotated.

This post is the other half of our 2025 article: what the 2026 vulnerability data actually says, why MCP is structurally invisible to a typical Wazuh deployment, and four detection layers you can put in place without buying a new product.

What changed in 2026: the numbers

The MCP ecosystem went from specification to default infrastructure in about eighteen months. Security review did not keep pace.

• 30+ CVEs were filed against MCP servers in a single 60-day window in early 2026, and roughly 43% of those were command-injection patterns.
• The community-run Vulnerable MCP Project tracks over 50 known vulnerabilities, 13 of them rated critical.
• An audit of 5,200+ MCP servers found 53% rely on static API keys or personal access tokens, 79% pass keys through environment variables, and only 8.5% use OAuth.
• GitGuardian found 24,008 secrets in MCP-related configuration files on public GitHub, 2,117 of them still valid.
• CVE-2025-6514 in mcp-remote (CVSS 9.6) gave remote code execution on the client machine when connecting to an untrusted server, across 437,000+ downloads.
• CVE-2025-54136 ("MCPoison") in Cursor showed a subtler pattern: a trusted MCP configuration that was later silently swapped for a malicious one, giving persistent code execution.

That last one matters most for detection. The attack surface is not only the server code. It is the configuration file that tells an AI client which servers to launch and with which credentials.

Why MCP is a blind spot, specifically

Our earlier posts on securing the SOC’s own AI agent and on detecting attackers that are themselves AI agents dealt with agents the security team knows about. Shadow MCP is different: these are agents and tool connections that employees set up for themselves, usually in good faith, to get work done faster.

flowchart TD
    A["Developer laptop"] --> B["AI client such as Cursor or Claude Desktop"]
    B --> C["MCP config file lists servers and keys"]
    C --> D["Local MCP server started as a child process"]
    D --> E["Static token for Git, database or SaaS API"]
    E --> F["Internal systems reached with the developer account"]

From the SOC’s side, each hop in that chain looks unremarkable:

1. The process looks normal. An MCP server launched over STDIO is usually just node, npx, python, or uvx running as the logged-in user. There is no service, no installer, no new binary on disk to flag.
2. The credentials look legitimate. The token belongs to a real employee. When the agent queries the customer database, the database log shows that employee’s identity, not "an AI agent acting on instructions from a tool description."
3. The tool calls are not logged anywhere you collect. The MCP protocol exchange happens inside the client process. Unless you deploy a gateway in the middle, there is no audit trail of which tools were called with which arguments.
4. Nobody owns the inventory. IT did not install these servers, security did not approve them, and the developer may have added three more last week.

This is why the Obsidian research team frames MCP security as an inventory problem before it is anything else: you cannot patch, rotate, or monitor a server you do not know exists. It is also the same structural gap we described in Your SOC Watches Your Employees. It Doesn’t Watch Your Vendors., except this time the unwatched third party runs inside your own endpoints.

Four detection layers you can deploy on Wazuh this month

None of the following requires an MCP-specific product. These are reference patterns for any Wazuh 4.x deployment, including simpliSOC. They are not a packaged simpliSOC MCP module; we are explicit about that distinction further down.

flowchart TD
    L1["Layer 1 FIM on MCP config files"] --> W["Wazuh manager"]
    L2["Layer 2 Process creation telemetry"] --> W
    L3["Layer 3 New listening ports"] --> W
    L4["Layer 4 Secret scanning before commit"] --> W
    W --> R["DFIR-IRIS case for analyst review"]

Layer 1: File integrity monitoring on MCP configuration files

MCPoison proved that the config file is a persistence mechanism. Watch it. On developer endpoints, add the known client config locations to Wazuh syscheck. Scope this to a "developer workstations" agent group so you are not scanning every user profile in the company.

<!-- agent.conf, group: dev-workstations (Linux/macOS example) -->
<syscheck>
  <directories check_all="yes" realtime="yes"
    restrict="mcp\.json$|claude_desktop_config\.json$">/home</directories>
  <directories check_all="yes" realtime="yes"
    restrict="mcp\.json$|claude_desktop_config\.json$">/Users</directories>
</syscheck>

Then raise the alert level for changes to those files:

<!-- local_rules.xml -->
<group name="mcp,syscheck,">
  <rule id="100910" level="10">
    <if_sid>550, 554</if_sid>
    <field name="file">mcp.json$|claude_desktop_config.json$</field>
    <description>MCP client configuration added or modified: $(file)</description>
    <mitre>
      <id>T1546</id>
    </mitre>
  </rule>
</group>

One deliberate omission: do not enable report_changes on these paths. These files routinely contain API keys, and report_changes would copy the diff, secrets included, into your alert index. You want to know the file changed, not replicate its contents into a second place that now also needs protecting.

Layer 2: Process creation telemetry for MCP server launches

On Windows endpoints already shipping Sysmon Event ID 1 to Wazuh, a low-severity inventory rule turns MCP launches into a searchable record:

<group name="mcp,sysmon,">
  <rule id="100911" level="5">
    <if_group>sysmon_event1</if_group>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(mcp-remote|@modelcontextprotocol|mcp-server|mcp_server)</field>
    <description>MCP server process launched: $(win.eventdata.commandLine)</description>
  </rule>
</group>

Level 5 is intentional. On a developer machine this will fire often, and that is the point: after two weeks you have an inventory of which MCP servers actually run, on which hosts, launched by which parent process. Once you know what normal looks like, write higher-severity rules for the exceptions, such as mcp-remote versions older than 0.1.16, or MCP servers launched on hosts outside the developer group. On Linux, the same pattern works through auditd execve records or osquery.

Layer 3: New listening ports on developer hosts

MCP servers that use HTTP transport sometimes bind to 0.0.0.0 by default, which turns a local tool into a network service anyone on the same segment can call. Wazuh’s default configuration already includes a netstat listening-ports command and rule 533, which fires when the set of listening ports changes. Make sure that command is enabled for the developer group, and route rule 533 alerts from those hosts to a review queue rather than letting them sink into noise. A new listener owned by node or python on a laptop is worth a look.

Layer 4: Secret scanning before the config reaches Git

The 24,008 leaked secrets did not leak from production. They leaked from config files committed to repositories. Wazuh is the wrong tool for this layer; a pre-commit and CI secret scanner such as gitleaks or TruffleHog is the right one, with MCP config filenames added to its scope. Forward the scanner’s findings to Wazuh as a log source so leaked-key events land in the same case workflow as everything else.

Fix the identity model, not just the detection

Detection tells you that a developer’s MCP server holds a long-lived GitHub token. It does not fix the fact that the token exists. The MCP specification’s June 2025 revision recommends OAuth 2.1 with PKCE for HTTP-based servers, separating the resource server from the authorization server. In practice, most internal MCP servers still take a static key, because that is the fastest thing to build.

For internal MCP servers your own teams build, the better pattern is to put them behind your existing identity provider, so every tool call carries a short-lived token tied to a real user, scoped to the tools that user actually needs, and revocable centrally. simpliSSO, our Authentik-based identity service, is the component we use for this in client projects. To be precise: acting as the authorization server for MCP servers is an integration pattern we scope per project, not a pre-built simpliSSO MCP feature.

Shipped vs. reference pattern: the explicit line

What simpliSOC ships today that this post relies on:

• Wazuh file integrity monitoring, Sysmon ingestion, and command monitoring, deployed and tuned per client
• DFIR-IRIS case management for analyst review of the alerts above
• The read-only local-LLM triage assist described in our agentic AI SOC post, which can explain any of these alerts in plain language

What is a reference pattern in this post, not a shipped feature:

• The specific MCP rules above (rule IDs 100910 and 100911). We deploy and tune them in client engagements; they are not part of a packaged simpliSOC ruleset
• MCP gateway or proxy logging of individual tool calls
• Automated MCP server inventory reporting across an estate
• simpliSSO acting as an OAuth 2.1 authorization server for MCP, which is scoped per project

A 30-day starting plan

1. Week 1: Create a developer-workstation agent group and deploy Layer 2 at level 5. Do not alert yet; just collect.
2. Week 2: Review the inventory. Classify each MCP server as sanctioned, tolerated, or remove.
3. Week 3: Deploy Layer 1 (config FIM) and Layer 3 (listening ports) for the group. Add MCP config filenames to your secret scanner.
4. Week 4: Rotate every static token you found in Week 2, and move the most-used internal MCP servers behind your identity provider.

FAQ

Isn’t MCP secure by design? Your own 2025 post said MCP "provides trust."
MCP gives you a standard place to put controls. It does not put them there for you. Authorization is optional in the specification, STDIO servers have no network authentication at all, and most servers in the wild use static keys. The 2025 post described what MCP makes possible; this one describes what most deployments actually look like in 2026.

Should we just block MCP on company machines?
You can, and some regulated teams should. For most organizations a blanket block pushes developers to personal devices, which is a worse blind spot. Inventory first, then decide per server.

Will the Layer 2 rule flood our SIEM?
On developer hosts it will be busy for a few days. That is why it starts at level 5 and only on the developer group. Its job is to build the inventory, not to page anyone.

Does this cover MCP servers running in the cloud?
Partially. Layers 1 and 2 cover the client side, where the configuration and credentials live. Cloud-hosted MCP servers need the same treatment as any other internet-facing API: authentication, rate limiting, and logging at the gateway.

Is simpliSOC’s AI able to detect tool poisoning automatically?
No. Our local-LLM assist explains alerts that Wazuh has already raised; it does not inspect MCP tool descriptions at runtime. Detecting tool poisoning requires visibility into the protocol exchange itself, which is the gateway pattern listed above as not shipped.

---

If you run Wazuh and want help turning these patterns into rules tuned for your own endpoints, or you want to put internal MCP servers behind proper identity, that is the kind of work we do. See simpliSOC and simpliSSO, or email us at hello@simplico.net with a short description of your environment.

---

Sources:

• MCP Security Statistics 2026: CVEs, Vulnerabilities & Breach Data — Practical DevSecOps
• MCP Security Vulnerabilities: Complete Threat Inventory — Obsidian Security
• How Agentic AI and MCP Servers Work Together — Simplico
• Agentic AI SOC in 2026: What simpliSOC Actually Ships — Simplico