Today, CyCognito announces the ability to discover externally reachable Model Context Protocol (MCP) servers across the external attack surface and bring them into external asset inventory and external exposure management workflows.
With this release, teams can:
- Identify externally reachable MCP servers
- Bring MCP servers into the external asset inventory
- Understand exposure context, including how each server is reachable
We’re introducing this capability because externally reachable MCP servers represent a distinct class of external exposure. As AI systems move from experimentation into production, these servers are showing up in more environments, but often outside standard external visibility.
How MCP Fits Into External Exposure Management
The ISG State of Enterprise AI Adoption report found that about 1 in 3 AI initiatives are now in production, indicating a shift from pilot to operational use. MCP servers are part of the integration layer that makes this shift possible, brokering access to capabilities such as data sources, services, and execution paths.
From an attack surface management perspective, an externally reachable MCP server is a callable surface. Its risk profile is defined by:
- Which tools are exposed
- How those tools are invoked
- Which systems they can act on
- How access controls behave in practice
Importantly, that surface is highly dynamic. It can change through configuration updates, new tools, auxiliary components, or shifts in how agents interact with the server, sometimes outside standard deployment and review processes.
This is why MCP servers require the same scrutiny as any other externally reachable service that can execute actions or reach sensitive systems when access controls fail.
Where MCP Security Breaks Down
Capability discovery becomes an action map
Many MCP servers support introspection flows that allow callers to enumerate available tools and their schemas. Depending on deployment, these flows may be exposed through JSON-RPC methods or HTTP endpoints that return tool metadata.
Introspection becomes a risk when it is externally reachable and not tightly gated. In that case, tool names, descriptions, and argument schemas can reveal privileged operations, internal integrations, and trust assumptions. This reduces attacker guesswork and enables targeted abuse, particularly when callable tools expose file systems, internal APIs, or administrative functions.
The risk is not introspection itself. It is introspection combined with external reachability and callable capabilities that are insufficiently constrained.
“Auth exists” is not the same as “auth is enforced”
A recurring MCP failure mode is inconsistent authentication enforcement. An MCP server may require authentication for some tools but not others, apply different policies across components, or depend on auxiliary proxy or inspector tooling that accepts unauthenticated requests.
This is not theoretical. CVE-2025-49596 (MCP Inspector) describes remote code execution caused by missing authentication between the Inspector client and proxy in affected versions.
In practice, these gaps create externally reachable execution paths that are easy to overlook during review but straightforward to abuse once identified.
Tool execution increases blast radius
MCP servers frequently broker access to high-impact operations, including shell commands, file systems, internal APIs, and cloud control-plane actions. When these tools are externally reachable, exposure shifts from data access to direct action.
CVE-2025-6514 (mcp-remote) illustrates this risk, involving OS command injection when connecting to untrusted MCP servers.
Because MCP servers act as intermediaries, a single exposed server can become a gateway to multiple downstream systems.
Agent-driven invocation complicates detection
Requests to MCP servers often originate from AI agents rather than human users. Tool calls can resemble normal automation, arguments may be constructed dynamically, and intent is harder to infer from logs alone.
This makes misuse more difficult to distinguish from expected behavior, particularly when agents operate across multiple applications or workflows.
Implementation quality varies widely
A cross-cutting issue is that MCP servers and related tooling vary significantly in authentication enforcement, secret handling, tool isolation, and input validation. That variation is a common driver of the failure modes above, and it often results in uneven security posture across environments, even when teams believe their MCP deployments are consistent.
Operationalizing MCP Discovery
External exposure issues are rarely caused by a single missed control. They are usually the result of assets that teams did not realize were reachable at all. In a global survey of IT and security decision-makers, only 49% said they have complete visibility into organization-owned assets.
MCP servers and other AI-related integration services are not exempt from this visibility gap. When deployed quickly to support production workflows, they often fall outside asset inventories and monitoring, even though they are reachable and capable of acting on real systems.
By discovering externally reachable MCP servers, CyCognito brings this emerging class of AI-related infrastructure into the same inventory and workflows used for other externally reachable services. MCP reachability becomes visible, reviewable, and monitorable over time, so drift and unplanned exposure do not sit outside normal external exposure management processes.
This echoes a simple core principle: if something is externally reachable, it should not be invisible.
What’s Next
As organizations adopt AI systems, they also adopt the integration layers that make those systems usable in production. Those layers are increasingly externally accessible, and they do not always map cleanly to existing asset categories or monitoring systems.
MCP server discovery is one of several AI-related discovery capabilities CyCognito is building to close that gap.
Next, we plan to expand visibility into AI-related services, add richer exposure context, and bring those findings into the same prioritization and remediation workflows used across the external attack surface. We are also exploring AI-specific testing and risk assessment approaches for these assets, beyond the standard checks applied to all asset types.
