AWS veröffentlicht Strands Box: Open-Source-Sandbox, die Agenten anhand ihrer bisherigen Aktionen bremst
Das Besondere an AWS’ Strands Box: Sie merkt sich, was ein Agent bereits getan hat, und blockiert anhand dessen die nächste Aktion.
AWS hat am 7. Oktober Strands Box als Developer Preview veröffentlicht. Die Open-Source-Sandbox steht unter der Apache-2.0-Lizenz (einer freien Open-Source-Lizenz, die jedem erlaubt, den Code zu nutzen und zu ändern) und schränkt ein, was KI-Agenten (Programme, die für Nutzer mehrstufige Aufgaben selbstständig erledigen) tun können. Eine Sandbox ist eine Sicherheitsbox, die einen Agenten einschließt und begrenzt, was er tun darf. Es ist eine Vorschau, daher sind die unterstützten Umgebungen noch eng, doch sie zeigt die Richtung der Schutzmaßnahmen für Entwickler, die Coding- und DevOps-Agenten bauen. DevOps steht für die Automatisierung von Auslieferung und Betrieb von Software.
Was das Tool macht
- Isolation auf OS-Ebene plus Policy-Engine. Es isoliert den Agenten auf Betriebssystemebene und leitet die vom Agenten ausgeführten Shell-Befehle, Python-Skripte, Netzwerkanfragen und MCP-Tool-Aufrufe durch eine Policy-Engine (Dogwood). Die Policy-Engine entscheidet, ob eine Aktion erlaubt oder blockiert wird. MCP ist ein Standard, mit dem KI externe Tools nutzen kann.
- Regeln, die frühere Aktionen berücksichtigen. Container und MicroVMs (kleine virtuelle Computer) schließen einen Agenten ein, wissen aber nicht, was er bisher getan hat. Strands Box wendet Regeln auf Grundlage dessen an, was der Agent schon getan hat.
- Beispielregeln. Der Agent darf in Slack posten, aber nur dreimal alle zehn Minuten. Ausgehende Web-Anfragen werden blockiert, sobald der Agent eine Datei aus einem Kundendaten-Ordner gelesen hat.
Kann man es schon nutzen?
- Unterstützte Umgebung. Die Vorschau unterstützt nur Apple-Silicon-Macs mit macOS 15 oder neuer.
- Roadmap. Linux-Unterstützung ist geplant, aber ohne Termin; Windows wird nicht erwähnt. Als künftige Plattformen werden Bedrock AgentCore, ECS und Kubernetes (ein Open-Source-System, das viele Container verwaltet) genannt, ohne festen Zeitpunkt.
- Framework. Manche Berichte nennen es im Zusammenhang mit dem Strands-Agents-Ökosystem, eine Analyse sagt dagegen, es solle unabhängig von einem bestimmten Agent-Framework funktionieren.
Auch die Grenzen sind klar
AWS benennt die Lücken im eigenen Beitrag selbst.
- Pfade, die direkt in der Konfigurationsdatei freigegeben sind, etwa für das eingebaute Dateiwerkzeug eines Agenten, werden vom Betriebssystem abgesichert, tauchen aber nicht im Aktionsverlauf der Regeln auf. Shell- und Python-Interpreter laufen außerhalb der Sandbox, was den vertrauenswürdigen Bereich vergrößert; AWS nennt das einen bewussten Kompromiss.
- AWS’ eigenes Beispiel begrenzt zuerst über eine IAM-Rolle (Berechtigungsverwaltung), was die Zugangsdaten tun dürfen, und legt die Regeln von Strands Box darüber – IAM wird also nicht ersetzt. Es ist eher eine nützliche Beschränkung als eine vollständige Isolation.
Angaben, die wir nicht bestätigen konnten
- Die Formulierungen „außer Kontrolle geratenes Agentenverhalten in Unternehmensumgebungen“ und „Echtzeit-Monitoring“ konnten wir in offiziellen Beschreibungen nicht bestätigen. Bestätigt sind Isolation und Regeln auf Grundlage früherer Aktionen.
- „Ein Framework für Agenten-Guardrails ist offiziell geworden“ ist übertrieben. Derzeit handelt es sich um eine Open-Source-Developer-Preview mit begrenzten Umgebungen.
Was sich für Entwickler ändern könnte
Das Folgende ist unsere Einschätzung und unser Rat auf Grundlage der Berichte.
- „Tu das nicht“ in den Prompt zu schreiben, reicht nicht. Aktionen auf Systemebene zu blockieren, sodass der Agent sie wirklich nicht ausführen kann, könnte zur Norm werden.
- Regeln lassen sich nach Anzahl und Reihenfolge entwerfen. Zustandsbehaftete Regeln, etwa Ratenlimits oder das Blockieren von Außenverkehr nach dem Lesen sensibler Daten, sind für Coding- und DevOps-Agenten besonders nützlich.
- Vorerst als experimentell behandeln. Eine Vorschau nur für Mac ist für Server-Deployments schwer nutzbar. In der Produktion sollten bestehende Schutzmaßnahmen wie IAM, Logs und menschliche Freigabe bleiben.
- Umgehungswege prüfen. Man sollte davon ausgehen, dass es Wege gibt, die das Tool nicht blockieren kann (eingebaute Tools, vertrauenswürdige Interpreter), und wichtige Vorgänge mit einem separaten Freigabeschritt versehen.
Was man beobachten sollte
Den Zeitplan für Linux-Unterstützung, die Frage einer Windows-Unterstützung und Cloud-Zielplattformen, Dokumentation und Beispiele zur Regelsprache (Dogwood) sowie den Umgang mit gemeldeten Umgehungsfällen.
Quellen
Quelle: aws.amazon.com