Shadow AI Detection Methods: The Five Detection Surfaces and Why Three of Them Miss Most Real Usage
Shadow AI detection happens on five surfaces: endpoint agents, network DNS, SSL inspection, identity provider logs, and inline AI request proxies. Endpoint, DNS, and identity logs detect attempts to reach known AI vendor domains but miss prompt content and never see browser-based usage to unsanctioned tools. SSL inspection captures content but only where TLS-break infrastructure is deployed to the AI provider domains. Inline proxies on the AI request path see identity, classification, and policy state at decision time. The five surfaces differ in what they detect and when.

IBM's Cost of Data Breach Report studied 600 breached organizations and found that one in five experienced breaches linked to shadow AI. Cloud Radix reports that 78% of employees use unauthorized AI tools at work, 77% admit to pasting sensitive business data into unsanctioned models, and 86% of IT leaders are completely blind to these interactions. Detection is a precondition for any response, but the five technical surfaces that vendors call "shadow AI detection" see different things. Endpoint agents, network DNS, SSL inspection, identity provider logs, and inline AI request proxies each catch part of the picture. Three of them miss most real usage. One of them is the only surface that produces the audit record an Article 12 reviewer accepts.
I want to walk through the five detection surfaces, what each one actually sees, where each one fails, and which surface produces the record that survives a regulatory review.
Shadow AI
Shadow AI is the use of AI tools inside the enterprise that have not gone through procurement, security review, or data-handling approval. The category includes employees pasting code into ChatGPT, marketing teams running Claude through a personal browser session, finance teams using copilots embedded in unapproved SaaS products, and engineering teams calling LLM APIs from local scripts with personal API keys. The IBM 247-day detection figure for shadow AI breaches sits six days above the average across all breach types, which means the surface most enterprises monitor today is not the surface shadow AI actually uses.
The five detection surfaces
The five surfaces vendors market as shadow AI detection differ in placement, coverage, and audit value.
Endpoint agents
Endpoint detection and response (EDR) and data loss prevention (DLP) agents installed on managed laptops can detect launches of known AI desktop applications, browser extensions that interact with AI vendor domains, and clipboard operations into recognized AI-tool windows. The agent sees what runs on the managed device. The agent does not see what happens on personal devices, on unmanaged BYOD endpoints, on mobile devices outside MDM, on contractor laptops, or inside virtualized desktops where the agent is not installed.
Network DNS resolution
DNS query logs at the corporate resolver show requests for known AI vendor domains: openai.com, anthropic.com, gemini.google.com, perplexity.ai, claude.ai, and the long tail of fine-tuning-as-a-service domains. The detection is cheap and broad but reads only at the domain level. The DNS log records that someone in the corporate network queried api.openai.com. It does not record which user, which prompt, or which response. The detection is also blind to AI usage through generic CDN domains or through enterprise SaaS that embeds model calls under the hood.
SSL inspection
TLS-break infrastructure at the network egress can decrypt and inspect HTTPS traffic to AI provider domains where the corporate root CA is installed on the client device. The inspection sees the prompt and the response in plain text and can apply DLP rules. The coverage requires TLS-break for the specific AI provider domains and acceptance of the man-in-the-middle posture by the application's TLS pinning behavior. Many AI provider mobile applications pin TLS and refuse the corporate root CA, which forces those applications outside the inspection scope. The inspection produces a log but the log lacks the identity context the enterprise IdP knows and the classification logic the data governance team owns.
Identity provider logs
The IdP logs authentication events when a user signs in to a sanctioned AI tool through SSO. The IdP sees the sign-in but not the prompts that follow. The IdP does not see usage of AI tools that do not federate to the IdP, which includes most personal-account usage of ChatGPT, Claude, or Perplexity. The IdP log is a coverage signal for sanctioned tools, not a detection mechanism for unsanctioned use.
Inline AI request proxies
An inline proxy that sits on the HTTP path between the calling identity and the LLM endpoint sees the request body in plain text, the response in plain text, the identity context the calling application supplies, and the per-request decision the proxy makes. The proxy is configurable to all AI provider domains the enterprise wants to inspect. The proxy produces a per-decision audit record with identity, classification, policy state, and decision outcome. The record is the artifact a regulator accepts under Article 12 and Article 19.
Where the first three surfaces miss most real usage
Endpoint, DNS, and IdP logs catch a slice of shadow AI but miss most browser-based usage to unsanctioned tools where the user signs in with a personal account, the corporate resolver is bypassed through a personal hotspot, or the agent is not installed on the device. Cloud Radix's 86% figure for IT leader blindness reflects this gap. The surfaces are quick to deploy and cheap to operate but the coverage is partial. SSL inspection extends the coverage where TLS-break is acceptable, but the audit record lacks the identity and classification context an Article 19 reviewer expects.
The inline proxy surface produces the record that survives the review. The trade-off is the deployment footprint: the proxy must sit on the AI request path, which requires routing the AI traffic through the proxy by configuration, by network policy, or by code instrumentation. The deployment is more work than turning on a DNS log. The audit record is the artifact that closes the compliance loop.
Governing shadow AI
The detection surface that produces the audit record is the same surface that enforces policy at decision time. Detection without enforcement leaves the enterprise with a log of what happened. Enforcement at the AI request boundary blocks the prompt before sensitive content reaches the model and produces the record contemporaneously.
The architectural pattern that satisfies both detection and enforcement involves four operational components. The first is AI traffic identification: every HTTP request to an AI endpoint is identified as such and routed through the inspection layer. The second is identity mapping: the calling identity (user, agent, service) is attached to the request as a header the inspection layer consumes. The third is prompt-level classification: the prompt is evaluated for PII, PHI, source code, or other sensitive categories before the model call proceeds. The fourth is inline policy enforcement: the per-route, per-role policy decides pass, redact, or block, and the decision is committed to the audit record before the model response returns.
DeepInspect
This is the gap DeepInspect closes. DeepInspect sits at the AI request boundary as an external enforcement layer that operates as a stateless proxy between authenticated users or agents and any LLM endpoint. Every HTTP request is evaluated against per-route, per-role policies using identity context the calling application supplies. The per-decision audit record is committed by the proxy, independent of the application and independent of the AI vendor, before the model response returns.
The record contains a verified identity for the requester, the role and authorization context, the data classification applied to the prompt, the AI vendor and model actually called, the policy version that governed the decision, the decision outcome, and a cryptographic signature that prevents post-hoc modification. Detection and enforcement happen on the same surface at the same moment.
Book a demo today.
Frequently asked questions
- Why do endpoint and DNS detection miss most shadow AI?
Endpoint agents are limited to managed devices and miss BYOD, contractor laptops, and personal devices. DNS resolution sees the domain but not the user, the prompt, or the response. Together the two surfaces produce a coverage signal for some AI traffic but not a contemporaneous record of the prompt content or the identity behind the request. Cloud Radix's 86% IT-leader blindness figure reflects the gap between these surfaces and actual usage.
- Does SSL inspection produce an audit-grade record?
SSL inspection at the network egress can capture prompt content where TLS-break is deployed for the AI provider domains. The capture lacks the enterprise identity context the IdP knows and the classification context the data governance team owns. The record is closer to a network capture than to the per-decision audit record Article 19 expects. The inspection produces a forensic artifact but not the contemporaneous, identity-bound record that closes the compliance loop.
- How does an inline AI proxy differ from a network firewall?
A network firewall enforces at the packet layer and runs underneath the TLS encryption. The firewall sees the destination domain but not the prompt content. An inline AI proxy terminates the AI provider TLS at the proxy, reads the request body, evaluates identity-bound policy, applies a pass, block, or modify decision, commits the per-decision audit record, and forwards the request to the model. The proxy operates at the application layer, not the network layer, which is why it sees what the firewall cannot.
- Can detection work without enforcement?
Detection without enforcement produces a log of shadow AI usage. The log is useful for trend analysis and for identifying high-risk users or tools. The log does not prevent the exposure event. The IBM 247-day detection figure for shadow AI breaches shows the time between exposure and detection on a detection-only architecture. Enforcement at the AI request boundary collapses that window to the decision moment.
- What about sanctioned AI usage through SSO?
IdP-federated AI tool usage is logged at the IdP for the sign-in event. The IdP does not see the prompt content or the response. A sanctioned AI tool that processes sensitive data still needs the prompt-level classification and the per-decision audit record at the AI request boundary. The IdP log is the entry record. The inline proxy log is the use record. Both feed the audit trail but only the inline proxy log carries the substance.