《Openclaw流行下Agent 沙箱架构：从技术选择到普通人能看懂的安全故事》 Zwei Modi Stell dir vor, du möchtest einen Sicherheitsdienst einstellen, der auf dein Haus aufpasst. Du hast zwei Optionen: Option eins: Der Sicherheitsdienst wohnt in deinem Haus, aber die Werkzeugkiste ist im Safe eingeschlossen. Der Sicherheitsdienst kann sich bewegen und dein Haus sehen, aber er hat keinen Schlüssel. Option zwei: Der Sicherheitsdienst wohnt in einem Wachhäuschen draußen, und in deinem Haus gibt es nichts für ihn. Wenn er irgendetwas haben möchte, muss er deinen Hausverwalter fragen. Die Browser Use Company (sie betreiben Millionen von Web-Agenten) hat sich für Option zwei entschieden. Ihre Geschichte betrifft eigentlich jeden, der AI nutzt.

Zweitens, Wie man Browser verwendet Ursprünglich verwendeten sie Lösung eins: Der Agent läuft auf seinem eigenen Server, der Code wird in einer isolierten Sandbox ausgeführt. Klingt sicher, oder? Aber es gibt ein Problem: Der Agent selbst ist noch auf dem Server, er kann Umgebungsvariablen, API-Schlüssel und Datenbankanmeldeinformationen sehen. Was, wenn der Agent beschließt, "ein bisschen zu stehlen"?

Drei, deshalb haben sie die gesamte Architektur neu geschrieben: • Agent vollständig isoliert: Jeder Agent läuft in seiner eigenen Unikraft-Micro-VM, der Start dauert weniger als eine Sekunde • Kontrollfläche als Hausmeister: Alle externen Kommunikationen (LLM anpassen, Dateien speichern, Abrechnung) laufen über die Kontrollfläche, die alle Berechtigungen hält • Sandbox weiß nichts: Der Agent erhält nur drei Umgebungsvariablen – Sitzungstoken, Kontrollflächen-URL, Sitzungs-ID. Keine AWS-Schlüssel, keine Datenbankanmeldeinformationen • Wegwerfbar: Agent tot? Starte einen neuen. Status verloren? Die Kontrollfläche hat den vollständigen Kontext. Es gibt nichts, was es wert wäre, gestohlen zu werden, und keinen Status, der aufbewahrt werden muss.

Vier, Technische Details: Produktions-Unikraft-Micro-VM (scale-to-zero, im Leerlauf anhalten), Entwicklungs-Docker-Container. Das gleiche Image überall. Perspektive des normalen Menschen: Was hat das mit mir zu tun? Vielleicht weißt du nicht, was "Micro-VM" oder "presigned URLs" sind, aber wenn du AI verwendest, hast du bereits mit dieser Art von Architektur zu tun.

Fünf, Sicherheitsgefühl: Wenn du einen bestimmten AI-Dienst nutzt, um Code zu schreiben oder Informationen zu suchen, laufen deine Anfragen tatsächlich in einer isolierten VM. Wenn die Architektur schlecht gestaltet ist (Option eins), könnte dieser AI-Agent theoretisch alle Geheimnisse des Dienstanbieters sehen – Datenbankpasswörter, API-Schlüssel, Daten anderer Nutzer.

Sechs, Kosten und Geschwindigkeit: Lösung zwei hat einen Preis – jede Operation erfordert einen zusätzlichen Netzwerk-Hops. Aber im Vergleich zur Reaktionszeit von LLM ist diese Verzögerung fast vernachlässigbar. Wichtiger ist, dass die VM im Leerlauf des Agents angehalten wird, die Kosten sind nahezu null. Datenschutz: Wie werden deine Dateien gespeichert? Die Sandbox fordert eine presigned URL vom Kontrollbereich an und lädt sie dann direkt in S3 hoch. Während des gesamten Prozesses hat die Sandbox die AWS-Schlüssel nie gesehen. Deine Daten werden nicht an den Agenten weitergegeben.

Sieben, Meine Überlegungen: Lokal vs. Cloud Mein aktuelles Setup (OpenClaw + LM Studio + x-reader) ist typisch für eine "Standalone-Version": • Modell läuft lokal (Qwen3.5-35B auf RTX 3090) • Agent ist nicht isoliert (da er direkt auf deinem Computer ist) • Daten vollständig lokal Das im Vergleich zur Browser-Nutzung: Dimension Lokaler Einzel-Agent (wir) Cloud-isolierter Agent (Browser-Nutzung) Privatsphäre Daten bleiben lokal Daten gehen in die Cloud, aber der Agent hat keinen Zugriff auf die Schlüssel Sicherheit Abhängig von lokalem Schutz Agent vollständig isoliert, nichts kann gestohlen werden Kosten Einmalige Hardware-Investition Zahlung nach Nutzung (scale-to-zero) Erweiterbarkeit Begrenzt durch lokale Hardware Unbegrenzte Erweiterung, mehrere Agenten parallel Latenz Null Netzwerk-Latenz Ein zusätzlicher Netzwerk-Hops (aber vernachlässigbar)

Acht, mein Urteil: Die Zukunft wird ein hybrides Modell sein. • Einfache Aufgaben lokal ausführen: Ein Skript schreiben, Informationen suchen, Dokumente organisieren – das kann lokal erledigt werden, Datenschutz ist gut, die Geschwindigkeit ist hoch. • Komplexe Aufgaben in der Cloud: Wenn mehrere Agenten parallel arbeiten, große Datenmengen verarbeitet werden müssen und lange Laufzeiten erforderlich sind, ist eine Architektur wie Browser Use geeigneter.

Neun, Ursprünglich gibt es nichts, woher sollte der Staub kommen? Dein Agent sollte nichts haben, was es wert ist, gestohlen zu werden, und keinen Zustand, den es behalten muss. In einfachen Worten bedeutet dieser Satz: • Nicht wert zu stehlen: Der Agent kennt kein Geheimnis. Braucht er Token für die LLM? Die werden vom Kontrollbereich bereitgestellt, nach Gebrauch weggeworfen. Muss er Dateien speichern? Presigned URLs sind temporär und laufen ab. • Nicht zu behalten: Ist der Agent tot? Starte einen neuen. Was er sich merkt? Im Kontrollbereich gibt es vollständige Aufzeichnungen in der Datenbank. Das ist eigentlich die Anwendung der Zero-Trust-Architektur im AI-Zeitalter: Vertraue keinem Bestandteil, selbst wenn es dein eigener geschriebener Agent ist.

Zehn, Wie sollte ein AI-Neuling lernen? 1. Auswahl der AI-Tools: Wenn Sie cloudbasierte AI-Dienste nutzen, fragen Sie sich – was könnte dieser Agent tun, wenn er außer Kontrolle gerät? Eine gute Architektur sollte es ihm ermöglichen, "nichts zu wissen". 2. Datenschutzbewusstsein: Lokale AI für einfache Aufgaben (OpenClaw, LM Studio), sensible Daten nicht in die Cloud. Für komplexe Aufgaben eine cloudbasierte Isolierungslösung verwenden, aber sich bewusst sein, dass die Daten den lokalen Speicher verlassen. 3. Zukünftige Arbeitsabläufe: Eine Person + mehrere Agenten zur Zusammenarbeit ist der Trend (Karpathy spricht von Tab→Agent→Parallel Agents→Agent Teams). Aber jeder Agent sollte isoliert sein, er sollte nicht "bei Ihnen wohnen".

Elf, Abwägung von Sicherheit und Effizienz Die Lösung von Browser Use ist nicht perfekt – drei zusätzliche Dienste müssen bereitgestellt werden, und bei jeder Operation gibt es einen zusätzlichen Netzwerk-Hops. Aber im Vergleich zum Risiko, dass "Agent alle Schlüssel stiehlt", sind diese Kosten gerechtfertigt. Für uns, die wir ein lokales AI-Setup haben, ist die Erkenntnis: • Einfache Szenarien: Weiterhin lokale Lösungen verwenden (OpenClaw + LM Studio), gute Privatsphäre, niedrige Kosten • Komplexe Szenarien: In Zukunft könnte es notwendig sein, auf cloudbasierte isolierte Agent-Dienste zuzugreifen, um Fachleuten die professionelle Arbeit zu überlassen. AI-Sicherheit ist keine Esoterik, sondern Architekturdesign. Ein gutes Design lässt den Agenten "nichts haben" – keine Geheimnisse zu stehlen, keinen Zustand, auf den man sich verlassen kann.

Zwölf, so könnte die zukünftige AI-Infrastruktur aussehen: Agenten sind entbehrlich, die Steuerungsebene ist vertrauenswürdig, und die Benutzerdaten sind geschützt. Was uns betrifft? Wir verwenden weiterhin OpenClaw, um lokale Agenten auszuführen, und wenn wir eines Tages Dutzende oder Hunderte parallel benötigen, denken wir darüber nach, eine Architektur wie Browser Use zu integrieren. Morgen wird es besser.