Island

What is it?

Island is a Chromium-based browser rebuilt for enterprise use. It strips out the consumer-oriented code from Chromium (ad delivery, tracking, monetization hooks) and replaces it with enterprise controls: IDP-based authentication, inline DLP, granular copy/paste and download restrictions, ZTNA (zero trust network access), session recording, extension risk management, and device posture checks. The core architectural advantage is that the browser sits at the “last mile” of encryption, meaning it sees all data after TLS decryption but before screen rendering. This lets it enforce policy at the presentation layer without requiring changes to the applications themselves.

Why did they build it?

Most enterprise work happens in a browser, but Chrome, Edge, and Firefox were built for consumers. Enterprises compensate by layering security tools around the browser: EDR on the endpoint, VPNs and ZTNA for transit, break-and-inspect proxies for DLP and web categorization. Island’s argument is that building these capabilities directly into the browser eliminates the need for much of that stack. Because the browser authenticates users via the corporate IDP, it can enforce identity-based policy per application, per user, per geography, and per context, something that is difficult or impossible at the network layer.

How does last-mile control actually work?

Island intercepts data after TLS termination but before rendering. This means it can redact sensitive fields before they hit the screen, block or allow copy/paste between specific applications (not just on/off globally), watermark screens with user-identifying QR codes, restrict downloads and screenshots per app, and record sessions for privileged access. These controls are policy-driven and contextual. For example, a user can copy/paste freely between seven approved apps but be blocked from pasting into anything outside that set. Google’s Chrome Enterprise, by comparison, offers blanket configuration (e.g., turn off copy/paste entirely), but lacks the per-app, per-user, per-context granularity.

What are the compliance use cases beyond security?

This is where Island has expanded significantly. Examples from CEO Mike Fey:

  • Labor law enforcement: A French customer uses Island to cut off application access at a specific time to comply with French working-hours regulations. A US restaurant chain kicks employees off a shift-scheduling portal after 9 minutes 45 seconds because California law requires paying a full hour if the worker spends more than 10 minutes on it.
  • Financial compliance: Investment firms use Island to allow traders to view LinkedIn (which they need for research) while recording or blocking LinkedIn messaging, since unaudited messaging channels create SEC violations. The browser can distinguish between the LinkedIn feed and the messaging component, something network-layer tools cannot do.
  • GDPR/data residency: Island enforces which regional tenant a user connects to (e.g., German Salesforce vs. US Salesforce), regardless of where the user physically is. It can redirect users via ZTNA back to specific data centers or source IPs. Tenant control is handled by URL and domain policy, with proxy chaining available when needed but rarely necessary.
  • Healthcare/contractor access: Doctors are almost always contractors. Hospitals need to give them access to patient data without installing agents on their devices. Island treats them as BYOD users with full DLP controls, and if onboarding is too burdensome, doctors simply work with a different hospital.

How does it handle extensions and infostealers?

Island catalogs and risk-scores all ~220,000 Chrome Web Store extensions by analyzing their codebase, permissions, and host permissions. Enterprises set a risk threshold, and extensions above it are blocked or require approval. Critically, extensions can be enabled or disabled per context: an extension like Grammarly (which functions as a keylogger, sending all typed text to a cloud instance for evaluation) can be allowed during personal browsing but disabled when the user is in a sensitive business application. This creates a “secure enclave” where extensions with DOM access cannot operate.

For credential theft, Island restricts where corporate credentials can be entered. Administrators define an allow list of domains, and if a user attempts to enter corporate credentials on any other site (phishing, man-in-the-middle, browser-in-the-middle), the browser blocks it. Island can also enforce MFA at any point in the application flow, even for apps that do not natively support it, by injecting an MFA challenge at the presentation layer. Browser enforcement ensures that protected applications can only be accessed through an Island browser connected to the correct tenant. Even if credentials are stolen, authentication from Chrome or any non-Island browser will fail via conditional access policies, certificate pinning, or IP allow-listing.

What about AI/GenAI governance?

Island provides visibility into which AI services users are hitting (the company found ~200 AI engines accessed by their own 400-person workforce). It can block specific AI services, but the more practical approach is steering: if a user tries to access one AI tool, Island can redirect them to the company’s licensed, governed alternative. DLP policies apply to AI interactions the same as any other web app, inspecting what data goes into prompts. For deeper content inspection (e.g., detecting whether a prompt contains proprietary code or deal information), Island is building AI-based detection, effectively using an LLM to evaluate whether prompt content violates company policy before it reaches the target model.

Risky Business appearances (last 24 months)

Sources

Disclosure

Island is a Risky Business sponsor.