Shadow AI agents require data-layer control, not app blocklists

At a glance

What this is: This is an analysis of why shadow AI agents are harder to discover and control than web-based shadow AI, with the key finding that endpoint visibility and data-layer policy are necessary.

Why it matters: It matters because IAM, PAM, and NHI programmes now need to govern autonomous software processes that operate like non-human identities, with access scope and data movement becoming the real control points.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Cyberhaven's analysis of discovering and controlling shadow AI agents

Context

Shadow AI agents are different from shadow AI applications because they do not sit neatly inside browser sessions or sanctioned SaaS controls. They run locally, spawn processes, read files, call external model APIs, and interact with internal systems through MCP servers or workflow frameworks, which means the security problem is closer to endpoint governance and identity control than simple application blocking.

The primary failure mode is visibility fragmentation. Traditional DLP, network proxies, and asset inventories were built for traffic and application identities, not autonomous software that moves data across multiple systems without a human initiating every step. That creates a genuine identity, NHI, and agentic AI overlap because the agent becomes a governable runtime actor with its own access scope.

Key questions

Q: What breaks when security teams rely on app blocklists for shadow AI agents?

A: App blocklists fail because agent tooling changes faster than policy can be updated, and users can switch tools without changing the underlying behaviour. Local agents still spawn processes, read files, and call model APIs directly from endpoints. The stronger control is to govern data movement and endpoint behaviour, not to chase every new application name.

Q: Why do shadow AI agents create a governance gap for IAM and NHI teams?

A: Shadow AI agents create a governance gap because they can hold persistent permissions, act on behalf of users, and connect to corporate data while staying outside normal inventory processes. IAM and NHI teams cannot review, recertify, or offboard what they cannot see. That makes discovery a prerequisite for any meaningful lifecycle control.

Q: How do security teams know if shadow AI is actually under control?

A: Security teams know shadow AI is under control when they can inventory every agent, model workflow, and tool connection, then map each one to an owner and access scope. If they cannot explain who owns it, what it can access, and when it was last reviewed, it is not controlled.

Q: Who is accountable when an unsanctioned AI agent causes an incident?

A: Accountability should sit with the business and technical owner who allowed the agent to connect to enterprise systems, plus the control owners responsible for approval and monitoring. If no owner is named, accountability is already broken and incident response will be slower than it should be.

Technical breakdown

Why endpoint visibility is the first control layer for shadow AI agents

Shadow AI agents generate signals at the operating system layer, not just the network layer. They spawn processes, open files, inherit local permissions, and make outbound API calls directly from endpoints. That means browser logs, SaaS audit trails, and perimeter DLP will miss much of their activity. Discovery has to start where the agent executes, because the machine itself is the only place that can observe both process behaviour and local data access in one sequence. In practice, this shifts the control plane from application inventory to endpoint telemetry with identity-aware interpretation.

Practical implication: deploy endpoint-level visibility before attempting policy enforcement or agent blocklisting.

How MCP servers change the trust model for AI agents

Model Context Protocol servers create a standard path from an agent to internal resources such as databases, code repositories, file systems, and APIs. That standardisation helps integration, but it also expands the trust boundary because an unsanctioned MCP server can expose broad access without obvious signs in conventional asset management. The security team may not see the authorisation scope, the connected agents, or the data classes exposed. In identity terms, MCP turns a technical connector into a delegated access layer that needs lifecycle control.

Practical implication: inventory MCP servers as access assets, not just infrastructure components.

Why data lineage is more useful than application allowlists

Application allowlists break down when users can switch from one agent tool to another without changing the underlying behaviour. Data lineage tracks what file was read, what prompt was formed, which model endpoint received it, and where the data went after processing. That gives security teams a chain of custody for sensitive content and exposes exfiltration paths that simple policy on application names cannot catch. For NHI governance, this is the crucial point: the control must follow the data, not the label attached to the agent.

Practical implication: pair agent discovery with lineage controls that preserve provenance across each session.

Threat narrative

Attacker objective: The objective is to move sensitive enterprise data out of approved controls through an autonomous endpoint agent or its connected MCP path.

1. Entry occurs when an employee installs a local AI coding assistant or connects an agent to an internal MCP server without security review, creating an unsanctioned runtime presence on the endpoint.
2. Escalation happens when the agent inherits broad local permissions, reads source code, configuration files, or credentials, and uses those entitlements to access internal resources and external model endpoints.
3. Impact occurs when the agent transmits sensitive internal data outside sanctioned channels, exposing code, credentials, or regulated information and leaving the organisation with incomplete visibility for investigation.

NHI Mgmt Group analysis

Shadow AI agents are becoming non-human identities with endpoint-native privileges. The governance mistake is treating them as ordinary software installs or browser-based AI usage. Once an agent can read files, call tools, and move data, it behaves like a runtime identity that needs scope, monitoring, and lifecycle control. That makes IAM and NHI thinking directly relevant to what many teams still frame as a shadow IT issue. Practitioners should treat agent inventory as identity inventory.

Data-layer control is the named concept this category needs. The article points to a control gap where policy follows the application name instead of the data. That model fails when agents proliferate, because users can change tools while the sensitive content and downstream action remain the same. A data-layer approach aligns better with NHI governance because it evaluates access by resource, classification, and destination rather than by product label. Practitioners should shift from tool-centric blocking to data-centric enforcement.

MCP governance is now a first-order access problem. An MCP server is not just an integration detail, it is a delegated access path that can widen exposure without obvious change in the user interface. That creates a new lifecycle problem for identity teams, because the exposure depends on who created the server, what it authorises, and whether anyone can later prove the connection set. Practitioners should manage MCP as part of access governance, not as shadow infrastructure.

Discovery without classification will produce either noise or blind spots. The article correctly distinguishes sanctioned, pending review, and high-risk agents. That is the right model because not every unsanctioned agent warrants the same response, but every agent with broad data reach should be triaged quickly. This is where NHI programmes can add discipline to broader AI governance by applying risk tiers, ownership, and review cadence. Practitioners should classify agents before they normalise.

The real control objective is to preserve legitimate AI use while constraining uncontrolled data movement. Blanket blocking is rarely durable, especially when agent tooling changes quickly. Security programmes that succeed will combine endpoint visibility, access scope reduction, and real-time policy evaluation so that productive use remains possible without creating a permanent blind spot. Practitioners should design for governed adoption, not prohibition.

What this signals

Data-layer policy is becoming the practical boundary for AI governance. Endpoint telemetry and model access logs now matter together because shadow agents collapse the distance between local execution and sensitive content movement. Programmes that only track sanctioned apps will miss the real control point, which is where data leaves the endpoint and enters an external model or internal MCP path.

Shadow AI agent discovery should be treated as an access review problem, not a one-off tooling project. Once agents are classified by scope and owner, the security team can link the inventory to remediation, containment, and review cadence. That creates a governance loop that fits identity programmes better than reactive software blocking does.

Agent sprawl will keep expanding unless teams adopt machine-speed controls. The combination of endpoint execution, delegated access through MCP, and rapid tool adoption means manual review alone cannot keep pace. Practitioners should align AI governance with NHI-style lifecycle control and use frameworks such as the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 where agent behaviour and tool access are in scope.

For practitioners

• Implement endpoint-level process monitoring Collect OS-layer telemetry on managed devices so you can identify agent processes, file reads, and direct model API calls that network tools miss. Prioritise developer workstations first because that is where shadow agent concentration is highest. This is the only reliable starting point for discovery.
• Inventory agent access scopes and connected resources Record which agents are installed, what directories they can read, what external endpoints they can contact, and which MCP servers they use. Treat the access scope as part of the control decision, because an agent with repository and credential access carries a different risk profile from one limited to a single project folder.
• Map MCP servers as delegated access assets Build a live inventory of MCP servers, their authorisations, and the agents connected to them. Review whether each server exposes databases, file systems, code repositories, or internal APIs, and require security review before new servers are stood up in development or production.
• Enforce data-layer policy on sensitive content Block or alert on attempts to send confidential or regulated data to unapproved model endpoints, regardless of which agent initiates the transfer. Policies should follow the data classification and destination, not the application name, so controls remain effective as tools change.
• Classify agents by governance status Use three categories: sanctioned and monitored, pending security review, and high-risk with immediate controls. Tie each class to an owner, a review interval, and a containment action so discovery leads to a response, not just a spreadsheet.

Key takeaways

• Shadow AI agents are not just another form of shadow IT. They act like runtime identities on endpoints, which makes data movement, permissions, and lifecycle control the real governance problem.
• Discovery based on network visibility or app names will miss the highest-risk activity. Endpoint telemetry, MCP inventory, and data lineage are the controls that reveal what agents are actually doing.
• The fastest path to control is to classify agents, constrain their access scope, and enforce policy on data rather than tool names.

Key terms

• Shadow AI Agent Access: AI agent access that reaches a system through an unmanaged or non-federated path instead of the corporate identity provider. The result is activity that may be real and risky, but remains outside normal identity governance, review, and certification processes.
• 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.
• Data Lineage: The record of how data moves across systems, applications, and workflows. In security operations, lineage shows where sensitive data propagates, which identities touch it, and how a compromise could spread across connected environments.
• Endpoint Telemetry: Endpoint telemetry is the process and event data collected from managed devices to understand local activity. For shadow AI, it includes process spawns, file access, and direct outbound calls from the operating system, giving security teams visibility that network tools and SaaS logs often miss.

What's in the full article

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

• A step-by-step discovery workflow for endpoint-level agent visibility and classification
• Operational examples of how to map MCP servers to connected agents and access scopes
• Specific data-layer policy patterns for restricting sensitive file access and model transmission
• The product framing for continuous monitoring, lineage, and real-time enforcement

👉 Cyberhaven's full post covers endpoint visibility, MCP mapping, and data-layer enforcement in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and agentic AI identity. It helps security practitioners build the governance foundation needed for autonomous software, secrets, and access control programmes.