What is the difference between shadow AI and shadow IT?

Shadow IT is the use of unsanctioned SaaS applications. Shadow AI is the use of unsanctioned AI tools. The architectural difference is where the data leaves. Shadow IT exfiltrates documents through SaaS upload, which DLP can sometimes inspect. Shadow AI exfiltrates prompt content through HTTPS POSTs to model APIs, which DLP cannot inspect at the prompt level.

Why is shadow AI more expensive per incident than standard breaches?

IBM Cost of Data Breach attributes the $670,000 incremental cost to longer detection time (247 days vs 241 days), higher PII exposure rate (65% vs 53%), and the difficulty of remediation once data has entered a model provider's training or operational logs. The data cannot be recalled in the way a leaked database snapshot can be quarantined.

Can browser controls or endpoint DLP solve shadow AI?

Browser controls and endpoint DLP catch some of the direct-consumer-AI case but miss the embedded-AI-in-SaaS case, the agent and copilot internal deployment case, and the off-managed-device case. The structural answer is the AI request boundary, not the browser or the endpoint.

What does an inventory of AI use look like?

An AI inventory lists every AI endpoint the enterprise calls, the identity of the calling principal, the data classification of the prompts and responses, the policy version in force, and the outcome of each decision. The inventory is not a spreadsheet maintained by procurement. It is a structured record produced by the enforcement layer, updated per request.

How does shadow AI affect HIPAA, SOX, and PCI compliance?

Each regime has a record-of-access expectation. Shadow AI produces no such record by definition. The HIPAA covered entity, the SOX audit committee, and the PCI auditor each expect a trail. The enforcement layer at the AI request boundary produces the trail; the application that ran the AI call cannot.

Is blocking AI tools at the firewall a sufficient response?

It blocks one vector and pushes users to other vectors. Personal hotspots, off-VPN browsing, mobile devices. The structural answer is to channel AI traffic through an enterprise AI gateway, not to wall off the traffic at the network perimeter.

Shadow AI in the Enterprise: Definition, Mechanism, and the Architecture That Closes the Gap

IBM's Cost of Data Breach Report, based on a study of 600 breached organizations, found that one in five experienced breaches linked to shadow AI. Those breaches cost $670,000 more on average than standard breaches. Customer PII exposure rose to 65% in shadow AI breaches compared with 53% across all breaches. Detection time stretched to 247 days, six days longer than the all-breach median. Cloud Radix found that 78% of employees use unauthorized AI tools at work, 77% of those users admit to pasting sensitive business data into the prompts, and 86% of IT leaders are completely blind to these interactions. 90% of CISOs identify shadow AI as their top security concern for the year.

The numbers describe a category problem. The mechanism is what makes the category solvable. I want to walk through what shadow AI actually is, why the security stack of three years ago is structurally blind to it, and the architecture pattern that contains the blast radius.

Shadow AI

Shadow AI is the use of AI tools inside an enterprise without authorization, oversight, or governance from the security or compliance organization. The use can be direct: an employee pastes source code into ChatGPT through a browser. The use can be indirect: a SaaS vendor adds an embedded AI feature to a product the enterprise already uses, and the feature begins consuming customer data on the next release.

Three operational vectors carry most of the risk:

Direct consumer AI use. Employees with ChatGPT, Gemini, Claude, or Copilot accounts paste internal data into prompts. The data travels as an HTTPS POST to the provider's API. The data leaves the regulated environment in the first request.
Embedded AI in SaaS. A SaaS feature added through a vendor release uses AI on data the SaaS already processes. The enterprise has no way to opt out at the data layer, only at the feature toggle layer, which the vendor controls.
Agent and copilot deployments not registered. Engineering teams stand up an agent or copilot for an internal use case. The deployment never enters the AI inventory because no inventory process exists.

The unifying property is that the AI call sits outside the deployer's visibility and outside the deployer's policy boundary. The traffic is happening; the deployer does not know it is happening, cannot inspect it, and cannot enforce policy on it.

DLP blind spot

Network-layer data loss prevention has been the standard answer to data exfiltration for fifteen years. For shadow AI it is structurally blind. The DLP product is not the problem; the architecture is.

Identity correlation fails at the API boundary

DLP correlates exfiltration to a user through network identity (IP, MAC, AD session) or document-level identity (file owner, label). API calls authenticated with personal API keys do not map cleanly to corporate identity. An engineer with a personal OpenAI key uses the key from a corporate laptop on the corporate network; the DLP sees an HTTPS POST to api.openai.com from that laptop, but the prompt content is in the request body, and the body is inside the TLS tunnel. The DLP sees encrypted traffic to an authorized destination.

Data classification fails at the prompt boundary

DLP classifies documents. A file labeled "confidential" is detected when it crosses the perimeter. A prompt is not a document. The prompt is the user's freeform composition of text inside the context window. The classification has to happen at the prompt level, against the actual content the user just typed, not against a label that was applied at file save time. DLP products are not designed for prompt-level classification.

Policy enforcement fails at the model API layer

DLP enforces on inspectable layers: SMTP, FTP, HTTPS file upload, USB. The AI call layer is HTTP POST to a model provider's API. The traffic is not on an inspectable layer in the DLP's worldview. The most a network DLP can do is block the destination entirely, which the enterprise will not do because the destination is api.openai.com and the enterprise is paying for an OpenAI enterprise license.

The combined effect: the DLP product is healthy, the dashboards are green, and the AI prompts containing source code, financial models, M&A material, and PHI leave the environment unobserved.

Governing shadow AI

The architecture that contains shadow AI sits at the AI request boundary as an enforcement layer. It evaluates every AI request before the request reaches a model and every response before the response reaches the user. It operates on prompt-level content, identity-level context, and policy-level rules.

AI traffic identification

The first capability is identifying that the traffic is AI traffic at all. A forward proxy with explicit AI provider routes catches direct consumer AI use. A network egress sensor with AI provider domain lists catches the same traffic from off-VPN devices. SaaS audit log ingestion catches embedded AI features in covered SaaS. A combination of the three produces a full inventory of AI calls leaving the environment.

Identity mapping

The second capability is mapping every identified AI call to a corporate identity. Service credentials map to the service account's owner. Personal API keys are blocked at the proxy; only authenticated calls through the enterprise SSO are permitted. SaaS-embedded AI calls inherit the SaaS user's corporate identity through OAuth federation.

Prompt-level classification

The third capability is classifying the actual prompt content against the enterprise's data sensitivity taxonomy. PHI, PII, source code, financial data, M&A material, customer lists. The classification runs in line with the request and produces a structured decision input.

Inline policy enforcement

The fourth capability is making the pass-or-block decision before the request reaches the model. Policy is identity-aware (this user's role), classification-aware (this prompt's sensitivity), and contextual (the model in scope, the time of day, the originating application). The decision is made at the AI request boundary as a deterministic policy evaluation, not as a probabilistic guardrail inside the model.

Tamper-evident audit record

The fifth capability is producing a signed, identity-bound audit record for every decision. The record survives application crash. The record is written by the enforcement layer, not by the application. The record is structured for SOC ingestion, regulator review, and incident reconstruction.

What shadow AI looks like in production environments

Three documented incident patterns illustrate the failure mode:

The Samsung source-code leak in 2023 (engineers pasted proprietary semiconductor design code into ChatGPT, the data left the perimeter through a browser to api.openai.com) is the canonical direct-consumer-AI case. The enterprise had DLP. The DLP did not see the traffic. The internal policy banning the use existed; the enforcement did not.

The Meta March 18, 2026 Sev-1 (internal AI agent exposed sensitive user and company data to engineers who should not have seen it, fully authenticated) is the canonical post-authentication-gap case. The users were authenticated. The agent was authorized. The specific prompt-level action of returning data outside the requesting user's authorization scope was not policy-evaluated.

The healthcare SOAP-notes case (57% of healthcare professionals use unauthorized AI to process PHI per Cloud Radix) is the canonical embedded-and-direct hybrid. Some PHI flows through SaaS-embedded clinical AI features the deployer enabled. Some flows through ChatGPT in a browser. Both vectors produce HIPAA exposure. Both are invisible to network DLP.

Regulatory framing

EU AI Act Article 12 requires automatic logging over the lifetime of high-risk AI systems. A shadow AI deployment by definition is unlogged and ungoverned, which means high-risk shadow AI exposes the deployer to the full Article 99 penalty tier (up to €15 million or 3% of global annual turnover). Article 26 makes the deployer liable for the operational obligations.

HIPAA's audit-trail expectations require a record of who accessed PHI and under what authority. Shadow AI handling of PHI produces no such record. NIST's AI agent identity and authorization framework splits AI security into three pillars; shadow AI by definition fails Pillar 1 (identity context) and Pillar 3 (action lineage).

Fannie Mae Lender Letter LL-2026-04 requires AI inventory and governance from mortgage lenders. Shadow AI inside a lender breaks the inventory obligation at the first instance.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits in line between authenticated users or agents and LLM APIs they call. Every request is evaluated against identity, role, prompt-level classification, model authorization, and organizational policy. Enforcement happens at the AI request boundary as a deterministic policy decision. The audit record for every decision is signed, written by DeepInspect rather than by the application, and structured for SOC ingestion.

DeepInspect is model-agnostic. The same enforcement layer covers OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, self-hosted Llama, and self-hosted Mistral endpoints. Shadow AI from any of those routes lands inside the policy decision point rather than outside it.

How exposed is your AI? Take the 3-minute readiness check.