Notifications
Clear all
Topic starter
02/08/2026 11:23 am
TL;DR: Shadow agents are autonomous AI agents running locally or through MCP servers without IT or security approval, and Cyberhaven says they bypass browser proxies, SSO logs, and legacy DLP channels that were built for human-paced activity. The governance model fails when agents can read, call, write, and transmit data at machine speed without a human-in-the-loop checkpoint.
NHIMG editorial — based on content published by Cyberhaven: What Are Shadow Agents and Why Are They a Security Risk?
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory endpoint-running agents and MCP connections Build a live register of local agents, coding assistants, and MCP servers across endpoints and development environments.
- Move monitoring below the browser layer Use endpoint telemetry that can observe process behaviour, file-system reads, and direct API calls.
- Scope agent permissions to task boundaries Review file, API, and repository access granted to agents and remove broad defaults that exceed the task.
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
👉 Read Cyberhaven's analysis of shadow agents and endpoint AI governance →
Shadow agents and endpoint AI risk: are your controls keeping up?
Explore further
02/08/2026 12:40 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Shadow agents expose the limits of browser-era AI governance
