Isolation gets the headlines, but a Remote Browser Isolation platform is only as trustworthy as the control plane behind it. If an attacker can replay a captured request, forge a token, or brute-force an administrator account, the isolation guarantee on the data path means very little. So Dejanu treats the control plane—the APIs and session logic that orchestrate everything—as a first-class part of the security story, and hardens every layer of it.
Request Integrity: Anti-Replay by Default
Every API request carries a signature built from three ingredients: a timestamp, a single-use number (a nonce), and an HMAC over the request. The server tracks nonce uniqueness in a distributed cache shared across the cluster, so a request captured off the wire cannot be replayed—not a second later, and not against a different node. The timestamp closes the window further by rejecting anything too old.
Tokens You Can Revoke Instantly
Session tokens (JWTs) include IP-binding and expiry checks, but the real safety net is server-side revocation. When a token is blacklisted, it stops working immediately—you don't have to wait for it to expire on its own. That turns "we think that account is compromised" into "that session is already dead."
- CSRF protection — pre-login tokens secure session initialization, and post-login tokens are bound to the authenticated session's state.
- Distributed rate limiting — Redis-backed sliding windows protect the APIs, with dedicated per-tenant limits for AI features so one tenant can't exhaust shared capacity.
- Strict security headers — Content-Security-Policy, HSTS on production builds, anti-clickjacking and anti-XSS hardening, and removal of server-identifying headers.
Identity You Can Trust
The system-administration plane—the most sensitive surface in any platform—adds TOTP two-factor authentication, account lockout by both user and IP address, and device fingerprinting to flag unfamiliar access. For end users, mutual-TLS (mTLS) device binding ties a session to an approved device, so a stolen password on its own cannot open a browser.
Hard isolation keeps web code off the endpoint. A hardened control plane keeps attackers off the platform. A serious deployment needs both.
Multi-Tenant, Cryptographically Separated
Each tenant has its own keys and a secure session-initialization chain. Configuration is encrypted at rest and decrypted only through that tenant's encryption chain—so even sensitive secrets like AI provider keys never sit in plaintext. Tenants are routed and isolated by domain, with independent policy, branding, and billing, so one customer's data and configuration are never entangled with another's.
Defense-in-Depth, Not a Single Wall
No one of these controls is magic on its own. Their value is cumulative: signing stops replay, revocation limits the blast radius of a leaked token, rate limits blunt automated attacks, 2FA and device binding raise the bar on identity, and tenant isolation contains the impact if something does go wrong. Layered together, they make the platform something you can defend to an auditor with evidence, not adjectives.