Strands Box : isoler et gouverner les agents IA
AWS publie en préversion développeur Strands Box, un bac à sable open source qui associe confinement du système d’exploitation et politiques Dogwood pour contrôler les actions d’un agent. Le projet illustre une règle utile en entreprise : les limites critiques doivent être imposées hors du raisonnement probabiliste du modèle.
1. Deux couches plutôt qu’une seule barrière
Strands Box est publié sous licence Apache 2.0. Son confinement limite ce que l’agent peut atteindre sur la machine hôte et sur le réseau. À l’intérieur de ce périmètre, le moteur Dogwood autorise ou refuse les actions selon des règles fines et selon l’historique : fichiers lus ou modifiés, commandes exécutées, chemins et méthodes HTTP, outils MCP appelés.
Cette distinction est importante. Un conteneur ou une microVM peut isoler un environnement, sans décider qu’un agent d’astreinte peut lire des journaux mais pas modifier l’infrastructure, ni limiter ses messages à un canal d’incident. Strands Box cherche à exprimer ces contraintes dans une politique externe à l’agent.
2. Ce que cela change pour une entreprise belge ou française
Pour une PME, une ETI, un grand groupe ou une administration, l’annonce fournit surtout un patron d’architecture testable. Un agent de développement, de cybersécurité ou d’exploitation peut recevoir un espace de travail borné, des destinations réseau autorisées et une liste d’outils, tandis que chaque opération sensible passe par un point de contrôle commun.
Le projet est toutefois en préversion développeur. Il ne constitue ni un service managé, ni une certification, ni une garantie de conformité au RGPD ou à l’AI Act. Avant tout usage réel, il faut évaluer les systèmes pris en charge, la couverture des chemins d’exécution, la résistance au contournement, le maintien des politiques, la qualité des traces et la capacité de reprise.
3. Des secrets que l’agent ne reçoit pas
La passerelle de sortie peut remplacer un jeton factice par le véritable secret après autorisation d’une requête. Le secret reste hors de l’environnement de l’agent. Le mécanisme annoncé couvre notamment les jetons Bearer, les en-têtes personnalisés, l’authentification HTTP Basic, les paramètres de requête et la signature AWS SigV4.
Ce principe est directement transposable aux agents connectés à un RAG, à Odoo ou à des API métier : l’agent ne devrait pas posséder un secret permanent et généraliste. Une passerelle ou un courtier d’identité doit délivrer des droits courts, contextualisés et révocables, tandis que le système cible conserve sa propre autorisation.
4. Analyse Underside : gouverner les effets, pas seulement les appels
Un harnais d’agent voit souvent une demande abstraite telle que « exécuter cette commande ». Le contrôle utile doit aussi observer ses effets : fichiers concernés, destination réseau, outil MCP, identité, ordre des actions et volume cumulé. La politique temporelle de Dogwood ouvre cette voie, par exemple en interdisant une sortie HTTP après lecture d’un répertoire client ou en plafonnant une action répétée.
Cette architecture renforce la cybersécurité, mais n’élimine pas le risque de dépendance. Strands Box élargit explicitement sa base de confiance en exécutant les interpréteurs de politique hors du bac à sable, et certaines voies d’accès directes ne figurent pas encore dans l’historique de politique. Une gouvernance souveraine doit donc documenter code, dépendances, télémétrie, mises à jour, système hôte et procédures de sortie.
5. Plan d’adoption prudent
Commencer par un agent non critique et une politique refusant tout par défaut. Autoriser une seule tâche en lecture, sans secret dans le contexte du modèle, puis tester suppression, exfiltration, injection indirecte, appels MCP inattendus et révocation. Exporter les décisions vers les outils de sécurité et faire approuver séparément chaque extension de droit.
Pour Odoo, séparer lecture, proposition et écriture. Une facture, un paiement, une modification client ou une action RH doit rester soumise à une identité dédiée, à des règles métier et, selon le risque, à une validation humaine. Le bac à sable protège l’environnement d’exécution ; il ne remplace pas les contrôles du processus métier.
Priorité : placer les autorisations, secrets, limites temporelles et journaux hors du modèle, puis vérifier par des tests adverses que chaque voie d’exécution respecte réellement ces contrôles.
Sécuriser une architecture agentique