Browser-based AI control is becoming an identity problem

At a glance

What this is: This is an analysis of why browser-based AI activity is becoming an identity and access problem, with Push Security framing the browser as the control point for seeing and governing AI use.

Why it matters: It matters because IAM, NHI, and security teams need a way to govern shadow AI, token use, and session-level access where AI tools are actually used, not just where they are approved.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read Push Security's analysis of browser-based AI control and identity risk

Context

Browser-based AI control is the growing gap between where people use AI tools and where security teams can actually observe identity behaviour. In practice, AI apps are often accessed through unmanaged browser sessions, with tokens, prompts, and data movement handled outside traditional endpoint or network visibility.

That matters for IAM because the control problem is no longer just whether an AI tool is approved. It is whether the organisation can see who is using it, what identity or token is carrying the session, and whether browser-native activity is creating shadow AI exposure across human, machine, and delegated access paths.

Push Security positions the browser as the place where these interactions can be seen and controlled, which is a typical response to a very typical enterprise condition: adoption moves faster than governance.

Key questions

Q: How should security teams govern employee use of public AI tools in the browser?

A: They should treat browser AI use as an identity and data-control problem, not just an acceptable-use issue. The team needs visibility into what was pasted, which account was active, whether the content was sensitive, and whether policy enforcement occurred before the data left the organisation. Controls that only inspect network events will miss the real decision point.

Q: Why do AI tools create new identity governance risks for IAM teams?

A: AI tools create new identity governance risks because they combine fast adoption with broad access paths and subordinate permission objects. A user may look clean in the directory while the platform still holds project roles, service accounts, or keys that can act independently. That makes governance a control-plane problem, not a simple login problem.

Q: What breaks when organisations rely on endpoint controls alone for AI use?

A: Endpoint-only control misses the in-session behaviour that determines whether AI use is safe or compliant. Users can copy data, authorise connected apps, and interact with web-based AI tools without those actions being visible at the endpoint layer in a useful way. That leaves a governance gap between sign-in and actual use.

Q: How can teams decide whether to block or allow browser-based AI usage?

A: Base the decision on data sensitivity, identity assurance, and the browser context of the session. If the user is signing in from an unmanaged device, using an external AI service, or moving regulated data, the safer choice is to block or heavily constrain the session rather than rely on policy alone.

Technical breakdown

Why browser telemetry matters for AI app governance

Browser telemetry captures the session where the user, token, and application actually meet. For AI apps, that matters because the security event is often not a download or endpoint execution but a browser session that sends prompts, receives output, and may expose data or credentials. Browser visibility can surface account takeover, suspicious consent, unmanaged SaaS use, and AI tool access that never reaches endpoint agents. The architectural point is simple: if AI use is mediated by the browser, then the browser becomes the most useful layer for identity-linked detection and control.

Practical implication: treat browser visibility as part of your identity control stack for AI use, not as a separate monitoring add-on.

Shadow AI and unmanaged identities in the browser

Shadow AI is not just undiscovered software, it is undiscovered identity use. When employees sign into consumer AI services, connect work data, or reuse accounts and tokens in personal browsers, governance loses track of the identity boundary. That creates a non-human identity style problem even when the user is human, because the risk is carried by session artefacts, tokens, and permissions rather than by the person alone. The browser becomes the place where approved and unapproved AI usage converge, which is why browser-native guardrails matter for discovery, blocking, and response.

Practical implication: inventory AI access by session and browser context, not just by sanctioned application lists.

Why session-level controls matter more than app-level policy

Application allowlists cannot fully govern what happens once a browser session is established. AI tools can be used through shared links, connected apps, copied credentials, or browser-based prompts that move data outside the approved path. Session-level controls look at the live identity state, the destination domain, the data being pasted or uploaded, and the risk signals around token abuse or account takeover. That is a different control model from static approval, and it is better aligned to how browser-native AI use actually unfolds.

Practical implication: pair AI app policy with session controls that can block risky uploads, prompts, and token-driven abuse in real time.

Threat narrative

Attacker objective: The objective is to use browser-mediated AI activity to steal data, abuse sessions, or operate inside an unmanaged identity channel that conventional controls do not see.

1. Entry occurs when a user or attacker interacts with AI services through a browser session, often using a legitimate login or a compromised account rather than malware on the endpoint.
2. Escalation happens when tokens, sessions, or connected apps extend access beyond the original approval boundary, allowing data movement or account abuse inside the browser.
3. Impact follows when unmanaged AI use exposes sensitive content, enables account takeover, or creates a blind spot for defenders who cannot see the browser-native interaction.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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 is now an identity governance problem, not just an application governance problem. Once prompts, uploads, and connected accounts move through the browser, the security boundary shifts from installed software to live session behaviour. That makes traditional approval lists insufficient on their own, because the identity risk lives in what the browser session can do right now. Practitioners should treat browser-mediated AI activity as a first-class governance domain.

Shadow AI is the unmanaged identity layer of AI adoption. The core issue is not whether a tool is sanctioned in theory, but whether the organisation can see the identity, token, and browser context that make it usable in practice. When those signals are absent, organisations lose the ability to distinguish benign experimentation from policy-breaking data movement. The result is blind governance, not just shadow software.

Browser telemetry closes a control gap that endpoint and SaaS controls leave open. Endpoint tools see far less of modern AI usage than many teams assume, especially when activity happens inside a browser session with copied data, federated logins, or connected SaaS integrations. Browser-level inspection gives identity teams a chance to detect account takeover, suspicious consent, and exfiltration paths earlier. That makes browser telemetry a governance input, not merely a detection source.

Identity teams need to decide where session authority ends and policy enforcement begins. AI use in the browser often crosses the line between user intent, delegated access, and automated data movement. That creates a governance question IAM teams cannot avoid: which browser actions are allowed, which are blocked, and which require review because the session itself has become the control point. The programme implication is that browser control must be mapped into identity policy.

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.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to the same report.
• The NHI Lifecycle Management Guide is the right next step for teams trying to close visibility, rotation, and offboarding gaps.

What this signals

Browser-based AI governance will increasingly sit inside IAM operating models. Teams that still separate browser security, SaaS governance, and identity policy will keep missing the live session where AI actually happens. The practical shift is toward unified visibility across sign-in, session, and data movement, with browser telemetry feeding identity decisions.

Shadow AI should be treated as a discovery problem with identity consequences. Once organisations can see which browsers, accounts, and connected services are involved, they can start distinguishing experimentation from unmanaged risk. That makes governance more measurable and helps reduce the number of blind spots created by consumer AI adoption.

With 72% of organisations already reporting or suspecting NHI breaches in the broader identity estate, the control lesson is clear: visibility must extend to the places where identities are actually used, including the browser.

For practitioners

• Map browser-accessed AI services Inventory which AI tools are accessed through browsers, who is using them, and which identities, tokens, or connected apps are involved. Separate approved usage from unmanaged usage so you can distinguish policy-compliant sessions from shadow AI activity.
• Add session controls for AI uploads Use browser-native controls to detect and restrict risky prompt, paste, upload, and file-sharing behaviour when sensitive data may leave the organisation through AI tools. Focus on the live session rather than only on application approval.
• Correlate identity telemetry with browser events Join identity logs, SaaS audit trails, and browser telemetry so security teams can see whether a human login, delegated token, or compromised session is driving AI activity. That correlation is essential for triage and response.
• Review consent and token governance Check whether browser-based AI use can introduce new OAuth consent grants, session extensions, or third-party app links that outlive the original business purpose. Revoke or constrain those paths where the session no longer matches the intended access scope.

Key takeaways

• Browser-based AI use shifts control from installed software to live identity sessions, which is why IAM teams need browser telemetry.
• Unmanaged AI activity is really unmanaged identity activity when tokens, consent grants, and browser context are not visible.
• Teams that want real governance should combine identity telemetry, session controls, and browser-based enforcement rather than relying on policy lists alone.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Browser telemetry: Browser telemetry is the event data produced by enterprise browser activity, including logins, profile changes, downloads, session starts, and extension or site interactions. In identity governance, it becomes useful when those events are correlated with account state and privilege context rather than treated as generic activity logs.
• Session-Level Data Movement Control: Session-level data movement control is the practice of constraining how information can be copied, uploaded, printed, shared, or exported during an active browser session. It matters because many breaches begin with ordinary user actions, not malware or exploit chains.
• Managed Identity: A cloud-provider-managed identity assigned to a compute resource, allowing it to authenticate to cloud services without storing credentials in application code.

What's in the full article

Push Security's full post covers the operational detail this post intentionally leaves for the source:

• Specific browser-side detection patterns for account takeover, token misuse, and suspicious AI app activity
• Product and telemetry examples showing how browser visibility is used to investigate AI-related identity events
• Implementation detail on how browser controls are applied to unmanaged identities and shadow SaaS usage
• Threat-research context behind the Push team's view of browser-native AI exposure

👉 Push Security's full post covers the browser telemetry, identity signals, and control detail behind this analysis

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.