Security architecture

Security wasn't an afterthought.

When you build a tool that runs browsers on behalf of users, you have two choices: assume nothing goes wrong, or assume something always will. We assumed the second. Every architectural choice in Lokbox — sandboxes, isolation boundaries, cost caps, pause-for-human gates — exists because we walked through what could go wrong if we didn't have it.

Why this page exists

In April 2026, security researchers disclosed 14 CVEs across ~200,000 MCP servers — the standard for AI agent tools used by Cursor, Windsurf, Claude Code, Gemini CLI, and GitHub Copilot. 9 out of 11 MCP marketplaces could be poisoned to ship malicious tool bundles. Anthropic's response was “expected behavior” — the threat model is fundamental to how agents call tools.

Lokbox is built differently. This page documents the specific architectural choices that make us safer than the average AI agent tool — and where we're still improving.

Per-task browser isolation

Every task spins up a fresh Chromium BrowserContext via Playwright. When a task finishes, its context is destroyed. This design is intended to limit session and token carry-over between tasks.

Other tools share a long-lived browser session. Lokbox treats each task as if it might be the last one that ever runs in that browser.

OAuth token handling outside the agent sandbox

When Lokbox processes a connected-service request, the service code executes inside a V8 isolate via isolated-vm wrapped in a worker_threads child thread.

The OAuth Bearer token is kept outside that isolate by the token-handling boundary. It stays in the host process. When the skill calls ctx.fetch_with_oauth(...), the host injects Authorization: Bearer ... at the network boundary. The skill sees only the response body.

The token-handling boundary is designed so that the boundary is intended to keep the token outside the sandbox. This reduces an important exposure path, but it is not a guarantee against every compromise.

AI pauses for CAPTCHA and 2FA

CAPTCHAs, two-factor codes, login walls — the AI doesn't bypass these. It calls a built-in pause_for_human tool, which explains the required action in your dashboard.

At a login, a CAPTCHA or a question, Lokbox pauses and asks for your input.

Cost limits

Per-task cap: hard $1 limit per task. Prevents runaway loops.
Per-workspace daily reference value: Lokbox records an estimated cost per workspace and day. In your subscription area you see the total for the past 7 days. There is no automatic stop at a daily value yet.
Global daily cap: hard ceiling on total fleet spend per UTC day. Bounds worst-case loss in a security incident.

How we compare

Side-by-side with the most common alternatives. Last updated 2026-05-02.

Per-task browser isolation

Lokbox:Yes — fresh contextBrowserbase:Partial — pooled sessionsComputer Use:No — your responsibilityMost MCP:No — shared process

OAuth tokens isolated from agent code

Lokbox:Yes — network-layer injectionBrowserbase:No — direct in codeComputer Use:No — direct in codeMost MCP:Partial — server-by-server

SSRF guard on agent navigation

Lokbox:Yes — private-IP block + DNS checkBrowserbase:Partial — some checksComputer Use:No — your responsibilityMost MCP:Partial — server-by-server

Pauses for CAPTCHA / 2FA

Lokbox:Yes — built-inBrowserbase:No — fail or bypassComputer Use:No — manualMost MCP:No — generally not

Hard cost cap per task

Lokbox:Yes — $1 defaultBrowserbase:Partial — per-session billingComputer Use:No — your responsibilityMost MCP:No — generally not

Security architecture documentation

Lokbox:Described on this pageBrowserbase:Partial — SOC 2 onlyComputer Use:N/AMost MCP:No — self-disclosed

	Lokbox	Browserbase	Computer Use direct	Most MCP servers
Per-task browser isolation	Yes — fresh context	Partial — pooled sessions	No — your responsibility	No — shared process
OAuth tokens isolated from agent code	Yes — network-layer injection	No — direct in code	No — direct in code	Partial — server-by-server
SSRF guard on agent navigation	Yes — private-IP block + DNS check	Partial — some checks	No — your responsibility	Partial — server-by-server
Pauses for CAPTCHA / 2FA	Yes — built-in	No — fail or bypass	No — manual	No — generally not
Hard cost cap per task	Yes — $1 default	Partial — per-session billing	No — your responsibility	No — generally not
Security architecture documentation	Described on this page	Partial — SOC 2 only	N/A	No — self-disclosed

What we don't claim yet

We try to be specific about gaps too. As of 2026-05-02:

No external pen test yet. Scheduled for month 2-3 post-launch. Findings will be published on this page when complete.
Swiss infrastructure. Web and application hosting run in Switzerland; the database is in Zurich. Claude processing uses the separate AWS Bedrock EU geographic inference profile described in our Privacy Notice.
No SOC 2 / ISO 27001. We won't pursue these speculatively. If a named customer requires it, we'll engage; until then, we'd rather invest in real architecture wins than audit theatre.
Database tenant isolation is enforced in application code. Workspace boundaries are enforced at the application layer. Row-Level Security is enabled on tenant tables; the application connects through a privileged role that bypasses these policies.
Browser AI is prompt-injection-vulnerable by nature. When the AI navigates to a webpage, malicious page content can theoretically instruct it. We mitigate with cost caps, sensitive-action pause, and audit logs for forensic review.

Found a vulnerability?

Email security@lokbox.ch with details. We do not currently operate a formal bug-bounty program; please include enough context for us to assess the report.

Please coordinate any public disclosure with us after a fix is available.

Last updated 2026-05-02.