Ein Bereitschaftsteam lässt einen KI-Agenten einen Produktionsfehler untersuchen. Er soll Logs lesen, Konfigurationen vergleichen und einen Statusbericht senden. Dafür benötigt er Werkzeuge und Netzwerkzugriff. Daraus darf aber nicht automatisch das Recht entstehen, Infrastruktur zu verändern, Zugangsdaten auszulesen oder beliebig viele Nachrichten zu veröffentlichen. Die entscheidende Frage lautet deshalb nicht nur: Welche Systeme erreicht der Agent? Sondern: Welche konkrete Handlung ist unter welchen Bedingungen erlaubt?
Am 7. Oktober 2026 hat AWS dafür Strands Box als Developer Preview vorgestellt. Die quelloffene Laufzeit verbindet Betriebssystem-Isolation mit Regeln in der Policy-Sprache Dogwood. Neu ist nicht das Versprechen einer weiteren Sandbox, sondern die Verbindung von Ausführungsgrenzen mit einer gemeinsam ausgewerteten Handlungshistorie. Das Projekt veröffentlichte Version 0.1.0 am selben Tag. Für Unternehmen ist das ein prüfbarer Architekturansatz, noch kein Nachweis produktionsreifer Rundumabsicherung. [1,2,6]
Zwei Grenzen statt eines Sicherheitsversprechens
Strands Box trennt zwei Ebenen. In box.toml wird festgelegt, welche Dateien und Programme ein Agent unmittelbar erreichen darf. Diese Grenze setzt das Betriebssystem durch. In policy.dw stehen dagegen Regeln für Operationen, die über die vertrauenswürdigen Komponenten von Box laufen. Dazu gehören Strands Shell, der Python-Interpreter Monty, ein Gateway für ausgehenden Verkehr und ein MCP-Broker. [2,3]
Die Policy-Engine und ihre Durchsetzung laufen außerhalb des Agentenprozesses. Die geprüfte Aktion wird anhand ihrer Parameter und gegebenenfalls früherer Ereignisse zugelassen oder abgewiesen. Dogwood verwendet dafür permit und forbid: Ohne passende Erlaubnis wird eine geprüfte Operation abgelehnt; ein passendes Verbot hat Vorrang. Das ist eine technische Entscheidung außerhalb des Sprachmodells, keine Bitte im Systemprompt. [2,4]
Der Geltungsbereich ist allerdings wichtig. Direkt freigegebene Dateipfade werden nicht zusätzlich bei jedem Zugriff von Dogwood geprüft. Die Dokumentation weist ausdrücklich darauf hin, dass solche Zugriffe auch keinen einzelnen Policy-Entscheidungseintrag erzeugen. Soll eine Datei einer inhaltlich oder zeitlich bedingten Regel unterliegen, darf sie nicht gleichzeitig unbeschränkt über die direkte Freigabe erreichbar sein. [2,3]
Was Regeln mit Gedächtnis ermöglichen
Eine gewöhnliche Berechtigung beantwortet beispielsweise, ob ein Werkzeug gestartet werden darf. Eine zeitbezogene Regel kann zusätzlich verlangen, dass zuvor ein bestimmter Test erfolgreich abgeschlossen wurde, oder Aufrufe innerhalb eines Zeitfensters begrenzen. Shell, Python, Netzwerk-Gateway und MCP-Broker teilen dafür eine Ereignishistorie. Ein über einen Interpreter beobachteter Dateizugriff kann dadurch eine spätere Netzwerkentscheidung beeinflussen. [2,4]
AWS demonstriert dies unter anderem mit einem Limit von drei erfolgreichen Slack-Anfragen innerhalb von zehn Minuten. Das ist ein Konfigurationsbeispiel, kein festes Produktlimit. In einem weiteren Beispiel soll ein git push nur nach einem erfolgreichen Testlauf innerhalb der letzten 15 Minuten erlaubt sein. Der Architekturbeitrag bezeichnet diese Beispielregel ausdrücklich als unvollständig: Ein zwischenzeitlicher Branchwechsel könnte die beabsichtigte Zusicherung unterlaufen. [1,5]
Genau diese Einschränkung ist für die Praxis wertvoll. „Tests waren erfolgreich“ ist nicht gleichbedeutend mit „der jetzt veröffentlichte Code wurde getestet“. Unsere Empfehlung: Freigaben an nachvollziehbare Artefakte und Zustandswechsel binden, statt lediglich einen früheren Erfolg zu zählen. Der neue Mechanismus liefert Ausdrucksmöglichkeiten; die fachliche Vollständigkeit einer Regel bleibt eine Engineering-Aufgabe.
Zugangsdaten am Gateway statt im Agentenkontext
Ein zweiter relevanter Baustein ist die Übergabe von Zugangsdaten. Das Gateway kann erlaubte Anfragen mit konfigurierten API-Credentials oder einer AWS-SigV4-Signatur versehen. Der Agent soll die zugrunde liegenden Geheimnisse dabei nicht erhalten. Im AWS-Beispiel werden Modellzugriffe mit Platzhaltern vorbereitet; echte Werte setzt erst das Gateway ein. AWS-Anfragen werden dort mit Zugangsdaten eines Host-Profils signiert. [1,2]
Das reduziert die Notwendigkeit, einem Agenten vollständige Schlüssel zu geben. Es macht eine erlaubte Anfrage aber nicht automatisch ungefährlich. Wer einen legitimen API-Aufruf auslösen darf, kann dessen geschäftliche Wirkung weiterhin erreichen. Deshalb sollten Ziel, Methode, Pfad, Werkzeugparameter und Identitätsrechte gemeinsam begrenzt werden. Das ist unsere Architekturfolgerung aus der dokumentierten Trennung von Credential-Bindung und Policy-Erlaubnis. [4]
Die entscheidenden Limitierungen stehen in der Dokumentation
Besonders aufschlussreich sind die Grenzen der Ereigniszählung. Ein request-Ereignis entsteht auch für abgelehnte Versuche. Eine Voraussetzung wie „vorher erfolgreich geprüft“ sollte deshalb nicht bloß einen Versuch als Beleg verwenden. Umgekehrt entsteht ein response-Ereignis erst nach Abschluss einer Operation. Mehrere gleichzeitig laufende Anfragen können daher ein ausschließlich auf Antworten beruhendes Budget überschreiten. [3,4]
Für Kostenlimits, Freigabeketten oder Veröffentlichungsregeln ist diese Unterscheidung wesentlich. Unsere Empfehlung lautet, Parallelität, Wiederholungen und verweigerte Versuche ausdrücklich zu testen. Eine plausibel lesbare Regel ersetzt keinen Negativtest gegen die tatsächliche Ausführung.
Auch Dateiberechtigungen bleiben Verantwortung des Betreibers. Ein breit formuliertes Lese-Permit kann laut Dokumentation sensible Bereiche wie SSH- oder AWS-Konfigurationen einschließen. Bei extern gestarteten Programmen prüft die Policy deren Start; ihre einzelnen Dateizugriffe werden über die jeweilige Betriebssystem-Sandbox begrenzt, nicht einzeln von Dogwood entschieden. [3]
Die Preview unterstützt nach Projektangaben zunächst lokale Ausführung auf Macs mit Apple Silicon. Weitere Betriebssysteme und die Nutzung für bereitgestellte Agenten werden als nächste Entwicklungsrichtungen beschrieben. Unternehmen sollten daraus keine bereits verfügbare, einheitliche Absicherung ihrer gesamten Linux-, Windows- und Kubernetes-Landschaft ableiten. [1,2]
Was Unternehmen konkret daraus machen können
Erstens: Eine Berechtigungsmatrix für einen einzigen Arbeitsablauf erstellen. Für einen Diagnose-Agenten beispielsweise getrennt festhalten: Welche Logs darf er lesen, welche Infrastruktur nur abfragen, wohin darf er berichten und welche Änderungen bleiben ausgeschlossen? Diese Anforderungen sollten vor der Produktauswahl vorliegen.
Zweitens: Direkte und vermittelte Zugriffe getrennt prüfen. Jede unmittelbare Dateifreigabe ist eine bewusste Ausnahme von der feingranularen Policy-Prüfung. Unser Vorschlag ist, sensible Dateien aus direkten Grants herauszuhalten und Ausnahmen mit Eigentümer und Begründung zu dokumentieren. Die zweistufige Durchsetzung macht diese Inventur unverzichtbar. [3]
Drittens: Regeln wie sicherheitskritischen Code behandeln. Versionsverwaltung, Review und automatisierte Tests sollten zum Pilot gehören. Testfälle müssen verbotene Methoden, alternative Werkzeugpfade, parallele Anfragen, abgelaufene Zeitfenster und Änderungen nach einem erfolgreichen Testlauf abdecken. Agentengenerierte Regeln sollten denselben Review erhalten wie manuell geschriebene.
Viertens: Berechtigungen hinter dem Gateway klein halten. Auch wenn Geheimnisse verborgen bleiben, sollten die verwendeten Konten ausschließlich die erforderlichen Aktionen erlauben. Ein restriktiver Agenten-Proxy vor einer überprivilegierten Identität bleibt eine unnötig große Vertrauensabhängigkeit.
Fünftens: Den Pilot bewusst begrenzen. Zunächst synthetische Daten, ungefährliche Testendpunkte und keine produktiven Änderungsrechte verwenden. Erfolgreiche und abgelehnte Aktionen auswerten, aber Entscheidungseinträge nicht mit einer vollständigen Betriebssystem-Auditspur verwechseln. Die dokumentierten direkten Zugriffe zeigen, warum zusätzliche Beobachtung nötig bleibt. [3]
Fazit
Strands Box macht eine wichtige Unterscheidung konkret: Isolation begrenzt Reichweite; semantische und zeitbezogene Regeln begrenzen Handlungen innerhalb dieser Reichweite. Die aktuelle Veröffentlichung rechtfertigt einen technischen Pilot, weil Architektur, Quellcode und Einschränkungen öffentlich überprüfbar sind. [1,2,3]
Ein unabhängiger Wirksamkeitsnachweis liegt dieser Einordnung nicht zugrunde; die technischen Aussagen stammen aus Herstellerveröffentlichungen und Projektdokumentation. Unser Maßstab für Unternehmen bleibt deshalb nüchtern: Nicht die Zahl formulierter Regeln entscheidet, sondern ob alle relevanten Ausführungspfade erfasst sind, Nebenläufigkeit berücksichtigt wird und eine erlaubte Aktion nur die tatsächlich vorgesehenen Rechte erhält.
Quellen
- AWS Open Source Blog: Introducing Strands Box, 7. Oktober 2026
- Strands Box: Projektbeschreibung und Architektur
- Strands Box: Security – what Box governs, and what you own
- Strands Box: Policy-Dokumentation
- Marc Brooker: Strands Box – The Big Picture, 7. Oktober 2026
- Strands Box: Release v0.1.0, 7. Oktober 2026
