Contact us
AI Security

Shadow AI Data Leaks: Why Control Belongs in the Browser

·

From bans to conditional approval

In April 2023, Samsung Electronics confirmed internally that engineers in its semiconductor division had entered source code and meeting notes into ChatGPT. In early May, the company restricted generative AI use on company devices and its internal network, and several global financial companies and other businesses took similar steps around the same time.

The bans did not last. On August 13, 2024, Korea’s Financial Services Commission (FSC) and Financial Supervisory Service (FSS) announced the Financial Sector Network Separation Improvement Roadmap, opening the way for financial companies to use generative AI and SaaS. On November 27 of the same year, they designated the first 10 innovative financial services using generative AI, from 9 financial companies, and 74 companies filed 141 applications during the application period alone. Each designation is conditional on complying with security measures.

The question has changed. It is no longer “Should we block generative AI?” but “Should we allow it while controlling what data goes where, and under which account?”

Shadow AI in numbers

Shadow AI refers to AI tools that employees use for work without the organization’s approval or security review.

MetricFigureSource
Share of security incidents involving shadow AI20% (2025) → 43% (2026)IBM Cost of a Data Breach 2026
Average cost of breaches involving shadow AI$5.39 million (previous year: $4.63 million)IBM Cost of a Data Breach 2026
Share of breached organizations without an AI governance policy68%IBM Cost of a Data Breach 2026
Share of generative AI pastes made from unmanaged (personal) accounts82%LayerX Enterprise AI & SaaS Data Security Report 2025

The IBM report is based on a Ponemon Institute study of 602 organizations across 17 industries in 16 countries that experienced a breach between March 2025 and February 2026. The LayerX figure is based on browser telemetry from that company’s customers, so interpret it with the sample’s characteristics in mind.

Both sources point in the same direction. Data is leaving not as files but as snippets of text, through browser input fields.

Three gaps existing control layers miss

1. Traffic exempted from decryption

Network DLP and an SWG (Secure Web Gateway) need TLS decryption before they can inspect what is being sent. Traffic exempted from decryption for operational reasons, such as personal banking and healthcare sites or apps that use certificate pinning, is not inspected for content. As the exception list grows, the blind spot widens with it.

2. QUIC (HTTP/3) traffic

HTTP/3 runs on QUIC, and QUIC uses UDP rather than TCP (RFC 9000, RFC 9114). In environments that run only TCP-based proxies, UDP 443 traffic can bypass the inspection path. The Chromium issue tracker has a 2015 request to add a policy for this reason, and the QuicAllowed policy was introduced afterward.

If your proxy does not support QUIC inspection, the simplest measure is to turn off QUIC in managed browsers. In environments that do not use Windows Group Policy, the following registry values apply the same setting.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"QuicAllowed"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"QuicAllowed"=dword:00000000

You can confirm the setting at chrome://policy or edge://policy. If you also control UDP 443 at the perimeter firewall, the browser falls back to TCP-based HTTP/2 or HTTP/1.1. Some services may feel slower as a result, so apply the change through your change management process.

3. Same domain, different accounts

Many SaaS and generative AI services use the same domain for personal and enterprise accounts. A policy based only on the destination domain has difficulty distinguishing “input into an approved enterprise tenant” from “input into a personal account.” The figure in the table above, that 82% of pastes came from unmanaged accounts, shows how large this blind spot is.

Visibility by control layer

Control layerVisibility availableAreas prone to blind spots
Network (SWG, CASB, network DLP)Destination domain, decrypted HTTP requestsDecryption-exempt traffic, unhandled QUIC traffic, telling accounts apart within the same domain
Endpoint DLPFile movement, OS clipboard, storage mediaContext: which web app, and which account, the input is going to
Browser layerPlaintext of input, paste and upload events; tab URL and signed-in account contextUnmanaged browsers, desktop-only apps, API and CLI calls

No single layer closes these gaps on its own. The browser layer’s strength is that it has access to the plaintext before encryption, along with the service and account it is being entered into.

Design principles for browser-layer control

1. Decide per event, before transmission

Paste, keyboard input, file upload and drag-and-drop are separate events. You need to evaluate each event before the request is sent to the server to avoid after-the-fact response, where data is detected only after it has already left.

2. Combine account and tenant context

The same sentence should be allowed when it is entered into an approved enterprise tenant, and should trigger a warning or a block when it is entered into a personal account. The basic unit of policy is not the “domain” but the combination of “service + account + data type.”

3. Tiered responses, not blocking alone

ResponseExampleExpected effect
Allow + recordApproved enterprise tenant, no sensitive data detectedKeeps the workflow intact, makes usage visible
Warn + justificationUnapproved service, or text likely taken from internal documentsPrompts users to make the call themselves, reduces the incentive to work around controls
MaskingIdentifier patterns such as resident registration numbers or account numbers detectedRemoves only the identifying data so the task can still be done
BlockBulk paste of source code or customer data, file upload to a personal accountCloses high-risk leak paths

Block across the board, and users move to personal devices while the organization loses visibility.

4. Log metadata, not raw prompts

Storing raw prompt text as is turns the log server into a new store of sensitive data. It is safer to log detection type, action taken, target service, user and time by default, and to keep raw text only as an exception, with controlled retention periods and access rights.

5. Close bypass paths as well

Browser-layer control is effective only inside managed browsers. Apply network policy so that generative AI domains are reachable only from managed browsers, and cover desktop-only apps and API call paths with endpoint and network policy.

Rollout order: visibility, coaching, enforcement

Turn on blocking policies from day one, and false positives and user complaints pile up all at once. The order below is a recommended flow that spreads the operational load so the controls can take hold.

StageOperating modeGoalOutput
1. VisibilityRecord onlyUnderstand which AI services are used, with which accounts and which data typesUsage records by service, account and data type
2. CoachingWarn + justificationSteer users to approved services and make them aware of the policyApproved service list, exception request flow
3. EnforcementMasking, blockControl high-risk data types and personal-account paths firstEnforcement policy by data type
4. OperationsRegular tuningTune out false positives, add new AI servicesQuarterly policy review records

Stage 1 results give you an evidence base for designing the policies in stage 2 onward. Blocking policies built without usage records mostly end up either excessive or leaving gaps.

In closing

Generative AI has moved from something to ban to something to manage. The key to managing it lies in the moment before data is encrypted and sent out over the network, the moment the user presses paste. The browser is the closest point to that moment.

ZensLab offers BrowZen, a client-based secure browser that makes the browser a policy enforcement point (PEP). For the basic concept of a secure browser and how it differs from other approaches such as VDI and RBI, read What a Secure Enterprise Browser Is.

References

Frequently asked questions

Isn't blocking generative AI sites by domain enough?

New AI services keep appearing and AI features are being built into existing business SaaS, so a domain list alone leaves gaps. A total block pushes users to work around it with personal devices and personal accounts, which ends up costing you visibility. Allowing approved services and controlling only the input of sensitive data is the realistic approach.

Can a browser extension provide the same control?

An extension can also observe page events, and it has the advantage of deploying quickly to existing browsers. However, you have to use browser policy to force-install the extension and stop users from disabling it, and a user who switches to another browser without the extension falls outside your control. Either way, you also need network policy that blocks access from unmanaged browsers for the control to be effective.

Should we log raw prompts in full?

We do not recommend it. Logs of raw prompt text become a store of sensitive data in their own right, and a new target for leaks. Record mainly metadata such as detection type, action taken, target service, user and time. If you truly need to keep the raw text, control its retention period and access rights separately. This approach is in line with the spirit of the data minimization principle.

Related reading