MCP surface mapping is now a governance requirement for security teams

At a glance

What this is: Impart argues that MCP surface mapping is an ongoing governance requirement because discovery alone is not enough without manifests, ownership, and versioned baselines.

Why it matters: IAM, NHI, and security teams need this because MCP servers extend access into databases, APIs, and production systems, and unmanaged exposure creates invisible privilege expansion and control drift.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Impart's MCP surface mapping guidance for security teams

Context

Model Context Protocol, or MCP, gives AI agents structured access to tools and data sources, but the servers that expose those tools do not automatically appear in identity or security inventories. That leaves a governance gap for MCP server security, because teams cannot enforce authorization, scope tool permissions, or assess data exposure until they know what is running.

The article’s core point is that discovery, manifesting, and ownership are not separate tasks. They are the minimum operating model for controlling MCP server access, especially when servers are developer-led, ephemeral, embedded in frameworks, or hidden from conventional scanning and pipeline controls.

Key questions

Q: How should security teams discover hidden MCP servers in enterprise environments?

A: Use multiple discovery layers, not a single inventory source. Network scanning gives breadth, agent instrumentation gives runtime depth, CI/CD inspection catches pipeline-deployed servers, and infrastructure-as-code analysis catches declared assets. Combine them so you can reconcile what should exist with what actually runs, including ephemeral and embedded servers.

Q: Why do MCP tools create a governance problem for IAM teams?

A: MCP turns each tool into a potential permission boundary, which means IAM teams must govern many small access decisions instead of one broad application login. If those boundaries are not scoped carefully, autonomous agents can accumulate effective privilege faster than traditional reviews can catch.

Q: What breaks when an MCP manifest is missing or incomplete?

A: You lose the ability to baseline intended behaviour, detect drift, and prove who owns the server. Without function, schema, authentication, and data classification, an MCP deployment is just an endpoint list, and endpoint lists do not support reliable authorization governance or incident reconstruction.

Q: Who is accountable when a malicious MCP server exposes enterprise data or actions?

A: Accountability sits with the organisation operating the agent, the team approving the server, and the owners of the connected systems. The important governance question is whether provenance checks, runtime policy, and audit logging were in place before the server was trusted. If they were not, the failure is shared and preventable.

Technical breakdown

Why network scanning alone misses the MCP server surface

Network scanning provides breadth, but it is semantically shallow. It can show that an endpoint exists, yet it cannot tell you which tools are exposed, what arguments they accept, or what data those tools can reach. MCP surface mapping therefore needs multiple discovery layers, including agent instrumentation, CI/CD inspection, and infrastructure-as-code analysis. Each layer closes one blind spot, but none is complete on its own. The security issue is not just finding servers. It is identifying the tool surface that an agent can actually exercise.

Practical implication: build discovery around network traffic, runtime calls, and deployment pipelines, not around a single inventory source.

Why an MCP manifest must capture function, scope, and ownership

A server list records presence, but a manifest records intended behaviour. For MCP, that means exposed tools, schemas, transport, authentication, connected agents, authorization scope, ownership, and data classification. Without those fields, security teams cannot distinguish a harmless internal helper from a server that can reach sensitive systems. The manifest becomes the baseline for schema enforcement, drift detection, and behavioural baselining. In identity terms, it is the control record that turns an exposed service into a governable non-human identity surface.

Practical implication: require a manifest at registration and treat missing ownership or scope as an operational defect, not an admin detail.

How rugpull drift turns approved MCP tools into a governance problem

Catalog drift matters because the trust model changes when a tool description, schema, or capability changes after approval. A 'rugpull' occurs when a server continues to be called using a cached definition while its semantics have altered underneath the agent. That creates a mismatch between the approved identity surface and the actual runtime behaviour. Versioned manifests and timestamped snapshots are therefore essential, because incident reconstruction depends on knowing what the server advertised at a specific point in time, not only what it exposes now.

Practical implication: snapshot the full manifest on registration and on every detected change, then compare the live tool catalog against that baseline.

Threat narrative

Attacker objective: The attacker objective is to exploit unmanaged MCP exposure to reach systems and data through trusted tool paths that security teams never formally governed.

1. Entry occurs when a developer-led MCP server appears outside normal inventory paths, often through ephemeral deployment, localhost binding, or bundled third-party frameworks. Credential exposure and tool reach are then inherited by the agent or workload that can call it. Escalation follows when exposed tools provide access to databases, internal APIs, or production systems with no meaningful scope control. Impact is reached when hidden or drifting servers expand the accessible attack surface without being registered, reviewed, or revoked.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP surface mapping is now a control prerequisite, not a documentation task. Security teams cannot govern what they cannot enumerate, and MCP server sprawl makes that a live access problem rather than an asset-management issue. A server that can call internal APIs or databases is part of the identity plane as soon as it can execute tool actions. The practitioner conclusion is simple: surface visibility is the first access control.

Inventory debt becomes identity debt as soon as tool permissions are uncatalogued. An MCP server without a manifest is not just undocumented, it is unscoped. That is why ownership, tool schema, authentication method, and data classification have to sit in the same record. The practical conclusion is that the security team needs a governable control object, not a spreadsheet of endpoints.

Runtime enforcement cannot compensate for missing discovery. If the server is unknown, any policy layered above it is partial at best. This is the structural gap in many MCP programmes: they attempt to enforce before they have a complete catalog. The practitioner conclusion is that discovery and enforcement must be treated as one control chain.

Versioned manifests are the difference between approved access and silent semantic change. MCP catalog drift, including rugpull behaviour, breaks the assumption that an approved tool remains the same tool over time. That assumption is designed for static definitions, but MCP servers can change behaviour after approval without a new deployment signal. The practitioner conclusion is that tool identity must be versioned as tightly as credentials.

Named concept: runtime governance gap. This is the space between what an organisation thinks it has approved and what an MCP server actually exposes at runtime. In practice, it is created by ephemeral servers, embedded dependencies, and missing ownership, all of which let access outpace review. The practitioner conclusion is that MCP governance has to follow runtime reality, not deployment intent.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to Astrix Security's The State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which helps explain why discovery without manifest governance leaves so much exposure unchecked.
• For a broader NHI control lens, see NHI Lifecycle Management Guide for the provisioning, rotation, and offboarding controls that make surface mapping operational.

What this signals

Runtime visibility will become the gating control for MCP governance. If a server can appear outside the pipeline or outside the inventory, then policy and review both arrive too late. The next stage for security teams is to tie discovery to ownership assignment and change control, not to treat mapping as an audit exercise.

Ephemeral tool surfaces will keep widening the NHI gap. In our research, 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows how quickly hidden tool access can accumulate when deployment discipline is weak. Teams should expect more scrutiny on the control record for each server, not just on the secrets it uses.

Tool identity is becoming a lifecycle issue. Once an MCP server can change behaviour after approval, the operating model has to track manifest version, ownership, and access scope as a single lifecycle thread. For teams building that discipline, the NHI Lifecycle Management Guide is the right starting point, and the OWASP Agentic AI Top 10 helps frame tool misuse and identity abuse risks.

For practitioners

• Create a layered discovery model for MCP servers Use network traffic, agent instrumentation, CI/CD inspection, and infrastructure-as-code analysis together so that ephemeral, embedded, and localhost-bound servers are not missed. Treat network traffic as the first signal for unknown assets, then reconcile it against deployment records and runtime calls.
• Require a manifest before any MCP server is approved Capture exposed tools, argument schemas, transport, authentication configuration, connected agents, authorization scope, ownership, and data classification in one record. Block servers that cannot supply those fields from moving into the approved catalog.
• Version tool catalogs and compare them to live behaviour Snapshot the full manifest at registration and on every detected change, then diff tool descriptions, schemas, and capabilities against the current runtime state. Use timestamps so incident teams can reconstruct what the server advertised at the time of access.
• Prioritise exposed servers by ownership and data reach Rank external exposure, broad tool permissions, and sensitive data access above localhost-only or read-only servers. If ownership is unclear or data classification is missing, treat the server as a higher-risk identity surface until it is remediated.

Key takeaways

• MCP surface mapping is the control that makes authorization possible, because discovery, manifesting, and ownership have to exist before policy can be enforced.
• Hard-coded secrets, missing access scoping, and drift between approved and live tool behaviour turn MCP servers into a hidden identity surface.
• The practical response is to treat every MCP server as a versioned, owned, and classified access object, not as an ordinary application endpoint.

Key terms

• MCP Exposure Surface: The set of endpoints, tools, and sessions that can be reached through an MCP integration. It is broader than the network path alone because it includes identity context, tool permissions, and the lifetime of the access path.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• 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.

What's in the full article

Impart's full blog covers the operational detail this post intentionally leaves for the source:

• Detailed guidance on layering network, runtime, pipeline, and IaC discovery for MCP servers.
• Manifest field-by-field guidance for tool schemas, authentication, connected agents, and ownership.
• Operational examples of how to detect catalog drift and compare approved tool definitions to live runtime behaviour.
• Priority-setting logic for external exposure, sensitive data access, and server ownership gaps.

👉 Impart's full post covers the discovery layers, manifest model, and drift detection details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.