Employees using AI in the browser are creating hidden data leaks

At a glance

What this is: Cyera argues that everyday browser use is now the main route for AI data leakage, with risk coming from unsanctioned apps, mixed identities, and approved tools used without oversight.

Why it matters: IAM, NHI, and human identity teams need the same visibility into account context and browser activity that they already demand for privileged access, because AI use now crosses all three programme areas.

👉 Read Cyera's analysis of four risky ways employees use AI in the browser

Context

Browser-based AI use creates a governance gap because employees can move sensitive information into external models without any clean boundary between sanctioned and unsanctioned behaviour. The primary issue is not just tool choice, but identity context, account type, and whether the organisation can see where prompts and data are going.

The article frames four leak paths that matter to identity teams: personal accounts on unsanctioned tools, corporate accounts on unsanctioned tools, personal accounts on approved tools, and approved tools used without adequate oversight. For IAM leads, the question is no longer whether AI is present, but whether account attribution and session control are strong enough to distinguish safe use from risky use.

Key questions

Q: How should security teams control AI use in browsers without blocking productivity?

A: Security teams should focus on identity context, account separation, and data-sensitive enforcement rather than blanket blocking. The goal is to allow approved use while stopping sensitive content from moving into personal accounts or unmanaged tools. Browser visibility matters because that is where prompts, uploads, and account switching actually happen.

Q: Why do approved AI tools still create data leakage risk?

A: Approved tools still create risk when users rely on personal accounts, bypass governance with unmanaged sign-ins, or process data that should never enter an LLM. Approval covers the application, not every account or prompt path. Without oversight, the organisation can still expose confidential data through a trusted interface.

Q: What breaks when employees use personal and corporate AI accounts interchangeably?

A: Interchangeable account use breaks attribution, policy enforcement, and data handling assumptions. Security teams can no longer tell whether a prompt came from a governed enterprise identity or a personal account with different terms and controls. That weakens both auditability and the organisation's ability to enforce acceptable use.

Q: Who is accountable when sensitive data is sent to an AI model from the browser?

A: Accountability sits with the organisation that allowed the identity, session, and data flow to remain uncontrolled. IAM teams own attribution, security teams own policy enforcement, and business leaders own acceptable use boundaries. If the browser session is invisible, accountability becomes fragmented and hard to prove.

Technical breakdown

Browser-based AI leakage and identity attribution

Browser sessions have become the control plane for day-to-day AI use, which means identity attribution matters as much as the model or app itself. When a user signs into an AI tool with a personal account, the organisation loses both policy control and reliable ownership of what data was shared. When the same activity happens with a corporate account on an unmanaged service, the identity looks legitimate while the data handling remains outside enterprise governance. The security problem is not simply access, but the mismatch between visible authentication and invisible downstream use of the prompt or upload.

Practical implication: correlate browser session context with identity source so approved access does not become ungoverned data transfer.

Approved AI tools do not equal safe data handling

An approved AI application only reduces risk if the enterprise has control over account type, data processing terms, and usage boundaries. The article highlights a common failure mode: users keep personal AI accounts active while doing work, or they use sanctioned tools to process material that should never enter an LLM. In both cases, the interface looks normal, but the trust model is broken. The underlying issue is that application approval does not automatically extend to every account, every prompt, or every dataset a user can reach from the browser.

Practical implication: treat app approval and account authorization as separate controls, not interchangeable assurances.

Context-aware enforcement in the browser

Traditional DLP struggles when the risky event happens inside a live browser session rather than in a file transfer or email flow. Cyera describes contextual intelligence as the ability to distinguish between benign actions, such as summarising public content, and higher-risk actions like uploading confidential business data. That distinction depends on understanding identity, account context, and data sensitivity together. In practice, this is a browser-enforced policy problem, not just a content inspection problem.

Practical implication: build enforcement rules that use identity and data context together, rather than keyword-based blocking alone.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser-based AI use has turned the user session into an identity-governance boundary. The article shows that employees are not waiting for sanctioned AI rollout, which means governance now begins at the browser rather than at procurement. That shifts the control question from whether AI is approved to whether the enterprise can attribute usage, separate account types, and stop sensitive data from leaving trusted identity boundaries. Practitioners should treat browser sessions as governed identity events, not just endpoint activity.

Personal and corporate AI accounts create different trust failures, but both break the same governance premise. Personal accounts on unsanctioned tools remove enterprise control entirely, while corporate accounts on unmanaged tools create a false sense of legitimacy. The named concept here is identity-context leakage: the account may be known, but the organisation still loses control over where the data goes and how it is reused. The implication is that identity proof alone is not enough when the downstream model relationship is outside policy.

Approved apps without oversight expose a data-governance gap, not a tool-selection problem. Cyera's example of sanctioned AI used for insider misuse, trading abuse, and unethical HR decisions shows that approval does not constrain intent. The issue is not just access to the model, but access to sensitive material inside a trusted session. For IAM and security teams, this means the control plane must distinguish authorised use from authorised abuse, which is a very different governance challenge.

Browser-level AI controls now sit at the intersection of IAM, NHI, and human behaviour management. Human users initiate the activity, but the resulting data path can extend into third-party AI services and corporate identities at the same time. That makes cross-domain visibility more important than any single control point. Organisations that only manage sanctioned applications will miss the mixed-account and shadow-use behaviour that creates the actual exposure. Practitioners need a unified view of identity context across the browser, the account, and the prompt.

What this article really signals is that AI governance is becoming an account-context problem before it is a model-risk problem. The first control failure is often not the model, but the mismatch between who the user is signed in as and what data they are allowed to process. That makes attribution, session visibility, and policy enforcement the practical foundation for safer AI use. Teams that cannot see the account context cannot govern the risk.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to the same research.
• For the broader control model, see OWASP NHI Top 10 for the risk patterns that emerge when identity and runtime behaviour drift apart.

What this signals

Identity-context leakage: browser-based AI use shows that governance now depends on knowing who is signed in, which account is active, and what data is leaving the environment. Teams that cannot connect those three elements will keep confusing approved use with controlled use.

The next control gap will be attribution at session speed, not after-the-fact audit. Security teams should expect more pressure to integrate browser telemetry with identity controls and with policy logic that can distinguish personal accounts from enterprise accounts in real time.

For practitioners extending zero trust into AI usage, the relevant baseline remains the NIST Cybersecurity Framework 2.0. The practical shift is to apply it at the browser boundary, where identity, data sensitivity, and user intent intersect.

For practitioners

• Separate personal and corporate AI usage at the identity layer Block work-data prompts from personal accounts and require clear attribution for sanctioned tools so users cannot blend identities inside the browser session.
• Enforce contextual browser policies for sensitive data Use browser controls that distinguish public summarisation from uploads containing confidential material, customer records, or M&A data.
• Review approved AI tools as data-handling environments Check whether enterprise contracts, account controls, and logging actually cover the way employees use the tool in practice, not just the procurement decision.
• Tie AI governance to identity attribution and session visibility Feed browser telemetry into IAM and DLP workflows so security teams can see who used which account and what kind of data was involved.

Key takeaways

• Browser-based AI use creates a governance gap because identity attribution often ends where the prompt begins.
• Account approval is not the same as data control, and mixed personal or corporate account use makes that gap harder to see.
• Browser-level enforcement and identity-aware telemetry are now practical requirements for controlling AI data leakage.

Key terms

• Identity-context leakage: Identity-context leakage is the loss of control that happens when a user’s authenticated identity looks legitimate but the data they send is handled outside enterprise policy. In browser-based AI use, the account may be known, yet the prompt, upload, or model relationship escapes governance.
• Shadow AI: Shadow AI is AI use that occurs without clear organisational visibility, approval, or control. It often appears in browser sessions where employees sign into public tools with personal accounts or use corporate accounts on unmanaged services, creating hidden data exposure and weak auditability.
• Browser-enforced policy: Browser-enforced policy is control that evaluates identity, content, and context at the point where a user interacts with an AI service. It is more precise than static blocking because it can distinguish safe interactions from risky ones while the session is still active.

Deepen your knowledge

Browser-based AI governance and identity attribution are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to control AI use without slowing people down, this is a relevant place to start.

This post draws on content published by Cyera: 4 Risky Ways Your Employees Use AI in their Browser. Read the original.