Notifications
Clear all
Topic starter
02/08/2026 11:25 am
TL;DR: Shadow AI persists because governance programs were built for human-initiated actions and known data channels, while AI tools and agents operate autonomously across endpoints and APIs, according to Cyberhaven. The real control gap is architectural: visibility, data-layer enforcement, and continuous inventory matter more than awareness campaigns or approved-tool lists.
NHIMG editorial — based on content published by Cyberhaven: Shadow AI Is Not a People Problem. It's a Governance Problem
By the numbers:
- Endpoint agents grew 509% in 2025.
Questions worth separating out
Q: How should security teams govern shadow AI without blocking productivity?
A: Use visibility-based controls instead of blanket bans.
Q: Why do acceptable use policies fail to control shadow AI?
A: Because policies govern people, while many AI tools now act as software entities that operate with their own runtime behaviour.
Q: What breaks when AI agents are approved only once at deployment?
A: Point-in-time approval breaks when an agent’s capabilities, integrations, or data access change after review.
Practitioner guidance
- Implement continuous AI tool inventory Track browser-based tools, locally installed agents, and MCP-connected services across managed and unmanaged endpoints so shadow AI is visible before data moves.
- Enforce data-layer policy controls Apply controls to the data itself rather than only to approved destinations, so prompts, file reads, and API-bound transfers are evaluated in context.
- Assign identity ownership to AI agents Define who owns each agent, what it may access, how long its access lasts, and what terminates it when the task ends.
What's in the full article
Cyberhaven's full blog post covers the operational detail this post intentionally leaves for the source:
- Endpoint visibility methods for detecting browser-based AI tools, local agents, and MCP-connected services in real environments.
- Data Lineage workflow detail showing how sensitive data is traced from source file to prompt, API call, and downstream output.
- Risk-differentiated governance examples for separating routine AI use from high-risk sessions that touch regulated or contractual data.
- Practical guidance on policy enforcement at the data layer instead of relying only on destination blocking.
👉 Read Cyberhaven's analysis of why shadow AI is a governance problem →
Shadow AI and agentic tools: what governance gap are teams missing?
Explore further
02/08/2026 12:42 pm
Shadow AI is now an identity governance issue, not just an acceptable-use issue. The article is right to reject the idea that training alone will control AI adoption. When AI tools can access data, call APIs, and operate inside endpoints, they behave like governed software identities and must be treated as such. That shifts the programme from policy compliance to lifecycle control, with ownership, scope, and review tied to actual runtime behaviour.
A question worth separating out:
Q: Who is accountable when an AI-assisted workflow leaks sensitive data?
A: Accountability sits with the organisation that allowed the workflow to operate outside governed controls. Security, IAM, and business owners all share responsibility for ensuring approval, logging, and lifecycle management exist before data moves through the path. If no one can block or revoke it, no one is governing it.
👉 Read our full editorial: Shadow AI is a governance gap, not a training failure
