Do CASB and browser-extension visibility products satisfy the EU AI Act Article 12 logging obligation?

The Article 12 obligation calls for automatic recording of events over the lifetime of the system, with enough detail to reconstruct the operation. Visibility products that record adoption metadata satisfy the discovery framing of the obligation. Products that do not record the prompt content, the data classification, or the policy state at the moment of decision fall short of the reconstruction requirement. The practical position is that visibility products complement an enforcement-layer record but do not substitute for it.

What is the minimum coverage an identity-aware AI proxy has to provide to address shadow AI?

The coverage has to reach the AI surfaces the workforce actually uses. For a typical enterprise, that means the browser-based chat surface for ChatGPT, Claude, Copilot Chat, and Gemini, the API surface for internal applications and agents calling OpenAI, Anthropic, AWS Bedrock, and Azure OpenAI, and the server-to-server surface for SaaS embeddings the deployer can route through the proxy. Coverage gaps in any of these surfaces show up as gaps in the audit evidence.

How does shadow AI monitoring interact with employee privacy in EU jurisdictions?

GDPR limits the processing of employee personal data and requires a lawful basis, transparency, and proportionality. Shadow AI monitoring that captures prompt content has to be designed around these constraints, with the lawful basis usually being the legitimate interest of the deployer in compliance and data protection, balanced against the employee's reasonable expectation. Works council notification, employee notice, and limits on what the security team can review without further authorization are standard parts of the design. The technical architecture has to support these limits with role-based access to the records and field-level controls on what reviewers see.

Does Microsoft Defender for Cloud Apps cover shadow AI sufficiently?

Defender for Cloud Apps is a strong CASB and produces good visibility into AI SaaS adoption in environments where Microsoft is the identity provider. The product's coverage of prompt-layer content and per-decision policy enforcement for non-Microsoft AI surfaces is the area where deployers commonly need additional architecture. The practical pattern is to pair Defender's discovery and SaaS-app integration with an enforcement layer at the AI request boundary for the surfaces the CASB does not terminate.

What does the shadow AI monitoring tool stack typically look like at a mature enterprise?

A mature stack has three layers: discovery (CASB or equivalent for SaaS-app adoption signals), endpoint observation (browser extensions or endpoint agents for the user-surface coverage), and enforcement (identity-aware proxy at the AI request boundary for the per-decision record and the policy operation). The layers feed each other: the discovery surfaces the AI adoption, the endpoint observation closes the user-surface gaps, and the enforcement produces the audit and the control. Few enterprises have all three operating today; the gap is most often at the enforcement layer.

Shadow AI Monitoring Tools: What to Measure and Where to Operate

Shadow AI monitoring tools observe employee AI usage that runs outside the IT-sanctioned stack. The category covers four operational architectures: browser extensions that intercept ChatGPT and Claude sessions, CASB integrations that surface AI SaaS use, network telemetry that flags AI endpoints, and identity-aware proxies that route AI traffic through a policy point. IBM's Cost of Data Breach Report found that one in five breached organizations experienced incidents linked to shadow AI, with an average $670,000 incremental cost. Most tooling today produces visibility without enforcement. The architectural distinction that matters for compliance is whether the tool can block, redact, or modify AI traffic at the moment of the request.

I want to walk through the four categories, what each one actually observes, where the visibility-only model fails the audit question, and what an enforcement-capable architecture has to produce.

Where shadow AI actually shows up

The shadow AI problem has three dominant surfaces. The first is the browser surface: employees using ChatGPT, Claude, Gemini, and Copilot Chat from a personal account or an unmanaged tab. The second is the SaaS embedding surface: AI features inside Notion, Slack, Salesforce, and a long tail of enterprise tools where the AI runs on the vendor's infrastructure with prompts sourced from the deployer's data. The third is the agent and API surface: scripts, internal tools, and customer-facing applications calling LLM provider APIs directly with credentials the security team did not authorize.

Cloud Radix found that 78% of employees use unauthorized AI tools and 77% admit to pasting sensitive business data into the prompts. 86% of IT leaders are completely blind to these interactions. The blindness is structural: the corporate logging stack was built for email, file shares, and SaaS-app access, not for prompt-layer data movement.

Category 1: browser extensions

Browser extensions sit in the user's browser and intercept the page-level interaction with ChatGPT, Claude, Copilot Chat, and similar tools. The extension reads the prompt the user is about to send and the response the model produces. The visibility is rich: full prompt text, full response text, the user's corporate identity if the extension authenticates to a management plane.

The architectural limits are also clear. The extension covers only the browser surface. It does not see API calls, embedded SaaS AI features, agent-driven flows, or any AI usage from devices the extension is not installed on. Enforcement depends on whether the extension can block the prompt before it leaves the browser, which is achievable for some products and absent in others.

Browser extensions work as part of a layered architecture for general workforce AI usage. They fail as a standalone enforcement layer for compliance frameworks that expect coverage of API traffic, agent traffic, and SaaS embeddings.

Category 2: CASB integrations

Cloud Access Security Broker products integrate with the major SaaS apps and produce visibility into which apps are in use, what users access them, and what data flows through them. Modern CASB products include AI SaaS in their app catalogues and produce visibility into ChatGPT, Claude, Copilot, and the smaller AI tools employees adopt.

The CASB visibility covers the SaaS adoption signal: who logged in, when, from where, with what corporate identity. The prompt-layer visibility is partial. CASB can surface that an employee logged into ChatGPT 47 times last month. CASB has limited insight into what the employee actually typed into the prompt box, since the prompt content rides over HTTPS that the CASB does not terminate.

CASB integrations satisfy the discovery question for shadow AI. They have limits on the enforcement question for what was sent.

Category 3: network telemetry

Network telemetry products observe AI endpoint traffic from the corporate network: TLS metadata showing the OpenAI API host, the Anthropic API host, the Google Vertex AI host. The observation tells the security team that AI traffic is flowing. The observation produces volume metrics and endpoint coverage.

The architectural ceiling is the TLS encryption. Without terminating the connection at a proxy, the network telemetry sees the destination but not the prompt. Encrypted-only signals tell the security team where AI traffic is going. They do not tell the team what is being sent.

Network telemetry is useful as a baseline for AI traffic discovery in environments where the security team controls the network egress and can pair the telemetry with a proxy that terminates the traffic. As a standalone enforcement layer, the encrypted observation has limits.

Category 4: identity-aware proxies

Identity-aware AI proxies sit at the AI request boundary and terminate the TLS connection before forwarding to the LLM provider. The proxy sees the full prompt, the user's corporate identity, the data classification of the prompt content, and the model's response. Enforcement happens inline: the proxy can redact PII from the prompt before forwarding, block the request based on policy, modify the prompt to add deployer-controlled instructions, or surface the request to a human reviewer.

The architectural property that matters for compliance is that the proxy produces a per-decision audit record at the request boundary, with verified identity, data classification, policy version, and decision outcome. The record satisfies the EU AI Act Article 12 automatic logging obligation in a way the browser-extension and CASB architectures cannot, since the record covers all AI traffic that flows through the proxy regardless of surface.

The deployment cost is real: the proxy has to be in the traffic path for AI requests, which requires routing decisions at the API client and at the browser. The benefit is that one architectural layer produces the visibility and the enforcement.

What the visibility-only model fails

The visibility-only model produces a report. The enforcement model produces a decision.

The auditor reviewing the deployer's posture against Article 26 of the EU AI Act asks whether the deployer can demonstrate the monitoring of high-risk AI systems operated as required. A visibility report shows the traffic the deployer observed. The report does not show the requests the deployer prevented, the prompts the deployer redacted, or the access decisions the policy enforced.

The compliance question reaches further than the discovery question. Once the deployer knows shadow AI is happening, the obligation moves to control. The architectural layer that produces the control is the layer that decides at the moment of the request.

Netwrix found that 97% of organizations that suffered AI-related breaches lacked proper access controls for AI services. The discovery part of the problem is well understood. The control part is where most current tooling stops short.

What an enforcement-capable architecture has to produce

For shadow AI monitoring to satisfy the compliance frameworks taking effect in 2026, the architecture has to produce three things at the request boundary.

The first is per-decision evidence: a record for every AI request, containing the verified user identity, the data classification of the prompt, the policy version in effect, the decision outcome, the model destination, and a timestamp. The record is tamper-evident and retained for the period the applicable framework requires.

The second is enforcement at the moment of the request: the policy is evaluated before the prompt reaches the model, and the architecture supports redaction, blocking, modification, and human-in-the-loop review based on the policy decision. The deployer's policy is the operational expression of the deployer's risk management decisions.

The third is coverage of the AI surface area that matters: browser traffic to ChatGPT and Claude, API traffic from internal applications and agents, server-to-server traffic to LLM providers, and the egress paths the SaaS embeddings use when the deployer can route them through the proxy. The architecture's coverage limits define what the deployer can credibly claim about shadow AI control.

DeepInspect

This is the architecture shadow AI monitoring has to operate at if the compliance question is in scope. DeepInspect sits at the AI request boundary as a stateless proxy between the user or agent and the LLM provider. For each request, the proxy evaluates the policy against the user identity, the data classification of the prompt, and the model destination. The decision is enforced inline: block, redact, modify, or pass. The decision is recorded as a per-decision audit record under the deployer's control.

For the EU AI Act Article 12 record-keeping obligation, the records are automatic, lifetime-spanning, and detailed enough to reconstruct the decisions. For the HIPAA, GLBA, DORA, and Fannie Mae LL-2026-04 frameworks, the same architecture produces the per-decision evidence the framework expects. For the discovery question, the same records produce the visibility into who is using which AI service for what.

If your shadow AI program has produced visibility through CASB and browser extensions and you are now facing the question of how to enforce, the architecture decision is whether to add layers on top of the existing visibility tooling or to consolidate on the enforcement layer. Book your free AI readiness check.