Browser-layer controls for AI data leakage in unsanctioned tools

At a glance

What this is: This is an analysis of new browser-layer controls for blocking sensitive data from flowing into unsanctioned AI tools, with the key finding that the browser session has become the primary control point for these exposures.

Why it matters: It matters because IAM and security teams must now govern data movement, account trust, and browser-session behaviour together across human, NHI, and emerging AI-assisted workflows.

By the numbers:

• 67% of GenAI users on corporate devices are accessing AI tools through non-corporate accounts.
• 37% of file uploads to AI tools come from shadow accounts rather than approved organizational ones.
• 89-category framework spanning personal file sharing, unapproved AI tools, adult content, gambling, and more.

👉 Read Push Security's analysis of browser controls for AI data leakage

Context

Browser-session data leakage is the practical problem here: users can upload files, paste secrets, or download sensitive material in ways that bypass controls focused only on endpoints, networks, or sanctioned SaaS apps. For IAM teams, the issue is not just where access is granted, but where identity and data handling converge inside the session, especially when shadow accounts and unsanctioned AI tools sit outside standard governance.

The browser has become a control plane for human identity activity, and increasingly for AI-assisted work that still runs through a person’s session. That changes the governance question from simple policy compliance to visibility, enforcement, and telemetry at the moment of action. The article’s starting point is typical of enterprises that have expanded AI use faster than they have expanded browser-level control.

Push Security positions its browser controls as a way to monitor and block risky file, clipboard, app, and domain activity in real time. That framing matters because it reflects a broader shift in identity security: the relevant trust boundary is no longer just the login event, but the browser session where data leaves the organisation.

Key questions

Q: How should security teams control sensitive data going into unsanctioned AI tools?

A: Security teams should enforce policy at the browser session, where uploads, clipboard actions, and downloads actually occur. That gives them visibility into both the identity used and the destination reached, which endpoint and network tools often miss. The best starting point is to classify destinations, monitor risky transfers, and block only where the business cannot justify the data flow.

Q: Why do personal AI accounts create more risk than sanctioned ones?

A: Personal AI accounts weaken governance because they sit outside organisational control for MFA, retention, monitoring, and revocation. Even if the user is known, the account is not managed like a corporate identity, so the organisation loses assurance over how sensitive data will be stored or reused. That makes the account itself part of the risk decision.

Q: What do security teams get wrong about browser-based data leakage?

A: They often assume the signal appears in endpoint logs or network security tools. In practice, the risky event may be a copy, paste, or upload inside an authenticated browser session, long before any downstream control sees it. Teams need to look at user behaviour in-session, not just the final destination or the saved file.

Q: How should organisations decide between monitor, warn, and block modes?

A: Use monitor for low-confidence discovery, warn for behaviours that are allowed only with user awareness, and block when the transfer crosses into clearly unsanctioned destinations or regulated data classes. The decision should be based on data sensitivity, account governance, and whether the organisation can accept the exposure if the action completes.

How it works in practice

Browser-session telemetry and why endpoint controls miss it

Browser-session telemetry captures what users upload, paste, download, and submit while they are authenticated in a web application. That is materially different from endpoint DLP or CASB coverage, which often sees the file on disk or the destination domain but not the in-session action that caused the exposure. The browser is therefore the closest practical point to inspect intent and destination together. When the session is the control surface, policy can be enforced at the moment data leaves the user boundary, before the transfer becomes irreversible.

Practical implication: teams need visibility and enforcement inside the browser session, not only at disk, network, or SaaS boundaries.

File, clipboard, app, and domain controls as one policy surface

The article describes a policy model that combines file upload and download controls, clipboard monitoring, and app and domain categorisation. This matters because sensitive data rarely moves through one channel only. A user might copy source code into a prompt, upload a document, then continue in a personal account on an unapproved domain. By grouping those behaviours under one browser-layer policy surface, security teams can scope decisions by user group, file type, destination, and risk category rather than chasing isolated events after the fact.

Practical implication: define browser policy around behaviour classes and destinations, not isolated app blocks.

Shadow accounts change the trust model for AI use

Shadow accounts are the core governance problem in this article because they decouple AI usage from managed organisational identity. Once users interact with AI tools through personal or otherwise unmanaged accounts, the organisation loses visibility into MFA posture, retention, investigation, and revocation. That is an identity problem as much as a data problem. It is also why browser-layer telemetry is useful: it can reveal which account was used and whether the session crossed into unmanaged identity territory.

Practical implication: classify AI-tool access by account governance status, not just by application name.

NHI Mgmt Group analysis

Browser-session leakage is now an identity governance problem, not just a data-loss problem. The article shows that the same person can remain authenticated to corporate systems while moving sensitive material into an unmanaged AI session. That means governance has to account for where identity authority ends and where ungoverned browser behaviour begins. Practitioners should treat the session as a governance boundary, not just a transport layer.

Shadow accounts create a trust gap that conventional IAM does not close. The issue is not merely that users access AI tools, but that they do so through accounts outside organisational control, where MFA, retention, and response visibility may be absent. That weakens accountability across human identity programmes and creates a new blind spot for security review. The implication is that account provenance must become part of risk evaluation whenever data leaves the browser.

Clipboard and upload controls expose the real policy gap: data transfer happens before security teams realise the interaction was risky. The article’s emphasis on monitor, warn, and block modes reflects a simple reality, which is that user intent is visible only at the moment of action. This strengthens the case for browser-layer enforcement as a category, but it also exposes how little endpoint and network tooling can say about in-session identity behaviour. Practitioners should re-evaluate where they expect the first actionable signal to appear.

Category-level browser policy is a better fit for AI governance than per-URL exception handling. A workforce is not managing one AI tool at a time, it is managing classes of destinations, users, and data flows. Automating category decisions reduces policy drift and makes governance scalable across sanctioned and unsanctioned AI use. The field should move away from brittle allowlists toward policy structures that reflect how users actually work in the browser.

Browser controls bridge human IAM and emerging NHI concerns because the same session now mediates both user decisions and machine-assisted content handling. That does not make every browser action autonomous, but it does mean identity governance can no longer stay inside authentication and access review alone. The operational conclusion is that browser telemetry, identity posture, and data controls have to be analysed together if organisations want to understand modern leakage paths.

From our research:

• 67% of GenAI users on corporate devices are accessing AI tools through non-corporate accounts, according to The 2024 State of Secrets Management Survey.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
• Read next: The 52 NHI Breaches Analysis shows how identity visibility gaps turn routine access into breach paths.

What this signals

Browser-layer governance is becoming a practical extension of identity security, not a separate data-loss add-on. The more work moves into unsanctioned AI tools and personal accounts, the more organisations need controls that understand the session, the identity, and the destination together. That shift rewards programmes that can correlate browser telemetry with identity posture and data sensitivity in one workflow.

Shadow AI and shadow accounts are converging into the same governance problem. When users interact with AI through unmanaged identities, the organisation loses the ability to enforce MFA, retain evidence, or revoke access cleanly. Teams should expect browser visibility to become a primary source of truth for where those unmanaged interactions are happening.

Identity programmes that stop at authentication will miss the next wave of data leakage. The browser is now where access, content handling, and user intent intersect, so the practical control point has moved closer to the session than to the login event. This is where browser policy, identity posture, and data governance need to meet.

For practitioners

• Instrument browser-session telemetry for sensitive transfers Track uploads, downloads, copy, and paste actions where data may leave managed systems and land in unsanctioned AI tools or personal accounts. Ensure telemetry includes user group, destination category, and file or content indicators so security teams can reconstruct the event path later.
• Classify AI destinations by risk category Group apps and domains into policy categories such as unapproved AI tools, personal file sharing, and other high-risk destinations so controls can be applied consistently. Use category-level policy to reduce per-URL drift and avoid one-off exceptions that weaken governance.
• Treat unmanaged accounts as a governance exception Flag AI-tool interactions that occur through shadow accounts or non-corporate identities and route them for review. If the account cannot be proven to meet organisational control requirements, it should not be treated as equivalent to a managed identity in access or data-risk workflows.
• Forward browser control events into SIEM workflows Send permitted and blocked actions into your SIEM so investigations can distinguish normal browsing from data movement that crossed an unsanctioned boundary. This is especially useful when the browser session is the only place that reveals the identity used and the destination reached.

Key takeaways

• The main risk is not simply AI usage, but sensitive data moving through browser sessions into unmanaged accounts and tools.
• Push’s telemetry and the cited Verizon figure both point to a governance gap that is already operational, not theoretical.
• Practitioners should shift controls toward browser-session visibility, category-based policy, and account provenance checks.

Key terms

• Browser-session telemetry: Browser-session telemetry is the record of what a user does inside an authenticated web session, including uploads, downloads, copy, paste, and submission actions. It matters because it captures the moment data leaves the organisation, which is often earlier and more specific than endpoint or network logs can see.
• Shadow account: A shadow account is an identity used for work that is not managed under normal organisational controls. It may lack approved MFA, monitoring, retention, and revocation processes. In practice, it creates a parallel trust zone where sensitive activity can occur without the same governance applied to corporate identities.
• Browser-layer enforcement: Browser-layer enforcement is policy control applied directly in the browser rather than at the endpoint, network, or SaaS boundary. It lets teams monitor or block actions such as uploads, clipboard use, and domain access at the exact point where a user interacts with data and destinations.
• Category-based policy: Category-based policy groups apps and domains into risk classes such as unapproved AI tools or personal file sharing, then applies controls across each class. This reduces exception drift and makes it easier to govern large numbers of destinations without maintaining brittle per-site rules.

Deepen your knowledge

Browser-session data leakage and shadow account governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI tool usage and unmanaged identity risk, it is worth exploring.

This post draws on content published by Push Security: browser controls to prevent sensitive data and secrets leaking into unsanctioned AI tools. Read the original.