Strands Box: Eine quelloffene Agenten-Sandbox, die OS-Isolation mit „semantischen Richtlinien“ verbindet und nach früheren Aktionen entscheidet
strands-agents/box ist eine quelloffene Sandbox-Engine für KI-Agenten vom Strands-Agents-Team, in Rust geschrieben und unter Apache-2.0. Sie verbindet Isolation auf Betriebssystemebene mit permit/forbid-Richtlinien in der Sprache Dogwood, ausgeführt von einer Engine außerhalb des Agentenprozesses, standardmäßig mit Ablehnung. Es ist eine Vorschau nur für macOS auf Apple-Silicon, mit etwa 393 Sternen beim Schreiben; ein unabhängiges Sicherheitsaudit sahen wir nicht.
strands-agents/box ist ein quelloffenes Projekt des Strands-Agents-Teams, beschrieben als „eine quelloffene Sandbox-Engine für KI-Agenten“. Das Repository ist in Rust geschrieben und steht unter Apache-2.0. Es wurde am 2. Oktober 2026 angelegt, der letzte Push war am 12. Oktober, und es hat beim Schreiben etwa 393 Sterne und 19 Forks. Die Frage ist praktisch. Wenn ein Agent Befehle ausführen, Dateien lesen und schreiben, das Netz erreichen und fremde Werkzeuge aufrufen kann, wie macht man aus „was er darf“ statt einer Zeile im Prompt eine Grenze, die ein Programm durchsetzt? Das Projekt bindet sich an keinen bestimmten Agenten. Man wählt das auszuführende Programm oder Binärprogramm, legt seinen Zugriff in box.toml fest und schreibt seine Richtlinien in policy.dw.
Der Entwurf hat zwei Schichten. Die erste ist die OS-Isolation: Direkte Zugriffsrechte in box.toml, etwa welche Verzeichnisse les- und beschreibbar sind und welche Programme starten dürfen, setzt das Betriebssystem des Hosts durch. Die zweite ist die „semantische Richtlinie“ in einer Richtliniensprache namens Dogwood, die nur zwei Regeltypen kennt, permit und forbid. Operationen, die die Richtlinien-Engine prüft, sind standardmäßig abgelehnt, ein passendes permit muss sie erlauben, und ein passendes forbid hat Vorrang vor dieser Erlaubnis. Interessant ist die Anordnung der Teile. Strands Shell, Monty für Python, das Egress-Gateway und der MCP-Broker schicken jeweils die von ihnen bearbeiteten Operationen an die eingebettete lokale Dogwood-Engine. Diese läuft im eigenen Prozess von Box, außerhalb der Sandbox des Agenten. Der Agent kann Anfragen an die Interpreter von Box senden, externe Programme und lokale MCP-Server aber nicht, und der Netzwerkverkehr externer Programme läuft standardmäßig über das Gateway von Box.
Aus dieser Anordnung ergeben sich mehrere konkrete Fähigkeiten. Erstens teilen Interpreter und Gateways eine Ereignishistorie, sodass Regeln frühere Aktionen und verstrichene Zeit nutzen können. Das Beispiel im README ist, dass das Lesen einer Datei über Shell oder Python das Gateway dazu bringt, eine spätere ausgehende HTTP-Anfrage zu verweigern, was einem echten Datenabfluss näher kommt als eine einfache Liste erlaubter Adressen. Zweitens prüft das Egress-Gateway Verbindungen und HTTP-Anfragen samt Methode und Pfad, und der MCP-Broker prüft konfigurierte Werkzeugaufrufe und ihre Argumente. Drittens kann das Gateway erlaubte Anfragen mit konfigurierten API-Zugangsdaten oder AWS-SigV4-Signaturen authentifizieren, sodass der Agent die zugrunde liegenden Geheimnisse nicht erhält. Viertens wird jede Richtlinienentscheidung im Format OTLP JSON protokolliert, standardmäßig in private/telemetry/records.jsonl im Box-Verzeichnis, was die spätere Prüfung erleichtert.
Lesen Sie vor der Nutzung die vom Projekt genannten Grenzen. Es ist eine Vorschau und unterstützt nur die lokale Ausführung auf macOS mit Apple-Silicon. Die Anleitung verlangt macOS 15 oder neuer, Node.js 22.21 oder neuer über Homebrew und Zugriff auf Claude Opus 5 auf Amazon Bedrock in us-west-2. Das Download-Skript prüft die Prüfsumme der Version und entpackt die Programme nach ./box-core, ohne PATH oder Systemverzeichnisse zu ändern. Außerdem sagt das README, dass direkte Dateisystemrechte in box.toml vom Betriebssystem durchgesetzt werden und keine einzelnen Dogwood-Entscheidungen erzeugen. Um Richtlinien auf Dateioperationen anzuwenden, nutzen Sie die Interpreter und halten diese Dateien aus den direkten Rechten des Agenten heraus. Schließlich stammt all dies aus der Beschreibung des Projekts. Wir haben es nicht ausgeführt und weder ein unabhängiges Sicherheitsaudit noch einen Penetrationstest gesehen.
Wie ist es zu beurteilen? Für Teams, die Agenten bauen, bietet es eine klare Arbeitsteilung: Das Betriebssystem entscheidet, was berührt werden darf, die Richtlinien-Engine entscheidet, unter welchen Bedingungen eine Aktion erlaubt ist, und beides liegt außerhalb des Agenten. Das ist weit verlässlicher als „bitte gib das Passwort nicht weiter“ im Prompt und feiner als eine Sandbox mit bloßer Netzwerk-Freigabeliste. Der Preis ist, eine neue Richtliniensprache zu lernen und Dateien, Netz und Werkzeugaufrufe über Box zu leiten. Unter Linux und Windows läuft es noch nicht. Wenn Ihr Agent mit sensiblen Daten arbeitet, probieren Sie zuerst das mitgelieferte Beispiel mit dem Strands-Python-SDK, lesen Sie die Entscheidungsprotokolle und entscheiden Sie dann, ob sich eine Umstellung Ihrer Betriebsweise lohnt.
Sources
FAQ
Welches Problem löst Strands Box, und wie?
Es legt zwei Schichten von Beschränkungen um den Prozess, der einen Agenten ausführt. Die erste ist eine OS-Sandbox: box.toml legt fest, auf welche Dateien, Programme und Netzwerke der Agent direkt zugreifen darf, und das Betriebssystem setzt das durch. Die zweite ist die semantische Richtlinie: policy.dw enthält permit- und forbid-Regeln in Dogwood, beurteilt von einer lokalen Engine außerhalb des Agenten. Von der Engine geprüfte Operationen sind abgelehnt, außer ein passendes permit erlaubt sie, und ein passendes forbid hat Vorrang. Box ist nicht an einen bestimmten Agenten gebunden: Sie wählen das auszuführende Programm.
Was heißt „verlaufsabhängige Richtlinie“?
Die Interpreter und Gateways von Box teilen eine Ereignishistorie, daher können Regeln frühere Aktionen und verstrichene Zeit nutzen. Das Beispiel im README: Das Lesen einer Datei über Shell oder Python kann dazu führen, dass das Gateway eine spätere ausgehende HTTP-Anfrage verweigert. Das Gateway prüft außerdem Methode und Pfad einer Anfrage, der MCP-Broker prüft konfigurierte Werkzeugaufrufe samt Argumenten, und das Gateway kann API-Zugangsdaten oder AWS-SigV4-Signaturen ergänzen, sodass der Agent das Geheimnis nie hält. Jede Entscheidung wird als OTLP JSON protokolliert.
Ist es produktionsreif, und wo liegen die Grenzen?
Das Projekt nennt sich selbst eine Vorschau. Es unterstützt nur die lokale Ausführung auf macOS mit Apple-Silicon. Die Anleitung verlangt macOS 15 oder neuer, Node.js 22.21 oder neuer über Homebrew und Claude Opus 5 auf Amazon Bedrock. Eine weitere Grenze: Direkte Dateisystemrechte in box.toml setzt das Betriebssystem durch, und sie erzeugen keine Dogwood-Entscheidungen. Um Richtlinien auf Dateioperationen anzuwenden, nutzen Sie die Interpreter von Box und halten diese Dateien aus den direkten Rechten heraus. Ein unabhängiges Audit sahen wir nicht; verlassen Sie sich für wertvolle Daten nicht ohne eigene Prüfung darauf.