Isolation and sovereignty by architecture
Where the trust boundaries sit in Browserberg: what runs natively, what runs in hardened containers, and how EU sovereignty is enforced in the request path.
Last updated:
The trust model
Browserberg's own platform code — the API, the fleet orchestration, the vault — runs natively on the host. Only the untrusted work runs inside per-session hardened containers: the browser, the pages it loads, and your workflow's code blocks, which are your JavaScript and are treated with the same suspicion as a webpage.
A container here is a security boundary, not a packaging convenience: one container per session, locked down, destroyed at teardown. To be precise about what that is: it is hardened OS-level containment, not a virtual machine, and we do not claim kernel-level isolation. MicroVM isolation is on the roadmap for a later phase; today the boundary is the hardened container.
Sovereignty as architecture
Sovereignty is enforced by where things run, not asserted in a policy document. Hosting is in the EU on hardware we operate; inference is routed to EU endpoints; there is no US CDN anywhere in the product path. See EU data residency for the compliance detail.
Every model call the platform makes passes through a single gateway. That chokepoint scans outbound requests for secrets and wraps page content in mandatory fencing before it can reach a model — page text is never handed to a prompt unfenced.
Note · sovereign never silently downgrades
If you request the `sovereign` routing tier and no sovereign backend can serve the call, the platform refuses — it does not quietly fall back to another route. The tier that actually served each call is on the response's provenance, so the claim is checkable per request.