How is shadow AI detection different from CASB?

CASB tools inventory SaaS applications by API integration or browser-extension telemetry. The CASB sees the application is in use. Shadow AI detection is one layer deeper: it surfaces the AI calls inside or alongside those applications and produces traffic, identity, classification, and policy signals at the AI request layer. Most CASB pivots into shadow AI cover the first signal well and the other three thinly.

Can a SIEM correlate the discovery signal with corporate identity?

A SIEM ingesting endpoint DNS and proxy logs can correlate AI service traffic with the endpoint user identity from MDM. The correlation surfaces likely actors. It does not produce the strong identity-correlation signal that ties the corporate IdP identity to the specific HTTPS call. The strong correlation requires inspection at the AI request boundary, where the request can be tied to the SSO session that authenticated it.

Why does prompt-level classification require reconstructing the prompt?

The prompt arrives over HTTPS in an API payload. The classifier needs the prompt text and the context that surrounds it. Reconstruction means parsing the API request body, extracting the user message, extracting any system prompt context, and treating the combined content as the classification target. Document-level classifiers built for file scanning do not run against this kind of structured payload by default.

What happens to the discovery report once enforcement is in place?

The discovery report becomes a structured view of the audit log. Every AI call that flowed through the enforcement layer is in the log with identity, prompt classification, policy state, and decision. The weekly inventory report turns into a dashboard the security team runs against the audit log, with the difference that every entry was evaluated before it reached the model.

Does this architecture work for AI calls embedded inside vendor SaaS tools?

It works for calls the enterprise can route through the proxy. AI calls embedded inside third-party SaaS tools (where the vendor's backend calls the LLM, not the user's browser) require the SaaS vendor to integrate with the proxy or expose its own audit trail. The enterprise's procurement contract and the vendor's compliance posture become the controls for that traffic.

Shadow AI Detection Software: What the Category Should Actually Detect

Shadow AI detection software is converging into a recognizable category. The category name varies across vendors: AI discovery, AI usage telemetry, GenAI visibility, AI posture. The detection problem decomposes into four signals: traffic identification (this endpoint is talking to an AI service), identity correlation (this specific user or agent is responsible for the call), prompt-level classification (this prompt content includes regulated data), and policy state (this call should or should not have been permitted under the current usage policy). Software that produces the first signal without the other three solves discovery and leaves the enforcement gap open. 90% of CISOs identify shadow AI as their top security concern for the year (Cloud Radix). The buying conversations I see start at discovery and end at enforcement.

I want to walk through the four signals, where most detection software stops today, and what an architecture that bridges to enforcement looks like.

Signal 1: traffic identification

The first signal is the simplest. An endpoint or a user account is generating HTTP requests to a known AI service. The detection mechanism is some combination of DNS resolution telemetry, TLS SNI inspection, browser-extension reporting, and network flow analysis against a vendor-maintained list of AI service domains.

Vendors marketing shadow AI detection produce this signal cleanly. A discovery report comes out at the end of the week showing which users are calling api.openai.com, claude.ai, Gemini, Perplexity, and the 30 to 80 long-tail AI services the catalog includes. The report shows volume and frequency.

Traffic identification is necessary and shallow. The signal says traffic exists. It does not say what was in the traffic, who in the corporate identity directory authorized it, or whether the call broke policy.

Signal 2: identity correlation

The second signal is harder. Map the AI request to the corporate identity behind it.

Two patterns get conflated as identity in the discovery reports. The first is endpoint identity: the device making the call is enrolled in the MDM and is associated with employee X. The second is account identity: the AI service is called using employee X's enterprise SSO. These are not the same. Employees frequently authenticate to consumer AI services using personal accounts on managed endpoints. The MDM sees the device. The IdP sees nothing.

A discovery report that lists employee identities pulled from MDM endpoint mapping creates a confidence problem. The list shows which employees use AI on corporate devices. It does not show which AI calls are authenticated by which corporate identity. Without that correlation, the policy decision that follows ("should this user be making this call") rests on the wrong evidence.

Signal 3: prompt-level classification

The third signal is the one most detection software cannot produce. What was in the prompt.

Network DLP runs underneath the TLS encryption. The prompt content is encrypted in transit between the browser and api.openai.com. Even with TLS inspection configured for AI provider domains specifically and the API payload parsed, the DLP classifies documents, not prompt context windows. A prompt that says "summarize this customer's account history for me" with the account history pasted as the next paragraph carries structured PII the DLP was not built to classify.

Endpoint DLP gets closer. It can see the clipboard and the browser input field. Endpoint DLP is bypassable by typing the prompt in a different window, by using a personal device that the agent does not control, by routing through a less-managed AI tool, by pasting screenshots that the DLP cannot OCR in real time.

The cleanest place to produce the prompt-level classification signal is at the AI request boundary itself. Once the prompt is reconstructed from the HTTPS body and the request is normalized into a structured payload, a classifier can run prompt-level rules against it.

Signal 4: policy state

The fourth signal is the one that bridges detection to enforcement. Was this call permitted under the AI usage policy in effect at the moment of decision?

The signal requires three inputs in addition to the prompt and the identity: the policy version, the role of the caller, and the data classification on the prompt. None of these exist in the detection reports most shadow AI vendors produce.

Only 37% of organizations have any detection or governance policies in place for AI usage (Netwrix). The other 63% have nothing to evaluate the call against. Of the 37%, most policies are written in HR-style usage documents with no machine-readable representation. The detection software has no machine-readable policy to compare the call to, so the report says "high-volume AI usage detected" without the dimension that makes the report actionable.

A policy-as-code representation, attached to the AI request boundary, turns the detection signal into an enforceable decision. The same request that the discovery report would have surfaced at the end of the week gets evaluated at request time.

The shift from detection to enforcement

Detection software produces a weekly report. Enforcement software produces a per-request decision.

The architecture that produces enforcement is an inline proxy at the AI request boundary. The proxy receives the request from the user or agent, normalizes it, attaches the identity context the application supplies, runs the prompt-level classification, evaluates the policy state, and returns a permit, redact, or deny decision before the request reaches the LLM. Every decision generates a structured record committed independently of the application.

Detection without enforcement is forensic value with no preventive capability. The 22-second median attacker handoff time Mandiant measured in 2025 (down from over 8 hours in 2022) renders detection-only architectures structurally incapable of preventing damage at machine speed. By the time the weekly discovery report identifies the call, the breach has already moved through several stages of escalation.

What buyers should ask of a shadow AI detection vendor

A discovery-only product is useful as a one-time inventory pass. The buyer should ask whether the architecture supports the other three signals natively.

The signal-coverage questions:

Does the product correlate AI calls to corporate identity at the request layer, not endpoint identity from MDM?
Does the product reconstruct the prompt content and run classification against it at the request boundary?
Does the product evaluate a policy version against the request before the request reaches the model?
Does the product produce a structured, cryptographically signed audit record for each call?

A vendor answering yes to the first signal and no to the other three is solving discovery. The buyer should price the discovery work at the value of one quarter of inventory and move the larger spend into the enforcement layer.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline between authenticated users or agents and any HTTP-based LLM endpoint. For every request, it evaluates identity, data classification, model authorization, and organizational policy, and makes a permit, redact, or deny decision before traffic reaches the model. Every decision produces a structured per-decision audit record that an auditor or a regulator reads as system-of-record evidence.

The architecture covers signals 2, 3, and 4 natively, and turns signal 1 into a byproduct: traffic the enterprise was previously blind to becomes traffic the enterprise has the most structured evidence about. The shift from detection to enforcement removes the need for the weekly discovery report.

If your shadow AI program is sitting at the detection-only stage and you are evaluating what to wire enforcement into, book a demo today.