Model Context Protocol (MCP) servers don't register themselves. Surface mapping is an ongoing operational requirement, not simply a one-time audit. Before security teams can write rules, enforce authorization policy, or establish behavioral baselines, they need to know what's present and running in their environments. The reality is: that's harder than it sounds.
Here's how security teams build the inventory, manifest, and ownership model that makes enforcement possible.
Why No Single Discovery Method Covers the Full MCP Server Surface
MCP doesn't have a native server registry, and deployment is typically developer-led. A dev team spins up a server that gives an AI agent access to a database, an internal API, or a production system; security only learns about it later. Or not at all.
As a result, inventory debt and risk accumulate.
Surface mapping provides the antidote. It requires a layered approach that encompasses:
- Network scanning: covers broad surface area but is semantically shallow. It maps endpoints, but doesn't reveal what tools are exposed or what data they can access.
- Agent instrumentation: provides depth on what systems and data agents are actively calling, but misses servers agents haven't yet touched.
- CI/CD pipeline inspection: catches servers at deployment, but is blind to anything deployed outside the pipeline.
- Infrastructure-as-code analysis: accurate for declared infrastructure, but invisible to runtime drift.
The goal of mapping is to identify unknown attack surface area so that SecOps teams can determine how to properly manage and minimize the risk. It gives teams the tools to know when a new server appears, and whether it was registered deliberately or spun up by a developer on a Friday afternoon.
In practice, network traffic is the most reliable signal for identifying new assets. Shadow/experimental servers and forgotten staging environments tend to surface the first time an agent calls them.
But here's the catch. If runtime enforcement sits in-path, the assets appear in the catalog. If it doesn't, operators are bound to miss crucial elements that leave them blind to risk.
MCP Server Manifest: Capturing Function, Authorization Scope, and Ownership
Most organizations begin MCP governance by cataloging MCP servers, connected agents, and exposed endpoints to understand what exists in the environment. Doing so creates visibility, but not operational context.
If the result of the inventory is a list of MCPs on endpoints, what's recorded is presence. That's not enough. What's needed is an understanding of function.
A manifest records function.
The distinction matters because controls like schema enforcement, drift detection, and behavioral baselining all depend on understanding intended behavior. Security teams need more than a record of exposed tools. They need a baseline for:
- How those tools are supposed to operate
- Who can access them
- What data they expose
For each MCP server, the manifest should capture:
- Exposed tools and argument schemas
- Resources and prompts, with data classification
- Transport methods and authentication configuration
- Consuming agents and authorization scope
- Ownership and accountability
MCP Catalog Versioning: Detecting Drift and Rugpull Attacks
A manifest snapshot is only useful against a baseline. Tool additions, schema modifications, and description changes after initial review aren't routine configuration updates. They change the operational behavior and trust model of the server itself. Catalog drift is how a legitimate MCP server becomes a malicious one without a redeployment or an obvious indicator of compromise.
The specific attack pattern is called a "rugpull." A tool's description or behavior alters quietly after approval while agents continue calling it based on a cached definition. The agent sees nothing different; the semantics of the interaction may have changed entirely.
Treating the tool catalog as a versioned contract is the defensible response. Snapshot the full manifest at registration and on every detected change. Timestamps matter. Incident investigation often depends on reconstructing what a server was advertising at a specific point in time, not just what it exposes now.
MCP Discovery Blind Spots: Ephemeral, Embedded, and Localhost Servers
Standard discovery methods also have predictable blind spots, many of which become more common as MCP adoption matures across engineering environments:
- Ephemeral servers spun up per-session, absent from persistent network scans and rarely reflected in IaC
- Localhost-bound invocations that never traverse network paths visible to scanning tools
- MCP servers embedded in third-party agent frameworks as transitive dependencies, not first-party deployments
- Development and staging servers carrying production data access despite lower-priority environment classifications
The third category is especially easy to miss. When an agent framework ships with an MCP server bundled as a dependency, that server inherits the access the organization already granted to the framework. And because no human intentionally deployed it, it may never appear in any inventory.
That's precisely what a manifest addresses. Without a baseline for expected tools, schemas, and authorization scope, teams may catch obvious risks but will struggle to identify unauthorized tooling changes or privilege expansion over time. The manifest ensures governance remains grounded in actual behavior rather than assumptions.
MCP Risk Prioritization: Assigning Ownership and Data Classification
An MCP inventory without ownership and classification is a basic list of infrastructure. With them, it is a governance model. Every server needs two attributes:
- A clear owner
- Data classification tied to what its tools can actually access
These determine prioritization. External exposure, broad tool permissions, and sensitive data access define the highest-priority tier. A localhost-bound server owned by a known team with read-only access to non-sensitive data sits lower. The same server with write access to a customer database doesn't.
Prioritization determines where security teams enforce first. Not everything can be protected with equal rigor on day one; ownership and classification are what make that call deliberate and strategic rather than a fire fight.
MCP Surface Mapping as the Foundation for Runtime Enforcement
MCP servers are direct conduits to databases, internal APIs, and production systems, and they are being deployed faster than security teams can track them. That gap does not close on its own.
Surface mapping is how security teams close it, but only when it operates as an ongoing operational requirement that ties discovery, inventory, and manifest into a single control plane. Authorization policy, behavioral baselining, drift detection, and runtime enforcement all depend on that catalog. Without it, none of those controls hold.