Enumerating Exposed MCP Gateway Endpoints in Enterprise Networks

MCP gateways are credential aggregators. A single interface connects an agent to dozens of downstream enterprise systems, and each has its own credentials, permissions, and data. That makes a gateway endpoint a different kind of target from an ordinary API: what an attacker learns by enumerating one is not one system's surface, but the combined surface of every system behind it.

The CSA Agentic MCP Security Best Practices Guide identifies three independent trust boundaries in every MCP deployment: LLM-to-client, client-to-server, and server-to-downstream systems. Each boundary can be exploited on its own. Each leaks information during enumeration. A traditional API has one boundary worth probing. An MCP deployment has three, and they do not all sit behind the same controls.

The protocol itself makes enumeration easy. By specification, an MCP server advertises its tool schemas, resource paths, and capability descriptions to any connecting client. Reconnaissance that would take weeks against a bespoke API is answered in a single handshake. The server is designed to tell you what it can do, which downstream systems it touches, and what parameters it expects.

Perimeter controls offer little help. Agents authenticating directly to MCP servers can bypass the normal WAF or API gateway entirely. The server's own exposure becomes the only line of defense. Platforms like Runlayer that sit between agents and MCP servers can enforce authentication and policy at this trust boundary, requiring verified credentials and identity verification before any tool discovery occurs, turning what is structurally an open reconnaissance surface into a gated one.

How the current deployment landscape creates an unusually wide passive attack surface

The problem is not hypothetical, and it is not small. Large numbers of unauthenticated, internet-reachable MCP servers already exist. An attacker can begin passive enumeration against a wide target set before touching a single enterprise network. The attack surface grew faster than the controls around it.

Shadow MCP deployments mirror classical shadow IT. A developer stands up a server to unblock a demo. A team wires an agent to a convenient endpoint. No one registers or verifies the server. The result is discoverable infrastructure that appears in no internal inventory. It is real, it is live, and the security team has never seen it. Enterprises that lack visibility into this footprint cannot apply consistent governance. An MCP control plane designed for shadow-AI discovery surfaces these unaccounted-for servers and brings them under policy enforcement before they become reconnaissance targets.

The CSA guide cites an Astrix Security research report that found a significant proportion of publicly accessible MCP servers exposed sensitive credentials, lacked transport security, or contained exploitable input validation flaws. These are not esoteric misconfigurations. They are the default state of a technology that spread through developer convenience rather than security review.

Passive discovery: what an attacker learns before sending a single probe

Before touching an enterprise network, an attacker can build a meaningful picture of its MCP footprint from public sources alone. Tool registries, certificate transparency logs, DNS records, and code repositories all contribute. None of this requires interaction with the target.

Public MCP registries are a primary passive source. The CSA guide notes that OX Security analyzed 11 public MCP registries and found 9 compromisable, meaning they accepted a benign proof-of-concept submission without any security review. Malicious packages could be distributed through these registries. The same registries an attacker would browse to map a target's tool stack are themselves partially controlled by adversaries.

Developer repositories are another rich source. GitHub and npm frequently contain hardcoded MCP server addresses, OAuth client IDs, and tool configuration files committed alongside agent code. Passive enumeration of an organization's repos can reveal internal MCP topology without any network interaction. The Lyzr MCP Security guide describes how a developer can stand up an MCP server against a production database in an afternoon. The configuration artifacts from that setup (server URLs, port assignments, tool schemas) often land in shared wikis, Slack logs, or public ticket trackers.

Tunnel services add another vector. When developers use ngrok or Cloudflare Tunnel during development, they create resolvable subdomains that can be re-registered after the session ends. An attacker who finds an old subdomain may get a live replacement server at the same address. The CSA guide identifies this as tunnel subdomain hijacking. Security teams that monitor what is discoverable in the open (tool schemas, server addresses, credential patterns in code) can close the reconnaissance window before active probing begins. Runlayer's audit and observability layer provides the visibility needed to spot when internal MCP infrastructure is leaking into public surfaces.

Active probing: using the MCP protocol's own discovery mechanisms against a target

Once an attacker decides to probe actively, the MCP protocol itself becomes the scanning tool. The server is designed to advertise its capabilities on connection, so a standard handshake extracts tool schemas, resource paths, internal system names, and credential hints from any server that responds. No exploit is required.

MCP uses JSON-RPC 2.0 as its transport layer. A scanner that sends a well-formed tools/list or resources/list request to a candidate port receives a structured response enumerating every tool the server exposes. The response includes parameter names and descriptions that reveal which downstream systems the server connects to. The protocol is self-describing by design, which is what makes it useful, and what makes it vulnerable.

The search space is predictable. Common default ports and path conventions such as /mcp, /sse, and /api/mcp reduce the scanning effort. Many servers are deployed from the same SDK reference implementations, so port and path fingerprints repeat across organizations. A scanner that finds one MCP server typically knows how to find many more.

Authentication rarely interferes. The CSA guide documents that the November 2025 specification formalized OAuth 2.1 for remote servers, but also notes that only a small fraction of implementations actually use OAuth. Most servers that respond to a probe do so without requiring authentication, handing over their full tool catalog to any requester. The tool descriptions themselves are reconnaissance payloads. A schema that names internal hostnames, database table structures, or API key parameter formats tells an attacker exactly what systems sit behind the server and how they expect to be called. The Lyzr guide's Microsoft Defender research scenario illustrates this: a finance team's agent connected to a third-party invoice enrichment tool that had passed approval. Active probing of that server's tool list would have revealed its access to unpaid invoice records before any weaponization.

What enumeration reveals: the credential and permission blast radius behind a found endpoint

A successfully enumerated MCP endpoint does not reveal just one system. It exposes the credential and permission surface of every downstream system the server aggregates, often without the server's operators knowing what that surface looks like. Enumeration alone, without any follow-on exploit, is a serious security event.

The Amazon Q VS Code extension flaw, disclosed by Wiz Research in June 2026, shows the blast radius in concrete terms. A malicious repository achieved arbitrary code execution and cloud credential theft through a crafted workspace MCP configuration file. The spawned MCP server processes inherited the full developer environment, giving immediate access to cloud infrastructure. One enumerated configuration file connected code execution, credential theft, and cloud access in a single incident.

Server-side request forgery compounds the problem. The CSA guide cites analysis finding a meaningful share of MCP servers vulnerable to SSRF. In one disclosed case, an attacker queried a cloud provider's metadata service through an MCP tool and retrieved live IAM credentials from a production system. The tool's normal function became the attack path.

Multi-agent deployments multiply the blast radius further. If an orchestration agent holds API keys for multiple downstream agents, enumerating the orchestration layer grants an attacker visibility into all of them at once. The credential aggregation that makes MCP gateways useful is exactly what makes enumeration so damaging.

How tool poisoning and rug pulls turn an enumerated endpoint into an active weapon

Enumeration gives the attacker a map. Tool poisoning turns that map into a weapon. MCP picks up tool description changes on the fly. A server does not need to restart or notify clients when a description changes. An attacker who has write access to a server, or who has substituted a malicious server at an enumerated address, can push a poisoned description that agents consume on their next invocation. No further network access is required.

The attack is designed to be invisible. The visible tool name and summary remain unchanged. The malicious instruction is buried in the description field, where a human reviewer scanning a tool catalog would not notice it. The Lyzr guide's walkthrough of the Microsoft Defender research scenario documents this structure precisely.

Cross-server shadowing makes it worse. The CSA guide documents this vector: because all MCP server tool descriptions are loaded into the same LLM context window, a malicious server can use its descriptions to override or interfere with the instructions of legitimate servers. The LLM cannot reliably distinguish instruction priority across servers. One poisoned description in a shared context can redefine the agent's understanding of every tool it uses.

The postmark-mcp case illustrates the operational subtlety. Rather than a loud exploit, the package quietly added a hidden recipient to every email an AI agent sent through the server. Copies of internal communications flowed to an attacker. Enumeration identified the server. Poisoning made it an ongoing exfiltration channel. The CSA guide also documents rug-pull timing: even a server that passes an initial security review can be updated after approval to introduce malicious behavior. Without a re-approval trigger on description changes, the poisoned version goes live with no review.

Why detection fails: the audit and telemetry gaps that make enumeration nearly invisible

Enumeration and its follow-on exploits go undetected in most enterprise environments because MCP deployments generate fragmented or no telemetry. Security teams have no baseline of what normal agent behavior looks like. The signals exist. The infrastructure to collect them does not.

The CSA guide identifies Lack of Audit and Telemetry (OWASP MCP08) as a first-class risk. Without comprehensive logs of tool invocations, context changes, and user-agent interactions, security teams cannot determine what an agent did, when it did it, or whether a prompt injection ever fired. A small minority of organizations can reliably trace agent actions back to a human sponsor across all environments. An even smaller share maintains a real-time inventory of active agents. The majority of enterprises deploying autonomous AI cannot tell in real time what those agents are doing or which MCP servers they are calling.

The detection window makes this gap especially dangerous. An agent operating with valid credentials can traverse multiple systems in seconds. A delayed or absent telemetry posture is not a gap but a chasm. The problem is also bigger than most teams realize. The CSA guide cites Tanium endpoint data showing almost 400 distinct named MCP servers appearing consistently across millions of enterprise endpoints. That footprint is far larger than most security teams have inventoried. Enumeration by an attacker often precedes the defender's own discovery of the same servers.

Token passthrough is a structural telemetry failure as well as an auth failure. When upstream tokens are forwarded to downstream tool calls rather than replaced with audience-bound tokens via OAuth 2.0 token exchange per RFC 8693, a credential issued for one audience reaches systems it was never meant to touch. No authorization event is generated that a SIEM would flag. The data flows, and the logs are silent.

Closing the enumeration gap: inventory, authentication, and runtime controls that work together

Stopping MCP enumeration and its downstream exploits requires three controls working in concert. Authoritative server inventory comes first. Identity-bound authentication on every tool call comes second. Real-time behavioral detection comes third. Any one of them alone leaves the other two gaps open.

The CSA guide recommends treating MCP as critical infrastructure, applying the same rigor an enterprise would apply to an API gateway or identity provider. That begins with a registry that captures every server, its owner, its approved tool list, and its downstream access scope before agents are permitted to connect. A registry that requires approval workflows and version-controlled tool descriptions closes the rug-pull vector: description changes trigger re-review before the updated version reaches production agents. The Lyzr guide adds that an MCP registry must connect to a broader AI control plane governing agents, identities, and runtime activity together. A standalone registry that does not enforce controls at the tool-call level stops short of the problem.

Authentication closes the identity gap. SSO and SCIM-backed identity tied to every tool call means enumeration events generate an identity-linked audit record. JIT credential issuance limits what a discovered server can return even if it is reached. Replacing token passthrough with proper OAuth 2.0 token exchange per RFC 8693 ensures that credentials scoped for one system cannot reach another. That collapses the multi-system blast radius that makes MCP enumeration so valuable to attackers.

Runtime controls close the detection gap. Tamper-proof audit logs and full OTEL tracing make enumeration events and follow-on tool invocations visible after the fact, enabling incident response even when attacks are not caught in real time. Circuit breakers at the gateway level address the runaway-agent failure mode documented in the CSA guide, where agent loops hammer paid APIs or write garbage into production databases because no policy enforced at tool-call depth was in place to stop them.

Runlayer addresses all three layers on one platform. A registry covering thousands of MCP servers provides the inventory. Built-in OAuth and credential handling, with SSO, SCIM, and JIT identity tied to every action, provides the authentication. Real-time detection for MCP-specific threats including tool poisoning, prompt injection, and intent drift, backed by tamper-proof audit logs and full OTEL tracing, provides the runtime control. It is the architecture the CSA guide recommends, delivered as a foundation rather than a set of bolted-on protections. The enumeration gap exists. Closing it is a matter of treating MCP infrastructure with the seriousness its blast radius demands.