Shadow AI for the CISO: The Three Boards a Detection Program Has to Cover
Cloud Radix data shows 90% of CISOs rank shadow AI as their top security concern for the year. The detection program has to cover three boards a typical detection stack does not look at: browser extensions, IDE plug-ins, and chat-platform apps. This piece walks through the three populations, the detection signal for each, the regulatory exposure under EU AI Act Article 26 and HIPAA, and the policy enforcement layer that closes the loop after detection.
Cloud Radix data shows 90% of CISOs rank shadow AI as their top security concern for the year. 78% of employees use unauthorized AI tools at work. 77% admit to pasting sensitive business data into unsanctioned models. 86% of IT leaders are completely blind to these interactions. The detection problem is large, and the detection programs most organizations have running today were designed around the classical shadow-IT pattern: cloud-app discovery via DNS and proxy logs. Shadow AI hides in three additional populations the classical detection stack does not look at: browser extensions, IDE plug-ins, and chat-platform apps.
I want to walk through the three populations, the detection signal for each, the regulatory exposure that follows, and the enforcement layer that closes the loop after detection lands.
Shadow AI
Shadow AI is the population of AI tools employees use without IT or security sign-off, often without the deployer's knowledge that AI is involved at all. The category is broader than shadow IT in two ways. AI features are embedded inside tools the organization has already sanctioned (Slack's AI search, Google Drive's Gemini features, Notion's AI summarization). And AI access often runs through personal accounts, personal API keys, or browser extensions that authenticate independently of the corporate identity.
IBM's Cost of Data Breach report studied 600 breached organizations and found one in five experienced breaches linked to shadow AI. Shadow AI-linked breaches cost $670,000 more on average. Customer PII exposure jumped to 65% in shadow AI breaches versus 53% across all breaches. Detection takes 247 days, six days longer than standard breaches.
Three populations the classical detection stack misses
The classical shadow-IT detection stack looks at three signals: DNS for unsanctioned domains, proxy logs for unsanctioned destinations, and OAuth consent grants for unsanctioned applications. These signals work for shadow cloud apps. They miss three populations specific to AI.
Population 1: Browser extensions
A material share of personal AI use today happens through browser extensions that authenticate to AI services using the user's personal credentials. ChatGPT browser plugins, Claude browser extensions, Copilot-in-browser tools, AI-summarization extensions for email and Slack. The traffic looks like normal browser traffic to the corporate proxy. The destination is the AI provider's domain, which may or may not be on a block list. The OAuth consent grant, if any, is to a personal account.
Detection signal
Endpoint detection has the right vantage. The corporate endpoint sees the extension installed, the extension's manifest, and the extension's network calls. EDR products can enumerate browser extensions per host. The detection rule: flag installed extensions whose manifest declares access to AI provider domains or that match a maintained list of AI-extension IDs from the Chrome Web Store and Firefox Add-ons.
Why proxy and DNS miss this
The user's browser handles the TLS termination. The proxy sees the destination domain but not the prompt content. DNS sees the lookup. Neither shows whether the request came from the corporate-sanctioned ChatGPT account or the user's personal one, and neither shows what was in the prompt.
Population 2: IDE plug-ins
Engineers integrate AI assistants directly into the IDE. GitHub Copilot, Cursor, Claude inside VS Code, Windsurf, AI-coding plug-ins for JetBrains. The plug-ins authenticate to AI services using OAuth tokens or API keys held inside the IDE. The traffic goes from the developer machine to the AI provider, often over personal accounts.
Detection signal
Endpoint inventory of installed software shows the IDE plug-ins. Outbound network monitoring catches the destination. Corporate identity-provider audit logs catch the OAuth grants if the developer used the corporate account. Personal-account use does not show up in the IdP logs at all.
The detection rule combines two signals. First, enumerate installed AI IDE plug-ins via endpoint inventory. Second, correlate with the corporate IdP audit log for OAuth grants to AI domains. The diff (installed plug-in but no corporate IdP grant) is the personal-account use.
Population 3: Chat-platform apps
Slack, Microsoft Teams, Discord, and similar platforms host AI apps that users add to channels. The app authenticates through the platform's app surface, with permissions to read messages and to call the underlying AI provider. The traffic flows inside the chat platform's tenancy and is often invisible to the corporate proxy.
Detection signal
The chat platform's audit log captures the app installation, the permission grants, and the message-read activity. Slack's Enterprise Grid audit logs, Microsoft's audit logs in Purview, and Discord's audit logs at the server level. The detection rule: query the chat platform audit log for AI app installations and verify against the sanctioned list.
Why the corporate proxy misses this
The chat platform is the transport. The AI app reads messages and calls AI providers from inside the chat platform's network, not from the user's endpoint. The corporate proxy sees the user logged into Slack. It does not see the AI app's outbound calls.
Compliance gap
Shadow AI detection that covers the three populations above closes the visibility gap. It does not close the enforcement gap, which is where the regulatory exposure sits.
EU AI Act Article 26 deployer obligations
Article 26 makes the deployer responsible for ensuring high-risk AI systems are used in accordance with the instructions for use, with human oversight, with relevant logs, and with input data that is relevant for the intended purpose. If an employee is using an unsanctioned AI tool to process customer data, the deployer is in default on each of these obligations. Detection identifies the gap. Enforcement closes it.
HIPAA exposure
Cloud Radix data shows 57% of healthcare professionals use unauthorized AI to process PHI without a Business Associate Agreement. The HIPAA Security Rule audit controls under 164.312(b) require recording of access to ePHI. Personal-account use of AI tools for PHI work satisfies none of the audit-control requirements. Detection without enforcement leaves the violation in place.
The 22-second argument
Detection is a forensic capability. By the time the detection signal fires, the data has reached the model. Inline enforcement is the only control that prevents the data from reaching the model in the first place. The Mandiant M-Trends 2026 finding that the median time between initial access and handoff to a secondary threat group is now 22 seconds applies here: at machine speed, the gap between detection and prevention is structural.
DeepInspect
This is the architecture DeepInspect was built to provide. DeepInspect sits at the AI request boundary as a stateless proxy between any application and any LLM. The detection signals from EDR, IdP, and chat-platform audit logs identify the shadow AI surface. The enforcement layer at the AI request boundary controls what the corporate identity can do with the model.
The deployment pattern for shadow AI control has two halves. Detection: maintain visibility into the three populations through EDR-driven extension inventory, IdP audit on OAuth grants, and chat-platform audit on AI app installs. Enforcement: route sanctioned AI calls through the AI gateway with identity-bound policy and per-decision records. Unsanctioned calls (personal accounts, personal API keys, unsanctioned extensions) are blocked at the network or endpoint layer. Sanctioned calls go through the gateway where the policy decides whether the prompt content is permitted.
The detection program is necessary. The enforcement layer is what stops the next incident. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- How do I prioritize among the three populations as a CISO?
The right prioritization depends on the workforce. For a heavily engineering-oriented organization, IDE plug-ins are the highest-volume vector and often the highest-risk because source code is leaving the environment. For a knowledge-work organization, browser extensions tend to dominate. For an organization with heavy chat-platform use, the chat-platform AI app surface is the population most likely to process customer or employee data without governance. The most common pattern is to run discovery across all three in parallel and prioritize policy work on the population with the highest exposure to regulated data. A single quarter of discovery typically clarifies which population the policy work should focus on.
- Does the AI provider's enterprise plan solve the problem?
The enterprise plan changes the contractual surface but not the architectural one. An employee on a ChatGPT Enterprise plan still pastes the same data into the same prompt. The data still leaves the environment. The contractual protections improve the disclosure obligations and reduce the litigation exposure but do not change what the model sees or the per-decision audit record at the deployer's gateway. The enterprise plan plus the gateway is the combined story: contractual protection plus architectural enforcement plus per-decision records. The enterprise plan alone leaves the architectural and records gaps in place.
- What's the right relationship between shadow AI detection and DLP?
Network-layer DLP runs underneath the TLS encryption that protects AI traffic. It cannot inspect the prompt content. DLP gives the CISO a partial signal (a connection to an AI provider domain) and no visibility into what was sent. The right relationship is to use DLP for traffic-level visibility and a gateway at the AI request boundary for content-level decisions. The two are not interchangeable. A DLP rule on the AI provider domain catches the traffic; the gateway catches the policy violations inside the prompt.
- How does this map to the OWASP Top 10 for Agentic Applications?
The OWASP Top 10 for Agentic Applications framework lists ten categories of risk specific to agentic AI deployments. Several of them (excessive agency, identity spoofing, prompt injection at the boundary) are operationalized by the same enforcement pattern shadow AI control uses: identity at the request, classification at the prompt, policy at the gateway, records at the decision. The CISO running a shadow AI program is implementing controls that satisfy multiple OWASP categories at once. The framework is useful as a board-level reference. The control implementation is what closes each category.
- What's the smallest defensible shadow AI program for a 500-person organization?
The minimum viable program has three components. Detection across the three populations using EDR, IdP audit logs, and chat-platform audit logs (the data sources are already in place at most 500-person organizations). A sanctioned AI gateway that the corporate identity provider directs all corporate AI traffic through. A monthly review of the detection signal that identifies the gap between sanctioned use (through the gateway) and unsanctioned use (everything else). The review feeds policy decisions about which AI surfaces to permit, which to deny, and which to bring under the gateway. The program scales with the workforce; the architecture stays constant.