Shadow agents expose the limits of browser-era AI governance

At a glance

What this is: Shadow agents are unsanctioned autonomous AI agents on endpoints and local systems that create a governance blind spot because they operate outside the controls designed for browser-based AI use.

Why it matters: They matter because IAM, DLP, and AI governance teams need visibility and policy at the endpoint and agent level, not just at the browser, proxy, or SaaS boundary.

By the numbers:

• Endpoint-based AI agents grew 509% in 2025, according to Cyberhaven.
• 49.5% of developers use AI coding assistants, according to Cyberhaven.

👉 Read Cyberhaven's analysis of shadow agents and endpoint AI governance

Context

Shadow agents are autonomous AI agents that operate inside an enterprise without formal approval, usually on endpoints, local servers, or development environments. The primary governance problem is not just unauthorised AI use, but identity and access control that was built around human-paced interaction, browser access, and known egress paths.

That model breaks when an agent can read files, call APIs, write to repositories, and move data without a user taking each step. For IAM, NHI, and agentic AI programmes, the issue is visibility into the actor, the permissions it holds, and the data paths it can reach.

The article frames shadow agents as a subset of shadow AI, but with a materially different risk profile because autonomy removes the human checkpoint. That makes endpoint discovery, agent-level policy, and data lineage more central than browser-centric monitoring alone.

Key questions

Q: How should security teams govern shadow agents in production workflows?

A: Security teams should govern shadow agents as first-class identities with explicit ownership, a bounded purpose, and enforceable revocation. The priority is to make the agent discoverable, tie it to the systems it touches, and review cumulative access over time. If the agent cannot be inventoried and revoked, it should not be trusted in production.

Q: Why do shadow agents create a bigger risk than ordinary automation?

A: Shadow agents create more risk because their authority can expand quietly as teams adapt them to new tasks. Ordinary automation usually has a narrower, more fixed control path. Shadow agents can cross systems, accumulate permissions, and continue acting without a clear owner, which makes accountability and containment much harder.

Q: What breaks when traditional DLP is used alone for AI security?

A: Traditional DLP misses much of the risk because prompts, browser submissions, and generated outputs do not always look like file transfers. It also struggles with inference risk, where harmless inputs combine into a sensitive result. AI security needs lineage, context, and identity-aware controls, not only pattern matching.

Q: Who is accountable when AI search exposes sensitive enterprise data?

A: Accountability sits with the teams that approved the data connections, retrieval scope, and response handling, not just the users who queried the system. Governance should cover access design, provenance controls, and operational monitoring across identity, search, and AI platform owners.

Technical breakdown

Why browser proxies and SSO logs miss shadow agents

Browser proxies and SSO logs are built to observe user sessions that start in a browser and traverse known access paths. Shadow agents often run locally, call APIs directly, and interact with files, processes, and internal tools outside those channels. That means the control plane sees the user who installed the agent, but not the agentic behaviour that actually moves the data. In identity terms, this is an actor and execution mismatch: the human authorises installation, but the software executes independently afterward. Traditional visibility tools therefore overstate control coverage while missing the real runtime behaviour.

Practical implication: move discovery and monitoring to the endpoint and process layer, where the agent actually acts.

How MCP changes the access model for AI agents

Model Context Protocol lets agents connect to tools and data sources programmatically, which is useful only if those connections are governed as identities, not just integrations. When teams stand up MCP servers without review, they create a new access path that may bypass sanctioned channels and normal entitlement scrutiny. The technical issue is not MCP itself, but the fact that it can expand the action surface of an agent beyond what a browser policy or SaaS audit log was built to capture. That makes agent-to-tool trust a first-class governance problem.

Practical implication: inventory MCP-connected agents and treat each connection as an identity-bearing access path.

Why legacy DLP cannot reliably detect agent-driven data movement

Legacy DLP was tuned for file uploads, email, USB, and browser egress. Shadow agents move data through local API calls, interprocess reads, process memory, and MCP traffic, which do not always resemble classic exfiltration patterns. They also operate at machine speed, so a volume threshold calibrated for a person can under-detect the same action when an agent executes it in seconds. The result is a detection gap between sanctioned browser activity and unsanctioned endpoint activity. Data lineage helps close that gap by tracing source, transformation, and destination across the full movement path.

Practical implication: supplement DLP with data lineage and OS-level telemetry that can follow non-browser data paths.

Threat narrative

Attacker objective: The attacker objective is to use an unsanctioned autonomous agent as a high-speed data access and exfiltration path that avoids standard visibility and control points.

1. Entry occurs when an employee installs a local coding agent, connects an MCP server, or enables a workflow agent on an endpoint without security approval. Escalation begins when that agent is granted file-system, API, or repository access broader than the task requires. Impact follows when the agent reads, transforms, or transmits sensitive data at machine speed through paths that legacy controls do not monitor.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow agents are not just another shadow AI problem. They are autonomous identities with runtime authority that legacy AI governance was never designed to observe. A browser proxy can tell you what a user did in a browser session, but it cannot reliably tell you what a locally running agent did across files, APIs, and repositories. That is why shadow agents turn identity governance into an endpoint problem as much as an access problem. Practitioners should treat agent runtime behaviour as the primary control surface, not an edge-case extension of SaaS oversight.

Endpoint AI governance is now a visibility discipline, not a policy document. The article correctly shows that agents can move data through process memory, local reads, and direct API calls without generating the signatures that legacy DLP expects. That creates a new governance gap: the organisation may have policy, but no observation point that matches how the actor really behaves. The practical implication is that discovery and lineage must precede enforcement, because you cannot govern what you cannot see.

Human-in-the-loop assumptions collapse when a software actor can execute multi-step actions independently. The assumption that a person decides each material data movement was designed for human-paced workflows. That assumption fails when the actor is autonomous because the agent can chain reads, tool calls, and writes without per-step approval. The implication is that security teams must rethink review cadences and entitlement models around runtime actors rather than human session boundaries.

Shadow agent sprawl: local, unsanctioned agent deployments create an identity estate that security teams cannot enumerate through traditional SaaS controls. The article shows that endpoint-based AI agents, MCP servers, and embedded pipeline agents all expand the reachable identity surface. That means programme owners need a named concept for the problem itself, not just a generic AI risk label. Once the estate cannot be enumerated, least privilege becomes an aspiration rather than an enforceable control boundary.

Governing shadow agents requires IAM, NHI, and AI governance to converge on the same runtime artefact. The agent is both a software identity and an execution actor, so isolated controls from IAM, DLP, or AI policy will miss part of the risk picture. A mature programme ties discovery, data lineage, and access policy to the same runtime event stream. That is the only way to keep legitimate agentic use from becoming uncontrolled data access.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• A separate finding from the same research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility.
• For a deeper lifecycle lens, see Ultimate Guide to NHIs, why NHI security matters now for the broader pressure driving governance change.

What this signals

Shadow agent sprawl: once agents are running locally, the control problem shifts from authorisation at the browser edge to discovery at the endpoint. Organisations that still depend on proxy-only oversight will undercount the real identity estate and miss the runtime behaviour that matters most.

The programme signal is clear: IAM, NHI, and AI governance teams need a shared view of runtime actors, permissions, and data movement. With only 1.5 out of 10 organisations highly confident in securing NHIs, the gap is not just technical. It is also organisational, because the same actor can now look like an endpoint, an identity, and an AI control problem at once.

For practitioners

• Inventory endpoint-running agents and MCP connections Build a live register of local agents, coding assistants, and MCP servers across endpoints and development environments. Capture who installed them, what data sources they can reach, and which business systems they can call.
• Move monitoring below the browser layer Use endpoint telemetry that can observe process behaviour, file-system reads, and direct API calls. Browser proxy logs alone will miss the data paths shadow agents actually use.
• Scope agent permissions to task boundaries Review file, API, and repository access granted to agents and remove broad defaults that exceed the task. Treat standing access as a governance failure when the agent can act without a human checkpoint.
• Add data lineage for agent-driven movement Trace how sensitive data moves from origin to destination when an agent reads, transforms, or forwards it. Lineage gives incident responders the evidence needed to distinguish misconfiguration from misuse.

Key takeaways

• Shadow agents expose a governance blind spot because they act outside the browser and outside the review model built for human-paced access.
• The risk is amplified by runtime autonomy, which lets agents chain file reads, API calls, and writes without the visibility legacy DLP expects.
• Security teams need endpoint discovery, agent-level policy, and data lineage to govern these actors in a way that matches how they actually behave.

Key terms

• 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.
• Endpoint-Level Policy: Authorization logic that evaluates a specific API or tool action at the moment of execution rather than only at exposure time. It can account for delegating identity, resource scope, intent, and approval state, which is essential when one tool catalog contains mixed-risk actions.
• 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.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.

What's in the full article

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

• Endpoint-level visibility mechanics for identifying shadow agents in active use
• Data lineage workflow details for tracing reads, writes, and downstream exposure
• Policy enforcement examples for restricting agent access to sensitive destinations
• Operational differences between browser-based AI monitoring and OS-level monitoring

👉 Cyberhaven's full post covers endpoint visibility, Data Lineage, and agent-level policy detail.

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.