3 min de lecture

Les agents IA ont besoin d'un sandbox, pas du bypass par défaut

AI-агентыконтейнеризацияsandboxкибербезопасность

Les incidents de suppression de partitions montrent que les agents IA ne doivent pas recevoir de larges droits par défaut. Une architecture sûre associe un sandbox isolé, le moindre privilège, un accès réseau limité et une validation humaine pour les actions destructrices. Le mode bypass ne convient qu'à un environnement strictement borné et réversible.

Le conteneur doit limiter les dégâts, pas créer une illusion

Après des incidents de suppression de partitions de disque, je ne débattrai pas des paramètres d'autorisation tant que l'agent peut voir l'hôte. La conclusion est simple : l'autonomie n'est acceptable que dans un environnement où une erreur ne peut pas entraîner la perte d'une partition, de secrets ou de la configuration système.

Le résumé de discussion à l'origine de cette note ne nomme ni l'organisation ni le document source. Au 6 septembre 2026, les dates des incidents ne sont pas non plus précisées ; j'aborde donc le sujet comme une analyse d'architecture, et non comme une annonce récente. Deux modes sont examinés : l'accès en ligne après validation humaine et les bypass permissions activées par défaut.

Le conteneur ne résout pas seul le problème. Une frontière sérieuse suppose une exécution sans root, la suppression des capacités Linux superflues, un système de fichiers en lecture seule et un unique répertoire de travail accessible en écriture. Le résumé cite également gVisor, microVM, Landlock, AppArmor et des mécanismes de niveau SELinux pour renforcer l'isolation.

Le réseau mérite la même méfiance que le disque. Les connexions sortantes ne devraient atteindre que les services autorisés, tandis que les identifiants devraient être émis pour une tâche précise, avec un périmètre étroit, puis révoqués. Des identités distinctes pour le modèle, le contrôleur de l'agent et les outils réduisent le rayon d'impact lorsqu'une couche est compromise.

Je vérifierais séparément le socket du runtime de conteneur, les répertoires parents, les secrets montés et toute possibilité d'étendre l'accès réseau via un outil disponible. C'est par ces failles qu'un conteneur cesse vite d'être un sandbox pour devenir une boîte décorative.

Le bypass n'est utile que pour des actions bornées à l'avance

Le bon équilibre ne se situe pas entre autonomie totale et fenêtres de confirmation permanentes. Un agent peut lire automatiquement des fichiers, modifier des données dans son répertoire de travail et exécuter des commandes réversibles lorsque ces opérations sont physiquement incapables d'affecter l'hôte.

La suppression de fichiers, la modification de partitions, l'accès aux secrets, les réglages système et les sorties hors de la liste réseau autorisée doivent passer par un moteur de politiques et une validation humaine. L'autorisation doit viser une action précise, pas toute la session : l'accord pour une commande ne doit pas devenir un laissez-passer permanent.

Le coût du contrôle humain est évident : l'agent travaille plus lentement et s'arrête plus souvent. Mais un bypass large sans isolation stricte échange simplement la commodité contre un rayon de défaillance accru. L'autonomie ne commence pas avec un bouton d'autorisation automatique, mais avec la preuve que l'agent n'a presque rien à casser.

Nous avons précédemment étudié Pydantic Monty, un interpréteur Python sécurisé qui exécute du code généré par un LLM sans conteneurs. Cette approche aide à comparer l'isolation de l'environnement aux risques liés au contournement des autorisations des agents IA.