TL;DR: MCP servers often appear outside normal inventory paths, and Impart argues that surface mapping must become an ongoing operational control because discovery, manifesting, and ownership are prerequisites for authorization, drift detection, and runtime enforcement. That shifts MCP governance from one-time audit thinking to continuous identity and access control for tool exposure.
At a glance
What this is: This article argues that MCP surface mapping has become a standing governance requirement because security teams cannot enforce authorization, detect drift, or apply runtime controls until they know what servers, tools, and owners exist.
Why it matters: IAM, IGA, PAM, and SecOps teams need a reliable view of MCP exposure because unmanaged tool surfaces create hidden access paths for agents, developers, and production data.
Context
Model Context Protocol server discovery is not a solved inventory problem. The governance gap is that MCP servers can be created by developers, embedded in frameworks, or launched outside standard deployment paths, which means security teams may be unable to see tool exposure before agents begin using it.
For identity and access teams, the issue is not just visibility. If a server cannot be tied to an owner, authorization scope, and data classification, then policy enforcement, behavioral baselining, and drift detection all start from an unreliable control point.
In practice, this makes surface mapping a continuous operational requirement rather than a periodic review. The article frames that requirement around MCP because exposure can change faster than traditional asset catalogues update.
Key questions
Q: What breaks when MCP servers are deployed outside normal inventory paths?
A: When MCP servers bypass normal inventory paths, security teams lose the ability to prove what tools exist, who owns them, and which agents can call them. That breaks authorization, drift detection, and runtime enforcement because those controls depend on a trusted catalog before they can operate effectively.
Q: Why does MCP surface mapping change the way teams prioritize risk?
A: Surface mapping separates a harmless-looking endpoint from a server that can reach production systems or sensitive data. Once ownership, exposure, and data classification are known, teams can focus enforcement on the MCP assets that create the largest identity blast radius rather than treating every server equally.
Q: What are the signs that an MCP catalog is already out of date?
A: The usual signs are tool additions, schema changes, description edits, and servers that appear in runtime traffic but not in the approved inventory. If agents are calling a live server that is absent from the baseline or if manifests have no timestamps, the catalog is already stale.
Q: How should teams govern MCP servers once they are discovered?
A: Classify recurring MCP servers as managed access objects, not personal tooling. Put approved servers behind a shared control point, assign ownership, restrict who can use them, and remove direct local registrations that cannot be reviewed or logged. That approach keeps productivity while restoring observable access governance.
Technical breakdown
Why MCP discovery needs layered signals
MCP environments are difficult to inventory because no native registry exists and deployment is often developer-led. Network scanning finds endpoints, but not exposed tools or authorization scope. Agent instrumentation reveals what agents actually call, but it misses untouched servers. CI/CD inspection catches declared deployments, while infrastructure-as-code analysis misses runtime drift and anything deployed outside the pipeline. A usable map therefore combines multiple signals into one operational view of what is actually running.
Practical implication: combine network, agent, pipeline, and IaC telemetry before treating an MCP server as governed.
Why manifests matter more than simple inventories
An inventory says a server exists. A manifest says what the server does. That distinction matters because schema enforcement, behavioral baselining, and access policy all depend on intended function, not just presence. For MCP, the manifest should capture exposed tools, argument schemas, resource and prompt data classification, transport and authentication configuration, consuming agents, authorization scope, and ownership. Without that baseline, security teams cannot tell whether a tool is acting within its approved role.
Practical implication: record function, scope, and ownership at registration, not just asset presence.
How catalog drift turns approved tooling into a governance problem
Catalog drift occurs when tool descriptions, schemas, or behavior change after approval. In MCP, that creates a trust problem because an agent may continue calling a cached definition while the live server has changed. The article calls the resulting attack pattern a rugpull, where a legitimate tool mutates without a redeployment event that security would normally notice. Versioned manifests and timestamped snapshots are therefore central to investigating what the server advertised at a specific point in time.
Practical implication: version every manifest change and compare runtime behaviour against the approved catalog.
Threat narrative
Attacker objective: The objective is to expand or disguise MCP access so tools and data exposure remain active without reliable inventory, ownership, or policy control.
- Entry occurs when a new or existing MCP server appears outside the normal inventory path, often through developer-led deployment, embedded frameworks, or ephemeral runtime creation.
- Credential or access exposure follows when the server gives an AI agent access to a database, internal API, or production system without a complete governance record.
- Escalation happens when catalog drift or a rugpull changes exposed tools, schemas, or semantics after approval while agents keep using the cached definition.
- Impact is the expansion of unknown attack surface area, hidden data access, and runtime enforcement gaps that can let unauthorized tooling persist undetected.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Surface mapping is the control plane for MCP governance. MCP servers do not self-register, and that breaks the assumption that security teams can govern exposure from an asset list alone. Discovery, manifesting, and ownership are not administrative extras here; they are the minimum conditions for authorization and runtime enforcement. The practitioner conclusion is straightforward: if the server surface is unknown, every downstream control is already operating on partial truth.
Catalog drift is the governance failure mode MCP introduces. A server can look approved while its tools, schemas, or descriptions have changed in place. That makes the approved catalog a versioned contract, not a static record, and it shifts audit thinking toward continuous comparison of live behavior versus baseline. Practitioners should treat post-approval change as a control event, not a housekeeping update.
Unknown MCP exposure creates identity blast radius. Once a server can reach a database, internal API, or production system, its owner and data classification determine how far the resulting risk spreads. This is a governance problem across NHI, agent access, and production authorization because the same hidden surface can amplify every connected identity path. The practitioner conclusion is to reduce blast radius by governing the surface before agents depend on it.
Ephemeral and embedded servers expose a coverage gap in traditional discovery. Network scans, pipeline checks, and IaC reviews each miss a different class of MCP server. That means the control assumption of a complete inventory is structurally false unless multiple discovery layers are reconciled. The practitioner conclusion is that coverage, not just policy, is now part of MCP governance maturity.
Unowned tool exposure: MCP servers without a named owner and classification are not merely incomplete records; they are governance blind spots. Ownership assigns accountability for approval, drift response, and access scope, while classification determines prioritization. The practitioner conclusion is to treat every unowned server as unresolved risk, not just undocumented infrastructure.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
MCP surface mapping is becoming an access governance requirement, not an inventory exercise. Security teams cannot enforce authorization or detect drift against servers they have never identified, so discovery quality now shapes the quality of every downstream control. That is why surface mapping belongs in the same operational conversation as identity governance, runtime policy, and tool approval.
Ephemeral and embedded servers are the hardest class to govern. They often bypass the deployment paths that traditional control owners rely on, which means governance has to reconcile multiple discovery sources rather than trust any single one. For practitioners, the practical shift is from asking whether a server was approved to asking whether it can still be seen.
24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026. That figure shows why MCP governance cannot stop at discovery and manifests; exposed configuration material can turn surface visibility into immediate credential exposure.
For practitioners
- Establish layered discovery for MCP surfaces Correlate network telemetry, agent activity, CI/CD deployment records, and infrastructure-as-code to identify servers that are present but not governed.
- Require a manifest for every MCP server Capture exposed tools, argument schemas, data classification, authentication method, consuming agents, authorization scope, and named ownership at registration.
- Version the approved tool catalog Snapshot the full manifest at registration and on every change so schema edits, description changes, and tool additions are auditable.
- Prioritise externally exposed and data-rich servers Assign faster review and tighter enforcement to servers with broad permissions, sensitive data access, or production system reach.
- Detect and investigate rugpull-style drift Compare live tool behaviour against the approved manifest to catch semantic changes that agents may not notice because they still trust cached definitions.
Key takeaways
- MCP governance fails when security teams cannot see every server, tool, and owner that can reach data or production systems.
- The central control gap is catalogue drift, where approved tool definitions change after review and agents continue trusting stale state.
- Layered discovery, versioned manifests, and ownership assignment are the controls that turn MCP surface mapping into enforceable governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Embedded and developer-led MCP servers create unmanaged non-human identities and dependency risk. |
| NHI-05 — Overprivileged NHI | The article focuses on servers that can reach databases, APIs, and production systems with unclear scope. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Ephemeral, localhost-bound, and out-of-pipeline deployments create governance gaps at the deployment layer. | |
| Recommendation — Inventory embedded and third-party MCP surfaces before allowing them to carry production access. Constrain MCP server permissions to the minimum tools and data paths they actually need. Scan MCP deployments for paths that bypass normal cloud and pipeline controls. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agents calling MCP tools depend on accurate identity and scope to avoid privilege abuse through stale catalogs. |
| Recommendation — Tie agent tool access to current authorization scope and revalidate it when the catalog changes. | ||
| MITRE ATT&CK | TA0007;TA0008 — Discovery; Lateral Movement | Surface mapping addresses hidden assets and the movement paths they open into internal systems. |
| Recommendation — Map discovered MCP servers to discovery and lateral movement tactics to prioritise monitoring. | ||
Key terms
- MCP Surface Mapping: MCP Surface Mapping is the process of identifying every place an AI agent can connect to tools, data, and actions through Model Context Protocol interfaces. It catalogs exposed servers, methods, permissions, and data paths so security teams can understand attack surface, trust boundaries, and governance scope for agentic systems.
- MCP Manifest: An MCP Manifest is the configuration file that describes an MCP server, its capabilities, and how clients can connect to it. In practice, it lists tool endpoints, resources, prompts, authentication details, and metadata so an AI agent can discover and use external functions in a controlled way.
- Catalog Drift: Catalog drift is the gap between what the governance catalog says exists and what the live environment actually contains. It appears when synchronization is too slow, ownership changes are not captured, or manual processes cannot keep pace with platform growth and schema change.
- Rugpull: A change in an MCP tool’s advertised behaviour after approval while agents continue using a cached definition. The server appears familiar, but its semantics have shifted, which means the identity and access decision made at approval time no longer matches the live system.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org