Browser security ranks highest for AI and identity controls

At a glance

What this is: This is an analysis of which security problems browser-based controls can solve best, with the key finding that the browser is the strongest layer for identity, phishing, SaaS, and AI governance visibility.

Why it matters: It matters because IAM, NHI, and security teams need to decide which identity controls belong in the browser, which belong in the IdP or endpoint, and where browser-only visibility closes real governance gaps.

By the numbers:

• Browser security is already a top-five priority for 88% of organizations, and the top priority for 26%.
• The browser is where 85% of work now happens.
• 94% of all login attempts originate from bots.
• 63% of all human logins involve credentials already compromised elsewhere.

👉 Read Push Security's ranking of the top browser security use cases

Context

Browser security matters because many of the most important identity events now happen in the browser session, not in the identity provider. That includes credential entry, OAuth consent, shadow SaaS sign-up, AI tool access, and phishing interaction, which means the browser can observe behaviour that traditional IAM and SSPM tools never see.

The article argues that browser security should be ranked by security value and browser fit, not by whether a control sounds modern. That framing is directly relevant to IAM programmes because it separates browser-native identity visibility from controls that still belong in the IdP, endpoint stack, or access platform.

For identity teams, the practical question is whether the browser is the right enforcement point for account takeover, phishing, shadow SaaS discovery, and AI usage governance. In this topic area, browser-layer controls are strongest when they observe authentication and consent events that other systems only learn about after the fact.

Key questions

Q: How should security teams use browser controls to reduce account takeover risk?

A: Use browser controls to observe login attempts, credential entry, MFA status, and fallback authentication at the point of use. That lets teams stop password reuse, breached credentials, and ghost logins before they become account takeover, especially where the IdP cannot see shadow SaaS or unmanaged devices.

Q: Why do browser-based controls matter for OAuth and shadow SaaS governance?

A: Because the browser is where users create accounts, approve connected apps, and grant third-party access that can persist after the session ends. Without browser visibility, teams often learn about those access paths only after data has already moved into another tenant or service.

Q: What do security teams get wrong about AI governance in the browser?

A: They often treat AI as a separate problem, when much of the risk is the same identity and access behaviour seen in SaaS governance. Browser controls help with routing, visibility, and policy enforcement, but they still need to work alongside endpoint and platform-native controls.

Q: When should organisations prioritise browser security over other identity controls?

A: Prioritise it when the risk is concentrated in session-level behaviour such as login, consent, shadow SaaS discovery, or AI access that the IdP cannot observe. If the identity event happens in the browser, that is usually where enforcement and telemetry need to live first.

Technical breakdown

Account takeover prevention in the browser

Account takeover prevention in the browser works because every login, including password fallback, shadow SaaS access, and MFA gaps, is visible at the moment authentication happens. The browser can observe credential stuffing, password spraying, weak or reused passwords, and ghost logins that bypass the IdP’s normal visibility. That matters because many breaches start with stolen identity material rather than direct exploitation. Browser-native enforcement can evaluate context before the session is fully established, which gives defenders a chance to intervene where the IdP has no line of sight.

Practical implication: place login-time detection and credential-entry guardrails where the authentication event actually occurs.

Shadow SaaS and OAuth integration governance

Shadow SaaS discovery is browser-native because the browser sees the app before the organisation formally knows it exists. OAuth governance is even more sensitive, because granting a connected app can create persistent access across SaaS platforms without a traditional password prompt. In practice, this turns the browser into a consent control point for third-party integrations, including AI tools and agent-connected workflows. Once a grant is issued, the access path often outlives the user’s immediate session, which makes discovery and control fundamentally different from simple application inventory.

Practical implication: enforce policy on OAuth consent and connected-app creation at the point of user approval.

AI visibility and control in browser sessions

AI governance in the browser is not a new category so much as a consolidation of identity problems already present in SaaS and OAuth. Employees use personal accounts, unsanctioned apps, browser extensions, and connected integrations to reach AI tools, so the browser becomes the only common layer that can see account context, grant flows, and application choice together. That makes browser control especially useful for routing users to corporate tenants and reducing unmanaged AI access. It does not replace endpoint or platform-native governance, but it does close a major visibility gap in the session layer.

Practical implication: use the browser to steer users to sanctioned AI tenants and block unapproved access paths.

Threat narrative

Attacker objective: The attacker wants persistent identity-based access that survives beyond the initial browser session and opens pathways into data, SaaS, or connected AI services.

1. Entry begins with credentials being reused, phished, or sprayed inside a browser session, often across shadow SaaS or apps that never passed through the IdP.
2. Escalation occurs when the attacker gains session access, captures tokens, or uses OAuth grants to create persistence across connected services without needing repeated password entry.
3. Impact follows when the compromised browser session is used to pivot into cloud data, additional SaaS tenants, or AI-connected workflows with broader business reach.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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 security is now an identity control plane problem, not just a web protection problem. The article’s ranking makes sense because the browser increasingly hosts the identity events that matter most: login, consent, app discovery, and AI access. That means browser-layer controls are directly relevant to NIST CSF Protect and Detect functions, plus NHI governance where third-party access paths need continuous visibility. The practitioner conclusion is simple: if the browser sees the identity event first, it can also be the first enforcement point.

Shadow SaaS discovery changes the economics of identity governance. The value is not just inventory, but discovering unauthorised authentication and integration behaviour at the moment it happens. That is a different governance model from post-hoc app discovery because it exposes the access path, the user context, and the consent action together. The practitioner conclusion is that SaaS governance now has to track consent and authentication at session level, not just through sanctioned app catalogs.

AI governance is becoming a browser-native extension of existing IAM controls. The article correctly shows that AI risk often enters through the same identity channels already used for SaaS and extensions. That means AI governance should not be treated as a separate discipline in isolation from identity posture, OAuth governance, and browser extension control. The practitioner conclusion is that the same browser signals can support policy enforcement across shadow AI, connected apps, and unmanaged account use.

Identity blast radius: the browser is where small access decisions become enterprise-scale exposure. A login, consent grant, or extension permission may look local in the moment, but in practice it can open multiple downstream systems at once. That is why browser security deserves to be evaluated as a blast-radius control, not just a detection layer. The practitioner conclusion is to map which browser events create persistent access paths and then prioritise controls there first.

Browser fit should determine control placement, not product category language. The article’s core insight is that some problems belong in the browser because that is where the event exists, while others still belong in the IdP, endpoint, or access platform. That distinction matters for programme design because overloading the browser with every security use case dilutes the controls that truly fit there. The practitioner conclusion is to place each identity control at the layer where it can observe and enforce the real event.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how thin machine-identity oversight still is.
• That visibility gap is why Ultimate Guide to NHIs , Why NHI Security Matters Now remains the right next resource for teams reassessing identity control points.

What this signals

Identity blast radius: browser-level access decisions can create persistent downstream exposure across SaaS, AI, and third-party integrations. Teams should treat browser telemetry as a governance input, not just a detection source, because it captures the consent and login events that create the blast radius in the first place.

The next programme shift is architectural. IAM teams will need to decide which controls belong at the browser, which belong in the IdP, and which still require endpoint or platform-native enforcement. The organisations that win this split will reduce blind spots without turning the browser into an overloaded control layer.

With 30.9% of organisations storing long-term credentials directly in code, per the Ultimate Guide to NHIs, identity governance still fails whenever access is created outside the cleanest path. Browser controls help close one part of that gap, but only if they are tied to lifecycle and consent governance as well.

For practitioners

• Map identity events to the browser session Catalogue where login, consent, shadow SaaS sign-up, and AI access actually occur, then assign enforcement to the layer that can see the event first. Use that mapping to separate browser-native controls from IdP, endpoint, and access-platform controls.
• Enforce credential-entry guardrails Block corporate credentials from being submitted to unapproved domains and flag ghost logins, breached passwords, and MFA gaps during the login attempt. Treat this as a control for account takeover prevention, not just phishing response.
• Govern OAuth consent as access creation Require review and policy checks for connected-app grants, especially for third-party SaaS and AI integrations that create persistent access paths. Include consent events in your access audit trail so review teams can see what was authorised and when.
• Use browser telemetry for AI access policy Route users to corporate AI tenants, block unapproved personal accounts where policy requires it, and monitor browser extensions that can broker hidden AI access. Extend governance to the apps, grants, and extensions that create unmanaged entry points.

Key takeaways

• Browser security matters because the most important identity events now happen inside the session, where traditional IAM visibility is weakest.
• The strongest use cases are account takeover prevention, phishing defence, shadow SaaS discovery, OAuth governance, and AI access control.
• Practitioners should place enforcement at the layer that sees the identity event first, then align it with IdP, endpoint, and lifecycle controls.

Key terms

• Browser-native identity control: A browser-native identity control is an enforcement or visibility mechanism that operates inside the browser session where authentication, consent, and app use actually occur. It matters because it can observe identity behaviour that the IdP, endpoint, or network stack may not see in real time.
• Shadow SaaS: Shadow SaaS is software used by employees without formal approval, visibility, or governance from IT and security teams. In practice, it often appears first as a browser login or sign-up event, which makes the browser a critical discovery point for access control and risk tracking.
• OAuth integration governance: OAuth integration governance is the process of controlling which connected applications can access corporate data and identities through delegated authorisation. It covers consent, review, revocation, and monitoring because a single grant can create persistent access that outlasts the original login session.
• Identity blast radius: Identity blast radius is the amount of downstream exposure created when a login, token, or consent decision opens access to multiple systems. It helps practitioners think about access not as a single event, but as a potential chain of persistence, lateral movement, and data reach.

Deepen your knowledge

Browser-native identity visibility and OAuth governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are deciding where browser controls fit in your identity programme, it is worth exploring.

This post draws on content published by Push Security: ranking the top security problems you can solve in the browser. Read the original.