MCP is driving an identity explosion behind AI agent access

At a glance

What this is: MCP standardises AI agent connections to tools, but the article argues that every integration still creates or depends on non-human identities that must be governed.

Why it matters: That matters because IAM, PAM, and lifecycle programmes now have to track agent ownership, scope, and credential hygiene alongside human and workload identities.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Entro Security's analysis of MCP and the identities behind AI agent access

Context

MCP is a standard for connecting AI agents and large language models to external systems such as GitHub, Slack, Postgres, and internal file stores. The governance gap is that standardised connectivity does not remove the need for identity controls, because every tool connection still depends on secrets, scopes, and ownership.

For IAM teams, the question is not whether MCP works technically. The real issue is that each agent-connected workflow adds another non-human identity to inventory, classify, protect, and retire, often without a clear lifecycle owner or consistent audit trail.

Key questions

Q: How should security teams govern AI agents that connect through MCP?

A: Security teams should govern MCP-connected AI agents as non-human identities with owners, scopes, and lifecycle controls. That means mapping every tool connection to a credential source, limiting permissions to the minimum required, and reviewing access when the agent’s purpose changes. The goal is not just secure integration, but accountable identity governance across the full chain.

Q: Why does MCP increase identity risk even when the protocol is secure?

A: MCP can be secure at the transport and protocol layer while still leaving the identity layer exposed. The risk comes from what sits underneath the protocol, including secrets, service accounts, and broad tool permissions. If those controls are weak, a secure protocol simply makes it easier to scale insecure access patterns across more systems.

Q: What do teams get wrong about AI agent access in MCP environments?

A: Teams often focus on the agent interface and ignore the identity objects that actually authorize actions. The common mistake is assuming the protocol replaces credential governance, when in fact it depends on it. If ownership, rotation, and revocation are not defined, the organisation inherits hidden access paths that are hard to audit and harder to remove.

Q: How do you know if MCP-connected identities are under control?

A: You know they are under control when each agent has a named owner, every credential is scoped and short-lived, and offboarding removes access without manual exception handling. Strong programmes can also show which systems each agent touched and whether those entitlements were reviewed on schedule. If any of that is missing, governance is incomplete.

Technical breakdown

How MCP creates non-human identities at the integration layer

MCP uses a client-server pattern in which an AI client requests tools from a server over a structured protocol, typically JSON-RPC. The protocol standardises how the agent asks for access, but it does not eliminate the underlying identity objects used to authorize those requests. In practice, the tool server may rely on OAuth tokens, API keys, or service accounts, and each of those becomes part of the access chain. That means the protocol layer can be clean while the identity layer remains fragmented. Practical implication: treat every MCP connection as a governed identity relationship, not just a software integration.

Practical implication: Inventory the identities behind each tool server before expanding MCP beyond pilots.

Secrets, scopes, and lifecycle are the real control plane

The article points out that MCP does not provide native vaulting or lifecycle management. That matters because the security of the connection depends on how credentials are issued, stored, rotated, and retired outside the protocol. OAuth 2.1 can reduce hardcoded secrets and support scoped access, but only if the surrounding IAM programme enforces expiration, ownership, and revocation. Without that, the protocol simply makes it easier to connect more systems with the same unresolved governance debt. Practical implication: move the control discussion from protocol adoption to identity lifecycle enforcement.

Practical implication: Align MCP onboarding with secrets rotation, ownership tagging, and deprovisioning workflows.

Why agent access behaves like a non-human identity problem

The article’s core claim is that AI agents do not merely consume credentials, they act through them. Once an agent can read from one system, write to another, and continue operating 24/7, the identity problem becomes one of entitlement scope and blast radius. That is classic NHI territory, even if the front end is an AI assistant. The technical risk is not the connector itself, but the aggregation of permissions across multiple toolchains without a single authoritative owner. Practical implication: model AI agent access as a non-human identity estate with explicit governance boundaries.

Practical implication: Set access boundaries per agent and per toolchain, then review them as a single identity estate.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.

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 is an identity multiplication layer, not just an integration protocol. Standardised tool connectivity lowers engineering friction, but it also makes it easier to create many more machine access paths than most IAM programmes can currently inventory. The governance burden shifts from building each integration manually to proving who owns each agent, what it can reach, and when it should lose access. Practitioners should treat MCP adoption as an NHI growth event, not a developer convenience.

Secret sprawl becomes more dangerous when it sits behind agent-driven workflows. When AI agents use OAuth tokens, API keys, or service accounts to reach multiple systems, the risk is no longer a single exposed credential. The real issue is that the credential often outlives the human who created it and the workflow it was meant to serve. That is a lifecycle failure, and it belongs in NHI governance, PAM oversight, and offboarding discipline.

Agent ownership is the missing control in most MCP conversations. The article correctly asks who owns the AI agent after it connects to multiple toolchains. Without an accountable owner, entitlement review becomes mechanical rather than meaningful, and incident response becomes slower because no one can quickly answer why the agent had access in the first place. Practitioners should make ownership part of identity design, not an afterthought in deployment.

Blast radius, not connector count, is the metric that matters. Each additional MCP server does not just add convenience. It adds another place where a broadly scoped identity can cross system boundaries, access sensitive data, or take action at machine speed. That is why MCP should be evaluated through NIST CSF-style access governance and OWASP NHI thinking, not just through application architecture. The practical question is how far one compromised or misused agent identity can travel.

Identity governance for MCP has to converge across human, NHI, and autonomous workflows. The article sits at the edge of all three domains because developers create the connections, service accounts power the access, and AI agents initiate the actions. The market is moving toward a single control problem with multiple actor types, and teams that keep these programmes separated will miss the combined risk surface. Practitioners should build one governance view that spans the full delegation chain.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Another finding from that research shows only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• For a broader view of how hidden access compounds across agent estates, see AI Agents: The New Attack Surface report.

What this signals

Hidden agent credentials will become a routine governance failure if teams keep treating MCP as an application integration problem. The control conversation needs to move upstream into identity design, because hardcoded secrets, unmanaged service accounts, and unowned agent workflows create a compound risk profile. That is especially true where agent access spans development, collaboration, and data platforms.

Identity ownership is the concept MCP most clearly exposes. An agent that can read, write, and execute across multiple systems is not just a workload. It is a governed identity with a lifecycle, a blast radius, and a retirement date. Programmes that cannot assign ownership will struggle to prove access intent, access review quality, or revocation effectiveness.

With 92% of organisations saying AI agent governance is critical but only 44% having implemented any policies, the gap is already visible in policy maturity rather than architecture. The practical signal is that the next control failure will not come from a missing connector, but from a missing owner or expired credential.

For practitioners

• Inventory every MCP-connected identity Map each AI client, tool server, token, API key, and service account to a named owner and business purpose before broad rollout.
• Enforce scoped, short-lived credentials Require OAuth scopes or equivalent least-privilege controls for each tool connection, and remove any hardcoded credentials from configuration files.
• Tie agent access to lifecycle controls Include MCP-linked identities in joiner, mover, leaver, recertification, and offboarding processes so access can be revoked when the workflow changes.
• Review blast radius across toolchains Assess how far one agent identity can move between systems such as GitHub, Slack, and databases, then reduce cross-system entitlements where possible.

Key takeaways

• MCP standardises agent connectivity, but it does not solve the identity governance burden behind each connection.
• Hardcoded secrets, weak scoping, and missing ownership turn AI agent integrations into a growing non-human identity estate.
• IAM teams should treat MCP rollout as a lifecycle and blast-radius problem, not just a protocol adoption project.

Key terms

• Model Context Protocol: A standard way for AI clients to connect to external tools and data sources. In identity terms, MCP is a connector layer, not an identity layer. It still depends on credentials, scopes, and ownership outside the protocol to make access safe and auditable.
• Non-Human Identity: Any identity used by software, workloads, bots, or AI agents instead of a person. It includes service accounts, API keys, tokens, and certificates. In MCP environments, NHIs are the real control point because they authorize the agent's actions across systems.
• Secret sprawl: The uncontrolled spread of credentials across code, configuration files, and tooling. Secret sprawl becomes more dangerous when AI agents can use those credentials across multiple systems. The security problem is not only exposure, but also the difficulty of tracing, rotating, and retiring them.
• Blast radius: The amount of damage an identity can cause if it is misused, compromised, or over-scoped. For AI agent workflows, blast radius is shaped by tool count, privilege scope, and how many systems one credential chain can touch before detection or revocation occurs.

What's in the full article

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

• How MCP client-server authentication works in practice, including the roles of OAuth tokens and service accounts.
• Examples of the AI tools and data sources MCP can connect to, such as GitHub, Slack, Postgres, and internal file systems.
• Why developers still hardcode API keys in AI assistant workflows, despite protocol support for scoped access.
• The article's own framing of ownership, blast radius, and identity visibility across agent-driven access paths.

👉 Entro Security's full post covers the MCP access pattern, credential concerns, and agent ownership questions in more detail.

Deepen your knowledge

MCP-connected AI agents and the identities behind them are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing governance for agentic integrations, the course helps connect protocol choices to lifecycle and access controls.