By NHI Mgmt Group Editorial TeamPublished 2026-05-20Domain: Governance & RiskSource: Surf Security

TL;DR: Browser-based work now concentrates SaaS access, admin activity, contractor sessions, and GenAI usage in one control point, while phishing, malicious extensions, session hijacking, and unsafe data movement increasingly target that layer, according to Surf Security. The browser is now where identity, policy, and data protection have to converge, or governance becomes fragmented and easy to bypass.


At a glance

What this is: This is an analysis of enterprise browser security as a browser-layer control plane, with the key finding that modern work and modern attacks now meet in the same session.

Why it matters: It matters because IAM, PAM, and NHI programmes increasingly depend on the browser as the enforcement point for identity-aware access, data handling, and session governance.

By the numbers:

👉 Read Surf Security's guide to enterprise browser security for modern teams


Context

Enterprise browser security is the practice of enforcing identity, data, and threat controls at the browser layer, where most SaaS and web-based work now happens. The problem is not simply that browsers are popular. It is that existing perimeter, endpoint, and network controls were designed for a different access model, one where the session itself was not the primary security boundary.

For IAM and governance teams, that shift is material because the browser now carries human sessions, contractor sessions, and AI-assisted workflows through the same interaction surface. The browser becomes the practical control plane for least privilege, DLP, phishing resistance, and policy enforcement, especially when users operate from unmanaged devices or distributed environments.

The article’s starting position is typical of the market moment: browser activity has become operationally central faster than most organisations have re-architected their control stack. That gap creates both security exposure and governance ambiguity.


Key questions

Q: How should security teams govern browser-based SaaS access on unmanaged devices?

A: Security teams should govern browser-based SaaS access by combining identity-aware policy, action-level controls, and session logging. The goal is to allow business use without giving unmanaged devices unrestricted movement of sensitive data. Focus on the specific browser actions that create risk, then apply restrictions based on app sensitivity and data classification.

Q: Why do browser-layer controls matter more as work shifts into SaaS and GenAI apps?

A: Browser-layer controls matter because the browser is now the place where authentication, data entry, content transfer, and AI interaction all happen in one session. Network controls cannot reliably see user actions such as paste, upload, or screenshot. That makes the browser the most practical boundary for enforcing identity-aware policy.

Q: What do organisations get wrong about browser security and zero trust?

A: Many organisations still think zero trust is only about verifying access before entry. In browser-first environments, the risk often appears after authentication, when a user moves data, installs extensions, or submits information to a public AI tool. Zero trust has to extend into the session, not stop at login.

Q: Who should be accountable for browser session governance in regulated environments?

A: Accountability should sit across IAM, security architecture, compliance, and endpoint governance, with clear ownership for browser policy design and audit evidence. Regulated environments need session records, data handling rules, and access policy that line up with internal controls and external obligations such as privacy and industry requirements.


Technical breakdown

Identity-aware browser access control

Enterprise browser security combines browser policy with identity context, so access decisions can incorporate user identity, group membership, device posture, location, risk signals, and application sensitivity. This is different from network access control because the enforcement point sits inside the user session rather than around the network path. In practice, the browser can permit, restrict, or block actions based on who is acting and what data is being handled. That makes it a policy enforcement layer rather than just a rendering client.

Practical implication: teams should treat browser policy as an extension of identity governance, not as a separate endpoint feature.

Browser-layer DLP and session control

Browser-layer DLP works by controlling actions such as copy, paste, upload, download, printing, screenshots, and clipboard transfer at the moment they occur. This is materially different from proxy-only inspection because the system can see the user action, the destination, and the content context in the live session. For modern SaaS and GenAI usage, that matters because the highest-risk exfiltration path is often user-driven, not malware-driven. The browser becomes the enforcement layer where policy can react in real time.

Practical implication: map your most sensitive data flows to browser actions, then decide which actions must be blocked, masked, or audited.

Securing browser-based GenAI and agent workflows

The article also highlights browser-mediated GenAI usage, which is increasingly relevant when users or AI agents interact with data through web interfaces. In these workflows, the browser is where prompts are entered, data is retrieved, and outputs are transferred. That means governance has to cover not only access to the application, but also what can be pasted, submitted, downloaded, or copied out during the session. When the browser is the interface for AI-assisted work, session controls become a governance requirement, not a convenience feature.

Practical implication: define policy for public AI tools and browser-based copilots before sensitive prompts and outputs become routine.


NHI Mgmt Group analysis

Browser security is becoming an identity control plane, not a niche endpoint feature. The article is right to frame the browser as the place where modern work actually happens, because that is also where identity, session, and data controls collide. From an NHI and IAM perspective, the browser now hosts human sessions, service interactions, and AI-assisted workflows in a way that legacy perimeter tools cannot model cleanly. Practitioners should stop treating browser security as a bolt-on and start treating it as part of access governance.

Browser-layer policy exposes a governance gap that network-only thinking cannot close. VPNs, proxies, and virtual desktops still assume that controlling the path is enough to control the action. That assumption no longer holds when the risky event is a paste into a GenAI interface, an upload to an unsanctioned SaaS app, or a malicious extension acting inside the session. The implication is that governance must move from transport control to action control, with the browser as the policy boundary.

Identity blast radius: the browser is now where a single authenticated session can touch far more data and systems than earlier access models assumed. That concentration makes session governance more important than device trust alone, especially for contractors, BYOD users, and regulated workloads. The practical consequence is that access review, DLP, and policy enforcement all need to account for what a user can do after authentication, not only what they were allowed to reach.

GenAI governance and browser governance are converging. The article correctly places browser-based AI usage inside the security conversation, because prompts, retrieved data, and outputs all move through the same session layer. Security teams that separate AI governance from browser policy will miss the actual exfiltration path. Practitioners should align browser controls with AI usage policy before adoption outpaces oversight.

For identity programmes, the browser is now where policy becomes measurable. Detailed logging, action control, and context-aware enforcement make the browser a practical source of evidence for compliance, access governance, and user behaviour review. That does not replace IAM or PAM, but it gives those programmes a session-level enforcement surface they have lacked in browser-first work. Teams should use that surface to connect identity decisions to observable actions.

From our research:

  • Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
  • 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
  • For related governance context: 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.

What this signals

Identity blast radius: browser-first work expands the number of actions that occur after authentication, which means access governance has to measure session behaviour, not just login success. That becomes more urgent when only 5.7% of organisations have full visibility into their service accounts, because the broader identity stack is already operating with limited observability. Security teams should expect browser policy to become a core evidence source for access reviews and data control.

Browser governance will increasingly sit alongside IAM, PAM, and DLP rather than beneath them. The organisations that adapt fastest will be the ones that define browser policy around real user actions, then tie those controls back to SIEM, compliance reporting, and zero-trust policy design.


For practitioners

  • Map browser-controlled actions to high-risk data flows Inventory where copy, paste, upload, download, print, screenshot, and clipboard actions occur in SaaS, admin, contractor, and GenAI workflows. Then decide which actions need block, mask, or log treatment for each application class.
  • Use the browser as the enforcement point for third-party access Apply identity-aware policy for contractors and vendors who work from unmanaged devices, with restrictions tied to application sensitivity and data classification rather than only network location.
  • Separate GenAI policy from general web policy Create browser rules for public AI tools, browser-based copilots, and agent-assisted workflows so sensitive prompts and outputs are governed explicitly, not left to user judgment.
  • Integrate browser logs into access review and compliance workflows Route browser session evidence into SIEM, DLP, and governance processes so reviewers can see how access was actually used, not only who authenticated successfully.

Key takeaways

  • Browser security is now an identity and data governance problem, not just a web protection problem.
  • The largest risk is after authentication, when users move data inside a live browser session.
  • Security teams should treat browser policy as a control plane for SaaS, contractors, and GenAI workflows.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST Zero Trust (SP 800-207)The article centres zero-trust access at the browser session boundary.
NIST CSF 2.0PR.AC-4Browser identity-aware access supports least-privilege access governance.
OWASP Non-Human Identity Top 10NHI-01Browser-based workflows increasingly expose non-human and delegated access paths.

Review browser-mediated access paths for service and delegated identities that can touch sensitive data.


Key terms

  • Enterprise Browser Security: Enterprise browser security is the practice of enforcing access, data, and threat controls directly inside the browser session. It treats the browser as an execution and policy boundary for SaaS, web apps, and AI-assisted workflows, rather than relying only on network or endpoint controls.
  • Browser-Layer DLP: Browser-layer DLP is data loss prevention applied to user actions inside the browser, such as copy, paste, upload, download, printing, and screenshots. It gives security teams control over what happens to sensitive data at the moment of use, when exfiltration risk is highest.
  • Identity-Aware Access: Identity-aware access is policy that changes based on who the user is, what device they are using, and the context of the session. In browser security, it lets organisations enforce finer-grained controls than network location or simple login success can provide.
  • Browser Session Governance: Browser session governance is the discipline of controlling and auditing what happens after authentication inside a live browser session. It matters because modern work often continues well past login, where data movement, AI prompts, and extension use create the real risk.

What's in the full article

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

  • Browser security capability breakdowns across identity-aware access, DLP, extension control, and session enforcement.
  • Implementation discussion for SaaS-heavy, BYOD, contractor, and regulated environments.
  • Coverage of GenAI and browser-based AI workflow controls that this post only summarises at a strategic level.
  • The vendor's comparative framing of browser security against VPN, VDI, RBI, proxy, and SWG models.

👉 Surf Security's full article covers browser-layer controls, deployment use cases, and GenAI governance considerations.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-05-20.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org