AWS publie Strands Box, un bac à sable open source qui bloque les agents selon ce qu'ils ont déjà fait

La particularité de Strands Box, d’AWS, est qu’il se souvient de ce qu’un agent a déjà fait et s’en sert pour bloquer la suite.

AWS a publié le 7 octobre en préversion pour développeurs Strands Box, un bac à sable open source qui limite ce que les agents d’IA (des programmes qui accomplissent seuls des tâches en plusieurs étapes pour l’utilisateur) peuvent faire, sous licence Apache 2.0 (une licence open source libre qui permet à chacun d’utiliser et de modifier le code). Un bac à sable est une boîte de sécurité qui enferme un agent et restreint ce qu’il peut faire. C’est une préversion, donc les environnements pris en charge restent limités, mais elle montre la direction que prennent les garde-fous pour les développeurs qui construisent des agents de code et de DevOps (l’automatisation du déploiement et de l’exploitation des logiciels).

Ce que fait l’outil

Isolation par le système d’exploitation et moteur de règles. Il isole l’agent au niveau du système d’exploitation et fait passer les commandes shell, scripts Python, requêtes réseau et appels d’outils MCP exécutés par l’agent par un moteur de règles (Dogwood). Ce moteur décide d’autoriser ou de bloquer chaque action. MCP est une norme qui permet à l’IA d’utiliser des outils externes.
Des règles qui se souviennent des actions passées. Les conteneurs et les microVM (de petits ordinateurs virtuels) enferment un agent mais ignorent ce qu’il a fait. Strands Box applique des règles fondées sur ce que l’agent a déjà fait.
Exemples de règles. Autoriser l’agent à publier sur Slack, mais seulement trois fois toutes les dix minutes. Bloquer les requêtes web sortantes dès que l’agent a lu un fichier d’un dossier de données clients.

Peut-on l’utiliser maintenant ?

Environnement pris en charge. La préversion ne prend en charge que les Mac Apple silicon sous macOS 15 ou version ultérieure.
Feuille de route. La prise en charge de Linux est prévue, sans date ; Windows n’est pas mentionné. Les cibles de déploiement comme Bedrock AgentCore, ECS et Kubernetes (un système open source qui gère de nombreux conteneurs) sont présentées comme des objectifs, sans calendrier fixé.
Framework. Certains articles le présentent avec l’écosystème Strands Agents, tandis qu’une analyse indique qu’il vise à fonctionner indépendamment de tout framework d’agents particulier.

Les limites sont claires aussi

AWS reconnaît elle-même ces lacunes dans son article.

Les chemins autorisés directement dans le fichier de configuration, par exemple pour l’outil de fichiers intégré d’un agent, sont protégés par le système d’exploitation mais n’apparaissent pas dans l’historique des actions des règles. Les interpréteurs shell et Python s’exécutent hors du bac à sable, ce qui élargit ce à quoi il faut faire confiance ; AWS parle d’un compromis délibéré.
L’exemple d’AWS commence par limiter ce que les identifiants peuvent faire avec un rôle IAM (gestion des droits) et ajoute les règles de Box par-dessus : il ne remplace pas IAM. Il vaut mieux le voir comme une contrainte utile que comme un confinement complet.

Affirmations que nous n’avons pas pu confirmer

Les formules « comportements d’agents hors de contrôle en environnement d’entreprise » et « supervision en temps réel » n’ont pas pu être confirmées dans les descriptions officielles. Ce qui est confirmé, ce sont l’isolation et les règles fondées sur les actions passées.
« Un framework de garde-fous pour agents est devenu officiel » est exagéré. Il s’agit pour l’instant d’une préversion open source pour développeurs, aux environnements limités.

Ce qui pourrait changer pour les développeurs

Ce qui suit est notre estimation et nos conseils à partir des informations disponibles.

Écrire « ne fais pas ça » dans un prompt ne suffit pas. Bloquer les actions au niveau du système, pour que l’agent ne puisse réellement pas les accomplir, pourrait devenir la norme.
Les règles peuvent tenir compte du nombre d’actions et de leur ordre. Les règles à état, qui tiennent compte de ce qui s’est déjà passé, comme les limites de débit ou le blocage du trafic sortant après la lecture de données sensibles, sont particulièrement utiles pour les agents de code et de DevOps.
À considérer comme expérimental pour l’instant. Une préversion réservée au Mac se prête mal au déploiement sur serveur. En production, gardez les protections existantes : IAM, journaux, validation humaine.
Vérifier les chemins de contournement. Partez du principe qu’il existe des chemins que l’outil ne peut pas bloquer (outils intégrés, interpréteurs de confiance), et ajoutez une étape de validation distincte pour les opérations importantes.

À suivre

Le calendrier de la prise en charge de Linux, l’éventuelle prise en charge de Windows et les cibles de déploiement cloud, la documentation et les exemples du langage de règles (Dogwood), et la manière dont les cas de contournement sont signalés et corrigés.