Does the inspection layer block shadow AI traffic or just record it?

The egress inspection can apply a policy decision on the shadow AI traffic the same way the approved-route inspection applies a decision on the AI traffic the application sends. The block policy stops the POST from reaching the AI endpoint. The record policy lets the traffic through and records the event. The choice depends on the deployer's posture: a strict deployer blocks the consumer AI domains for sensitive-data classifications and routes the employee to the approved tool, a moderate deployer records first and reviews the patterns before deciding on the block.

How does the egress detection distinguish the employee reading the AI documentation from the employee posting customer data?

The egress inspection reads the request body of the POST to the AI endpoint, not the GET that retrieves the AI vendor's website. The POST body carries the prompt content the employee submitted. The classifier passes over the body and tags the data classes the prompt reaches: PII, source code, customer behavioral data. The documentation read is a GET with no POST body and does not surface in the shadow AI signal.

Can the employee bypass detection by using a phone or a home laptop?

The employee on a personal device outside the corporate network does not produce the egress signal. The corporate device covered by the EDR or DLP produces the endpoint-side signal. The deployer's policy choice is to allow personal-device usage for non-sensitive data and to block sensitive-data extraction at the source (the source system the employee would copy from). The off-route exposure on personal devices is bounded by what the employee can extract from the source systems the corporate device has access to.

How does the inspection layer connect the shadow AI signal to the user's HR identity?

The egress proxy and the EDR agent surface the natural-person identifier from the SSO that authenticated the device. The inspection layer joins the off-route record to the approved-route record on the natural-person identifier and produces a single timeline per user. The HR identity is the join key the security team and the data-protection officer use during a subject access request or a workplace review.

Shadow AI vs Shadow IT: Why the Old Detection Stack Misses the AI Request Layer

Shadow IT is the SaaS subscription the security team did not approve. The marketing manager signs up for Notion on a personal credit card, the team migrates, and the security team finds out six months later when an integration request lands on the IAM queue. The detection stack the security team built reads the four signals shadow IT leaves: new SaaS domains in the DNS logs, OAuth grants in the IdP, expense lines on personal cards, and SSO requests that arrive from unrecognized vendors. The stack catches a good share of shadow IT before the procurement team formally reviews the vendor.

Shadow AI looks similar at the procurement layer (an employee using a tool the security team did not approve) and looks different at every other layer. The employee opens chat.openai.com in the browser tab next to the approved SaaS, pastes a customer support ticket into the prompt, and copies the response back into the approved tool. The four signals the shadow IT stack reads do not surface this behavior. IBM's Cost of Data Breach Report 2026 found that one in five breached organizations experienced breaches linked to shadow AI. Cloud Radix found 86% of IT leaders are completely blind to these interactions.

I want to walk through the four mechanisms shadow IT detection uses, why each one misses the AI request layer, what shadow AI detection has to read instead, and the inspection topology that closes the gap.

Mechanism 1: DNS log review

Shadow IT detection reads DNS resolution logs and flags new SaaS domains. A spike in resolution to a domain the security team has not seen before triggers a review. The mechanism works because new SaaS adoption typically lights up a new domain.

The mechanism misses shadow AI because the AI domains (chat.openai.com, claude.ai, gemini.google.com) are visited from corporate browsers as part of normal employee research and learning. The DNS log spike is already there, baseline since the LLM tools launched. The DNS log cannot distinguish "the employee read the AI vendor's documentation" from "the employee pasted a customer record into the AI chat." Both look like the same resolution.

The shadow AI detection has to read what the employee did with the AI domain, not the domain visit itself.

Mechanism 2: OAuth grant inventory

Shadow IT detection reads the IdP's OAuth grant log and flags new applications the employee authorized. The mechanism works because SaaS adoption typically involves the SaaS asking for OAuth scopes (calendar access, email access, file access).

The mechanism misses shadow AI because the consumer AI tools the employee uses do not ask for corporate OAuth scopes. The employee logs into chat.openai.com with a personal Google account or a personal email, copies data through the browser clipboard, and never grants the AI tool any corporate OAuth scope. The IdP sees no new grant. The detection mechanism reads no signal.

The shadow AI detection has to read the browser-to-AI traffic the OAuth-grant inventory was never asked to cover.

Mechanism 3: Expense report analysis

Shadow IT detection reads expense reports for SaaS line items and flags new vendors. The mechanism works because the employee who needs the SaaS for work typically expenses the subscription back to the company.

The mechanism misses shadow AI because most consumer AI usage is free at the entry tier and even the paid tier is often charged to a personal card the employee does not expense. The Cloud Radix research found 78% of employees use unauthorized AI tools, and most of those usages carry no expense trail. The procurement team sees nothing in the expense system.

The shadow AI detection has to surface usage that has no spend signal.

Mechanism 4: SSO request review

Shadow IT detection reviews SSO integration requests as the procurement-side trigger. A vendor that asks for SAML integration with the corporate IdP is a vendor the security team can pre-review. The mechanism works because enterprise SaaS adoption typically asks for SSO before broad rollout.

The mechanism misses shadow AI because consumer AI tools do not ask for corporate SSO. The employee uses a personal account, the IdP never sees a request, and the security team never receives the trigger. The same employee may also use the team's approved AI tool through SSO, but the personal-account usage runs in parallel and uses different data than the approved tool.

What shadow AI detection has to read instead

The shadow AI signal lives in the network egress to the AI endpoints and in the browser-side activity that posts data to those endpoints. Three reading mechanisms produce the signal.

The first mechanism is egress inspection at the corporate network boundary. A web proxy or SASE node that terminates TLS for the corporate egress traffic reads the AI provider POSTs and classifies the request body. A POST to api.openai.com that contains content matching a customer-data pattern produces a shadow AI signal even when the employee used a personal account.

The second mechanism is endpoint-side telemetry on the corporate device. An EDR or DLP agent that reads browser-side activity (clipboard pastes into AI domains, form submissions to AI domains) produces a signal independent of the network egress path.

The third mechanism is the inspection layer at the approved AI request boundary. The layer produces the per-route audit record for the approved AI tools, and the absence of a record for an employee's AI activity (compared to the network egress that shows the employee did interact with an AI endpoint) flags the off-route usage.

The three mechanisms compose. The egress inspection catches the AI traffic in flight. The endpoint telemetry catches the user action that produced the traffic. The approved-route inspection produces the baseline against which off-route activity stands out.

The inspection topology that closes the gap

The two pipelines surface different states. The approved-route pipeline produces the AI Act Article 12 record series and the GDPR Article 22 right-to-explanation evidence. The shadow AI pipeline produces the discovery signal the security team uses to migrate users from the off-route tools to the approved route. The two are independent stores with a single common axis: the natural-person identifier of the employee.

DeepInspect

DeepInspect runs as the inspection layer on the approved AI routes. The product terminates the AI provider TLS, reads the request and response, evaluates identity-bound policy per route, applies pass, modify, redact, or block decisions, and commits per-decision audit records to a tamper-evident store. The record series is the baseline the shadow AI detection compares against.

For the shadow AI side, the product integrates with the corporate egress proxy and the EDR telemetry to produce the cross-source discovery signal. The mechanism reads the egress and endpoint events, joins them to the natural-person identity from the SSO, and emits an off-route activity record that the security team triages. The triage typically lands the user on the approved-route migration path and closes the shadow AI window for that user.

If your security team is sitting on the 86% blind-to-shadow-AI figure and looking for the layer that produces the discovery signal, let's talk today.