Remote browser isolation: boundaries and limits

Direct answer

Remote browser isolation runs page code remotely. The local device receives a controlled representation instead of executing the original page code locally.

CISA describes remote isolation as moving web processing off the local workstation. This reduces direct endpoint exposure. It does not make every page trustworthy.

The boundary has two sides. Page code can stay remote. Submitted credentials and exported files can cross back.

How RBI works

1. Route the request to a remote browser.
2. Execute page code in that remote runtime.
3. Return a controlled view and input channel.
4. Apply the provider's session lifecycle policy.

Session policies vary. Some systems reset state after each session. Others allow bounded persistence. Verify the actual provider contract.

What the boundary changes

Active page code

Untrusted scripts start in the remote runtime. They do not start inside the local browser profile. The boundary holds while content stays remote.

Browser exploits

An exploit reaches the remote runtime first. Containment still depends on runtime permissions, container controls, and network reach. Google tracked 75 exploited zero-days during 2024. Browser zero-day exploitation fell from 17 to 11. Chrome remained the primary browser target.

Browser-native ransomware

The RøB research demonstrated browser ransomware using file access and WebAssembly. The attack depended on access to local files. Remote execution reduces that local reach. An approved file transfer can reopen it.

What RBI does not solve

• Credentials entered into untrusted pages can be captured.
• Downloaded files can move risk onto endpoints.
• Isolation does not grant authorization or verify identity.
• Weak egress rules can expose internal services.
• Latency and application compatibility still vary.
• Endpoint, identity, and monitoring controls remain necessary.

NIST defines zero trust around users, assets, and resources. Network location creates no implicit trust. RBI can support that design. It is not the entire design.

Evaluation checklist

1. Execution location. Confirm where page code runs.
2. Delivery path. Identify what the local device receives.
3. Data transfer. Test uploads, downloads, clipboard, and printing.
4. Session state. Verify reset and persistence behavior.
5. Network reach. Constrain egress and internal access.
6. Identity boundary. Keep privileged sessions outside untrusted pages.
7. Operations. Measure latency, compatibility, logging, and cost.

Where Legba fits

Legba is a Chrome extension with two modes. Ghost gives you a private browser route. Shield opens a page in an isolated browser off your device.

Shield applies isolation to one selected page. It does not promise safe credentials or safe downloads. Keep sensitive data outside untrusted sessions.

Sources

• CISA: Securing web browsers and defending against malvertisingVerified September 1, 2026
• NIST SP 800-207: Zero Trust ArchitectureVerified September 1, 2026
• Google Threat Intelligence: 2024 zero-day exploitation analysisVerified September 1, 2026
• USENIX Security 2023: RøB ransomware researchVerified September 1, 2026