Browser-based AI control is becoming an identity problem

At a glance

What this is: This is an analysis of why browser-based AI usage is turning into an identity control problem, with browser telemetry positioned as the practical control surface.

Why it matters: It matters because IAM and security teams now need visibility into AI activity that may never pass through endpoint tooling, forcing new controls around unmanaged identities, sessions, and data movement.

Context

Browser-based AI use is creating an identity governance gap because the browser has become the place where sessions, prompts, data movement, and access decisions converge. Traditional endpoint and application controls may still see the device or the SaaS app, but they often miss the browser-native interaction layer where the real risk now appears.

For IAM and security programmes, this is less about blocking an app and more about governing how people and unmanaged identities use AI inside a live session. The control question shifts to what is visible, what is attributable, and what can be constrained before browser activity becomes data exposure or account takeover.

Push Security frames the browser as the enforcement point because that is where AI usage, shadow SaaS activity, and session behaviour can be observed together. That is a practical response to a governance problem that spans human users, SaaS access, and browser-based identity behaviour.

Key questions

Q: What breaks when AI use is only controlled at the app layer?

A: App-layer control misses the browser session where prompts, data movement, consent grants, and account switching actually happen. That leaves security teams blind to the actions that turn AI access into identity risk. Effective governance has to see and constrain behaviour in the browser, not just decide whether an application is permitted.

Q: Why do AI browsers create new identity and access risk?

A: Because they turn the browser from a passive display layer into a system that can interpret content and execute actions. That collapses the distance between authentication, privilege use, and data movement. Existing IAM models assume a user or workload is behind the action. AI browsers weaken that assumption.

Q: What signs show that agentic AI is escaping identity governance?

A: The clearest signs are agents appearing without inventory, connectors being added without review, and permissions that remain broad after deployment. If teams cannot say which agents exist, what they can touch, and how they are offboarded, governance is already behind the environment.

Q: How should security teams govern Shadow AI in everyday browser use?

A: Security teams should govern Shadow AI by enforcing controls where users actually interact with AI tools, not only at the network edge. That means browser-level inspection, content classification, and policy enforcement for paste, upload, and prompt actions. If users can move sensitive data into an AI tool without a control decision, the governance model is incomplete.

Technical breakdown

Why browser telemetry changes AI governance

Browser telemetry captures activity that often sits between identity providers, endpoint tools, and the SaaS application itself. In browser-based AI usage, that matters because prompts, copy-paste actions, token reuse, and session transitions may never appear as a clean event in a central IAM log. The browser becomes the closest thing to a control plane for observing who accessed what, when, and from which session context. That does not replace identity governance. It gives practitioners the missing operational layer needed to correlate AI use with account state, browser session state, and data movement.

Practical implication: treat browser telemetry as a governance signal, not just a detection feed.

Unmanaged identities and shadow SaaS in the browser

Browser-based AI control becomes difficult when the identity in play is unmanaged, transient, or outside the primary directory boundary. Shadow SaaS and consumer AI apps can be accessed with corporate credentials, personal accounts, or delegated sessions that never receive the same lifecycle controls as managed enterprise identities. That creates an attribution problem as much as an access problem. If the browser is where the identity presents itself, then the browser is also where policy must detect risky access paths, session reuse, and mismatched trust levels before those behaviours blend into normal user activity.

Practical implication: map browser-visible AI usage to identity ownership so unmanaged access paths do not escape governance.

Why session-level control matters more than app blocking

App blocking is a coarse control. It assumes the main question is whether an application is allowed at all. Browser-based AI usage shows why that is too narrow: the real risk often sits inside the session, where a user can copy sensitive content, authorise a third-party connection, or move data into an AI tool without any separate infrastructure event. Session-level controls focus on the behaviour that follows access, including whether the browser can detect, constrain, or respond to risky actions in real time. That is where identity, content, and usage context intersect.

Practical implication: prioritise controls that observe and constrain session behaviour, not just allow or deny the app.

Threat narrative

Attacker objective: The attacker aims to use the browser as a low-friction path to identity abuse, data exposure, or account compromise inside AI-enabled workflows.

1. Entry occurs when a user opens an AI app or browser session that is not fully governed by standard endpoint and SaaS controls.
2. Access is then sustained through normal browser-based session behaviour, including reused credentials, delegated consent, or unmanaged identities.
3. Impact follows when prompts, copied data, or connected accounts expose sensitive information or enable account takeover inside the browser session.

Breaches seen in the wild

• Gitloker GitHub extortion campaign: Phishing via GitHub notifications tricked developers into authorising malicious OAuth apps; Gitloker then wiped repos and demanded contact.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser-based AI control has become an identity governance problem, not just a content or endpoint problem. The browser now sits between the user, the identity provider, and the AI application, which means the control surface has shifted. When prompts, session state, and data movement all happen in one place, governance has to follow the browser layer if it wants visibility into actual AI use. The implication is that IAM teams can no longer treat browser behaviour as ancillary telemetry.

Unmanaged identity is the real governance gap hiding behind AI usage. Browser-based AI often involves accounts and sessions that are outside normal lifecycle discipline, even when the activity looks employee-led on the surface. That creates a blind spot where trust is granted to a session that has not been governed as an identity in its own right. Practitioners should treat browser-mediated AI access as an identity inventory problem as much as a security monitoring problem.

Session-level control is becoming the deciding factor in whether AI use can be governed at all. Blocking apps does not address copied data, delegated consent, or account switching inside a live browser session. The browser makes those actions observable, which is why it is becoming the most practical enforcement point for AI governance. Security teams should re-evaluate whether their current controls operate before access, during use, or only after exposure.

Browser-native AI activity changes the balance between visibility and enforceability. Conventional controls often know that a session exists, but not what the user did inside it. Push Security is pointing to a broader market direction: control is moving toward the layer where identity, browser activity, and SaaS behaviour converge. Practitioners should expect more governance pressure on browser-resident telemetry and less tolerance for blind spots in shadow AI usage.

Browser telemetry is emerging as the identity evidence layer for AI governance. The useful concept here is a browser identity perimeter: the practical boundary where user, device, session, and AI activity can be observed together. That perimeter does not replace directory governance, but it does expose the behaviour that directory controls alone cannot see. Teams should use it to make unmanaged AI use visible enough to govern.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Research and Survey Results

What this signals

Browser-based AI creates a control problem that sits between IAM and data protection. If the browser is where prompts, consent, and data transfer happen, then governance has to move closer to the session rather than relying on application allowlists or endpoint-only detection. The practical change is to treat browser activity as part of identity evidence, not just user behaviour.

Browser identity perimeter: the browser is becoming the point where identity evidence, session state, and AI usage can be observed together. That matters because conventional controls often know the user exists but not what happened inside the session. Teams should define which browser events are sufficiently trustworthy to drive governance decisions.

Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That gap is a useful proxy for the broader problem here: if machine identities are already poorly governed, browser-mediated AI access is likely to produce similar blind spots unless visibility moves closer to the interaction layer.

For practitioners

• Define the browser identity perimeter Identify which browser-visible events count as governable identity evidence for AI use, including session creation, consent grants, copy-paste, and account switching.
• Inventory unmanaged AI access paths List browser-based AI apps, shadow SaaS services, and consumer accounts that are reachable with corporate credentials or delegated sessions.
• Correlate sessions to identity ownership Tie browser sessions back to managed users, shared accounts, or unmanaged identities so AI activity is attributed before it becomes a review gap.
• Constrain high-risk browser actions Apply guardrails to data movement, OAuth consent, and suspicious copy-paste flows inside the browser rather than relying on app allowlists alone.

Key takeaways

• Browser-based AI usage is exposing a governance gap that conventional endpoint and app controls do not close.
• The browser is becoming the practical layer for observing sessions, consent, and data movement tied to AI use.
• Identity teams need browser-visible evidence if they want to govern shadow AI, unmanaged access, and session-level risk.

Key terms

• Browser Identity Perimeter: The browser identity perimeter is the practical boundary where user activity, session state, and identity evidence can be observed together. In browser-based AI use, it becomes the layer where governance can see prompts, consent, copy-paste, and account switching before those actions disappear into separate logs.
• Browser-native Ai: A browser-native AI capability embeds generative assistance directly into the browsing experience, so prompts, summaries, and transformations happen where users read and interact with content. It changes security control design because the disclosure decision happens inside the session, not only in backend systems or approved apps.
• Unmanaged identity: Any identity that can authenticate or act without being fully controlled by the organisation’s standard identity stack. That includes service accounts, API keys, tokens, and some AI agents. The risk is not just visibility loss. It is loss of ownership, lifecycle control, and reliable revocation.
• Session-level control: Session-level control is the ability to govern what a user, service, or agent can do during an active login or connection. It applies policy after authentication, using signals such as risk, device state, time, and action type to allow, restrict, step up, monitor, or terminate activity in real time.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.