Executive Summary
- The session is where work, data, and AI prompts actually live now — inside browser tabs and the embedded webviews wearing the costume of Outlook, Slack, Teams, ChatGPT Desktop, and Claude Desktop. The category has converged on this as the right enforcement layer. That part is settled.
- There are two paths to reach it. Install software on every surface where a session renders — a managed browser, extensions, desktop agents, and now a network plane to cover what the managed browser couldn’t reach. Or deliver the enforcement into the session itself, with no new browser, no new network plane, and no persistent agent on the device.
- The install-everywhere path has a footprint problem the diagram doesn’t show — partial deployments, stale extensions, adoption ceilings that users route around. A security tool that never fully deploys isn’t really securing your environment. The architectural question isn’t whether the session is the right layer. It is. And has been for a while now. It’s how you get there without building a stack to compensate for the stack.
****
Most of what your team does at work happens inside a web session. Not just the browser tabs — the Outlook window with Copilot inside it, the Slack desktop app, ChatGPT Desktop, Claude Desktop, Figma, Teams. They look like applications. They’re web sessions wearing a desktop shell. Windows and macOS are mostly carriers at this point. The real operating system is the session.
That’s where work lives now. It’s also where the data lives, where the AI prompts happen, and where security has the least visibility. The category that was supposed to govern this — traditional SASE, the kind that detours your traffic to a distant cloud proxy, decrypts it, inspects it, re-encrypts it, and forwards it on — was designed for a different world. Offices. Managed devices. Traffic that could be broken and inspected without breaking the work. That world is gone, and the architecture built for it is buckling under TLS 1.3, HTTP/3, certificate pinning, and a volume of AI traffic it was never sized for. If you can’t see inside an AI session, you’re not governing AI. You’re guessing.
In May 2025, Island named that problem out loud. They published an architectural argument that the backhaul-and-inspect model is structurally broken in the AI era, and announced a network plane to replace it. The diagnosis is right.
We’ve been operating on it for two years.
The question at the security layer isn’t whether the session is where enforcement belongs. That’s settled. The question is how you get there.
Two paths to the same layer
If the moment of interaction is the right enforcement point, what gets you there? There are essentially two paths on the table now.
The first is to install software on every surface where a session can render. A managed browser for the browser sessions. An extension or runtime for the existing browsers you can’t replace. A desktop agent for the embedded webviews inside Outlook, Slack, Teams, ChatGPT Desktop, Claude Desktop. A network plane for the rest.
Each install gives you rich local context. Each install also has to be deployed, managed, updated, kept current, and accepted by users. Island’s newly-announced network plane is the latest piece of this path — a second enforcement system added to cover what the managed browser could never reach. The unstated concession in the announcement is that the original architecture, by itself, didn’t get to where work actually happens. Outlook with Copilot is not the managed browser. The Slack desktop app is not the managed browser. ChatGPT Desktop is not the managed browser. Reaching them takes more architecture.
The second path is to deliver the enforcement into the session itself, wherever the session renders. No new browser. No new network plane. No persistent agent. A lightweight engine is embedded into the session’s memory before the page renders, governs page interactions, keystrokes, clipboard actions, file transfers, and AI prompts locally in real time, and vanishes when the session ends. It exists for the duration of the session, then it’s gone. This is the Red Access path. It reaches the same enforcement layer the install-everywhere path reaches, but it gets there by being in the session rather than by being installed on every surface where a session can render.
Both paths land at the same layer. The point isn’t whether the session is where security enforcement belongs — both architectures agree. The point is whether you reach the session by installing software on every surface, with multiple layers of security stacked on top of each other, or by being in the session in the first place.
A small note on language. Island’s announcement frames the unit of governance as the “Perfect Packet.” Packet is a network-layer word doing non-network-layer work — the thing being governed is a session-layer interaction, not a packet. We’d just leave the observation there. Many of you would’ve caught it anyway.
What that architectural choice actually costs you
A partner on a recent call described the lived reality of install-everywhere security this way: customers with browsers that weren’t updated for a year or two because of the hassle around upgrading extensions and keeping them current. That’s not a hypothetical operational state. That’s where a meaningful share of install-everywhere deployments actually live — partially deployed, partially current, partially enforcing. It’s the gap between the architecture diagram and the production estate.
Three specific costs sit underneath that reality.
The first is change management. Forcing a workforce to switch browsers — or accept a new desktop agent, or install another extension — is a behavior-change project, not a security project. Enterprise-browser deployments at scale have struggled to clear that threshold; rollouts stalling well below half adoption are not rare. A security tool that never fully deploys doesn’t secure anything.
The second is footprint. Every install is something to deploy, update, patch, integrate, and reconcile when policies conflict between layers. Adding a second enforcement plane on top of the managed browser doesn’t subtract complexity; it adds it. The organization that couldn’t get the original architecture past partial adoption now has two systems it couldn’t fully deploy.
The third is the adoption ceiling itself. A control that slows people down isn’t just annoying — it’s a vulnerability. Users route around it. Every workaround is a gap. Every gap is exposure. The install-everywhere model has been running into this ceiling quietly for years, and adding architecture to compensate for the adoption ceiling of the original architecture has its own ceiling.
None of this is a vote against the diagnosis. The diagnosis is right. It’s a question about what the diagnosis costs you depending on which path you take to act on it.
The choice the buyer is making
The category has converged on the session layer, and the public architectural debate that started this year is the healthiest thing that’s happened to browser security in a long time. The question on the table is no longer whether enforcement belongs at the moment of interaction. It’s how you reach that moment.
You can reach the session by installing software on every surface where a session renders, and managing the substrate that comes with it. Or you can reach the session by being in it — using the browsers your team already has, the firewall you already own, and a session-scoped engine that’s there when work happens and gone when it doesn’t.
If you’re sizing up what session-layer enforcement actually looks like in your environment — across the browsers your team already uses and the embedded webviews inside Outlook, Slack, and the AI clients — talk to Red Access →
