MCP server discovery exposes hidden AI access and secret sprawl

At a glance

What this is: This blog explains why MCP server discovery matters: hidden AI servers can expose secrets, connect to sensitive systems, and evade existing security oversight.

Why it matters: It matters because IAM, NHI, and AI governance teams need visibility into AI-driven services that inherit human credentials, create shadow access paths, and weaken Zero Trust assumptions.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Token Security's analysis of hidden MCP servers and exposed secrets

Context

MCP server discovery is a governance problem as much as a detection problem. Model Context Protocol servers can connect AI assistants to files, databases, tickets, APIs, and business applications, but they are often deployed outside normal inventory, ownership, and approval processes, which leaves identity security teams blind to who or what is actually holding access.

The key issue is that these servers frequently run under personal credentials or embed long-lived secrets in configuration files. That makes them look like ordinary helper processes while acting like privileged non-human identities, which is exactly where traditional endpoint and IAM controls start to lose clarity.

For practitioners, the central question is not whether AI tooling is being adopted. It is whether the enterprise can still explain every credential, every integration, and every data path once MCP servers begin to proliferate across developer laptops and cloud instances.

Key questions

Q: How should security teams govern MCP servers that run inside developer workflows?

A: Treat them as identity-bearing services with explicit ownership, scoped access, and continuous discovery. If an MCP server can read files, call APIs, or reach production systems, it must be inventoried like any other privileged integration. The key control is not just detection. It is making the server, the user, and the credential lineage auditable end to end.

Q: Why do MCP servers complicate NHI governance and Zero Trust models?

A: They complicate governance because they often authenticate with personal credentials while behaving like standalone services. That creates a gap between who appears to be acting and what is actually executing. Zero Trust also weakens when hidden services initiate outbound connections without clear provenance, ownership, or data-boundary enforcement.

Q: What breaks when secrets are stored in MCP configuration files?

A: A single exposed config can turn a helper process into a durable access path. If API keys, tokens, or credentials are stored in plaintext or environment variables, any process that reads the file may reuse the privileges. That makes secret rotation necessary but insufficient unless the underlying integration is also reviewed and constrained.

Q: Who should own the risk when an AI assistant connects to an MCP server?

A: Accountability should sit with the team that deployed or approved the server, not with the abstract AI tool itself. The server creates the access path, the credential holder grants the privilege, and the business owner must define acceptable use. Without that chain, incidents become difficult to investigate and harder to contain.

How it works in practice

Why MCP servers become invisible identity endpoints

MCP servers are lightweight services that let AI clients call tools and data sources through a common protocol. The visibility problem starts when they authenticate with user credentials, blend into developer workflows, and run without dedicated ownership records. Because endpoint and identity tools usually classify the user, not the process, the server is treated as benign infrastructure even when it can query databases, create tickets, or delete records. That creates a blind spot where a non-human process inherits human access but escapes human-style governance.

Practical implication: inventory MCP servers as identity-bearing services, not just endpoints, and tie each instance to a named owner and approval record.

How hardcoded secrets and OAuth create hidden NHI exposure

The article describes MCP servers storing API keys, tokens, and credentials in config files or environment variables. That combination matters because any process or AI assistant that can read those files can reuse the credentials, and OAuth does not remove the governance issue if the server acts on behalf of a user without explicit approvals for each action. The result is an NHI control problem, not only a secrets problem: access exists, persists, and is usable outside the original intent of the integration.

Practical implication: treat MCP configuration files as high-risk secret stores and correlate discovered credentials back to the identity and scope that created them.

Why shadow AI breaks Zero Trust assumptions

Zero Trust depends on knowing what is connecting, what it can reach, and whether access is continuously justified. MCP servers weaken that model because they initiate outbound connections, may operate with full user privileges, and can move data without the same logging and approval patterns expected from managed services. When the process is hidden, the access path is also hidden, which makes auditability and containment much harder during incident review. This is the same structural failure seen whenever identity is embedded in a workflow but not governed as one.

Practical implication: extend Zero Trust review to AI-assisted workflows and require every MCP connection to map to explicit data and application boundaries.

NHI Mgmt Group analysis

MCP server discovery is really non-human identity discovery in disguise. The article describes a class of AI-connected services that can browse files, call APIs, and manipulate business systems while remaining invisible to ordinary inventory processes. That makes the governance problem an identity problem first and a tooling problem second. Practitioners should treat every MCP instance as an accountable identity endpoint, not as a harmless integration.

Hardcoded secrets in MCP configs create identity blast radius. The combination of plaintext tokens, environment variables, and user-context authentication means a single hidden server can inherit far more access than its operator intended. This is not simply secret sprawl; it is secret sprawl attached to a live execution surface. The practical conclusion is that discovery without access-scope analysis leaves the real risk untouched.

Shadow AI invalidates the assumption that all meaningful access is centrally issued. Traditional governance assumed that privileged activity could be traced back to a managed account, an owned service, or a reviewed workflow. That assumption fails when an AI assistant quietly connects to an MCP server on a developer machine and exercises user credentials without explicit security oversight. The implication is that identity governance has to account for autonomous-looking execution paths even when the underlying actor is still non-autonomous.

Model Context Proxy visibility gap: the enterprise now has services that behave like workloads, authenticate like users, and are governed like neither. That is the central failure mode this article exposes. Existing IAM and endpoint models split those responsibilities across teams, which leaves MCP servers in the gap between ownership, approval, and audit. Practitioners should close that gap by making discovery, entitlement review, and secret hygiene one control plane.

Zero Trust for AI tools requires provenance, not just policy. The article shows why network reachability alone is insufficient when hidden servers can initiate connections from inside trusted developer environments. If security teams cannot prove where the MCP server came from, who owns it, and what data it can touch, then Zero Trust becomes a label instead of a control. The field should treat AI-linked infrastructure as a first-class governance domain.

From our research:

• 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.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, showing that detection without revocation leaves exposure in place.
• For lifecycle control guidance, see Ultimate Guide to NHIs - Static vs Dynamic Secrets for how to reduce standing credential risk in AI-linked services.

What this signals

MCP visibility is becoming a prerequisite for AI governance. Once AI assistants and local agent services can touch production systems, the programme can no longer rely on user-level authentication alone. Teams should expect discovery, ownership, and entitlement review for AI-connected services to move into the same operational tier as other non-human identities, especially where secrets management and endpoint telemetry intersect.

Model Context Proxy sprawl is a stronger predictor of identity risk than tool count. A small number of hidden services can create more exposure than a large number of visible integrations because the control failure sits in provenance, not volume. That means practitioners should measure how many AI-linked processes are invisible to inventory, not just how many AI tools are deployed.

With 92% of organisations agreeing that governing AI agents is critical but only 44% having implemented policies, the gap is no longer awareness. The programme signal is whether AI-connected services have been pulled into the same entitlement, secrets, and audit workflows as the rest of the identity estate.

For practitioners

• Inventory MCP servers as governed identities Require every discovered MCP server to have an owner, business purpose, and documented access scope before it is allowed to persist in the environment.
• Scan configs for hardcoded secrets Search claude_desktop_config.json, .mcp.json, and environment variables for API keys, plaintext tokens, and credentials, then correlate findings to the identity that created them.
• Separate user authentication from process authority Do not let a personal login become the default control for an AI-connected service. Map the process, the user, and the data path separately so hidden services cannot inherit unmanaged privilege.
• Extend Zero Trust reviews to AI workflows Track which AI assistants and MCP servers can reach AWS, Salesforce, Snowflake, and other sensitive services, then restrict outbound connections to explicit, reviewed boundaries.
• Create shutdown criteria for shadow AI services Define the conditions under which a discovered MCP server is paused or removed, especially when it lacks ownership, stores secrets in config, or cannot be tied to a sanctioned workflow.

Key takeaways

• MCP servers create a shadow identity layer when AI tools connect to business systems outside normal oversight.
• Secrets embedded in MCP configs turn discovery problems into live access problems, especially when user credentials are reused by hidden services.
• Practitioners need one control plane for discovery, ownership, and entitlement review if they want Zero Trust to apply to AI-connected workflows.

Key terms

• MCP Server: A Model Context Protocol server is a service that exposes tools or data sources to AI clients through a standard interface. In practice, it can become a privileged non-human identity when it authenticates, stores secrets, or reaches business systems on behalf of a user or agent.
• Shadow AI: Shadow AI is AI software or agent infrastructure operating outside the security team's inventory, ownership, or approval processes. It often looks like a helper workflow, but it can still hold credentials, move data, and create unmonitored access paths that standard governance tools miss.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of API keys, tokens, certificates, and credentials across files, environment variables, chat tools, and build systems. The risk is not just exposure, but persistence, because leaked secrets often remain valid long after they are discovered.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause if its credentials, permissions, or trust relationships are misused. For MCP servers and AI-connected services, the blast radius grows quickly when a single hidden process inherits broad user or system access.

What's in the full announcement

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

• Endpoint discovery and forensic collection workflow for MCP server configs and AI agent processes
• How the platform correlates CrowdStrike logs with Claude Code and IDE activity to identify MCP communication paths
• Examples of configuration files and redacted secret findings used to build the risk graph
• How discovered MCP instances are classified by authentication and connected systems

👉 Token Security's full post covers discovery workflow, config analysis, and risk graph examples

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.