Browser-based AI risk is exposing the limits of perimeter security

At a glance

What this is: This is an analysis of Omdia research showing that browser-based attacks and unsanctioned AI use are now converging into one of the enterprise’s least visible risk surfaces.

Why it matters: It matters because the browser now sits at the intersection of SaaS access, AI prompts, credentials, and sensitive data, which means IAM and security teams need controls that operate at the point of interaction, not only at the network edge.

By the numbers:

• 55% experienced a successful attack or near-miss through employee browser use in the prior 12 months.
• 68% of organizations reported an increase in browser-based security incidents over the past two years.
• 59% say browser-based AI use is the attack vector they are least able to monitor.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.

👉 Read Island’s analysis of Omdia’s browser security findings and AI risk data

Context

The browser has become the enterprise control point for SaaS, internal tools, AI systems, and sensitive data, but most security models still treat it as a user endpoint problem. That leaves a governance gap because browser activity happens inside the session, where network proxies, VPNs, and perimeter tooling have limited visibility into copy-paste, downloads, prompts, extensions, and credential use.

For identity teams, the browser is now where human identity, NHI-style access patterns, and emerging AI workflows intersect. That makes browser security more than an endpoint question: it is an access, auditability, and data-handling problem that touches IAM policy enforcement, shadow AI oversight, and session-level control.

The report’s starting point is typical of modern enterprises, not an edge case. Work moved into the browser faster than security architecture moved with it, which is why the gap is now visible across productivity, data protection, and access governance.

Key questions

Q: How should security teams govern AI browsers that can act on enterprise content?

A: They should govern them as access intermediaries, not just as user interfaces. That means binding them to federated identity, restricting the data classes they can touch, and requiring exportable telemetry for every meaningful action. If the browser can act without those controls, it should stay out of regulated workflows.

Q: Why do traditional tools struggle to secure the browser session?

A: Traditional tools usually govern traffic around the browser rather than actions inside it. They can see a connection, but often not the copy-paste event, the prompt submission, the download, or the extension activity that creates the risk. That gap matters because many browser threats originate within a trusted session, where the user is already authenticated and perimeter controls are already bypassed.

Q: What do security teams get wrong about browser AI risk?

A: Many teams focus on whether AI tools are allowed, but ignore the prompt itself as the exposure event. That misses accidental leakage and deliberate misuse, especially when users paste restricted financial, legal, or architectural information into public services. The mistake is treating AI as an application issue instead of a data and identity control point.

Q: What should organisations do first if browser-based attacks are rising?

A: Start by identifying which browser workflows carry credentials, sensitive data, and AI interactions, then prioritise those paths for policy enforcement and audit logging. The first objective is not to block every browser action, but to control the highest-risk session behaviours where the greatest leakage and credential abuse occurs.

Technical breakdown

Why browser sessions create a control gap for identity and data

A browser session is a live runtime environment where authentication, authorisation, data transfer, and user interaction all occur together. Unlike network-layer inspection, session-level activity can include prompt entry into AI tools, token reuse, extension permissions, and file movement that never leaves a clear perimeter trace. That is why traditional tools often detect only after data has already moved or credentials have already been used. The core weakness is not the browser itself, but the fact that most enterprises still govern access around the browser rather than inside it.

Practical implication: move from perimeter checks to session-aware controls that can govern browser activity in real time.

How AI use turns the browser into a shadow data path

When employees use generative AI inside the browser, each prompt becomes a potential data-handling event. If the organisation cannot see which AI platform is being used, what data is pasted, or whether the destination is sanctioned, then policy enforcement becomes probabilistic rather than deterministic. This is where shadow AI becomes an identity governance issue: the user is authenticated, but the destination system and the data path are not necessarily governed. Auditability matters as much as blocking, because many organisations need evidence of what was shared and where.

Practical implication: define approved AI destinations, block sensitive data to unsanctioned tools, and retain interaction logs.

Browser-native policy versus layered browser security

Layered approaches such as proxies, VPNs, and agents were designed for access control and threat filtering at the edge, not for fine-grained control inside a browser session. Browser-native policy changes the enforcement point by applying rules at the interaction layer, where downloads, copy-paste, extension use, and prompt submission actually happen. That matters because browser-based threats often originate inside the trusted session, not from an external network event. For identity practitioners, this shifts control design toward policy enforcement that follows the user and the session, not the device alone.

Practical implication: evaluate whether your current controls can govern actions inside the session, not just traffic around it.

Threat narrative

Attacker objective: The attacker wants to exploit trusted browser activity to steal credentials, exfiltrate data, or leverage AI-assisted workflows without triggering perimeter controls.

1. Entry occurs through normal employee browsing or browser-based application use, often while interacting with SaaS, AI tools, or web-delivered internal systems.
2. Escalation happens inside the browser session through phishing, malicious extensions, vulnerable plugins, credential theft, or scripted interaction with trusted workflows.
3. Impact is achieved through data loss, credential exposure, or unauthorized AI prompt submission that moves information beyond governance boundaries.

NHI Mgmt Group analysis

Browser security has become an identity governance problem, not just an endpoint problem. The browser is now where authenticated users, sensitive data, AI prompts, and SaaS access converge. That means the main question is not whether a device is managed, but whether session activity is being governed at the point of action. Practitioners should treat browser controls as part of access governance, not as a separate perimeter add-on.

Shadow AI creates a visibility trust gap that conventional IAM cannot close on its own. IAM can authenticate the user, but it cannot by itself determine which AI service received the data, what was pasted, or whether the interaction was sanctioned. That is a policy and auditability problem as much as an access problem. Organisations need controls that can enforce destination approval and retain interaction evidence.

Browser-native enforcement is the named concept this report reinforces. Browser-native enforcement means governing copy, paste, downloads, prompts, extensions, and session behaviour where the work actually happens. The report shows why external controls are increasingly reactive: they see the connection, but not always the action. For practitioners, the lesson is to align enforcement with the browser session itself.

AI use is widening the attack surface faster than traditional browser controls can adapt. The browser is no longer only a path to web applications, it is also a path to unmanaged AI workflows and sensitive prompt leakage. That increases the governance burden for identity, data security, and security operations teams together. Practitioners should assume browser activity now needs policy, logging, and exception handling as a standard control plane.

Operational friction is now a security signal, not just a user-experience metric. If browser controls create too much friction, users route around them and rebuild the risk elsewhere. The report’s emphasis on usability matters because governance that cannot survive day-to-day work will fail in production. Security teams should measure whether policy is being bypassed, not only whether it exists.

What this signals

Browser-native governance will increasingly become part of identity programme design. As SaaS, AI, and sensitive workflows continue to collapse into the browser, teams will need controls that can distinguish sanctioned from unsanctioned interaction paths. The practical signal is that browser policy, auditability, and identity context will need to be managed together, not in separate operational silos.

Shadow AI changes the evidence standard for security operations. It is no longer enough to know that a user reached an application. Teams need to know what was pasted, where it went, and whether the destination was approved. That makes browser telemetry and governed access logs more important than broad perimeter inspection for many enterprise use cases.

Browser governance is now a control-plane question for identity teams. If the browser is where users authenticate, interact with AI, and move data, then session-level policy becomes a core part of least-privilege design. That is why programmes that already track privileged access and secrets governance should extend their review to browser-mediated workflows.

For practitioners

• Map browser activity to governed identity and data flows Identify which browser workflows carry authentication, prompt submission, file transfer, and sensitive data movement, then classify them as governed access paths rather than general web traffic.
• Control sanctioned and unsanctioned AI destinations Maintain an explicit allowlist for AI platforms that may receive company data, and block or warn on prompt submission to unsanctioned services.
• Test whether existing tooling sees inside the session Validate whether VPNs, proxies, EDR, or DLP controls can detect copy-paste, downloads, extension use, and browser-based prompt activity before data leaves the session.
• Build audit trails for browser interactions Retain logs of browser-based AI usage, file movement, and policy interventions so investigators can reconstruct what a user did inside the session.

Key takeaways

• The browser has become a primary enterprise control surface, but most security models still govern it from the outside in.
• Omdia’s data shows the scale of the problem, with 55% of organisations reporting a browser-related attack or near-miss in the last year.
• Practitioners need session-aware policy, AI destination controls, and audit trails that follow the work into the browser itself.

Key terms

• Browser-native protection: Security controls that run inside the browser and can observe page content, script behaviour, session state, and user interaction directly. For identity security, this matters because the browser is where modern authentication and application abuse increasingly happen, beyond the endpoint's field of view.
• 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.
• Session Governance: The practice of binding access to a specific task, time window, and execution context, then revoking it when the work is done. For non-human identities, session governance matters because tokens and delegated permissions often persist longer than the action they were created to support.
• Browser-mediated access: Browser-mediated access is access that is exercised through the browser rather than through a tightly controlled native client or backend workflow. It matters because many modern identity and data control failures occur after sign-in, during the live session where users interact with SaaS and AI tools.

What's in the full report

Island's full blog covers the operational detail this post intentionally leaves for the source:

• The full Omdia benchmark table on browser incident frequency, budget response, and top-five priority ranking
• The breakdown of browser security spending shifts across IT and security teams, including funding ownership trends
• The detailed productivity-impact metrics that show where browser security friction is actually appearing
• The report’s application-access findings on browser-based and Windows workflows, which explain tool sprawl in more depth

👉 Island’s full blog covers the browser-attack categories, AI visibility gap, and enterprise adoption signals in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives identity and security practitioners a practical framework for extending control to modern access paths and session-driven risk.