AWS Rex gibt die Runtime-Schicht der Agentic-AI-Sicherheit als Open Source frei
Am 4. Mai 2026 veröffentlichte AWS Introducing Trusted Remote Execution: Policy-Enforced Scripts for AI Agents and Humans und stellte Rex unter der Apache 2.0-Lizenz als Open Source bereit. Die Architektur ist einfach: Skripte werden in Rhai geschrieben, einer leichtgewichtigen eingebetteten Sprache ohne integrierten Betriebssystemzugriff. Der einzige Weg, wie ein Skript auf den Host zugreifen kann, ist über ein speziell entwickeltes SDK. Jede Operation wird vor dem Systemaufruf anhand einer Cedar-Policy autorisiert. Wird die Aktion durch die Policy abgelehnt, erhält das Skript eine ACCESS_DENIED_EXCEPTION und die Operation erreicht nie den Kernel.
AWS gesteht im Produktivcode ein, was die Security-Research-Community seit zwei Jahren fordert: Code-Review, Freigabe-Workflows und erlaubte Kommandos können Code, der zur Laufzeit von einem KI-System generiert wird, nicht kontrollieren. Die klassischen Sicherheitsnetze versagen, wenn der Agent selbst der Autor ist.
5 Wichtige Erkenntnisse
1. AWS hat Runtime-Policy-Enforcement als neue Kategorie eingeführt.
Trusted Remote Execution (Rex) prüft jede Systemoperation eines KI-generierten Skripts gegen eine vom Host-Besitzer definierte Cedar-Policy – nicht vom Agenten. Das ist die erste große Anerkennung eines Hyperscalers, dass die Runtime-Schicht der agentischen KI-Sicherheit nicht dem Agenten selbst überlassen werden darf. Wenn AWS produktive Infrastruktur unter der Annahme ausliefert, dass Prompt Injection nicht gelöst wird, ist die Implikation für Enterprise-Architekten eindeutig: Planen Sie so, als würde der Agent sich fehlverhalten.
2. Das Bedrohungsmodell ist explizit und unbequem.
AWS benennt Halluzinationen im Code, Prompt Injection und zu eifrige Aufgabeninterpretation als konkrete Fehlerquellen, die Rex eindämmen soll. OpenAI hat erklärt, dass Prompt Injection „wahrscheinlich nie vollständig gelöst“ wird. Auch Anthropic räumt ein, dass das Problem „insbesondere bei realweltlichen Aktionen von Modellen“ weit entfernt von einer Lösung ist. Rex basiert auf diesen Eingeständnissen – und Ihre KI-Governance-Architektur sollte das auch tun.
3. Rex beschränkt den Host, nicht den Agenten.
Die meisten agentischen Sandboxes versuchen, die Ausgaben des Modells zu begrenzen. Rex dreht das um: Unabhängig davon, was der Agent generiert, kann der Systemaufruf nie über das hinausgehen, was die Policy erlaubt. Diese architektonische Umkehr – die Verschiebung des Enforcement-Perimeters darauf, was der Agent am Host tun darf – ist kein inkrementelles Feintuning. Es ist ein Paradigmenwechsel, wo Vertrauen verankert wird. Vertrauen wandert von den Ausgaben des Agenten zur Policy-Engine des Hosts.
4. Runtime-Gating ist notwendig, aber nicht ausreichend.
Cedar-Policies für Systemaufrufe können einem Agenten nicht sagen, welches Dokument er gar nicht erst hätte anfordern dürfen, welche Felder das Minimum-Prinzip erfüllen oder ob ein Abruf eine durch die Datenklassifizierung verbotene Jurisdiktionsgrenze überschreitet. Genau diese Kontrollen verlangen DSGVO Artikel 5, der HIPAA-Mindeststandard und die CMMC Level 2 Access-Control-Familien. Rex löst diese Anforderungen nicht.
5. Die auditierbare Schicht liegt unterhalb der Runtime.
Aufsichtsbehörden, Auditoren und Kläger werden Nachweise verlangen, wer welchen Datenzugriff autorisiert hat. Dieser Nachweis muss dort vorliegen, wo die Daten liegen – in manipulationssicheren Audit-Trails, die jede KI-Interaktion mit regulierten Inhalten abdecken. Eine Policy, die einen System-Call-Read erlaubt, ist auf Runtime-Ebene korrekt. Auf Datenebene ist es die falsche Policy – und das sind unterschiedliche Instrumente.
Sie Vertrauen darauf, dass Ihr Unternehmen sicher ist. Aber können Sie es belegen?
Jetzt lesen
Was AWS über agentische KI eingesteht
Drei architektonische Eingeständnisse aus der AWS-Ankündigung sind genauso wichtig wie der Code selbst.
Das erste ist das Bedrohungsmodell. Halluzinierter Code, Prompt Injection und zu eifrige Aufgabeninterpretation werden explizit genannt – nicht als theoretische Randfälle, sondern als die konkreten Fehlerquellen, die Rex adressiert. Wenn ein Hyperscaler Infrastruktur unter der Annahme ausliefert, dass diese Probleme nicht gelöst werden, sollten Enterprise-Architekten entsprechend planen.
Das zweite ist die architektonische Umkehr. Rex verschiebt den Enforcement-Perimeter darauf, was der Agent am Host tun darf, statt die Ausgaben des Agenten zu begrenzen. Diese Formulierung ist präzise: Den Agenten zu beschränken, setzt voraus, dass seine Ausgaben zuverlässig eingegrenzt werden können. Die Verschiebung zum Host geht davon aus, dass diese Grenzen unsicher sind, und verlagert die Kontrolle dorthin, wo das System tatsächlich ausgeführt wird. Das ist eine Architekturentscheidung in Sachen Vertrauen, kein Feature.
Das dritte betrifft das Policy-Modell. Cedar – im Mai 2023 von AWS als Open Source bereitgestellt und inzwischen ein CNCF Sandbox-Projekt – unterstützt sowohl RBAC als auch ABAC. Der Host-Besitzer, nicht der Agent, definiert die Policy. Skript und Policy werden separat versioniert. Das ist Policy-as-Code auf System-Call-Ebene – die richtige Ebene für dieses Muster und auch die einzige, die Rex adressiert.
Warum Runtime-Gating notwendig ist
Rex löst ein echtes Problem. Die meisten Skriptausführungsumgebungen geben Skripten sämtliche Berechtigungen des Ausführungskontexts – ein Skript, das eine Logdatei lesen soll, könnte sie genauso gut löschen. Wird dieses Skript zur Laufzeit von einem KI-Agenten generiert, greifen klassische Kontrollmechanismen nicht mehr. Ein fehlverhaltender Agent ist in so einer Umgebung nur einen falsch interpretierten Task von Produktionsschäden entfernt.
Die Kiteworks 2026 Prognose quantifiziert dieses Risiko. 63% der Unternehmen können Zweckbindungen für KI-Agenten nicht durchsetzen. 60% können einen fehlverhaltenden Agenten nicht schnell beenden. 55% können KI-Systeme nicht vom restlichen Netzwerk isolieren. 54% können KI-Eingaben nicht validieren. Rex-ähnliche Runtime-Policy-Enforcement schließt die erste und letzte dieser Lücken signifikant. Es gibt auch eine regulatorische Dimension: Unternehmen, die dem Druck des EU AI Act unterliegen, bauen die von Rex repräsentierte Runtime-, Identitäts- und Policy-Infrastruktur schneller auf als Unternehmen außerhalb dieses Perimeters. Die Beratungslandschaft schließt diese Lücke branchenübergreifend rasant.
Warum Runtime-Gating nicht ausreicht
Rex ist eine Runtime-Kontrolle. Sie steuert Systemaufrufe. Sie kann einem Agenten nicht sagen, welches Dokument er gar nicht erst hätte anfordern dürfen. Sie kann nicht durchsetzen, dass ein zurückgegebener Datensatz nur die Felder enthält, die ein menschlicher Anwender sehen darf. Sie kann nicht beurteilen, ob ein Abruf eine durch die Datenklassifizierung verbotene Jurisdiktionsgrenze überschreitet.
Das sind keine theoretischen Randfälle. Es sind die Kontrollen, die DSGVO Artikel 5 fordert – Zweckbindung, Datenminimierung, Speicherbegrenzung, Rechenschaftspflicht. Sie sind Voraussetzung für den HIPAA-Mindeststandard. Sie sind Grundlage der CMMC Level 2 Access-Control-Familien. Sie sind explizit im CISA-, NSA- und Five Eyes-Joint Advisory zu agentischer KI in den Risikokategorien Rechenschaft und Privilegien benannt.
Eine Policy, die file_system::Action::"read" auf /var/data/customer-records.csv erlaubt, ist auf Runtime-Ebene korrekt. Auf Datenebene ist es die falsche Policy. Die Datenschicht muss andere Fragen stellen: Erfolgt dieser Lesezugriff im Auftrag eines Anwenders mit der richtigen Autorisierung? Handelt der Anforderer im Rahmen des Engagements, das ihn autorisiert hat? Sind die Datensätze für die Aufgabe minimal erforderlich? Unterliegt einer der Datensätze einem Löschantrag, der noch nicht umgesetzt wurde? Wird der Zugriff ausreichend detailliert protokolliert, um auch drei Jahre nach Außerbetriebnahme des Modells nachvollziehen zu können, wer was autorisiert hat? Rex beantwortet diese Fragen nicht.
Das Architekturmodell, das funktioniert
Das funktionierende Muster ist mehrschichtig. Runtime-Kontrollen wie Rex regeln, was der Host erlaubt. Identitätskontrollen regeln, in wessen Auftrag der Agent handelt. Datenebenen-Kontrollen – Attribut-basierte Zugriffskontrollen, bewertet nach Klassifizierung, Jurisdiktion und Einwilligung – regeln, auf welche Daten der Agent zugreifen darf. Jede Schicht adressiert einen anderen Fehlerfall, keine einzelne Schicht reicht aus.
Der Kiteworks Secure MCP Server und das AI Data Gateway bilden die Datenebene dieser Architektur ab: Jede KI-Operation wird über OAuth 2.0 authentifiziert, anhand von ABAC-Policies in der Kiteworks Data Policy Engine bewertet, mit FIPS 140-3-validierter Kryptografie verschlüsselt und in einem manipulationssicheren Audit-Trail protokolliert, der bestehende SIEM-Infrastrukturen speist. Das Kiteworks Private Data Network erweitert diese Governance über E-Mail, Filesharing, Managed File Transfer, SFTP, Web-Formulare und APIs – alles unter einer Policy-Engine und einem konsolidierten Audit-Log.
AWS hat gerade starke Infrastruktur für die Runtime-Schicht geliefert. Die Identitäts- und Datenschicht müssen weiterhin aufgebaut werden – und die Kiteworks 2026 Prognose bestätigt, dass nur 43% der Unternehmen ein zentrales AI Data Gateway im Einsatz haben.
Was Security- und Compliance-Teams daraus mitnehmen sollten
Erstens: Nehmen Sie die AWS-Ankündigung als Signal ernst. Wenn ein Hyperscaler eine Runtime veröffentlicht, die jeden Systemaufruf unabhängig vom Agenten gegen eine Policy prüft, ist Runtime-Policy-Enforcement in ernsthaften KI-Deployments nicht mehr optional. Rex schließt eine bedeutende Lücke auf Runtime-Ebene, die viele Unternehmen bislang offenließen.
Zweitens: Verwechseln Sie Runtime-Enforcement nicht mit Data Governance. Rex regelt, was ein Agent am Host tun darf. Es sagt nichts darüber aus, auf welche Daten der Agent zugreifen darf. Runtime-Kontrolle ohne Governance auf Datenebene schließt die Audit-Lücke nicht – sie dokumentiert nur eine Schicht und lässt die andere offen.
Drittens: Entwerfen Sie die mehrschichtige Architektur explizit. Ordnen Sie Runtime-Kontrollen (Rex), Identitätskontrollen (OAuth, kurzlebige Anmeldedaten) und Datenebenen-Kontrollen (ABAC, Klassifizierung, Jurisdiktion, Einwilligung) den jeweiligen Fehlerquellen zu. Jede Schicht stellt andere Fragen; jede ist für eine vollständige Antwort notwendig.
Viertens: Behandeln Sie Policy-Versionierung als Audit-Nachweis. Cedars Trennung von Policy und Code erzeugt Artefakte, die Auditoren prüfen können. Kombinieren Sie Rex‘ Runtime-Artefakte mit manipulationssicheren Audit-Logs auf Datenebene, um ein vollständiges Nachweispaket zu liefern – die Lücke zwischen Sichtbarkeit dessen, was ausgeführt wurde, und dem, was an Daten berührt wurde, ist Ursprung vieler Audit-Feststellungen.
Fünftens: Nutzen Sie das Five Eyes Joint Advisory als Architekturtest. Wenden Sie die fünf Risikokategorien der CISA-Empfehlung „Careful Adoption of Agentic AI Services“ – Privilegien, Design und Konfiguration, Verhalten, Struktur, Rechenschaft – auf Ihr aktuelles KI-Deployment an. Rex adressiert Teile der Kategorien Privilegien und Verhalten. Struktur- und Rechenschaftskategorien erfordern Data-Governance, die keine Runtime allein leisten kann.
Erfahren Sie mehr über die Governance sensibler Daten und die Optimierung von KI-Agenten – vereinbaren Sie noch heute eine individuelle Demo.
Häufig gestellte Fragen
Rex setzt auf System-Call-Enforcement auf Skript-Ebene – dort, wo ein Agenten-generiertes Skript vor jedem Lese-, Schreib- oder Öffnen-Befehl durch eine Cedar-Policy geprüft wird. Es ersetzt keine Identitätskontrollen, Netzwerksegmentierung oder Governance auf Datenebene. Laut Kiteworks 2026 Prognose verfügen nur 43% der Unternehmen über ein zentrales AI Data Gateway. Rex ohne diese Datenschicht schließt eine Lücke, lässt aber eine größere offen.
Das Policy-as-Code-Modell von Cedar erzeugt versionierte Artefakte, die SOC 2 CC6 Access Controls und ISO 27001 A.5/A.8 Access Management erfüllen – aber keinen ausreichenden Nachweis der Autorisierung auf Datenebene liefern. Kombinieren Sie Rex‘ Runtime-Audit-Trail mit ABAC-Enforcement und manipulationssicheren Logs auf Datenebene für ein vollständiges Nachweispaket. Auditoren fordern zunehmend Containment-Nachweise – also Belege, dass ein fehlverhaltender Agent schnell beendet und isoliert werden kann.
Nein. Der HIPAA-Mindeststandard verlangt Kontrollen darüber, auf welche Daten der Agent im Auftrag eines autorisierten Anwenders zugreifen darf – nicht nur, welche Systemaufrufe das Skript ausführen darf. Zweckbindung ist eine semantische Datenkontrolle. 63% der Unternehmen können dies laut Kiteworks 2026 Prognose bei KI-Agenten nicht durchsetzen. Runtime-Kontrollen und ABAC-Enforcement auf Datenebene ergänzen sich – keine ersetzt die andere.
Rex adressiert Teile von zwei der fünf Risikokategorien der CISA-Empfehlung: Privilegienrisiken (Erzwingen von Least Privilege bei Systemoperationen) und Verhaltensrisiken (Eindämmung von halluziniertem oder injiziertem Code). Struktur- und Rechenschaftskategorien werden nicht abgedeckt. Die Rechenschaftskategorie – die von Auditoren und Aufsichtsbehörden besonders geprüft wird – erfordert einen Audit-Trail auf Datenebene, den Runtime-Gating allein nicht liefern kann.
Es gibt Überschneidungen und klare Abgrenzungen. Rex erzwingt Policies an der System-Call-Grenze im Host. Identity-Aware-Proxies und Service-Mesh-Policies setzen Policies an Netzwerk- und Request-Grenzen durch. Beide sind Runtime-Kontrollen auf unterschiedlichen Ebenen des Stacks. Die Netzwerkisolation von KI-Systemen – eine Lücke, die Mesh-Policies adressieren, Rex aber nicht – bleibt branchenweit ein Defizit. Mehrschichtige Durchsetzung ist die architektonische Antwort; jede einzelne Schicht als ausreichend zu betrachten, ist der Fehler. Das Kiteworks Private Data Network liefert die benötigte Datenebene für diesen Stack.
Weitere Ressourcen
- Blogbeitrag
Zero‑Trust-Strategien für erschwinglichen KI-Datenschutz - Blogbeitrag
Wie 77% der Unternehmen bei KI-Datensicherheit scheitern - eBook
AI Governance Gap: Warum 91% kleiner Unternehmen 2025 russisches Roulette mit Datensicherheit spielen - Blogbeitrag
Es gibt kein „–dangerously-skip-permissions“ für Ihre Daten - Blogbeitrag
Aufsichtsbehörden fragen nicht mehr, ob Sie eine KI-Policy haben. Sie wollen den Nachweis, dass sie funktioniert.