Is the consumer version of an enterprise-approved AI tool sanctioned or shadow?

It is shadow. Sanctioned status applies to the specific contractual instance that has been reviewed: the enterprise plan, on the enterprise tenant, with the enterprise terms. An employee using a personal account on the consumer tier of the same vendor is not covered by the enterprise contract. The data handling terms are different, the BAA status is different, the retention terms are different. A request through the consumer tier needs to be treated as shadow even if the vendor logo matches the approved list.

How do AI features inside SaaS tools change the boundary?

The SaaS tool sits on the approved list because the procurement review covered its data handling. New AI features added after that review introduce a new data path: the prompt content goes to a model, possibly hosted by a third party under a downstream contract the deployer never signed. The data classification, retention, and disclosure properties of the AI feature have to be evaluated independently of the wrapper SaaS tool. In practice, most procurement processes do not have a way to re-evaluate every quarterly release. The result is that the approved list overstates the actual sanctioned surface.

What does the EU AI Act say about the sanctioned-versus-shadow distinction?

The regulation does not use those terms. The August 2, 2026 high-risk obligations apply to the deployer of the AI system. If an organization is the deployer of a high-risk system and cannot produce the records of how the system handled specific requests, the deployer is in violation regardless of whether the AI ran through a sanctioned tool. Article 12 logging is a per-system requirement, and the sanctioned label does not exempt any system from it. The disclosure obligation lands on the deployer.

Can a CASB enforce the boundary on its own?

CASBs can block destination domains, throttle sanctioned applications, and enforce SSO on access. They cannot, in general, inspect prompt content at the wire because the TLS payload requires a per-vendor decoder and the vendor surface keeps changing. CASBs are useful for the access-control layer of the program (which user can reach which app from which device). They are not sufficient for the data-content layer (what data is in the prompt). The two layers need to operate together.

How do we handle requests where the user is authenticated but the prompt is restricted?

That is the post-authentication gap. The user passed the IdP check, the destination is on the approved list, the TLS connection is allowed - and the prompt still contains data that the classification policy disallows. The only place that decision can be made is at the request layer, before the prompt content reaches the model. An inline policy enforcement layer is the architectural answer. The audit record produced by the enforcement layer is what shows the regulator and the internal auditor that the decision was made deterministically at the moment of the request.

Shadow AI vs Sanctioned AI: Why the Line Moves Every Quarter

Cloud Radix found that 78% of employees use unauthorized AI tools at work and 86% of IT leaders are completely blind to those interactions. The same survey put CISO concern about shadow AI at the top of the 2026 priority list. The standard response is to declare a sanctioned set: Enterprise ChatGPT, Microsoft Copilot, an approved Bedrock model, and a short list of vendor SaaS tools whose AI features have passed procurement. Everything else is shadow AI.

That sanctioned-versus-shadow line is what every governance program ends up defending. The line moves every quarter because vendors keep adding LLM features inside SaaS products that were already on the approved list.

I want to walk through what the distinction actually means at the request layer, where most CASB-style approaches fall behind the vendor release cadence, and what the architecture has to do for sanctioned-versus-shadow to remain operational.

Shadow AI and sanctioned AI as operational categories

Sanctioned AI is the set of AI tools the organization has reviewed against its data handling, privacy, and procurement standards and added to the approved-use list. Shadow AI is everything else - the consumer ChatGPT a developer pastes a stack trace into, the Claude tab a marketing manager keeps open, the AI features inside vendor SaaS that the security team has not signed off on. The definition is operational, not technical. The same product (ChatGPT) is sanctioned on the enterprise plan and shadow on the consumer plan, and the prompt content is what determines which one a given request belongs to.

Three properties separate sanctioned from shadow at the request layer. Identity binding: sanctioned use authenticates the requesting user against a corporate identity. Data classification: sanctioned use evaluates the prompt content against the organization's classification rules. Audit retention: sanctioned use produces a record an auditor can review.

A tool can be on the approved list and a specific request through it can still be shadow if the user pastes prompt content the classification policy disallows. The boundary is per-request, not per-vendor.

The line moves every quarter

The quarterly release cadence at major vendors keeps the sanctioned list out of sync with what the tools actually do. Microsoft Copilot ships new features in Teams, SharePoint, and Outlook every release window. Salesforce Einstein adds new LLM-backed actions. Notion AI extends to new surfaces. The security review that approved the tool six months ago covered a different feature surface.

The pattern I see across regulated organizations is that the approved list captures vendors at a point in time. The vendors keep shipping. The review process catches up after the fact, often after a Sev-2 has surfaced the new feature surface in the wrong way.

A sanctioned-versus-shadow program that depends on the approved list staying current depends on a process that is structurally behind the vendor release schedule. The boundary needs to be enforced where the request hits the wire, not where the procurement form gets filled out.

Why CASB classification falls behind

Traditional CASB tools were built to classify SaaS applications, attach a risk score, and let the organization allow, block, or proxy traffic to each one. The classification model assumes the app surface is stable: Salesforce is a CRM, Slack is a chat tool, Notion is a wiki. AI features added inside those apps blur the classification.

CASBs catch new AI features by adding them to the application catalog after the fact. The lag between feature release and CASB classification is typically several weeks. During that lag, the AI calls are flowing through a sanctioned application from the CASB's perspective and the prompt content is invisible to the policy layer.

The deeper problem is that CASB inspection of AI traffic is at the network layer. The destination domain matches the sanctioned vendor. The TLS connection is allowed. The HTTPS POST body carries the prompt and the response. None of that body is inspected unless the CASB has a specific decoder for the vendor's API shape. Microsoft Copilot's API surface, Notion's AI endpoint, Salesforce Einstein's prompt format, and the OpenAI-compatible APIs that vendors use under the hood all differ in payload structure.

Maintaining decoders for every AI-bearing SaaS endpoint is a treadmill. The shadow-versus-sanctioned classification at the SaaS level is too coarse for the actual data exposure question.

What sanctioned actually has to mean at the request layer

For the sanctioned-versus-shadow boundary to operate as a control rather than a label, three properties have to hold at the moment of the request.

The user has to be identified against a corporate identity. Personal-account access to a tool on the approved enterprise list still counts as shadow if the personal account is not in the corporate IdP.

The prompt content has to be evaluated against the data classification rules in effect at that moment. A request that contains source code, PHI, MNPI, or other restricted data is shadow regardless of which tool it is going through, if the data classification policy does not permit that content to leave the environment.

The decision has to be recorded against an identity-bound audit trail that the application generating the request does not control. Self-attested logs from the SaaS vendor are not the same as an independent audit record.

When those three properties hold, sanctioned-versus-shadow is a per-request determination. When they do not hold, the program is sorting vendors into buckets while the actual data is moving on a different layer.

The compliance and breach math

Per IBM, shadow AI breaches cost $670,000 more on average than standard breaches, take 247 days to detect, and exposed customer PII at 65% versus 53% across the full breach population. Netwrix found that 97% of organizations that suffered AI-related breaches lacked proper access controls for AI services and only 37% had any AI-related governance policies in place.

Most of those breaches did not happen because the organization had no approved AI list. They happened because the approved list and the actual prompt-level data movement were not the same thing.

The EU AI Act high-risk obligations under Article 12 take effect August 2, 2026 and require automatic recording of events over the lifetime of the system. The mandate applies regardless of whether the AI ran through an approved vendor or an unapproved one. A regulator does not care that the SaaS tool was on the approved list. The regulator asks for the record of what data was processed, by whom, under what policy. If the only record is in the vendor's audit log under the vendor's terms, the deployer is exposed.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users and agents and any LLM endpoint, including the AI features inside SaaS tools that route through OpenAI-compatible APIs under the hood. Every request that passes through it is evaluated against identity, role, data classification, and policy. The decision is recorded as a per-decision audit record that the application calling the AI does not control.

For the sanctioned-versus-shadow program, the proxy is what makes the line operational. A request that meets the classification and identity policy is allowed. A request that violates either is blocked or redacted at the wire. The audit record is the same regardless of which tool the request went through. The approved-vendor list stops being the control. The per-request evaluation is the control.

The architecture works against the quarterly vendor release problem because the policy is evaluated per request rather than per vendor. A new AI feature inside an already-approved SaaS tool produces traffic that the proxy classifies in the same way as any other traffic.

If you are running a shadow AI program against a vendor list that has to be re-validated every quarter, the architecture is fighting the wrong battle. Let's talk today.