Key takeaways

• Most zero trust evaluations cover identity, network segmentation, and ZTNA but leave the browser uncontrolled, which is where more than 90% of enterprise work actually happens.
• A zero trust architecture without last-mile enforcement in the browser creates a perimeter-secured but session-exposed environment, where data can be exfiltrated, phished, or leaked inside sessions that ZTNA and SASE tools cannot inspect.
• True zero trust requires embedding policy where work happens, not wrapping controls around the outside of the workspace; the shift is from protecting the path to governing the destination.
• The same blind spot undermining today's zero trust evaluations also exposes organizations to an AI governance gap: AI tools run inside the browser, and most zero trust frameworks have no visibility into what happens inside those sessions.

Introduction

Most security teams have deployed ZTNA, with continuous identity verification and device posture checks enforced at every login. The network is segmented, and the evaluation scorecard is green across the board. And yet something still feels exposed.

The discomfort isn't unfounded. Most zero trust security evaluations were built for an architecture that assumes the network is the primary attack surface. They're thorough, well-reasoned, and incomplete. The gap they miss is architectural, and it lives at the last mile: the browser session where enterprise work actually happens. This article maps that gap, explains why existing controls can't close it, and introduces a more complete zero trust architecture evaluation framework that accounts for the session layer.

The zero trust evaluation gap most teams don't see

Security leaders who've completed a thorough zero trust evaluation know the feeling. Every pillar is addressed. Identity verification is continuous. Device posture is assessed before access is granted. The network is microsegmented. ZTNA governs application access. The audit looks strong. Then a phishing incident surfaces inside an authenticated session, or sensitive data appears in a personal cloud storage account, and the post-mortem reveals the breach vector was a browser tab the entire zero trust framework treated as invisible.

The standard zero trust security evaluation framework covers four well-established pillars: identity verification, device posture, network segmentation, and zero trust network access for applications. Each of these pillars is legitimate and valuable. The gap isn't that these controls are wrong. It's that they all operate at the perimeter or the path, never at the point where work actually happens.

More than 85% of enterprise work now happens through a browser or SaaS application, according to Gartner. Yet most zero trust frameworks treat the browser as a transparent conduit rather than a policy enforcement point. Once a user is authenticated and their device is verified, ZTNA opens the tunnel and steps aside. What happens inside the application session (inside a browser tab, inside a data transfer) is largely invisible to the access layer.

The result is a well-protected perimeter around a session the organization can't see or control. This isn't a design flaw in ZTNA or microsegmentation. These tools were built for a network-centric world where controlling the path was sufficient. That world has changed. The browser isn't a dumb pipe anymore; it's the primary work environment. The zero trust framework just hasn't caught up.

Why network-level zero trust isn't enough

An authenticated, policy-compliant contractor opens a browser tab to the application they've been approved to access. They screenshot sensitive data, paste it into a personal email in an adjacent tab, and close both tabs. Every access control passed. Every identity check cleared. Nothing in the zero trust model flagged the exfiltration, because nothing in the architecture could see it.

This isn't a hypothetical edge case. It's the structural reality of network-level zero trust. ZTNA verifies identity and device posture before granting entry, then steps back. It can't govern what happens after the session begins: downloading files to local drives, sharing screens, pasting data into unapproved applications, or interacting with a malicious page inside a trusted site. The enforcement boundary ends at the access point, and the controls that follow face a parallel limitation.

SASE and secure web gateways attempt to fill this gap at the network level. They inspect traffic at the network level, but browser traffic to SaaS applications is TLS-encrypted. Gateways must break and re-inspect to see content, a performance-degrading approach that still can't reach what happens inside the rendered browser session. Microsegmentation limits lateral movement between network segments, but a user's browser session to a SaaS application is a direct internet connection. Lateral movement via copy-paste or file download doesn't touch the internal network at all.

Organizations can have a mature zero trust posture across identity, network, and device and still have zero visibility into data leaving through browser-based actions. According to IBM's 2025 Cost of a Data Breach Report, organizations with a deployed zero trust architecture save an average of $1.76 million per breach. But that figure assumes the architecture actually covers the breach vector. When 90% of work happens in sessions the architecture can't inspect, the coverage assumption deserves scrutiny.

The important insight here isn't that ZTNA needs better policies. It's that this is an architectural gap, not a configuration gap. SASE and ZTNA were designed for a world where controlling the network path was sufficient. They solved that problem elegantly. The problem they weren't built for (governing what happens inside a browser session) wasn't a design criterion when those architectures were defined. You can't fix it by tuning policies at the access layer. You need enforcement at a different layer entirely.

What changes when zero trust starts at the browser

The question security leaders should be asking isn't "how do I get more out of my existing zero trust tools?" It's "what if zero trust controls were embedded at the point of work, not wrapped around the outside of it?"

The architectural shift is from "secure the path to work" to "secure the environment where work happens." Instead of applying policy at the network edge, enforcement lives inside the session itself, in the browser layer, where every action, every data interaction, and every page visit is visible and governable.

This is the core capability of Island's Enterprise Browser: a Chromium-based enterprise browser where zero trust policy isn't a layer added on top. Conditional access, DLP, session recording, anti-phishing, and last-mile controls operate inside every browser session without requiring traffic to backhaul through a proxy or decrypt and re-encrypt at a gateway.

What changes in practice is concrete. A user authenticated through the enterprise browser can view sensitive data but is prevented from printing, downloading, or copy-pasting it. A contractor can access the specific applications they need without touching the internal network or waiting for a managed device. A phishing site is blocked at the point of engagement rather than after the credential has been entered.

The proof points illustrate the scale of the shift. Bank of Marion reduced phishing investigation time from hours to three minutes using Island's Enterprise Browser, because investigators could replay the exact session rather than reconstructing it from network logs. In another deployment, contractor onboarding dropped from 45 days to 45 minutes, because access doesn't require provisioning devices, VPNs, or VDI sessions. It's governed through browser-layer policy.

The zero trust network access component reinforces this. Island Private Access, part of Island Network Services, provides zero trust access to private applications. Because enforcement lives inside the browser, Island Private Access doesn't require backhaul for most sessions. Up to 90% of sessions go direct, which eliminates the latency penalty traditional SASE architectures impose by routing everything through a distant proxy.

This isn't about replacing network controls. ZTNA, microsegmentation, and SASE still serve important functions. The shift is adding the session layer to the architecture so zero trust extends to where work actually happens, not just the path that gets users there.

How to evaluate zero trust solutions beyond the checklist

Every security team has been in this moment: halfway through an RFP or vendor evaluation, the realization surfaces that the evaluation criteria were designed for last year's architecture. The categories are right. The pillars are legitimate. But the framework doesn't account for the layer where most enterprise risk actually lives.

The standard evaluation framework (identity, device, network, application access) isn't wrong. It's incomplete. A more complete zero trust framework adds a fourth dimension: session governance and last-mile enforcement.

The four-layer zero trust evaluation framework

1. Identity layer: MFA, continuous authentication, and identity-aware access policies. Standard, well-covered by most evaluations.
2. Device layer: Device posture assessment, endpoint controls, and managed/unmanaged device policies. Often included, sometimes superficially.
3. Network layer: ZTNA for private application access, microsegmentation, and SWG for web traffic. Well-covered, frequently over-weighted.
4. Session layer (the gap): In-session DLP, last-mile controls (print, download, copy-paste, screenshot), session visibility and recording, anti-phishing inside authenticated sessions, and governance of data interactions after access is granted. Rarely evaluated.

When building your next zero trust evaluation, consider adding these questions to the RFP or vendor review:

• Can your solution govern what happens inside an authenticated session, not just at the access point?
• What visibility do you have into data interactions (copy, paste, download, print) that occur after a user is authenticated?
• Can you enforce different data policies for different user types (employee, contractor, BYOD) within the same application, without managing separate infrastructure?
• How does your architecture handle browser-based SaaS applications without requiring TLS break-and-inspect at the network layer?
• What happens when a legitimate user takes a malicious action inside a session your controls already approved?

The session layer is consistently underweighted in zero trust evaluations, and the reason is structural, not negligence. Evaluation templates and analyst frameworks were built when session-layer control didn't exist as a deployable capability. The vendor market for identity, network, and device controls is mature, with established RFP language and well-known analyst frameworks. Session-layer governance is newer, less standardized, and easier to miss or deprioritize in procurement cycles. Recognizing this helps teams adjust their evaluation approach before the next procurement round, not after the next incident.

The enterprise AI blind spot in zero trust

Security leaders across the industry are navigating the same tension: employees are using AI tools productively, and the organization wants to enable that. But the security team can see the AI entry point (the URL) and nothing inside the session. Not what data was submitted, not what was returned, not whether a prompt contained regulated information.

The mechanics are familiar. ChatGPT, Copilot, Gemini, and every enterprise AI tool are browser-accessed SaaS applications. Data flowing in and out of those tools travels inside browser sessions that most ZTNA and SASE architectures cannot inspect at the session layer. An organization can have a policy that says "AI tools are permitted for authenticated users" and still have no visibility into whether those users are submitting source code, customer PII, or regulated financial data.

This isn't a new risk category. It's the same last-mile session gap that affects all browser-based work, now amplified by the sensitivity of what employees share with AI tools and the speed at which AI adoption is expanding. NIST SP 800-207, the foundational zero trust framework, establishes the principles of least-privilege access and continuous verification. But it doesn't address session-layer AI governance, because the framework predates widespread enterprise AI adoption.

A zero trust architecture with session-layer enforcement can govern AI usage at the point of interaction: redacting sensitive data before it reaches AI providers, logging every AI interaction for audit, and blocking specific AI tools by policy while permitting others. Island Enterprise AI extends this capability through AI Protect, providing visibility and data protection across every AI entry point so the same session-layer governance preventing data exfiltration via copy-paste also prevents regulated data from being submitted to AI tools.

As AI agents and agentic workflows expand, the session-layer gap will widen. AI agents can take autonomous actions inside browser sessions: submitting forms, extracting data, and interacting with applications. Organizations that haven't addressed the session-layer gap today will face a significantly larger surface area when agents operate at scale.

FAQ

What are zero trust solutions?

Zero trust solutions are security technologies that enforce the principle "never trust, always verify" by requiring continuous authentication and authorization for every user, device, and session. A complete zero trust architecture spans identity, device, network, and session layers rather than assuming anything inside the network perimeter is trustworthy.

What is the difference between zero trust and ZTNA?

Zero trust is a security model and architectural philosophy. ZTNA (zero trust network access) is one category of technology that implements zero trust principles for private application access. ZTNA controls who gets in; a full zero trust architecture also needs to govern what happens after they're inside, which requires session-layer enforcement.

What does a zero trust framework include?

NIST SP 800-207 defines zero trust as a set of principles centered on least-privilege access, continuous verification, and assumption of breach. In practice, a zero trust framework covers identity verification, device health assessment, network segmentation, application-level access controls, and (in more complete implementations) session-layer governance of what users can do after access is granted.

How do I evaluate zero trust providers?

Evaluate zero trust providers across four layers: identity (continuous authentication, MFA), device (posture assessment, managed/unmanaged policies), network (ZTNA, microsegmentation, SWG), and session (in-session DLP, last-mile controls, AI governance). Most evaluations cover the first three thoroughly. The session layer is the most commonly missed and often the most relevant for browser-based SaaS environments.

How does zero trust implementation affect end-user experience?

Zero trust implementation done well is invisible to users, with policy enforcing in the background and friction appearing only when a boundary is reached. Architectures embedding controls directly into the browser layer can deliver this without the latency or session interruption typical of VPN- or proxy-dependent approaches.

Take the next step

If you're re-evaluating your zero trust architecture and want to see what session-layer enforcement looks like in practice, we're happy to walk through what we've built. Request a demo.