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 the task finishes, the context is destroyed. Cookies, session state, OAuth tokens — none of it bleeds across tasks, even when run in parallel by multiple workspace members.

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 tokens never enter the agent's sandbox

When LokBox runs a Gmail or Notion skill, the skill code executes inside a V8 isolate via isolated-vm 6.1.2 wrapped in a worker_threads child thread.

The OAuth Bearer token never enters that isolate. 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.

Even if an attacker found a sandbox-escape bug in V8, your token wouldn't leak. Token exfiltration is the most common AI-tool compromise pattern; LokBox closes it by design.

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 surfaces a modal in your dashboard explaining what it needs. You either complete the action in the live stream or paste a code, like a 6-digit OTP, into the modal. The agent picks back up where it left off.

You're never asked to share passwords with LokBox. If 10 minutes pass without your response, the task auto-aborts so it doesn't run up costs.

Three layers of cost cap

Per-task cap: hard $1 limit per task. Prevents runaway loops.
Per-workspace daily cap: limits how much a single workspace can spend in 24 hours. Prevents one user from consuming everyone's capacity.
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

Public security audit findings

LokBox:Yes — 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
Public security audit findings	Yes — 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.
Single-region infra. EU-Frankfurt only. US users see roughly 200ms baseline latency. Multi-region is on the v2 roadmap.
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 app-code-only today. Workspace boundaries are enforced at the application layer. Supabase Row-Level Security policies are planned for v2 as DB-side defense-in-depth.
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'll respond within 48 hours. Pre-launch we don't have a formal bug-bounty program; if your report is material, we'll figure something out.

Please don't publicly disclose before we've confirmed and shipped a fix. Standard responsible-disclosure window: 90 days.

Last updated 2026-05-02.