ShadowMCP
RESEARCH / UPDATED 22 SEP 2026

MCP Security Research 2026:
what the evidence is starting to show

Model Context Protocol security research is moving from hypothetical threat lists toward lifecycle analysis, runtime testing, scanner validation and operational discovery. This page tracks the evidence that matters for MCP server security teams without turning individual papers or scans into blanket safety verdicts.

Research boundary

Static repository evidence, runtime observations and network discovery answer different questions. None of them alone proves that an MCP server is safe or unsafe.

1. Why MCP security research changed in 2026

Early MCP security discussion focused heavily on threat enumeration: prompt injection, tool poisoning, over-broad permissions, token misuse and supply-chain risk. Recent work is increasingly asking a harder question: how do we measure those risks reliably across the MCP lifecycle and in real deployments?

A September 2026 ACM paper studies MCP from architectural and security perspectives and organizes the server lifecycle into creation, deployment, operation and maintenance. That lifecycle framing matters because a server can change materially after an initial review.

Read the ACM paper ↗

2. Runtime evidence is not the same as static scanner evidence

A July 2026 study on runtime MCP servers and security scanner reliability highlights an important measurement problem: a scanner's findings and a server's runtime behavior are not interchangeable. The study introduces MCPZoo, a large collection of MCP servers transformed into dynamic services for evaluation.

For defenders, the practical lesson is not that static scanning is useless. It is that static evidence should be treated as one layer: useful for pre-execution review, provenance, configuration and dependency signals, but incomplete for runtime-only behavior.

STATIC

Before execution

Repository ownership, manifests, install behavior, MCP configuration, declared tools and permission clues.

RUNTIME

During execution

Actual network calls, tool invocation behavior, identity use, data flow and side effects.

DRIFT

After approval

Changes to tools, dependencies, configuration, privileges or endpoints that invalidate an earlier baseline.

DECISION

Evidence, not verdict

Combine layers and preserve the limits of each measurement instead of compressing them into a false certainty score.

Read the runtime/scanner study ↗

3. Shadow MCP discovery is becoming an operational security problem

Recent vendor work shows MCP visibility moving into ordinary security operations. Cloudflare has described protocol-level detection for MCP traffic and views that separate known portal traffic from direct connections, while Microsoft's internal MCP governance work emphasizes inventory, automation and secure-by-default architecture.

The shared operational problem is straightforward: an approved catalog is not automatically an inventory of what developers and agents are actually using. Discovery therefore needs multiple evidence surfaces rather than a single registry or gateway.

ShadowMCP position

Configuration discovery can find evidence that never reaches an approved gateway. Network observation can see active traffic that static configuration misses. A mature inventory should distinguish those evidence types instead of pretending one replaces the other.

Read the Shadow MCP Discovery guide for a practical inventory model.

4. Research questions that matter for MCP security teams

  • Which scanner findings actually correlate with dangerous runtime behavior?
  • How should teams combine repository, endpoint, gateway and runtime evidence without double-counting risk?
  • Which changes to an MCP server should automatically invalidate a prior approval?
  • How can authorization be verified at the tool and resource boundary rather than only at connection time?
  • How should organizations discover unmanaged MCP use without collecting unnecessary developer data?
  • What evidence should be retained so a security decision remains explainable months later?

5. Turn research into a review workflow

For a concrete review, start with protocol and authorization guidance, then inventory the server's source and declared capabilities, verify least privilege, inspect tool schemas and untrusted outputs, and define what future drift forces re-review.

GUIDE

MCP security

Threats, trust boundaries and practical controls.

CHECKLIST

MCP server security

A deployment and approval checklist.

RESEARCH

Source hub

Primary specifications, independent research and evidence resources.

EVIDENCE

Repository scan

Inspect a public repository before executing its code.

Sources

This is an independent ShadowMCP synthesis. Papers and operational sources below are linked so readers can inspect the original evidence and its limitations.