Sicherheitsarchitektur
Sicherheit war kein Nachgedanke.
Wer ein Werkzeug baut, das Browser im Namen von Nutzern bedient, hat zwei Möglichkeiten: annehmen, dass nichts schiefgeht, oder annehmen, dass immer etwas schiefgehen kann. Wir haben die zweite gewählt. Jede Architekturentscheidung in LokBox — Sandboxes, Isolationsgrenzen, Kostenlimits und menschliche Freigaben — existiert, weil wir durchgespielt haben, was ohne sie passieren würde.
Warum diese Seite existiert
Im April 2026 veröffentlichten Sicherheitsforscher 14 CVEs bei rund 200'000 MCP-Servern — dem Standard für KI-Agenten-Tools, die von Cursor, Windsurf, Claude Code, Gemini CLI und GitHub Copilot genutzt werden. 9 von 11 MCP-Marktplätzen konnten manipuliert werden, um bösartige Tool-Bundles auszuliefern. Anthropic bezeichnete das als «expected behavior» — das Bedrohungsmodell ist grundlegend dafür, wie Agenten Tools aufrufen.
LokBox ist anders gebaut. Diese Seite dokumentiert die konkreten Architekturentscheidungen, die uns sicherer machen als das durchschnittliche KI-Agenten-Tool — und wo wir uns noch verbessern.
Browser-Isolation pro Aufgabe
Jede Aufgabe startet einen frischen Chromium BrowserContext über Playwright. Wenn die Aufgabe abgeschlossen ist, wird der Kontext zerstört. Cookies, Sitzungsstatus und OAuth-Tokens gelangen nicht in andere Aufgaben, auch nicht bei parallel laufenden Workspace-Mitgliedern.
Andere Tools teilen eine langlebige Browser-Sitzung. LokBox behandelt jede Aufgabe so, als könnte sie die letzte sein, die jemals in diesem Browser läuft.
OAuth-Tokens gelangen nie in die Agenten-Sandbox
Wenn LokBox einen Gmail- oder Notion-Skill ausführt, läuft der Skill-Code in einem V8-Isolat via isolated-vm 6.1.2 eingebettet in einen worker_threads-Child-Thread.
Das OAuth-Bearer-Token gelangt nie in dieses Isolat. Es bleibt im Host-Prozess. Wenn der Skill aufruft ctx.fetch_with_oauth(...), fügt der Host ein Authorization: Bearer ... an der Netzwerkgrenze ein. Der Skill sieht nur den Antwortkörper.
Selbst wenn ein Angreifer einen Sandbox-Ausbruch in V8 finden würde, würde dein Token nicht abfliessen. Token-Exfiltration ist eines der häufigsten Kompromittierungsmuster bei KI-Tools; LokBox schliesst es konstruktiv aus.
KI pausiert bei CAPTCHA und 2FA
CAPTCHAs, Zwei-Faktor-Codes und Login-Walls umgeht die KI nicht. Sie ruft ein eingebautes pause_for_human Tool auf, das in deinem Dashboard ein Modal mit der benötigten Aktion zeigt. Du erledigst den Schritt im Live-Stream oder gibst zum Beispiel einen 6-stelligen OTP-Code ein. Danach fährt der Agent fort.
Du wirst nie gebeten, Passwörter mit LokBox zu teilen. Wenn 10 Minuten lang keine Antwort kommt, bricht die Aufgabe automatisch ab, damit keine Kosten weiterlaufen.
Drei Ebenen von Kostenlimits
- Limit pro Aufgabe: hartes Limit von $1 pro Aufgabe. Verhindert Endlosschleifen.
- Tageslimit pro Workspace: begrenzt, wie viel ein Workspace innerhalb von 24 Stunden verbrauchen kann. Verhindert, dass ein Nutzer die gesamte Kapazität aufbraucht.
- Globales Tageslimit: harte Obergrenze für die gesamten Flottenkosten pro UTC-Tag. Begrenzt den Worst Case bei einem Sicherheitsvorfall.
Wie wir uns vergleichen
Direkter Vergleich mit den häufigsten Alternativen. Zuletzt aktualisiert am 2026-05-02.
| LokBox | Browserbase | Computer Use direct | Most MCP servers | |
|---|---|---|---|---|
| Browser-Isolation pro Aufgabe | Ja — frischer Kontext | Teilweise — gepoolte Sitzungen | Nein — deine Verantwortung | Nein — geteilter Prozess |
| OAuth-Tokens vom Agentencode isoliert | Ja — Injektion an der Netzwerkgrenze | Nein — direkt im Code | Nein — direkt im Code | Teilweise — je nach Server |
| SSRF-Schutz bei Agentennavigation | Ja — Private-IP-Block + DNS-Prüfung | Teilweise — einzelne Prüfungen | Nein — deine Verantwortung | Teilweise — je nach Server |
| Pause bei CAPTCHA / 2FA | Ja — eingebaut | Nein — Fehler oder Umgehung | Nein — manuell | Nein — meistens nicht |
| Hartes Kostenlimit pro Aufgabe | Ja — $1 Standard | Teilweise — Abrechnung pro Sitzung | Nein — deine Verantwortung | Nein — meistens nicht |
| Öffentliche Security-Audit-Funde | Ja — diese Seite | Teilweise — nur SOC 2 | N/A | Nein — selbst offengelegt |
Was wir noch nicht behaupten
Wir benennen auch Lücken konkret. Stand 2026-05-02:
- Noch kein externer Pen-Test. Für Monat 2-3 nach Launch geplant. Ergebnisse veröffentlichen wir auf dieser Seite.
- Single-Region-Infrastruktur. Nur EU-Frankfurt. Nutzer in den USA sehen rund 200ms Basislatenz. Multi-Region steht auf der v2-Roadmap.
- Kein SOC 2 / ISO 27001. Wir betreiben das nicht spekulativ. Wenn ein konkreter Kunde es verlangt, starten wir den Prozess; bis dahin investieren wir in echte Architekturgewinne.
- Datenbank-Mandantentrennung ist heute app-code-seitig. Workspace-Grenzen werden auf Anwendungsebene erzwungen. Supabase Row-Level-Security-Policies sind als DB-seitige Defense-in-depth für v2 geplant.
- Browser-KI bleibt von Natur aus prompt-injection-anfällig. Wenn die KI Webseiten liest, kann bösartiger Seiteninhalt sie theoretisch instruieren. Wir begrenzen das Risiko mit Kostenlimits, Pause bei sensiblen Aktionen und Audit-Logs für Forensik.
Schwachstelle gefunden?
Sende Details per E-Mail an security@lokbox.ch Wir antworten innerhalb von 48 Stunden. Vor dem Launch haben wir noch kein formales Bug-Bounty-Programm; bei einem wesentlichen Fund finden wir eine faire Lösung.
Bitte veröffentliche nichts, bevor wir den Fund bestätigt und einen Fix ausgeliefert haben. Übliches Responsible-Disclosure-Fenster: 90 Tage.
Zuletzt aktualisiert am 2026-05-02.