AWS Rex publie en open source la couche d’exécution de la sécurité de l’IA agentique
Le 4 mai 2026, AWS a publié Introducing Trusted Remote Execution: Policy-Enforced Scripts for AI Agents and Humans, en rendant Rex open source sous licence Apache 2.0. L’architecture est simple : les scripts sont écrits en Rhai, un langage embarqué léger sans accès natif au système d’exploitation. La seule façon pour un script d’atteindre l’hôte passe par un SDK dédié. Chaque opération est autorisée selon une politique Cedar avant que l’appel système ne soit permis. Si la politique refuse l’action, le script reçoit une ACCESS_DENIED_EXCEPTION et l’opération n’atteint jamais le noyau.
AWS admet, dans son code de production, ce que la communauté de la recherche en sécurité affirme depuis deux ans : la revue de code, les workflows d’approbation et les commandes sur liste blanche ne suffisent pas à encadrer le code généré à l’exécution par un système d’IA. Les filets de sécurité traditionnels ne fonctionnent plus quand l’agent est lui-même l’auteur.
5 points clés à retenir
1. AWS a introduit l’application de politiques à l’exécution comme nouvelle catégorie.
Trusted Remote Execution (Rex) contrôle chaque opération système tentée par un script généré par IA, en la confrontant à une politique Cedar définie par le propriétaire de l’hôte — et non par l’agent. C’est la première reconnaissance majeure, soutenue par un hyperscaler, que la sécurité de l’IA agentique au niveau de l’exécution ne peut pas être confiée à l’agent lui-même. Quand AWS livre une infrastructure de production en partant du principe que l’injection de prompt ne sera pas résolue, le message aux architectes d’entreprise est clair : concevez comme si l’agent allait mal se comporter.
2. Le modèle de menace est explicite et dérangeant.
AWS cite nommément le code halluciné, l’injection de prompt et l’interprétation trop zélée des tâches comme modes d’échec spécifiques que Rex vise à contenir. OpenAI a déclaré que l’injection de prompt « ne sera probablement jamais totalement résolue ». Anthropic reconnaît que ce problème reste loin d’être réglé, « en particulier à mesure que les modèles réalisent davantage d’actions dans le monde réel ». Rex est livré sur la base de ces constats — votre architecture de gouvernance IA doit donc en tenir compte.
3. Rex contraint l’hôte, pas l’agent.
La plupart des bacs à sable pour agents cherchent à limiter ce que le modèle produit. Rex inverse cette logique : peu importe ce que l’agent génère, l’appel système ne peut dépasser ce que la politique autorise. Ce renversement architectural — déplacer le périmètre de contrôle vers ce que l’agent peut faire sur l’hôte — n’est pas un simple ajustement. C’est un changement fondamental sur l’emplacement de la confiance. Celle-ci passe des sorties de l’agent au moteur de politique de l’hôte.
4. Le contrôle à l’exécution est nécessaire, mais pas suffisant.
Les politiques Cedar sur les appels système ne peuvent pas indiquer à un agent quel document il n’aurait pas dû demander, quels champs respectent le principe de minimisation, ni si une récupération franchit une frontière juridique signalée comme hors périmètre par la classification des données. Ce sont les contrôles exigés par l’article 5 du RGPD, la norme du minimum nécessaire de la HIPAA et les familles de contrôle d’accès du niveau 2 du CMMC. Rex ne répond pas à ces exigences.
5. Le niveau défendable en audit se situe sous l’exécution.
Les régulateurs, auditeurs et plaignants demanderont des preuves sur qui a autorisé quel accès aux données. Cette preuve doit se trouver là où résident les données — dans des journaux d’audit infalsifiables retraçant chaque interaction IA avec du contenu réglementé. Une politique autorisant une lecture système est adaptée au niveau exécution. Elle ne l’est pas au niveau des données, et il s’agit de deux instruments distincts.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Ce qu’AWS admet sur l’IA agentique
Trois concessions architecturales dans l’annonce AWS sont aussi importantes que le code.
La première concerne le modèle de menace. Le code halluciné, l’injection de prompt et l’interprétation trop zélée des tâches sont explicitement nommés — non comme des cas extrêmes théoriques, mais comme des modes d’échec précis que Rex vise à contenir. Lorsqu’un hyperscaler livre une infrastructure en partant du principe que ces problèmes ne seront pas résolus, les architectes d’entreprise doivent adapter leur conception en conséquence.
La deuxième porte sur le renversement architectural. Rex déplace le périmètre de contrôle vers ce que l’agent peut faire sur l’hôte, plutôt que d’essayer de limiter les sorties de l’agent. Ce choix est précis : contraindre l’agent suppose que ses sorties peuvent être limitées de façon fiable. Déplacer le contrôle sur l’hôte suppose que ces limites sont incertaines et place l’application de la politique là où le système exécute réellement. Il s’agit d’une décision d’architecture de confiance, pas d’une simple fonctionnalité.
La troisième concerne le modèle de politique. Cedar — open source par AWS depuis mai 2023 et désormais projet CNCF Sandbox — prend en charge RBAC et ABAC. Le propriétaire de l’hôte, et non l’agent, définit la politique. Le script et la politique sont versionnés séparément. C’est le principe du policy-as-code appliqué à la couche des appels système — le bon niveau pour ce modèle, et aussi le seul que Rex gère.
Pourquoi le contrôle à l’exécution est nécessaire
Rex répond à un vrai problème. La plupart des environnements d’exécution de scripts accordent aux scripts les mêmes autorisations que le contexte d’exécution — un script censé lire un fichier journal peut tout aussi bien le supprimer. Quand ce script est généré à l’exécution par un agent IA, les contrôles de revue traditionnels n’ont jamais l’occasion d’intervenir. Un agent malveillant dans un tel environnement n’est qu’à une mauvaise interprétation de tâche d’un incident en production.
Le rapport prévisionnel 2026 de Kiteworks quantifie ce risque. 63 % des organisations ne peuvent pas limiter l’usage des agents IA à leur finalité. 60 % ne peuvent pas mettre fin rapidement à un agent malveillant. 55 % ne peuvent pas isoler les systèmes IA du reste du réseau. 54 % ne peuvent pas valider les entrées IA. L’application de politiques à l’exécution façon Rex comble réellement les deux premiers de ces écarts. Il existe aussi un enjeu réglementaire : les organisations soumises à la pression de l’AI Act européen construisent l’infrastructure d’exécution, d’identité et de politique que représente Rex plus vite que celles opérant hors de ce périmètre. L’écosystème de conseil comble rapidement cet écart dans toutes les juridictions.
Pourquoi le contrôle à l’exécution ne suffit pas
Rex est un contrôle d’exécution. Il gère les appels système. Il ne peut pas indiquer à un agent quel document il n’aurait pas dû demander. Il ne peut pas garantir qu’un enregistrement retourné ne contient que les champs que l’utilisateur humain est autorisé à voir. Il ne peut pas vérifier si une récupération franchit une frontière juridique signalée comme hors périmètre par la classification des données.
Ce ne sont pas des cas extrêmes théoriques. Ce sont les contrôles exigés par l’article 5 du RGPD : limitation de la finalité, minimisation des données, limitation de la conservation, responsabilité. C’est ce qu’exige la norme du minimum nécessaire de la HIPAA. C’est ce que supposent les familles de contrôle d’accès du niveau 2 du CMMC. C’est ce que le rapport conjoint CISA, NSA et Five Eyes sur l’IA agentique cite explicitement dans ses catégories de risques responsabilité et privilèges.
Une politique autorisant file_system::Action::"read" sur /var/data/customer-records.csv est adaptée au niveau exécution. Elle ne l’est pas au niveau des données. Ce niveau doit poser d’autres questions : cette lecture est-elle réalisée pour un utilisateur disposant des autorisations adéquates ? Le demandeur agit-il dans le cadre d’un mandat qui l’autorise ? Les enregistrements sont-ils strictement nécessaires à la tâche ? Certains font-ils l’objet d’une demande de suppression non encore appliquée ? L’accès est-il journalisé avec assez de détails pour reconstituer qui a autorisé quoi trois ans après la mise hors service du modèle ? Rex ne répond pas à ces questions.
L’architecture qui fonctionne vraiment
Le modèle efficace est en couches. Les contrôles d’exécution comme Rex définissent ce que l’hôte autorise. Les contrôles d’identité définissent pour qui agit l’agent. Les contrôles au niveau des données — contrôle d’accès basé sur les attributs, évalué selon la classification, la juridiction et le consentement — définissent quelles données l’agent peut manipuler. Chaque couche cible un mode d’échec différent, et aucune ne suffit seule.
Le serveur Kiteworks Secure MCP et l’AI Data Gateway mettent en œuvre la couche données de cette architecture : chaque opération IA est authentifiée via OAuth 2.0, évaluée selon une politique ABAC dans le moteur de politique de données Kiteworks, chiffrée avec une cryptographie validée FIPS 140-3, et journalisée dans une piste d’audit infalsifiable alimentant l’infrastructure SIEM existante. Le Réseau de données privé Kiteworks étend cette gouvernance à la messagerie électronique, au partage de fichiers, au MFT, au SFTP, aux formulaires web et aux API sous un moteur de politique unique et un journal d’audit consolidé.
AWS vient de livrer une infrastructure robuste pour la couche exécution. Les couches identité et données restent à construire — et le rapport prévisionnel 2026 de Kiteworks confirme que seuls 43 % des organisations disposent d’une AI Data Gateway centralisée.
Ce que les équipes sécurité et conformité doivent retenir
Premièrement, prenez l’annonce AWS au sérieux comme signal. Lorsqu’un hyperscaler rend open source un contrôle d’exécution qui vérifie chaque appel système selon une politique indépendante de l’agent, l’application de politiques à l’exécution n’est plus optionnelle dans les déploiements IA sérieux. Rex comble un vide réel au niveau exécution que la plupart des organisations laissaient ouvert.
Deuxièmement, ne confondez pas contrôle à l’exécution et gouvernance des données. Rex définit ce qu’un agent peut faire sur un hôte. Il ne dit rien sur les données auxquelles l’agent peut accéder. Ajouter un contrôle à l’exécution sans gouvernance au niveau des données ne comble pas le vide d’audit — cela ne fait que documenter une couche en laissant l’autre exposée.
Troisièmement, concevez explicitement l’architecture en couches. Cartographiez les contrôles d’exécution (Rex), d’identité (OAuth, identifiants à durée de vie courte) et de données (ABAC, classification, juridiction, consentement) selon les modes d’échec que chacun cible. Chaque couche pose des questions différentes ; chacune est nécessaire pour obtenir une réponse complète.
Quatrièmement, traitez la gestion de versions des politiques comme une preuve d’audit. La séparation entre politique et code de Cedar produit des artefacts inspectables par les auditeurs. Associez les artefacts d’exécution de Rex à des journaux d’audit infalsifiables côté données pour constituer un dossier de preuves complet — le manque de visibilité sur ce qui a été exécuté et sur quelles données ont été manipulées est à l’origine de la plupart des constats d’audit.
Cinquièmement, utilisez le rapport conjoint Five Eyes comme test architectural. Appliquez les cinq catégories de risques du rapport CISA « Adoption prudente des services IA agentiques » — privilèges, conception et configuration, comportement, structure, responsabilité — à votre déploiement IA actuel. Rex couvre en partie les catégories privilèges et comportement. Les risques structurels et de responsabilité exigent une gouvernance au niveau des données qu’aucun contrôle à l’exécution ne peut fournir seul.
Pour en savoir plus sur la gouvernance des données sensibles tout en optimisant les agents IA, réservez votre démo sans attendre !
Foire aux questions
Rex gère l’application de politiques sur les appels système au niveau du script — là où un script généré par un agent est contrôlé par une politique Cedar avant toute lecture, écriture ou ouverture du noyau. Il ne remplace pas les contrôles d’identité, la segmentation réseau ou la gouvernance au niveau des données. Seules 43 % des organisations disposent d’une AI Data Gateway centralisée selon le rapport prévisionnel 2026 de Kiteworks. Ajouter Rex sans cette couche données comble un vide mais en laisse un plus large ouvert.
Le modèle policy-as-code de Cedar produit des artefacts versionnés qui répondent aux exigences SOC 2 CC6 sur le contrôle d’accès et ISO 27001 A.5/A.8 sur la gestion des accès — mais ne constituent pas une preuve suffisante d’autorisation au niveau des données. Associez la piste d’audit d’exécution de Rex à l’application ABAC côté données et à des journaux infalsifiables pour constituer un dossier de preuves complet. Les auditeurs demandent de plus en plus des preuves de confinement — la capacité à isoler et arrêter rapidement un agent malveillant.
Non. La norme du minimum nécessaire de la HIPAA exige des contrôles sur les données auxquelles l’agent peut accéder pour le compte d’un utilisateur autorisé — et pas seulement sur les appels système permis au script. La limitation de la finalité est un contrôle sémantique sur les données. 63 % des organisations ne peuvent pas l’appliquer aux agents IA selon le rapport prévisionnel 2026 de Kiteworks. Les contrôles à l’exécution et l’application ABAC côté données sont complémentaires ; aucun ne remplace l’autre.
Rex couvre partiellement deux des cinq catégories de risques du rapport CISA : les risques de privilèges (application du principe du moindre privilège sur les opérations système) et les risques de comportement (confinement du code halluciné ou injecté). Il ne traite pas les risques structurels ni de responsabilité. La catégorie responsabilité — la plus scrutée par les auditeurs et régulateurs — nécessite une piste d’audit au niveau des données qu’un contrôle à l’exécution ne peut produire seul.
Il existe un recouvrement partiel et une séparation claire. Rex applique la politique à la frontière des appels système à l’intérieur d’un hôte. Les proxies aware de l’identité et les politiques de service mesh appliquent la politique aux frontières réseau et requête. Les deux sont des contrôles à l’exécution à différents niveaux de la pile. L’isolation réseau des systèmes IA — un vide que les politiques mesh comblent mais pas Rex — reste une faiblesse sectorielle. L’application en couches est la bonne réponse architecturale ; considérer une seule couche comme suffisante est une erreur. Le Réseau de données privé Kiteworks fournit la composante données dont cette pile a besoin.
Ressources complémentaires
- Article de blog
Stratégies Zero‑Trust pour une protection abordable de la vie privée avec l’IA - Article de blog
Comment 77 % des organisations échouent à sécuriser les données IA - eBook
AI Governance Gap : Pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.