SpirexSecure Enterprise Browser
Session Enforcement Layer

Secure the micro perimeter, The Browser.

SASE controls the network. Your IdP handles login. Neither controls what users actually do after they're in. Spirex sits in the browser execution path and enforces real-time policies on every user action - without replacing your stack, your browser, or your VPN.

Request a Deep-Dive See All Capabilities

System Architecture

How every session flows end to end.

From the device in a coffee shop to the database in your datacenter — here's every hop.

ENDPOINTS SPIREX CLOUD YOUR INFRASTRUCTURE Office Worker Managed · Full policy Remote Employee Home / hotel · Any location Contractor / BYOD Unmanaged · Restricted INTERNET Policy Console Identity · DLP rules · App allowlists · Audit Okta / SSO Entra ID Google WS Policy pushed to browser on every session ZTNA Gateway Per-app tunnels · Identity-aware · Zero network exposure ✓ No inbound ports · No network-wide access Encrypted tunnel mTLS · per-app only ZTNA Connector Lightweight · DC or cloud VPC ↑ Outbound dial-out only Web App 🗄 Database Legacy / On-prem RDP · SSH · APIs LEGEND Browser traffic · policy enforced per session ZTNA tunnel · restricted access (contractor) Outbound-only connector · no firewall changes needed
Where Spirex Sits

Between your users and every SaaS app they touch.

Traditional security tools secure the wire or the login. Spirex secures the session - the space between authentication and the action. It operates alongside your existing SASE platform and identity provider, extending your security stack into the browser without replacing anything.

Works alongside your existing SASE platform
Uses your existing identity provider for session context
No browser replacement, no endpoint agent, no VPN dependency
Deploy in hours, not months
User
Spirex
Session Enforcement Layer
SaaS Apps - Google, Slack, ChatGPT, Salesforce…
Identity Provider - Okta, Google Workspace, Azure AD
SASE Platform
Management Plane · Policy Authority

Spirex Admin Console

The single source of truth for every policy, user, and published application. Admins define rules once and they propagate to every enrolled browser instantly - no manual rollout, no endpoint agents to update.

Admin Console Policy Management Real-Time Push ZTNA App Catalog Identity Management Audit Log
Encrypted channel · Policy push · ZTNA tunnel relay
Control Plane · Real-Time Enforcement

Spirex Browser Enforcement Runtime

The Spirex browser runtime translates cloud policy bundles into live, per-tab enforcement decisions - before any navigation request reaches the network.

Policy Stack Evaluation 30-second Cloud Sync Tab Lifecycle Control DLP Signal Aggregation Risk Score Integration ZTNA Local Proxy
Secure channel · Real-time signals · In-page enforcement
Data Plane · Browser-Native Last-Mile

In-Page Security Engine · Threat Detection · DLP Controls

Code injected into every tab that monitors DOM mutations, intercepts credential submissions, scores page risk in real time, and enforces DLP controls at the point of data contact - inside the page itself.

DOM-XSS Monitor Phishing Detection Upload Watermarking Screenshot Block Download Control Form Intercept
Zero Trust Network Access

Zero Trust access to private apps. Zero attack surface.

Spirex ZTNA publishes private applications through the cloud broker without putting them on the public internet. Access is identity-gated at the control plane before a tunnel is even attempted.

STEP 01

Admin publishes an app

The private application's internal host and connector are registered in the cloud admin console. No firewall rules changed.

STEP 02

Browser pulls the app catalog

On login and every sync cycle, the browser receives the list of published hosts the authenticated user is allowed to reach.

STEP 03

Local proxy starts

ztna-client.js opens an HTTP CONNECT proxy on an ephemeral localhost port. A PAC script routes only published-app traffic through it.

STEP 04

Tunnel token issued

The control plane requests a short-lived tunnel token from the cloud for each matching private host. Tokens are scoped to the session.

STEP 05

WebSocket tunnel opens

A WebSocket tunnel connects the browser-side proxy to the cloud broker, which relays to the on-premises connector and then to the private app.

STEP 06

Policy still applies

The ZTNA tunnel is a transport layer only. Navigation through it is still subject to the full policy stack - access can be revoked at any point from the admin console.

Authentication & Authorisation Flow

How Spirex authenticates and authorises every session.

Spirex Browser User Client
Spirex Cloud Control Gateway
Identity Provider Your IdP
Policy Engine Spirex Core
Protected App SaaS or Private
1 · Auth request with PKCE code challenge
2 · Redirect to IdP authorisation endpoint
3 · Authorisation code returned
4 · Code + PKCE verifier exchanged for tokens
5 · Access token + ID token issued
6 · Navigation request with access token
7 · Verify TLS · token signature · issuer · audience · expiry
8 · Authorisation request: identity · resource · action
9 · ALLOW
or
DENY
10 · Forward authorised request to protected application
11 · Response delivered to Spirex Browser
Spirex Browser
Spirex Cloud
Identity Provider
Policy Engine
Protected App
PKCE - No Secret Leakage

The authorisation code flow with PKCE means no client secret is embedded in the browser. Even if an auth code is intercepted, it cannot be exchanged without the original verifier - which never leaves the session.

Token Verification at the Gateway

Every access token is verified for TLS integrity, cryptographic signature validity, issuer, audience, and expiry before any request is forwarded. Expired or tampered tokens are rejected immediately - no grace windows.

Authentication ≠ Authorisation

Proving who you are does not automatically grant access. A verified identity is passed to the Spirex policy engine, which evaluates the specific resource and action requested against the user's assigned policies - separately from the IdP.

App Never Directly Exposed

The protected application only ever receives requests that have passed both authentication and policy authorisation. For private apps via ZTNA, the application is not reachable on the public internet at all - the tunnel exists only after authorisation is confirmed.

Why Spirex Cannot Be Bypassed

Not an extension. Not a proxy. Enforcement in the execution path.

Browser extensions operate at the UI layer. Users can disable them, switch browsers, or open an incognito session to work around them. Spirex is different - enforcement is built into the browser session itself, managed centrally, and cannot be disabled by end users.

Security does not depend on users keeping anything enabled.

Browser Extensions
✗  Users can disable at any time
✗  Bypassed via alternate browser or incognito
✗  UI-layer only - no session-level control
Spirex
✓  Enforcement in the browser execution path
✓  Policies applied at session level - not UI layer
✓  Centrally managed - cannot be disabled by users
Get Started

Extend your security stack into the browser.

No rip-and-replace. No new browser. Deploy alongside your existing SASE and IdP in hours.