Zero trust browser controls reshape secure access beyond the VPN

At a glance

What this is: This is a zero trust access analysis showing why browser-native controls and cloud-delivered SSE are being positioned to close gaps left by VPN, VDI, and device-centric security.

Why it matters: It matters because IAM and security teams need controls that extend beyond authentication into session behaviour, especially for BYOD, third-party access, and browser-based use of sensitive data.

By the numbers:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• Only 5.7% of organisations have full visibility into their service accounts.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Island's analysis of zero trust browser controls for modern access

Context

Zero trust access has matured beyond a simple device check at login. The problem now is that security controls often stop at initial authentication, while the real risk emerges during the session when users move data, use SaaS and private applications, or interact with AI tools from managed and unmanaged devices.

This article sits at the intersection of identity governance, access control, and browser security. For IAM teams, the key issue is not whether identity is verified once, but whether policy can continue to govern user actions, third-party access, and sensitive data handling after access has been granted.

Key questions

Q: How should security teams implement zero trust for BYOD and third-party access?

A: Security teams should separate authentication from device ownership and design controls for unmanaged endpoints explicitly. Use identity verification, real-time posture checks, and session policy enforcement together so contractors and partners can reach applications without inheriting full trust. The goal is not to make BYOD look managed, but to constrain what untrusted devices can do after access is granted.

Q: Why do VPNs and VDI struggle with modern access governance?

A: VPNs and VDI are strong at creating a protected path, but weak at governing behaviour inside the session. They do not naturally control copy, paste, downloads, or browser-based AI use. That gap matters because many data loss events happen after login, when users interact with applications rather than with the network boundary.

Q: What do teams get wrong about compliance in zero-trust browser models?

A: Teams often assume that centralising enforcement automatically centralises assurance. In reality, compliance depends on the quality of policy design, logging, exception handling, and identity ownership. A browser can help execute controls, but it cannot correct inconsistent governance across business units or compensate for missing review processes.

Q: How should organisations govern browser-accessible AI development tools?

A: They should classify them as identity-sensitive runtime services and apply the same scrutiny used for privileged admin tools. That means validating who can connect, what each channel can do, and whether command-bearing paths are isolated from read-only telemetry. If the browser can reach it, the interface is part of the security boundary.

Technical breakdown

Why VPN and VDI models struggle with modern zero trust access

VPNs and VDI were designed to create a controlled access path, but they do not naturally enforce granular behaviour inside the application session. Once connectivity is established, policy often becomes coarse and user experience can degrade. In modern work, that leaves a gap between identity verification and actual data handling, especially when users are on unmanaged devices or moving between apps and AI services. Browser-native controls shift the enforcement point closer to where work happens, while SSE adds cloud-based policy enforcement across traffic and access decisions.

Practical implication: review where your current controls stop enforcing policy and identify session-level gaps that VPN or VDI cannot close.

How browser-native policy enforcement changes access governance

An enterprise browser can enforce rules at the point where users view, copy, paste, download, or share data. That matters because many security failures are not about initial entry, but about what happens after entry. This is especially relevant for sensitive applications accessed from BYOD or partner devices, where full device management may not be realistic. Browser-level control creates a narrower and more observable policy surface than endpoint-only approaches, and it can reduce dependence on invasive agents.

Practical implication: define which actions on sensitive data must be controlled in-session, not just which users may authenticate.

What zero trust means when users also interact with AI in the browser

The rise of browser-based AI use creates a governance problem because prompts and outputs can become data leakage paths. Security teams need visibility into which AI applications are being used, whether they are approved, and whether sensitive content can be blocked before it enters a prompt or leaves in an output. This is not primarily an LLM model risk problem. It is an access and interaction control problem, and it touches both human identity governance and the growing number of unmanaged AI-assisted workflows.

Practical implication: inventory browser-accessed AI tools and apply policy to prompts, outputs, and approved application paths.

NHI Mgmt Group analysis

Zero trust is no longer just an access decision, it is a session governance problem. The article is right to move the boundary of control beyond login, because modern risk frequently begins after authentication rather than before it. That shift matters for identity teams that still measure success by successful sign-in, not by controlled use of data. The governance lesson is that continuous verification must extend to user actions, not merely identity proofing.

Browser-native control creates a more realistic enforcement layer for BYOD and third-party access. Traditional device-centric models assume the organisation can standardise endpoints, but contractors and partners often sit outside that assumption. A browser can become the policy point where access, data movement, and application use are governed without full device ownership. For teams running mixed human and non-human access models, that same principle reinforces the need for context-aware policy at the session edge.

Session-level governance is becoming a named concept in practical zero trust design. The valuable shift here is from trust at the perimeter to control inside the interaction. That is especially relevant where the browser now mediates access to SaaS, private applications, and AI tools. Practitioners should treat browser session control as a distinct governance layer, not as a replacement for identity, PAM, or endpoint controls.

AI use in the browser exposes a policy gap that IAM teams cannot ignore. When employees can access AI tools directly, the risk is often prompt leakage, shadow usage, or unapproved data exposure rather than model compromise. That places the issue squarely in governance, not just cyber operations. For identity programmes, the practical conclusion is that AI access policy, application approval, and data handling rules need to be governed together.

What this signals

Session governance will become a more visible control requirement as organisations try to extend zero trust beyond managed endpoints. IAM, PAM, and browser controls will increasingly need to work as a policy stack rather than as separate projects. For programmes that still measure success by login events alone, the next maturity step is to govern what happens after access is granted.

Browser-mediated AI use creates a new identity-adjacent control surface that security teams will need to inventory. If employees can reach AI tools from standard work sessions, then application approval, data handling policy, and user entitlements need to be evaluated together. The practical risk is not only shadow AI, but ungoverned data flow through ordinary browser activity.

For identity leaders, the signal is clear: zero trust is shifting from a perimeter model to a behaviour model, and that makes the browser a policy enforcement point worth treating as part of the identity architecture. Teams should align access review, session policy, and data protection controls before unmanaged access becomes the default operating model.

For practitioners

• Define session-level control points Map which actions must be controlled after authentication, including copy, paste, download, upload, and share events inside sensitive applications. This identifies where browser-enforced policy can supplement identity checks that end too early.
• Separate BYOD access from device trust assumptions Classify contractor, partner, and remote-user access flows by whether the organisation can manage the endpoint. Where it cannot, use browser- or SSE-based controls to keep policy enforcement independent of full device ownership.
• Inventory browser-based AI usage Track which AI applications users reach from the browser, whether they are approved, and what data can be entered or exported. This helps prevent shadow AI use from becoming an uncontrolled data path.
• Reassess where identity policy ends Review whether your IAM and PAM controls only decide who gets in, or whether they also govern what users can do once they are inside. If the answer stops at access, the programme still has a session governance gap.

Key takeaways

• Zero trust programs fail when they stop at initial authentication and do not govern what users do inside the session.
• Browser-native policy is becoming a practical way to manage BYOD, third-party access, and data movement without relying on full device control.
• Identity teams should treat browser-based AI use and session behaviour as governance problems, not only as network or endpoint issues.

Key terms

• 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-native control: Browser-native control is policy enforcement built into the browser itself rather than added only at the network or endpoint layer. It can inspect and restrict user actions where web applications, data, and AI tools are actually used, which makes it useful for unmanaged-device scenarios.
• Secure Access Service Edge: SASE is a converged architecture that combines network connectivity with security controls such as zero trust access, secure web gateway, and firewall services. It is useful for consistent enforcement across distributed environments, but it does not replace identity governance or entitlement ownership.
• Unmanaged Access: Any access to company data that does not pass through the organisation's primary control and logging stack. In practice, this includes devices, apps, or identities that can authenticate or reach data without being fully visible to IAM, MDM, or audit workflows.

What's in the full article

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

• Specific browser policy controls for copy, paste, download, and share actions that are not fully expanded here.
• The full access flow for unmanaged devices, including how posture signals are evaluated before application access is allowed.
• Examples of how approved and restricted AI interactions are governed inside the browser session.
• The combined Island and Cisco Secure Access architecture, including how SSE complements browser-native enforcement.

👉 The full Island post covers browser enforcement, unmanaged device access, and AI use governance 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 identity lifecycle management. It gives security and identity practitioners a stronger foundation for building controls that match how access now works across human, non-human, and AI-driven workflows.