MCP agents are expanding the identity attack surface for enterprises

At a glance

What this is: MCP is becoming the connective layer for AI agents, and the key finding is that its rapid adoption is expanding identity, access, and visibility risk faster than current controls can absorb.

Why it matters: For IAM teams, MCP matters because it stretches NHI governance into agentic workflows where access scope, auditability, and delegation now need to be controlled at runtime, not just provisioned.

👉 Read Lasso Security's analysis of why MCP agents are expanding enterprise attack surface

Context

MCP, or Model Context Protocol, is a standard way for AI systems to connect to tools, data sources, and workflows. In identity terms, that matters because each connected agent becomes a non-human identity with real access paths, not just a software integration.

The governance gap is simple: organisations can provision agent access, but they cannot assume that access remains stable, visible, or bounded once the agent starts interacting across systems. That makes MCP a workload identity and privileged access issue as much as an AI integration issue.

The article’s core warning is that MCP adoption is scaling faster than the supporting control plane. In practice, that creates shadow agents, hidden credentials, and weak auditability unless teams treat tool connectivity as an identity lifecycle problem rather than a developer convenience.

Key questions

Q: How should teams govern MCP-connected AI agents in production?

A: Govern MCP-connected agents like privileged non-human identities, not like ordinary integrations. Each server and agent should have a named owner, explicit purpose, scoped permissions, and logging at the tool boundary. Security teams should also require revocation and review processes so access can be removed when the workflow, business need, or deployment status changes.

Q: Why do MCP deployments increase identity risk so quickly?

A: MCP lowers the friction for connecting agents to tools and data, which means identities, permissions, and trust relationships can appear faster than governance processes can review them. That creates sprawl, hidden ownership, and weak auditability. The risk rises when teams allow broad permissions and long-lived credentials without a clear lifecycle.

Q: What breaks when MCP servers are deployed without central security oversight?

A: What breaks is the ability to prove who approved access, what systems the agent reached, and when the access should end. Without central oversight, MCP servers become shadow identities with untracked privileges. That undermines recertification, incident response, and offboarding because the organisation no longer has a reliable record of the access path.

Q: How do security teams decide whether an MCP agent has too much access?

A: A useful test is whether the agent can read data, trigger actions, and move across systems with one broad entitlement. If those capabilities are bundled, the access is too wide. Teams should separate those functions, then confirm that each permission is necessary, traceable, and removable without breaking unrelated workflows.

Technical breakdown

MCP resources, tools, prompts, and sampling create distinct access paths

MCP separates what an agent can read, what it can execute, and how it can request model output. Resources expose file contents, database records, and API responses. Tools let the model trigger functions. Prompts package reusable workflows. Sampling lets the agent request completions. That modularity is useful, but each path creates a different trust boundary. If teams treat all MCP interactions as one generic integration, they miss where data exposure starts, where action authority begins, and where audit records should be captured. The control problem is not just connectivity. It is the granularity of authorisation across different agent behaviours.

Practical implication: Map MCP permissions by resource, tool, and workflow, not as one broad integration entitlement.

Why MCP server sprawl behaves like shadow NHI growth

The article describes thousands of MCP servers appearing quickly, many deployed by developers outside central security review. That is classic identity sprawl, but at machine speed. Each server adds a new access path, often with credentials, permissions, and cross-system reach that security teams did not explicitly model. Because these agents can touch Slack, Jira, cloud consoles, and data stores, the blast radius is not confined to one application. The key mechanism is not malware. It is unmanaged delegation combined with low-friction deployment and weak visibility into who approved what.

Practical implication: Treat every new MCP server as a governed non-human identity with lifecycle, ownership, and logging requirements.

Unscoped agent access turns convenience into privilege escalation

The article’s security concern is that agents often receive broad permissions so they can operate usefully across systems. Once granted, those permissions can be used in ways that exceed the original intent, especially when the agent can act independently. That creates privilege escalation by design, not by exploit. If access scopes are vague, if credentials are long-lived, or if actions are not logged at the tool boundary, then a single agent can become a high-value pivot into sensitive systems. In NHI terms, the technical weakness is not the protocol itself. It is the absence of scoped enforcement around the identity that the protocol enables.

Practical implication: Require scoped, revocable, and fully logged access for every agent action that crosses a system boundary.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 turning agent connectivity into an identity governance problem, not just an integration problem. The article shows that once agents can reach tools and data through a standard protocol, the security question shifts from whether the system connects to whether the resulting non-human identities are visible, bounded, and attributable. That is a familiar NHI pattern, but MCP accelerates it across more systems at once. Practitioners should read MCP adoption as an expansion of identity surface area, not a feature upgrade.

Shadow MCP deployments create a control gap that looks like shadow IT but behaves like unmanaged machine identity. Developers can stand up servers and connect sensitive systems without central approval, which means ownership, logging, and offboarding are often missing from day one. The governance issue is not merely discovery. It is that security teams lose the ability to answer who granted access, what was reached, and when the access should end. Practitioners need to assume that invisible agents will be the default unless lifecycle controls are explicit.

Identity sprawl at machine speed is the named concept this category now needs. MCP does not invent sprawl, but it compresses the creation of new identities, permissions, and cross-system trusts into hours rather than months. That changes how IAM, PAM, and NHI programmes should frame risk because the control window narrows while the blast radius widens. The practitioner conclusion is straightforward: governance models built for slow provisioning cycles will not contain fast, developer-led agent deployment.

Zero trust for MCP only works when tool access is scoped at the protocol boundary. The article’s risk examples, including context injection and unauthorised actions, show that enforcement cannot stop at network access or model permissions. The relevant control point is the action itself, especially where the agent can call external tools or move data across boundaries. Practitioners should treat each MCP server as a privilege-bearing intermediary that needs explicit policy and continuous monitoring.

The emerging failure mode is not just credential exposure, but invisible delegation. When an MCP-connected agent inherits access without a durable governance record, the organisation can no longer prove why the access existed or who should revoke it. That undermines access reviews, incident response, and compliance evidence in one move. The broader implication is that lifecycle governance must extend to machine-facing workflows with the same discipline used for service accounts and privileged access.

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.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone.
• For a broader agent-risk lens, AI Agents: The New Attack Surface report shows that 80% of organisations report AI agents acting beyond intended scope.

What this signals

Identity sprawl is the operational signal security teams should watch first. When over 1,000 MCP servers can appear within months of a protocol’s release, the programme risk is no longer isolated configuration hygiene. It becomes a governance problem of discovery, ownership, and revocation, which is why agent and service-account inventories need to converge rather than live in separate tooling silos.

The control posture should now assume that agent connectivity will outpace manual review. That makes scoped permissions, tool-level logging, and lifecycle offboarding the minimum viable baseline for MCP-connected identities, especially where developers can deploy servers without central approval.

Teams should also align MCP governance with the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework where agents can independently select tools or actions. The point is not to over-classify every integration as autonomous. The point is to recognise when protocol convenience is creating a repeatable access-control blind spot.

For practitioners

• Inventory every MCP-connected agent and server Create a register of all MCP endpoints, connected tools, responsible owners, and business purpose. Include developer-managed deployments outside central security approval, because those are the most likely source of hidden access paths.
• Scope permissions by resource and tool Separate read access, action execution, and workflow prompts into distinct entitlements. Avoid broad agent permissions that bundle data retrieval with write actions, especially where the agent can touch cloud consoles, collaboration tools, or ticketing systems.
• Log tool-boundary activity for every agent Capture which agent invoked which tool, what context was passed, what action executed, and what data returned. Without boundary logging, investigations cannot reconstruct agent behaviour across systems or prove whether access stayed within policy.
• Apply lifecycle controls to shadow agents Assign ownership, review cadence, and offboarding criteria to each agent and server. If a deployment cannot be certified, traced, and revoked like any other non-human identity, it is not ready for production use.

Key takeaways

• MCP makes AI agents an identity problem because every new server adds a governed access path into real systems.
• The main risk is not protocol novelty, but unmanaged delegation, hidden credentials, and weak visibility across agent actions.
• Security teams need scoped permissions, lifecycle ownership, and boundary logging before MCP adoption becomes irreversible sprawl.

Key terms

• Model Context Protocol: A standard that lets AI systems connect to external tools, data sources, and workflows through a common interface. In practice, it turns an agent’s integrations into governed access paths, which means identity, authorisation, and logging must be managed at the protocol boundary as well as in the surrounding application stack.
• Shadow agent: An AI agent or MCP-connected server deployed without central security visibility, ownership, or approval. It behaves like shadow IT with machine identities, because the access path exists even when the security team cannot reliably discover, review, or revoke it.
• Tool-boundary logging: Logging that captures what an agent requested, which tool executed, what context was passed, and what data returned. This is the level of telemetry needed to investigate agent behaviour across systems and prove that access stayed within policy boundaries.
• Identity sprawl: The rapid growth of identities, permissions, and trust relationships faster than governance processes can track them. For MCP and agentic systems, the problem is not only the number of identities, but the speed at which new access paths appear and become difficult to retire cleanly.

Deepen your knowledge

MCP-connected agent governance is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is now dealing with shadow agents, scoped permissions, and lifecycle oversight, it is worth exploring.

This post draws on content published by Lasso Security: Why MCP Agents Are the Next Cyber Battleground. Read the original.