Zum Hauptinhalt springen

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 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.

Bei einer Anmeldung, einem CAPTCHA oder einer Rückfrage hält Lokbox an und bittet Sie um Ihre Eingabe.

Kostenbegrenzung

  • Limit pro Aufgabe: hartes Limit von $1 pro Aufgabe. Verhindert Endlosschleifen.
  • Tagesrichtwert pro Workspace: Lokbox erfasst eine Schätzung der Kosten je Workspace und Tag. Im Abo-Bereich sehen Sie die Summe der letzten 7 Tage. Eine automatische Sperre bei einem Tageswert gibt es noch nicht.
  • 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.

Browser-Isolation pro Aufgabe
Lokbox:Ja — frischer KontextBrowserbase:Teilweise — gepoolte SitzungenComputer Use:Nein — Ihre VerantwortungMost MCP:Nein — geteilter Prozess
OAuth-Tokens vom Agentencode isoliert
Lokbox:Ja — Injektion an der NetzwerkgrenzeBrowserbase:Nein — direkt im CodeComputer Use:Nein — direkt im CodeMost MCP:Teilweise — je nach Server
SSRF-Schutz bei Agentennavigation
Lokbox:Ja — Private-IP-Block + DNS-PrüfungBrowserbase:Teilweise — einzelne PrüfungenComputer Use:Nein — Ihre VerantwortungMost MCP:Teilweise — je nach Server
Pause bei CAPTCHA / 2FA
Lokbox:Ja — eingebautBrowserbase:Nein — Fehler oder UmgehungComputer Use:Nein — manuellMost MCP:Nein — meistens nicht
Hartes Kostenlimit pro Aufgabe
Lokbox:Ja — $1 StandardBrowserbase:Teilweise — Abrechnung pro SitzungComputer Use:Nein — Ihre VerantwortungMost MCP:Nein — meistens nicht
Dokumentation der Sicherheitsarchitektur
Lokbox:Auf dieser Seite beschriebenBrowserbase:Teilweise — nur SOC 2Computer Use:N/AMost MCP: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 in der Schweiz; die Datenbank liegt in Zürich. 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 wird im Anwendungscode erzwungen. Workspace-Grenzen werden auf Anwendungsebene erzwungen. Row-Level-Security ist auf Mandantentabellen aktiv; die Anwendung verbindet sich über eine privilegierte Rolle, die diese Policies umgeht.
  • 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?

Senden Sie 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.