Shadow agents expose the limits of browser-era AI governance

At a glance

What this is: Shadow agents are autonomous AI agents that run outside approved channels, and Cyberhaven says they bypass the controls built for browser-based AI use.

Why it matters: IAM, NHI and security teams need to govern where agent permissions are granted, how endpoint activity is observed and which data paths exist outside proxy and SSO visibility.

By the numbers:

• endpoint-based AI agents grew 509% in 2025

Context

Shadow agents are autonomous AI agents that operate on endpoints, local servers or development environments without formal IT or security approval. The governance problem is that most existing AI controls still assume browser-mediated activity, visible logins and a human deciding each step.

That assumption no longer holds when an agent can read files, call APIs, write to repositories and move data without per-step human authorization. For identity and access teams, this is an NHI governance problem first and a visibility problem second.

Cyberhaven’s analysis treats shadow agents as a distinct risk category within shadow AI, not just another tool adoption issue. That distinction matters because the control surface shifts from browser and SaaS policy to endpoint, process and data-flow governance.

Key questions

Q: What breaks when shadow agents are allowed to run outside approved controls?

A: Browser proxies, SSO logs and legacy DLP stop providing a reliable record of what the agent is doing. The result is that an autonomous process can read, call, write and transmit data without a reviewable human action trail, which leaves security teams governing a system they cannot actually see.

Q: Why do shadow agents create a different risk profile from other shadow AI use?

A: Because the agent removes the human-in-the-loop checkpoint. A person using an unauthorised AI tool still decides each disclosure, but an autonomous agent can repeat actions across files, APIs and repositories at machine speed once it has standing access.

Q: What are the signs that endpoint governance is failing?

A: The warning signs are fragmented inventories, repeated portal switching, inconsistent policy enforcement, and devices reaching resources without clear posture validation. If different teams cannot answer the same question about encryption, antivirus, or device health, endpoint governance is already too fragmented to support reliable access control.

Q: Should organisations treat MCP connectors like ordinary integrations?

A: No. MCP connectors often carry delegated access into multiple tools and data stores, which makes them part of the identity control plane. They should be registered, scoped, monitored, and offboarded like any other privileged machine identity, otherwise a compromise in one connector can expand into broader system access.

Technical breakdown

Why browser proxies miss endpoint agent activity

Browser proxies and SSO logs were designed to observe user sessions that begin and end through sanctioned web access. Shadow agents often execute locally, call APIs directly and move data through process memory or local interprocess communication, so the traffic never becomes a browser event. That means the control point is wrong for the behavior being governed. The same limitation applies to legacy DLP, which looks for uploads, email attachments and known SaaS egress rather than agent-driven reads and writes. Practical implication: security teams need endpoint-level visibility if they want to see agent activity at all.

Practical implication: move discovery and monitoring closer to the endpoint and process layer, not only the browser or network edge.

How MCP servers expand the AI access surface

Model Context Protocol lets an agent call tools and access data sources programmatically. That is useful when governed, but it also creates a new class of sanctioned-looking access path that can be stood up outside security review. In practice, MCP servers can connect agents to internal systems, repository content and operational data with permissions that were never assessed as a distinct identity boundary. The risk is not the protocol itself, but the new delegation layer it introduces. Practical implication: treat MCP-connected agents as governed identities with explicit review, not as simple app integrations.

Practical implication: inventory MCP-connected agents and review their delegated access as you would any other non-human identity.

Why human-paced DLP thresholds fail for autonomous agents

Traditional DLP heuristics are calibrated to human behavior, where large transfers and repeated access typically unfold over minutes or longer. Shadow agents can complete the same operations in seconds, which means the same data movement looks normal if the policy expects a person-sized cadence. That is why the article frames this as a mismatch between machine-speed execution and human-speed detection. The problem is compounded when the agent is approved by the employee who installed it rather than by security. Practical implication: tune controls for agent speed and task volume, not only human interaction patterns.

Practical implication: build detections around machine-speed task completion and unusual permission scope, not only transfer volume.

Threat narrative

Attacker objective: The objective is to obtain continuous access to internal data and move it across systems without triggering the controls designed for browser-based AI use.

1. Entry occurs when an employee installs a local agent, connects an MCP server or embeds an agent in a pipeline without security approval.
2. Credential and data access follow when the agent receives broad file-system, API or cloud permissions through that installation path.
3. Escalation happens as the agent reads, calls, writes and transmits data across multiple systems without per-step human authorization.
4. Impact is sustained data movement or exfiltration that bypasses browser proxies, SSO logs and legacy DLP visibility.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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

Browser-era AI governance is structurally mismatched to endpoint agents. Most organisations built their AI controls around web sessions, proxy inspection and SSO logging. Shadow agents operate below those layers, so the governance model is observing the wrong plane of activity. The practitioner takeaway is that discovery, authorization and monitoring must move to the endpoint and process level if the programme is meant to govern autonomous behaviour at all.

Shadow agents are an NHI governance problem before they are an AI policy problem. Once an agent runs locally or through MCP, it behaves like a non-human identity with delegated access to files, APIs and repositories. That means inventory, ownership, access scope and offboarding become the decisive controls, not just acceptable-use policy. The implication is that IAM and NHI teams need the operating model, not just the AI policy language, to own this category.

Runtime permissions are the real control boundary for shadow agents. The article shows that employees can approve broad access at install time and then forget the agent is still active. That creates permission persistence without oversight, which is exactly where governance breaks down. The practitioner conclusion is to re-evaluate how access is granted, reviewed and revoked for agentic workloads that can act faster than human review cycles.

Shadow agents expose an identity blast radius problem. When a single agent can read local files, call external APIs and write into repositories, the same delegated identity can cross multiple trust zones in one task. That means blast radius is no longer defined only by privilege level but by how many systems the agent can touch before anyone notices. Security teams should treat this as a containment and segmentation issue inside the identity layer, not as a narrow DLP event.

Shadow AI and shadow agents are not the same governance problem. A person using an unauthorized AI tool still leaves a human decision point in the loop. A shadow agent removes that checkpoint and replaces it with autonomous execution, which breaks the assumptions behind browser controls, user-centric audits and manual approvals. Practitioners need to separate conversational AI adoption from agentic execution, because the control model is different even when the underlying model family is similar.

From our research library:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Endpoint presence is becoming the governance boundary for AI use. If security teams only watch browsers, SaaS logs and sanctioned platforms, they will miss the class of agentic activity that actually touches enterprise data. The control model now has to account for process-level reads, writes and API calls on managed devices, because that is where shadow agents operate.

Shadow agents turn access review into a poor fit for runtime governance. Reviews assume privileges persist long enough to be sampled, certified and remediated. Agents that acquire broad permissions for a short task can complete the work and move on before any review cycle can act, so issuance-time control matters more than retrospective recertification.

According to the State of Secrets Sprawl 2026, 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks. That pattern reinforces the broader point here: the most important exposure paths are often the ones legacy monitoring assumes are low-risk or outside scope.

For practitioners

• Map endpoint-installed agents and MCP servers Create an inventory of locally installed agents, development assistants and MCP-connected services across user endpoints and developer machines. Record who approved them, what data sources they can reach and whether security has reviewed the deployment.
• Move discovery to the operating system layer Use endpoint telemetry to identify which processes are reading files, calling external APIs or writing to repositories, because browser and proxy logs will miss that activity. Prioritise processes with agent-like behavior and no formal governance record.
• Review delegated permissions as non-human identity scope Treat agent permissions as identity scope, not app settings, and evaluate whether file-system, clipboard, cloud and repository access matches the minimum task requirement. Revoke broad access that persists after the initial install or test use.
• Tune detections for machine-speed behavior Update alerting logic so it looks for fast, repeated reads and writes, unusual process-to-API activity and data movement that would be normal for a human only over a much longer period. Calibrate thresholds around task completion speed, not user typing speed.

Key takeaways

• Shadow agents are risky because they execute outside the browser and outside the human-paced oversight model that most AI governance programmes still rely on.
• The main failure is visibility and delegation, not model capability. Once an agent has local or MCP-based access, it can move data across systems without leaving the logs teams expect.
• Practitioners should govern shadow agents as endpoint-bound non-human identities, with inventory, scoped permissions and process-level monitoring at the center of the programme.

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.
• Runtime AI Governance: Runtime AI governance is control applied while the interaction is happening, rather than before deployment or after an incident. It combines discovery, policy enforcement, output inspection, and audit logging so that AI use can be managed in live enterprise conditions.
• Human-in-the-Loop (HITL): A governance pattern requiring human approval before an AI agent takes high-impact, irreversible, or out-of-scope actions. HITL is a critical control for agentic AI identity governance.
• 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.

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 identity security programme, it is worth exploring.