Docker vient d’annoncer Docker Sandboxes, un environnement léger et conteneurisé conçu pour laisser les agents de code travailler sur vos fichiers projet sans exposer l’ensemble de votre machine. C’est une addition bien pensée à l’écosystème, et un signe clair que les outils pour agents gagnent en maturité.
Le sandboxing répond à un vrai problème : les agents ont besoin de marge pour opérer. Ils installent des packages, exécutent du code, modifient des fichiers. Leur donner cette liberté sans mettre votre laptop en danger, tout le monde y gagne en sérénité.
Mais l’isolation d’environnement ne couvre qu’une partie du risque. Un sandbox contrôle où le code s’exécute et quels fichiers locaux un agent peut modifier. Il ne contrôle pas ce que l’agent est autorisé à faire sur les systèmes, ni avec quelle assurance il interprète la tâche qu’on lui a confiée.
Et c’est là que se concentrent la plupart des problèmes concrets.
Ce que les Docker Sandboxes règlent bien
L’approche de Docker correspond parfaitement à ce dont les développeurs ont besoin aujourd’hui :
- Isolation d’environnement
- Cloisonnement du système de fichiers
- Espaces de travail reproductibles
- Protection contre du code local non fiable ou incontrôlable, y compris les actions destructrices sur le système de fichiers
- Compatibilité avec les agents de code modernes comme Claude Code et Gemini CLI
Pour les workflows locaux, cela réduit drastiquement une catégorie de risques sans ralentir personne. C’est probablement la façon dont les agents de code vont tourner par défaut sur les postes de travail.
Mais même dans un conteneur parfait, un agent peut tout à fait faire le mauvais choix à haut niveau.
Où se produisent vraiment la plupart des défaillances d’agents
Dans le secteur, les équipes qui expérimentent avec des agents de code observent un schéma récurrent :
L’agent se comporte correctement, mais en dehors de l’intention de la demande.
Exemples courants :
- Fusionner une PR qui n’était destinée qu’à une revue
- Réécrire des fichiers de configuration qu’il juge obsolètes
- Supprimer des données de test qui « semblent inutilisées »
- Refactoriser des fichiers d’une façon qui passe les tests mais modifie subtilement le comportement
- Nettoyer des répertoires de façon plus agressive que prévu
- Traiter du contenu ambigu (logs, commentaires, e-mails) comme des instructions
- Émettre des commandes destructrices contre des bases de données en production faute de contexte
Aucun exploit. Aucune évasion de sandbox. Aucune malveillance.
Juste des capacités, de la confiance et des permissions plus larges que ce que la tâche exigeait.
Ces échecs ne sont pas causés par une exécution de code non sécurisée (le sandboxing d’exécution est une fondation nécessaire, et il remplit bien son rôle). Ils surviennent parce que le sandboxing seul n’isole généralement que l’exécution de l’agent (le processus et le système de fichiers dans lequel il tourne), sans contraindre les capacités que l’agent est autorisé à utiliser sur les systèmes. Le sandboxing limite où l’agent peut exécuter du code et quelles ressources locales il peut atteindre. Il ne contraint pas :
- les permissions que détient l’agent
- les outils ou APIs qu’il peut appeler
- les actions que ces outils sont autorisés à effectuer
- jusqu’où l’agent interprète des instructions ambiguës
Ces contrôles se situent au-dessus de la frontière du sandbox, au niveau des décisions, des permissions et des politiques.
Un sandbox peut empêcher des actions non intentionnelles d’affecter votre machine. Il ne peut pas déterminer si l’action elle-même était appropriée.
C’est une autre forme de sécurité.
Une fois cette frontière clairement tracée, la forme d’une architecture d’agent plus sûre devient bien plus évidente.
Une approche plus complète de la sécurité des agents
Voici le modèle en couches sur lequel de nombreuses équipes ont convergé en intégrant des agents dans de vrais workflows. Ce modèle décrit des couches complémentaires qui fonctionnent ensemble. En pratique, les équipes en utilisent souvent plusieurs simultanément, sandboxing inclus, pour atteindre une sécurité réelle.
1. Accès avec moindre privilège
Les agents ne devraient jamais hériter de l’ensemble des capacités d’un humain.
Le principe de limitation par défaut prévient la majorité des résultats indésirables :
- Lecture vs. écriture
- Accès limité à des répertoires ou dépôts spécifiques (appliqué au niveau du système de fichiers ou de l’autorisation)
- Revue vs. fusion
- Commentaire vs. commit
Si un agent n’a pas la permission d’effectuer une action sensible, il ne peut pas l’effectuer par accident.
2. Authentification & autorisation appropriées
L’isolation d’environnement protège la machine. Les permissions protègent les systèmes.
Les patterns les plus solides qui émergent :
- OAuth limité à l’utilisateur avec des scopes précis et minimaux
- Autorisation juste-à-temps plutôt que tokens globaux
- Zéro exposition des credentials au modèle
- Contrôle fin au niveau de l’outil ou de l’action
Cela empêche les actions « confiantes mais non intentionnelles » de dépasser leur périmètre approprié.
3. Sandboxing d’exécution (le rôle de Docker)
Cette couche gère :
- l’exécution de code non fiable
- les dépendances locales
- l’installation de packages
- le confinement du runtime
- les limites de ressources
La solution de Docker s’adapte parfaitement à cette couche.
4. Audit et traçabilité
Quand quelque chose d’inattendu se produit, les équipes ont besoin de voir :
- ce que l’agent a perçu
- ce qu’il a compris
- ce qu’il a décidé
- ce qu’il a exécuté
- ce que le système a autorisé
Ce n’est pas uniquement une question de sécurité : c’est aussi pour le débogage et la confiance.
5. Validation humaine pour les actions à fort impact
Les agents rédigent. Les agents proposent. Les agents préparent.
Mais les fusions, suppressions, changements de permissions et autres opérations irréversibles gagnent encore à passer par une étape de validation humaine.
Voyez ça moins comme une restriction que comme un garde-fou autour de l’intention.
Comment ces couches fonctionnent ensemble
- Sandboxing protège l’environnement
- Moindre privilège protège le système
- Auth protège l’identité et les accès
- Auditabilité protège la compréhension
- Revue humaine protège l’intention
Quand ces couches s’alignent, les agents deviennent nettement plus sûrs. Non pas parce que les modèles s’améliorent, mais parce que l’architecture évolue.
Un avenir collaboratif pour la sécurité des agents
L’annonce de Docker est un signal positif. Elle reflète un glissement plus large vers une approche de la sécurité des agents pensée comme architecture, et non comme ajout tardif.
Le sandboxing d’exécution est une fondation importante. Mais à mesure que les agents dépassent les workflows locaux mono-utilisateur, les équipes ont de plus en plus besoin de contrôles qui se situent au-dessus de la couche d’exécution : autorisation limitée à l’utilisateur, permissions au niveau de l’outil, auditabilité et visibilité centralisée sur le comportement des agents. Une approche qui gagne du terrain consiste à centraliser ces problématiques dans un plan de contrôle dédié, plutôt que de les reconstruire dans chaque agent ou outil. C’est le modèle qui sous-tend Arcade.devun runtime MCP centré sur l’autorisation qui gère les permissions, la gouvernance et la visibilité sur les agents multi-utilisateurs, tout en restant indépendant de l’endroit et de la façon dont ces agents s’exécutent.
Le sandboxing sécurise l’exécution. L’autorisation et la gouvernance centralisées aident à maintenir le comportement des agents aligné à mesure que les systèmes évoluent.
