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 eine Aufgabe abgeschlossen ist, wird ihr Kontext zerstört. Dieses Design soll die Übernahme von Sitzungs- und Token-Daten zwischen Aufgaben begrenzen.
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-Token-Verarbeitung ausserhalb der Agenten-Sandbox
Wenn Lokbox eine Anfrage an einen verbundenen Dienst verarbeitet, läuft der Dienst-Code in einem V8-Isolat via isolated-vm 6.1.2 eingebettet in einen worker_threads-Child-Thread.
Das OAuth-Bearer-Token wird durch die Token-Verarbeitungsgrenze ausserhalb dieses Isolats gehalten. 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.
Die Token-Verarbeitung ist so getrennt, dass die Grenze das Token ausserhalb der Sandbox halten soll. Das reduziert einen wichtigen Angriffsweg, ist aber keine Garantie gegen jede Kompromittierung.
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 Ihrem Dashboard die benötigte Aktion erklärt. Sie erledigen Login oder 2FA selbst im Live-Browser; die KI sieht Ihre Eingaben nicht.
Anmeldedaten und 2FA bleiben bei Ihnen. Sie geben sie selbst im Live-Browser ein; die KI sieht Ihre Eingaben nicht.
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 — Ihre 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 — Ihre 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 — Ihre Verantwortung | Nein — meistens nicht |
| Dokumentation der Sicherheitsarchitektur | Auf dieser Seite beschrieben | 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.
- Schweizer Infrastruktur. Web- und Anwendungs-Hosting laufen aus Zürich, Schweiz; eine Kopie der Produktionsdaten besteht bis 22.08.2026 in Frankfurt (DE). Die Claude-Verarbeitung nutzt das separate geografische EU-Inferenzprofil von AWS Bedrock, das in unserer Datenschutzerklärung beschrieben ist.
- 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 betreiben derzeit kein formales Bug-Bounty-Programm; bitte senden Sie genügend Kontext, damit wir den Fund beurteilen können.
Bitte stimmen Sie eine öffentliche Offenlegung mit uns ab, nachdem ein Fix verfügbar ist.
Zuletzt aktualisiert am 2026-05-02.