AWS Rex begrenzt, was KI-Agenten auf Servern anfassen dürfen

Worum es geht

AWS hat am 4. Mai 2026 Trusted Remote Execution veröffentlicht, kurz Rex. Es ist eine Open-Source-Laufzeit für Skripte, bei der nicht das Skript selbst entscheidet, was es auf einem System darf. Jede Dateioperation wird gegen eine separate Cedar-Policy geprüft, bevor sie ausgeführt wird.

Das klingt trocken, ist aber für KI-Agenten wichtig: Wenn ein Agent zur Laufzeit ein Skript schreibt, gibt es oft keine klassische Code-Review. Genau hier entstehen die gefährlichen Fälle, in denen ein Agent eigentlich nur Logs lesen soll, aber durch Prompt Injection, Halluzination oder unklare Anweisung plötzlich Dateien schreibt, Dienste verändert oder Daten löscht.

Was Rex tatsächlich macht

Rex führt Skripte in Rhai aus, einer kleinen Skriptsprache ohne direkten Systemzugriff. Der Host ist nicht automatisch erreichbar. Stattdessen stellt Rex einzelne Operationen bereit, etwa Lesen, Öffnen oder Schreiben. Jede dieser Operationen muss durch eine Cedar-Policy erlaubt sein.

Das zentrale Muster ist einfach: Das Skript beschreibt die Aufgabe, die Policy beschreibt die Grenze. Wenn ein Skript etwas versucht, das nicht erlaubt ist, bekommt es einen Fehler wie ACCESS_DENIED_EXCEPTION. Der Vorgang passiert dann nicht. Der Agent kann den Fehler sehen und seine nächste Aktion anpassen, aber er kann die Policy nicht einfach überschreiben.

Warum das wichtig ist

Viele Unternehmen wollen KI-Agenten nicht nur chatten lassen, sondern echte Betriebsaufgaben geben: Logs prüfen, Konfigurationen lesen, Healthchecks ausführen oder Dienste kontrolliert neu starten. Dafür braucht der Agent Zugriff auf produktionsnahe Systeme. Genau dieser Zugriff ist das Risiko.

Rex verschiebt die Sicherheitslogik weg vom Prompt und hin zu einer prüfbaren, versionierbaren Policy. Das ist ein anderer Schutz als „bitte lösche nichts“. Für DevOps-Teams, Plattformteams und Anbieter von Agenten-Werkzeugen ist das relevant, weil es einen konkreten Mechanismus gegen übergriffige Runtime-Aktionen anbietet.

Einfach erklärt

Stell dir vor, ein Praktikant soll im Archiv eine Akte holen. Ohne Kontrolle bekommt er den Generalschlüssel für das ganze Gebäude. Mit Rex bekommt er eine Karte, die nur den Archivraum und nur den Aktenschrank öffnet, der für die Aufgabe nötig ist. Wenn er aus Versehen die Tür zum Serverraum probiert, bleibt sie zu.

Der wichtige Punkt: Man muss dem Praktikanten nicht perfekt vertrauen. Man muss die Türen sauber konfigurieren.

Praktisches Beispiel

Ein On-Call-Team lässt einen Agenten nachts Logdateien auf 40 Servern prüfen. Die Policy erlaubt nur read auf /var/log/app/ und verbietet write, delete und Zugriffe auf /etc/. Der Agent findet bei 3 von 40 Servern wiederkehrende Fehler und schreibt einen Bericht.

Wenn der Agent wegen einer schlechten Anweisung versucht, eine Konfigurationsdatei zu ändern, blockiert Rex den Zugriff. Das Team bekommt eine klare Fehlermeldung statt eines Produktionsvorfalls. Der praktische Wert liegt nicht darin, dass Rex Fehler unmöglich macht. Der Wert liegt darin, dass ein Fehler nicht automatisch Systemrechte erbt.

Einordnung und Grenzen

• Rex schützt nur Operationen, die tatsächlich über die Rex-Laufzeit laufen. Wenn Agenten daneben direkten Shell-Zugriff bekommen, ist die Grenze wieder weg.
• Policies müssen sorgfältig geschrieben und getestet werden. Eine zu breite Policy ist fast so gefährlich wie gar keine Policy.
• Rex ersetzt keine Secrets-Hygiene, kein Monitoring und keine Review-Prozesse. Es ist eine zusätzliche technische Leitplanke für kontrollierte Ausführung.

SEO- und GEO-Schlüsselbegriffe

AWS, Trusted Remote Execution, Rex, Cedar Policy, AI Agents, Agent Security, DevOps Automation, Open Source Security, Rhai, Production Operations, Prompt Injection, Runtime Authorization