Ein typisches Enterprise-Problem der kommenden Monate wirkt zunächst banal: Ein KI-Agent soll eine Logdatei prüfen, eine Konfiguration validieren oder einen Service neu starten. Dafür erzeugt er zur Laufzeit ein kleines Skript. Genau dort gerät ein klassisches Sicherheitsmodell unter Druck. Übliche Skriptumgebungen übernehmen meist die Rechte des Prozesses, in dem sie laufen. Ein Skript, das eigentlich nur lesen soll, kann dann unter Umständen auch schreiben, löschen, Netzwerkverbindungen öffnen oder Prozesse beenden. Bei menschlich geschriebenem Code greifen Code Reviews, Freigaben und Change-Prozesse. Bei Agenten entsteht der Code dagegen im Moment der Ausführung.
Amazon Web Services stellte am 4. Mai 2026 ein Open-Source-Projekt vor, das diese Lücke schließen soll: Trusted Remote Execution, kurz Rex. Help Net Security griff das Thema am 6. Mai auf und beschrieb Rex als Laufzeitumgebung, die kontrolliert, „was KI-Agenten anfassen dürfen“. Für Unternehmen ist weniger das einzelne Tool entscheidend als das Architekturprinzip dahinter: Berechtigungen gehören nicht in den generierten Code, sondern in eine externe Policy, die bei jeder Systemoperation geprüft wird.
Das technische Prinzip: Skript und Erlaubnis werden getrennt
Rex kombiniert zwei Komponenten. Die Skripte laufen in Rhai, einer leichtgewichtigen eingebetteten Skriptsprache ohne direkten Zugriff auf das Host-Betriebssystem. Die Autorisierung übernimmt Cedar, die von AWS entwickelte und 2023 als Open Source veröffentlichte Policy-Sprache. Der zentrale Punkt: Ein Rex-Skript kann keine beliebigen Systemaufrufe ausführen. Es erreicht den Host nur über ausdrücklich bereitgestellte Operationen der Rex-Laufzeitumgebung. Jede dieser Operationen prüft Rex gegen eine Cedar-Policy, bevor sie tatsächlich ausgeführt wird.
AWS fasst das Modell klar: Das Skript beschreibt, was getan werden soll; die Policy entscheidet, was erlaubt ist. Erlaubt die Policy eine Aktion nicht, bekommt das Skript einen Fehler. Die Operation erreicht den Kernel nicht. Nach den verfügbaren Beschreibungen gilt das nicht nur für Dateioperationen, sondern auch für Netzwerkzugriffe, Prozessmanagement, Systeminformationen und verwandte Host-Funktionen, sofern Rex sie über das SDK anbietet.
Damit verschiebt sich die Sicherheitsfrage. Sie lautet nicht mehr nur: „Darf dieser Agent grundsätzlich in dieser Umgebung laufen?“ Sondern: „Darf diese konkrete Operation in diesem konkreten Kontext ausgeführt werden?“ Das ist ein wesentlicher Unterschied. Ein Agent kann weiter automatisieren, erhält aber nicht automatisch die vollen Rechte seines Ausführungskontexts.
Warum das für Agentic AI relevanter ist als für klassische Skripte
Bei klassischer Automatisierung ist der Umfang eines Skripts meist bekannt. Entwickler schreiben es, prüfen es, versionieren es und führen es anschließend aus. KI-Agenten verändern diese Annahme. Sie erzeugen Code dynamisch, interpretieren Aufgaben mitunter zu breit oder reagieren auf manipulierte Eingaben. Prompt Injection ist dabei kein reines Chatbot-Problem. Wenn ein Agent Anweisungen aus Tickets, Webseiten, Repositories oder Logdaten extrahiert, können schädliche Instruktionen direkt in den Arbeitsfluss gelangen.
Ein einfacher Sandbox-Ansatz reicht in solchen Szenarien oft nicht aus. Viele Sandboxes begrenzen den Agenten als Prozess. Rex begrenzt stattdessen die Wirkung des Codes auf den Host. Selbst wenn ein Agent ein Skript erzeugt, das mehr tun will als vorgesehen, muss jede Host-Operation durch die Policy. Das ersetzt keine Defense-in-Depth. Es reduziert aber eine besonders riskante Fehlerklasse: unkontrollierte Seiteneffekte durch Code, der erst zur Laufzeit entsteht.
Help Net Security nennt als Beispiele Datei- und Verzeichniszugriffe, Netzwerkfunktionen wie curl, DNS-Operationen, Prozessmanagement inklusive systemctl, Systemabfragen und Disk-Statistiken. Linuxiac verweist zusätzlich darauf, dass Rex laut Projektbeschreibung nach Möglichkeit File-Deskriptoren statt Pfaden nutzt, um Time-of-Check-to-Time-of-Use- und Symlink-Risiken zu verringern. Solche Details zeigen: Es geht nicht nur um eine abstrakte Policy-Schicht, sondern um konkrete Betriebssystem-Risiken.
Branchenkontext: Agenten treffen auf Produktionsrechte
Der Zeitpunkt ist bemerkenswert. Unternehmen testen längst nicht mehr nur Chatbots. Agenten wandern in Entwicklerwerkzeuge, Service-Desks, Cloud-Betrieb, Security Operations und Datenplattformen. Dort liegen häufig genau die Rechte, die Angreifer suchen: Zugriff auf Repositories, CI/CD-Systeme, Cloud-APIs, Secrets, Tickets, Logs und interne Wikis. Ein Agent, der nützlich sein soll, braucht Kontext. Je mehr Kontext er erhält, desto größer wird allerdings auch die Angriffsfläche.
Klassische Kontrollen lassen sich nur begrenzt übertragen. Allowlists für einzelne Shell-Kommandos bleiben grob. Container-Isolation hilft, beantwortet aber nicht automatisch, welche Datei ein Agent lesen oder welche URL er erreichen darf. Menschliche Freigaben skalieren schlecht, wenn Agenten viele kleine Operationen binnen Sekunden ausführen. Policy-basierte Laufzeitkontrolle ist deshalb ein naheliegender nächster Schritt.
Rex fällt auch deshalb auf, weil AWS das Projekt als Open Source unter Apache-2.0-Lizenz veröffentlicht hat. Teams können das Konzept prüfen, in Laborumgebungen testen und mit eigenen Policies experimentieren, ohne sich sofort an ein proprietäres Produkt zu binden. Für Entscheider ist das relevant: Die Sicherheitsfrage bei Agenten lässt sich nicht allein durch neue Plattformfunktionen lösen. Sie wird zu einer Architekturfrage für alle Umgebungen, in denen Agenten Code, Skripte oder API-Aufrufe ausführen.
Konkrete Implikationen für Unternehmen
Erstens sollten Unternehmen Agenten nicht wie normale Benutzerkonten behandeln. Ein Agent ist kein Mensch mit stabiler Absicht. Er ist ein System, das aus Kontext, Modellantwort und Werkzeugzugriff Handlungen ableitet. Rollen und Rechte müssen deshalb enger, expliziter und stärker kontextabhängig definiert werden.
Zweitens sollten generierte Skripte grundsätzlich als nicht vertrauenswürdig gelten. Auch intern eingesetzte Modelle können halluzinieren, Aufgaben falsch interpretieren oder auf manipulierte Eingaben reagieren. Eine externe Policy-Schicht trennt die Erlaubnis vom Code, den der Agent gerade erzeugt hat.
Drittens braucht jede Agentenplattform ein belastbares Audit-Modell. Entscheidend ist nicht nur, ob eine Aktion erlaubt oder blockiert wurde. Unternehmen müssen nachvollziehen können, welcher Agent, welche Aufgabe, welches Skript und welche Policy zu welcher Operation geführt haben. Ohne diese Spur bleibt Incident Response bei Agenten schwierig.
Viertens sollten Security-Teams ihre Schutzmaßnahmen näher an die eigentlichen Operationen rücken. Eine grobe Netzwerkregel oder ein pauschales Servicekonto reicht nicht, wenn ein Agent sowohl harmlose Diagnose als auch riskante Änderungen auslösen kann. Policies sollten Dateibereiche, Netzwerkziele, Prozessaktionen und Systemabfragen getrennt beschreiben.
Risiken und Grenzen
Rex ist kein Allheilmittel. Eine schlecht geschriebene Cedar-Policy kann zu viel erlauben. Ein Tool, das nicht in die Laufzeitumgebung integriert ist, fällt möglicherweise aus dem Schutzmodell heraus. Auch Datenabfluss über erlaubte Kanäle bleibt ein Problem, wenn die Policy zu großzügig formuliert ist. Zudem beantwortet Rex nicht die Frage, welche Aufgaben ein Agent überhaupt annehmen darf oder wie Eingaben gegen Prompt Injection gehärtet werden.
Trotzdem ist der Ansatz wichtig, weil er von einer realistischen Annahme ausgeht: Agenten werden Fehler machen, und generierter Code wird nicht immer vorhersehbar sein. Sicherheit muss deshalb zur Laufzeit greifen — nicht erst im Review-Prozess.
Fazit
AWS Rex ist weniger die fertige Antwort auf alle Agentic-AI-Risiken als ein Hinweis darauf, wohin sich Enterprise-Security bewegen muss. Wenn KI-Agenten Skripte erzeugen und Systeme bedienen, reicht Vertrauen in Modell, Prompt oder Container nicht aus. Jede relevante Host-Operation braucht eine explizite, prüfbare Erlaubnis.
Für Unternehmen, die Agenten in DevOps, Cloud-Betrieb oder Security Operations einsetzen wollen, ist das die zentrale Lehre: Agentensicherheit beginnt nicht im Chatfenster. Sie beginnt an der Grenze zwischen generierter Absicht und realer Systemwirkung.
Quellen: AWS Open Source Blog vom 4. Mai 2026 („Introducing Trusted Remote Execution: Policy-Enforced Scripts for AI Agents and Humans“), Help Net Security vom 6. Mai 2026 („AWS open sources Trusted Remote Execution to control what AI agents touch“), Linuxiac vom 5. Mai 2026 („Amazon’s New Open-Source Rex Project Controls What Scripts Can Do“).
