Can a CASB cover shadow AI detection?

A CASB enforces SSO against sanctioned SaaS apps and inspects API calls to specific storage and collaboration platforms. The CASB's policy surface was built against OAuth-mediated access patterns, not against per-request identity-bound prompt inspection on LLM endpoints. The CASB can flag new app usage and enforce session controls. It cannot capture the prompt body the regulator expects to see in a per-decision record.

How does shadow AI detection handle browser-side use against personal accounts?

Browser-side use against a personal account bypasses the corporate IdP and routes through a TLS session the corporate proxy may not be in the path of. The inspection layer at the HTTP boundary can only see traffic that traverses it. When the user routes around the corporate network, the control moves to the IdP (which can enforce SSO-only access to sanctioned AI apps and block personal-account login flows) and the acceptable-use policy with monitored attestation. The architecture for personal-device shadow AI is covered in the shadow AI monitoring piece.

Does the inspection layer affect LLM response latency?

End-to-end inspection overhead measures under 50 ms in DeepInspect's internal testing. LLM inference takes 500 ms to 5 seconds depending on the model and the request size. The inspection overhead sits inside the variance of the inference round-trip, so user-perceived latency does not move when the inspection layer goes inline.

What is the difference between shadow AI detection and shadow AI prevention?

Detection produces the inventory and the record. Prevention sits one step further: the inspection layer evaluates policy against the identity and the classification, and returns permit, redact, or block before the request reaches the model. The same inspection point that detects the use can prevent the use. Most organizations start in detection-only mode for the first thirty days to calibrate the policy against real traffic, then move the policy to enforce.

How does shadow AI detection map to NIST AI RMF?

NIST AI RMF's GOVERN function expects an inventory of AI systems in use. MAP expects classification of the use cases by risk tier. MEASURE expects ongoing metrics on the inventory and the policy outcomes. MANAGE expects a feedback loop between the measurement and the policy. The three-signal detection architecture (DNS, request shape, identity-bound prompt) feeds each of these four functions with the same evidence the EU AI Act Article 12 record references, which keeps the program coherent across regimes.

Shadow AI Detection: The Three Signals That Actually Identify Unauthorized LLM Use Inside the Enterprise

IBM's Cost of Data Breach Report studied 600 breached organizations and found that one in five experienced breaches linked to shadow AI, with shadow AI incidents taking 247 days to detect against the 241-day average for standard breaches. Cloud Radix found that 86% of IT leaders are completely blind to these AI interactions, and 78% of employees use unauthorized AI tools at work. The detection gap is not philosophical. It is mechanical: the prompt sits inside a TLS-encrypted POST body to a sanctioned SaaS endpoint, and every inventory tool the enterprise already runs terminates inspection before the body is in scope.

I want to walk through the three signals that actually identify shadow AI use, what each one captures, where each one stops, and the architectural placement that produces a per-request record auditors can sample.

Signal one: DNS resolution to LLM endpoints

DNS is the cheapest signal and the first one most security teams turn on. A DNS log captures every name resolution the corporate resolver answers. When a user's browser opens a session against api.openai.com, claude.ai, chat.openai.com, gemini.google.com, bedrock-runtime.us-east-1.amazonaws.com, or any of the dozens of LLM endpoints in active use, the DNS resolver sees the lookup. The detection rule is a maintained list of LLM hostnames matched against resolver logs, with a grouping by source IP or device identity.

DNS resolution tells you which workstation looked up which endpoint and when. It tells you nothing about who the user was at the moment of the lookup if the workstation is shared, nothing about what the user sent in the prompt, and nothing about whether the request actually went through (a lookup can be followed by a TLS handshake that fails or a request that the SaaS rate-limits). DNS is a coverage signal. It is the floor of detection, not the ceiling.

Signal two: HTTP request shape against published API contracts

HTTP request shape catches what DNS misses on the connection side. The OpenAI Chat Completions API, Anthropic Messages API, Google Generative AI API, and AWS Bedrock Runtime API each publish a request contract: the path (/v1/chat/completions, /v1/messages, /v1/models/<model>:generateContent), the required headers, and the JSON body schema. A network observer that can see TLS metadata and SNI can correlate a session to a published contract and infer that an LLM API call is in progress. With JA3/JA4 fingerprinting, the inference is tighter because the TLS handshake parameters distinguish the SDK from a generic browser session.

Request shape gives you a confidence-scored inventory of which LLM APIs are being called from which network segment over what time window. It does not give you the prompt content (the body remains encrypted), the natural-person identity (the API session uses a service credential or API key), or the decision context (whether the prompt carried PII, PHI, or source code). Request shape is the second floor of detection. It rules out false positives that DNS alone would not.

Signal three: identity-bound prompt content at the HTTP layer

The signal that closes the detection gap is the prompt content captured at the HTTP boundary between an authenticated user or agent and the LLM endpoint. The inspection layer terminates TLS at the proxy, authenticates the caller against the corporate identity provider, runs a content classifier against the prompt with deterministic categories (PII, PHI, source code, customer data, free-form sensitive categories defined per organization), and commits a per-decision record before the request reaches the model. The record carries the natural-person identity, the classification label, the policy version, the decision, the timestamp, and an integrity signature.

This is the placement where the same surface holds both the prompt and the verified identity at the same moment. Without it, the record either omits identity (because the prompt was captured at the network) or omits the prompt (because identity was captured at the application). Article 19 of the EU AI Act lists identification of natural persons involved as a required log field. The detection architecture that supports that field has to sit at the HTTP boundary.

What organizations typically run today

Most organizations run a combination of DNS-based inventory and CASB sanctioned-app catalog. The DNS feed flags new LLM endpoints. The CASB enforces SSO against the apps already in the catalog. Neither product captures the per-request body. Netwrix found that 97% of organizations that suffered AI-related breaches lacked proper access controls for AI services, and only 37% have any detection or governance policies in place for AI usage. The gap between detection and enforceable record is the gap between DNS inventory and identity-bound prompt inspection.

The instinct on most teams is to layer more network controls. The mechanical problem is that TLS terminates at the SaaS endpoint, and inserting an MITM appliance on general egress traffic carries operational cost most enterprises absorb only against general web browsing, not LLM-specific APIs.

Regulatory framing under EU AI Act and HIPAA

EU AI Act Article 12 requires automatic recording of events over the lifetime of the system sufficient to ensure traceability. Article 19 specifies that records identify natural persons involved. The August 2, 2026 deadline applies to high-risk AI systems including credit scoring, employment screening, education access, and biometric identification. Shadow AI use that touches any of those decision surfaces falls inside the obligation.

HIPAA Security Rule 45 CFR 164.312(b) requires audit controls on systems that process PHI. Cloud Radix found that 57% of healthcare professionals use unauthorized AI to process PHI without a Business Associate Agreement. The audit control requirement persists regardless of whether the PHI processing happened on a sanctioned platform or a shadow one. A DNS inventory alone fails the audit control standard because it lacks the prompt content the regulator expects to see on a sample.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline between authenticated users or agents and any LLM, terminates TLS at the proxy, authenticates against the corporate identity provider, classifies the prompt content, evaluates policy against identity and classification, and commits a per-decision audit record before the response returns to the application. The records carry the identity, classification, policy version, decision, and integrity signature on the same series an auditor would sample under Article 12 or HIPAA.

For organizations starting from a DNS-only inventory, the path to closing the detection gap runs through identity binding at the HTTP layer. The DNS feed identifies which endpoints are in use. The HTTP proxy identifies who, when, and what.

Book a demo today.