TL;DR: MCP is turning AI agent connectivity into an identity problem, with over 1,000 servers live by early 2025 and thousands more appearing across the ecosystem according to Lasso Security. The real issue is that existing IAM and monitoring models were built for stable, reviewable identities, not fast-moving agents that can reach sensitive tools and data.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Lasso Security's blog post: MCP is expanding the enterprise identity attack surface by making AI agents the new access layer to data and tools.
Why it matters: IAM, PAM and NHI teams need to treat MCP as an identity governance problem because agent connectivity can outgrow existing approval, visibility and authorization models.
By the numbers:
- By early 2025, over 1,000 MCP servers were live.
- By early 2025, more than 10K community-deployed MCP servers were live.
Context
Model Context Protocol, or MCP, is a standard that lets AI agents connect to tools, data and workflows across systems. In practice, it turns the agent into an active identity that can request resources, invoke functions and move between applications.
The governance problem is that this new access layer scales faster than traditional IAM operating models. Organisations can end up with agents that are difficult to inventory, hard to authenticate consistently and easy to over-privilege across cloud and SaaS environments.
That makes MCP a control-plane issue, not just an integration choice. The article’s core claim is that the security gap is created by rapid agent adoption, weak oversight and identity sprawl at machine speed.
Key questions
Q: How should security teams govern MCP servers used by AI coding assistants?
A: Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.
Q: Why do MCP-based agents create more risk than ordinary API integrations?
A: Because the agent is choosing actions, chaining tools, and preserving context across steps. Ordinary API controls assume predictable request patterns, while MCP can turn one legitimate session into a route for data exposure or privilege escalation. The risk increases when identity, context, and tool access are not governed together.
Q: What are the signs that MCP governance is failing?
A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.
Q: What should organisations do when agent access grows faster than review processes?
A: They should move control points closer to provisioning and runtime oversight, because periodic review cannot keep up with rapidly multiplying agents. That means agent inventory, explicit authorisation, telemetry and revocation need to be built into the operating model before scale turns into shadow access.
Technical breakdown
Why MCP changes the identity model for AI agents
MCP is designed to standardise how models and applications exchange context, but in security terms it also standardises how agents reach protected resources. Once an agent can call tools, read resources and request completions, it becomes an identity-bearing participant in enterprise workflows rather than a passive application client. That matters because the agent can act across systems with a scope that often exceeds what human-administered provisioning was meant to describe. The result is not just integration sprawl but identity sprawl, where each agent relationship adds another authorization boundary to govern.
Practical implication: Map every MCP-connected agent to an explicit identity, owner and access boundary before granting tool access.
Where MCP sprawl breaks authentication and authorization
The article’s security concern is that MCP servers and clients often appear faster than the controls needed to govern them. If agents are ephemeral, poorly inventoried or granted broad permissions to make workflows work, authentication becomes a formality rather than a control. Authorisation weakens further when the same agent can bridge multiple tools without clear scoping or human review. In that model, a compromised or rogue agent is not just a bad session, it is a durable path into data, APIs and administrative actions across the enterprise.
Practical implication: Enforce scoped, reviewable authorisation per agent and per tool instead of trusting broad inherited access.
Why visibility and auditability are central to MCP security
MCP adoption becomes dangerous when tool usage is invisible to security teams. The article notes that many agents operate with no clear audit trail, limited logging and weak monitoring across the tool chain, which makes detection and investigation difficult once misuse starts. This is especially important in agentic workflows because the risk is not only data exposure, but unobserved action across multiple systems. Without telemetry on model-tool interactions, security teams cannot distinguish routine automation from risky or unauthorized behaviour.
Practical implication: Instrument MCP traffic, tool calls and agent actions so misuse can be detected and investigated across systems.
Threat narrative
Attacker objective: The attacker objective is to use unmanaged agent connectivity to reach sensitive systems, harvest or move data and execute actions without detection.
- Entry occurs when developers spin up MCP servers and connect agents to internal tools without central security approval or visibility.
- Credential and access abuse follows as those agents receive broad permissions, including read, write and administrative API access.
- Escalation happens when the same agent can move across systems, invoke tools and trigger actions with little or no human oversight.
- Impact is cross-boundary data exposure, unapproved changes and a hidden backdoor into sensitive enterprise systems.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
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
Identity sprawl is the real MCP risk, not protocol novelty: MCP matters because it converts every agent connection into a new identity boundary that has to be authenticated, authorised and observed. The article shows that the control problem is no longer limited to human accounts or classic service accounts. Practitioners should treat each MCP relationship as a governed identity lifecycle, not a convenience layer.
Existing IAM assumptions break when agents can appear faster than review cycles: User-directory thinking assumes identities are relatively stable, centrally provisioned and slow to multiply. MCP-driven agent deployment breaks that assumption because access can be created, expanded and forgotten at machine speed. The implication is that entitlement governance has to move closer to issuance, inventory and runtime oversight.
Shadow agents are the MCP equivalent of shadow IT, but with tool execution power: Unapproved agents do not just hide data flows, they can actively call APIs, write records and trigger workflows across systems. That creates a broader blast radius than unsanctioned software because the identity itself can act. Security teams should focus on discoverability, approval and containment before the agent ecosystem becomes unmanageable.
MCP security is now an enterprise architecture question: The article’s strongest signal is that MCP cannot be treated as a point integration problem. Once agents reach cloud, SaaS and internal systems through a common protocol, governance becomes cross-platform by necessity. Practitioners need a single view of agent authorisation, logging and tool exposure rather than fragmented controls per client or server.
Runtime governance gap: MCP exposes the gap between identities that are provisioned once and identities that keep changing their tool reach as workflows expand. That gap is especially visible when agents are deployed first and governed later. The practitioner conclusion is to design identity controls for dynamic tool reach, not static account inventories.
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: Agentic AI Security Guide
What this signals
Runtime governance gap: MCP adoption exposes a mismatch between static entitlement models and agents that can be created, expanded and retired far faster than access review cycles can track. Security programmes should assume that discovery, approval and revocation now need to operate closer to runtime.
The next governance question is not whether agents can connect to tools, but whether those connections are visible, attributable and revocable across the whole workflow. That is where identity security, not protocol convenience, becomes the limiting factor.
The control conversation should also expand beyond the client application to the broader MCP ecosystem. Community servers and third-party integrations need the same inventory and offboarding discipline that teams already apply to other non-human identities.
For practitioners
- Inventory every MCP-connected agent Build a complete register of MCP clients, servers, tools and owners so no agent reaches production without an accountable identity record.
- Scope tool access per agent Separate read, write and administrative actions for each agent and each tool, then remove any default broad permissions that are not explicitly justified.
- Require logging for model-tool interactions Capture agent requests, tool invocations and downstream actions in a searchable audit trail that security teams can review and correlate.
- Treat community MCP servers as third-party risk Review externally built servers like any other supplier-connected identity surface, including approval, exposure and offboarding requirements.
Key takeaways
- MCP turns AI agent connectivity into an identity governance problem because each tool connection creates a new access boundary.
- The article shows that over 1,000 MCP servers and more than 10K community-deployed servers were live by early 2025, which makes unmanaged sprawl a real operating issue.
- The practical response is to inventory agents, scope tool permissions, and force logging and revocation into the MCP operating model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP agents can gain and misuse privileges across connected tools and systems. |
| Recommendation — Apply ASI03 to constrain agent privileges and verify every cross-tool authorization decision. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on agents receiving broad permissions that outgrow their intended scope. |
| NHI-10 — Human Use of NHI | Developers can spin up and use agents below security oversight, creating shadow access paths. | |
| Recommendation — Reduce agent blast radius by enforcing least-privilege access on every MCP-connected identity. Block informal agent deployment paths and require approved ownership for every MCP identity. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP agents and tools authenticate as non-human services across systems. |
| Recommendation — Use IA-9 to authenticate each MCP service interaction with explicit trust boundaries. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core governance issue is excessive and poorly governed agent entitlements. |
| Recommendation — Review entitlements continuously and remove any MCP access that exceeds the agent's stated purpose. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Unmanaged agents can bridge systems and enable cross-platform abuse after access is obtained. |
| Recommendation — Map agent misuse to credential access and lateral movement to prioritise containment and detection. | ||
Key terms
- 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.
- Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
- Identity Sprawl: Identity sprawl is the uncontrolled growth of identities, entitlements, and credentials across an environment. For NHIs, it usually appears when automation creates accounts faster than governance teams can inventory, review, and remove them. The result is hidden access, weak accountability, and a wider attack surface.
- Shadow Agent: An AI agent deployed without formal registration, identity governance, or security oversight, the agentic equivalent of shadow IT. Shadow agents are more dangerous than typical shadow NHIs because they actively take actions using their credentials.
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 June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org