Key takeaways
- Red Access operates from inside the session itself — DLP matching, prompt scanning, OCR, and token-theft detection run locally on the user’s device, not from a proxy sitting in the network path.
- The engine reaches browsers and Electron/WebView2 desktop apps (Slack, Teams, ChatGPT, Claude, Notion) through a single OS-level network directive pushed via Intune, Jamf, Kandji, or GPO — no agent, no extension, no browser to replace.
- Red Access doesn’t replace SASE. Existing Zscaler, Netskope, Cato, or Palo Alto deployments keep doing what they do; Red Access takes the sessions that need controls at the prompt or action level.
Every few weeks, a new surface appears. Claude shows up inside Slack. ChatGPT adds a browser to its desktop app. A developer finds a vibe-coding platform that sends prompts somewhere security hasn’t categorized yet. Each new tool can send a security team through the same cycle: assess it, categorize it, write a policy, push an update, then hope the policy lasts until the next launch.
Red Access is not a proxy or an SSE/SASE platform. It’s a session security layer for the web-based desktop. Nothing is installed on endpoints; the engine runs inside the session. When a customer uses SASE, its existing configuration can selectively direct chosen sessions to Red Access. The rest of the traffic stays with the existing network stack.
Where enforcement happens
Red Access operates from within the session itself, on the user’s device, in real time.
Once the engine is active in a session, it sees the user’s activity in that session and applies controls to it. A credit card pasted into a Slack message. A prompt typed into Claude. A file dragged into a ChatGPT upload. A browser extension attempting to send data to a third-party endpoint. A Microsoft token being lifted by an adversary-in-the-middle technique. DOM monitoring, DLP matching, token-theft detection, OCR on uploaded images, prompt scanning — these run locally, inside the session, on the user’s device.
Processing and enforcement happen locally. By default, Red Access logs metadata rather than session content — the destination, user identity, action, and policy decision. Customers can selectively enable prompt discovery, session recording, or DLP evidence capture; collected payload is stored in a dedicated, encrypted database for that customer.
How the engine reaches the session
The engine reaches the session through the operating system’s existing network configuration. Nothing is installed on the endpoint — no agent, no extension, no background process, no browser to replace. The only endpoint change is a single OS-level network directive, pushed through the organization’s endpoint-management tooling — such as Intune, Jamf, Kandji, or GPO. Rollout is measured in minutes, not months.
That OS-level setting is the mechanism that gives Red Access an attachment point across supported browsers — Chrome, Edge, Safari, Firefox — and across the Electron and WebView2 desktop applications where modern work actually happens: WhatsApp Desktop, Slack Desktop, Teams Desktop, Outlook with Copilot, ChatGPT Desktop, Claude Desktop, Notion Desktop. An extension installed in a browser doesn’t by itself extend its controls into these desktop applications. Red Access reaches them without installing anything inside them.
When a user opens a session covered by policy, Red Access’s cloud loads a lightweight JavaScript and WebAssembly engine — 17 to 60KB — into the session. The initial engine delivery typically takes 10 to 40 milliseconds. In monitor mode, the added latency is 0.0018ms. From that moment on, the engine operates locally within the session.
The engine itself was built from scratch for the way the modern web actually works — TLS 1.3, HTTP/2, HTTP/3, WebSocket sessions, and the asynchronous, session-encrypted patterns of modern SaaS.
There are three distinct configurations in play, and it’s worth keeping them separate. The OS-level network directive on the endpoint gives Red Access its attachment point — it’s deployment plumbing, pushed through endpoint-management tooling. The SASE routing policy, managed in the SASE admin console, decides which sessions are directed to Red Access. The Red Access session policy, managed in the Red Access admin console, defines which controls apply once the engine is active — DLP, per-application rules, prompt-level controls.
Red Access session policy reaches endpoints within seconds of being set in the Red Access admin console. No files to redistribute, no versions to track across the fleet, no inconsistency between the endpoints that pulled the latest policy and the ones that didn’t.
How Red Access coordinates with existing SASE
Red Access is not a replacement for an existing SASE deployment. For organizations with Zscaler, Netskope, Cato, or Palo Alto Prisma already in place, the existing network stack keeps doing what it does, and Red Access handles the sessions that need controls at the prompt or action level.
In Zscaler, the existing proxy-forwarding configuration can direct selected sessions to Red Access. The rest of the traffic remains with the existing network stack. This does not make Red Access a proxy or deploy a second proxy layer across all user traffic. Other SASE platforms integrate through comparable mechanisms, with the specifics documented separately.
In practice, most customers keep their SASE handling what it already handles well. Red Access takes the sessions that need in-session controls: GenAI tools, uncategorized domains, and the applications that may be excluded from inspection in a given SASE deployment because inspection can break their behavior. Those are among the sessions Red Access is designed to handle.
What this changes in practice
WhatsApp Web, Microsoft Teams, Slack, and other modern messaging and collaboration tools use persistent, encrypted WebSocket sessions. Red Access operates inside the session, where it can detect sensitive identifiers within session content — a credit card number pasted into a Slack message, a password sent through Teams, or a sensitive prompt entered into Claude.ai. By default, it can apply controls without logging the full message; customers who enable prompt discovery, session recording, or DLP evidence capture can selectively collect payload, as described above. It applies controls while preserving the application’s session behavior.
GenAI tools appear in multiple forms — as websites, desktop apps, browser extensions, plugins in Microsoft and Google Workspace, features inside chat apps, and agents in vibe-coding platforms. A policy aimed at ChatGPT.com covers only one of these. Red Access doesn’t need to recognize every AI tool to apply controls inside a session where its engine is active. Once the engine is in, it sees prompts, uploads, and model responses wherever they come from.
Browser extensions sending data to third-party endpoints, embedded webviews in desktop apps, and headless browsers used by AI applications to render content are handled through the same mechanism. The engine’s visibility isn’t tied to a list of applications. It’s tied to the session.
What Red Access doesn’t do
Red Access handles web sessions. It complements firewalls and endpoint EDR, which protect other parts of the environment. A small class of applications bypass OS-level network configuration — typically developer tooling that makes direct outbound calls instead of honoring system network settings — and sit outside what Red Access handles.
The architectural distinction is this: network controls can show which services a user reached; Red Access adds visibility into actions inside the session and can act on them. When new SaaS tools, AI agents, or embedded browsers appear, they fall within the same architecture rather than requiring a new one.
