Triaging Shadow MCP Servers by Blast Radius

A shadow MCP server is not the next iteration of shadow SaaS. It is a categorically different problem, with a blast radius bounded not by one application's features but by everything a single wired credential can reach. Triage by blast radius gives security teams a repeatable way to decide which servers demand immediate containment and which can wait for scheduled remediation.

Why Shadow MCP Servers Are a Categorically Different Risk from Ordinary Shadow IT

A shadow SaaS subscription exposes whatever that one product does. The difference is the tool-discovery handshake. An agent asks a server what it can reach, receives an inventory of capabilities, and then invokes those capabilities autonomously. A single ungoverned server becomes a traversal path across an entire environment.

OWASP MCP09:2025 names shadow MCP servers as a numbered, auditable risk category, not a configuration edge case but a predictable class of failure common enough to earn its own slot on the top-ten list. The protocol's authorization gap compounds the problem. OWASP MCP09:2025 notes that these deployments frequently rely on default credentials and permissive configurations, bypassing centralized authentication and monitoring entirely.

The absence of a procurement trail is load-bearing. It is a process on a developer's machine or a personal cloud instance. That means CASB and spend-based discovery tools see nothing. The very properties that make shadow MCP easy to spin up are what make it invisible to the tooling most security teams already own.

The Three Variables That Determine How Much Damage a Shadow MCP Server Can Actually Do

Blast radius in a shadow MCP deployment is determined by three compounding factors: credential inheritance, tool scope, and lateral reachability. Assess all three together. No single variable tells the full story.

Credential inheritance is the first variable. The server inherits whatever that developer, not the task, was ever authorized to touch. When a client requests all advertised scopes up front, a single token leakage spans files, databases, and administrative operations simultaneously.

Tool scope is the second variable. The set of capabilities a server advertises determines the action surface. OWASP MCP09:2025 identifies the impact dimensions: data exfiltration, RCE, injection, context poisoning, and supply-chain contamination through unsanctioned plugins. File-system operations and shell access rank as particularly high-scope because they give the agent a path to secondary systems the server owner may not have intended to expose.

Lateral reachability is the third variable, and it captures the downstream systems a compromised server can touch. Test environments connected to production data sources are a common failure mode flagged in the OWASP MCP09:2025 checklist. The credential says otherwise.

The three variables compound. A server with a high-privilege inherited credential, broad tool scope, and a direct path to production has the maximum blast radius. Most shadow deployments sit somewhere between those poles, so you need discovery before you can score them.

How to Find Unauthorized MCP Servers Before Scoring Them

Before a triage framework can be applied, the servers must be found. Because shadow MCP servers leave no procurement trail and require no central registration, discovery requires active network-layer scanning combined with behavioral traffic analysis. Neither alone is sufficient.

The absence that defines shadow MCP, no ticket, no purchase, no account, is also the absence that defeats spend-based and login-based discovery tools. OWASP MCP09:2025 recommends network discovery tools scanning for open MCP ports and endpoints, with ports such as 8000 and 8080 among the prime targets, alongside passive network sensors identifying MCP traffic patterns. The guidance flags a hard truth: if a security team cannot list all active MCP servers in the environment, shadow deployments already exist.

Effective discovery requires MCP-specific observability rather than general shadow-IT playbooks. Zuplo's guidance on agentic traffic monitoring notes the core challenge: producing observability metrics granular enough to distinguish MCP-generated traffic from ordinary API or human-generated calls. Qualys TotalAI approaches discovery across three layers, network, host, and supply chain, and uses graph-based relationship mapping to surface what each discovered server actually connects to, not just that it exists.

Runlayer takes a different route to the same problem, with real-time detection across MCP traffic and identity tied to every action via SSO and SCIM. OWASP MCP09:2025 recommends automated shadow MCP detection scans on a weekly cadence with alerts to the security operations team. Weekly, because shadow servers can appear and disappear faster than a monthly audit cycle catches them.

How to Score a Discovered Server: Translating the Three Blast-Radius Variables into a Triage Tier

A workable blast-radius score combines credential privilege level, tool action scope, and lateral reachability into a simple tier assignment. The goal is a repeatable decision, not a precise number. Credential privilege level is the first scoring dimension. Low means a scoped read-only token created for the specific integration, rotating on a defined schedule. Medium means a developer personal API key with access beyond the current task, or a static token with broad read/write scope. The signal to look for is the one Zuplo identifies: the server's credential scope almost always exceeds the task's actual requirement.

Tool action scope is the second dimension. Low means read-only data retrieval, with no write operations, no shell access, and no file-system traversal. Medium means write access to non-production data, or API calls that modify state in bounded systems. High means shell execution, file-system operations, write access to production systems, or the ability to invoke other agents and servers. Data retrieval without an exfiltration channel maps to Low or Medium.

Lateral reachability is the third dimension. Medium means connected to staging or internal tooling that shares credentials or network access with production. Qualys TotalAI's graph-based relationship mapping is the operational implementation of this dimension. It surfaces the actual downstream system graph, not just the server's self-reported connections.

Tier assignment follows from the three scores. Tier 1, Critical, includes any High on credential or reachability, regardless of tool scope. Tier 2, Elevated, includes Medium on at least two dimensions, and High on tool scope with Low on the other two still lands here because shell access is inherently escalatable. Tier 3, Monitored, means Low across all three dimensions. Apply the scoring at discovery, update it whenever credential or configuration changes are detected, and re-run it on a defined cadence. This is not a one-time classification.

What the GitHub MCP and Supabase/Cursor Incidents Reveal About How Blast Radius Becomes Actual Damage

Two documented incidents from 2025 show the framework working in reverse. Both servers carried high-privilege inherited credentials, broad tool scope, and a reachability path to sensitive data, the exact combination the framework flags as Tier 1. Neither attack needed a zero-day. Each simply actualized damage that was already possible the moment the server was wired up.

The GitHub MCP incident at Invariant Labs in May 2025 began with a developer connecting an AI assistant to GitHub using a single access token spanning both public and private repositories. An attacker embedded a prompt injection payload in a public GitHub issue, and the agent followed the embedded instructions to retrieve files from a private repository and post them publicly. Immediate containment would have been warranted before any prompt injection was delivered.

The Supabase and Cursor incident in mid-2025 followed the same shape. An AI agent ran with privileged service-role access while processing support tickets containing user-submitted input. Security researcher Simon Willison called the setup the lethal trifecta: access to private data, untrusted content, and an external channel for data exfiltration. The framework verdict is again Tier 1, with the lethal trifecta mapping exactly to the combination of High on credential and High on scope.

The shared pattern across both incidents is the point that matters for triage. Blast radius was established at configuration time, not at attack time. By the time an alert fires, the blast radius is already real.

Why Runtime Threats Can Upgrade a Server's Tier After Initial Scoring

A server that scores Tier 3 at discovery can become a Tier 1 threat after approval if its tool definitions are silently altered. The scoring model must treat runtime monitoring as a continuous input, not a one-time assessment. CVE-2025-54136, disclosed by Check Point Research in August 2025, is the clearest demonstration of the rug-pull mechanism. An attacker committed a benign MCP configuration to a shared code repository, waited for developer approval, and then replaced it with a malicious payload in a later commit. These are different moments with different failure modes.

Tool poisoning operates at the schema level. The server's tool manifest is the attack surface, not just the data it returns. A one-off request inspection misses this pattern of incremental overreach entirely.

The detection gap is structural. MCP connections are persistent and stateful, so a conventional WAF inspecting individual HTTP transactions cannot reconstruct the context of a multi-step agent interaction. Runlayer's real-time detection layer is built for this category of threat, with tool poisoning, prompt injection, and intent drift detection backed by tamper-proof audit logs and full OTEL tracing. The platform surfaces tier changes as they happen rather than after the fact.

What Response Each Tier Actually Warrants

Tier assignment is useful only if it drives differentiated responses. Applying the same remediation cadence to every discovered server wastes response capacity on low-risk servers while leaving Tier 1 exposure open too long. Tier 1 demands immediate containment. Run a forensic review of agent logs for the period the server was active, since a single undetected session may have executed a multi-step action chain. For high-risk systems, the EU AI Act Article 19 and Article 26(6) retention requirement of at minimum six months of immutable logs applies, and Runlayer's tamper-proof audit logs and OTEL tracing provide this out of the box.

Tier 2 warrants rapid remediation with temporary monitoring. The remediation goal is to reduce at least one scoring dimension to Low within a defined SLA. Apply least privilege to the server's tool manifest, removing or restricting tools not required for the stated task.

Tier 3 means scheduled remediation and policy enforcement. Approved secure-by-default configuration templates serve as the remediation target. OWASP MCP09:2025 recommends enforcing authentication and authorization through mTLS and OAuth, disabling unauthenticated tool calls, and preconfiguring logging and rate limits. Use their discovery to update developer onboarding documentation, run security workshops, and direct teams toward approved experimentation zones with pre-hardened templates, all of which reduces the rate of future shadow deployments.

One cross-tier principle applies regardless of tier. Intent-aware or attribute-based authorization is the necessary next layer. Runlayer operationalizes this requirement with SSO, SCIM, and JIT credentials tying identity to every action, policies enforced at tool-call depth, and a centralized MCP registry with single-pane oversight that makes the registry-first remediation model for Tier 2 and Tier 3 achievable without rebuilding auth plumbing per team.

Turning the Framework into a Repeatable Process

Shadow MCP triage is not a cleanup project. It is a governance discipline, because new shadow servers appear at developer speed and the blast-radius profile of existing servers changes as credentials rotate, tools are added, and systems are connected. Qualys TotalAI's analysis frames MCP as a protocol whose adoption moved faster than most organizations' governance frameworks, with over 10,000 active public servers within a year of release, and enterprise environments absorbed that curve invisibly.

A centralized MCP registry is the foundation. Run weekly automated shadow MCP detection scans with SOC alerts. Re-evaluate tiers whenever credential changes, tool-manifest updates, or network topology changes occur, not just on a fixed calendar.

Regulatory pressure makes this process mandatory. NIST's AI Agent Standards Initiative, launched February 17, 2026, and its companion NCCoE concept paper frame the gap directly: agents are commonly treated as generic service accounts without dedicated identity, authorization, or accountability controls. The EU AI Act's high-risk provisions, in force December 2, 2027, after the Digital Omnibus on AI under Regulation (EU) 2026/1744 deferred the original August 2, 2026 date, require human oversight, auditability, and conformity assessment for agents taking consequential actions, with at least six months of immutable log retention.

The governance loop also changes the security team's role. Zuplo and OWASP MCP09:2025 both emphasize that developer education and approved experimentation zones reduce the rate of future shadow deployments. The enablement layer gives developers a golden path to agent setup with more than 18,000 MCP servers, built-in OAuth and credential handling, and chat-platform-based agent instantiation, reducing the incentive to spin up a shadow server. The control layer enforces the registry, policies at tool-call depth, and identity on every action. The easy path and the compliant path converge, which is the only durable way to shrink shadow MCP from a crisis into a manageable, continuously scored surface.