Quand l'agent IA touche à votre machine, qui contrôle vraiment ce qui se passe ?
Les agents IA capables d'exécuter du code sont devenus une réalité opérationnelle. Ils génèrent des scripts, lancent des commandes, accèdent à des fichiers. Mais entre l'enthousiasme pour l'automatisation et la rigueur qu'exige la production, il y a souvent un angle mort : la surface d'attaque laissée ouverte sur la machine hôte. C'est précisément ce problème que Docker adresse avec ses Sandboxes et le protocole MCP (Model Context Protocol), deux briques qui, combinées, permettent enfin de donner les mains libres à un agent sans lui remettre les clés de la maison.
Cet article s'appuie sur une analyse publiée par Docker à partir de retours de CISOs sur la gouvernance des agents IA en entreprise.
Le vrai problème : l'agent IA n'est pas (encore) digne de confiance
Un agent IA agentique — c'est-à-dire capable d'enchaîner des actions de façon autonome — n'est pas un simple chatbot. Il peut appeler des APIs, écrire des fichiers, exécuter des commandes shell, interagir avec des bases de données. En théorie, c'est exactement ce qu'on lui demande. En pratique, cela soulève trois risques concrets :
- L'exécution de code non vérifié : un agent peut générer du code malformé, voire malveillant par injection de prompt, et l'exécuter directement sur le système hôte.
- L'escalade de privilèges : si l'agent tourne avec les droits de l'utilisateur courant, il hérite de tous ses accès — y compris aux secrets, aux volumes montés, aux sockets Docker.
- Le mouvement latéral : une compromission de l'agent peut devenir une compromission du réseau interne si aucune isolation réseau n'est en place.
Les CISOs interrogés par Docker pointent tous le même constat : les équipes adoptent les agents IA plus vite que les politiques de sécurité ne peuvent suivre. Le résultat ? Du shadow AI qui court en production sans audit trail, sans limite de ressources, sans rollback possible.
Docker Sandboxes : l'isolation comme posture par défaut
La réponse technique de Docker aux agents IA, ce sont les Docker Sandboxes : des environnements conteneurisés, éphémères et isolés, spécialement conçus pour que les agents exécutent du code sans jamais toucher la machine hôte.
Concrètement, chaque exécution de code par un agent se passe dans un conteneur jetable avec :
- Pas d'accès au système de fichiers hôte (sauf montages explicitement définis)
- Réseau isolé par défaut, configurable selon le besoin
- Ressources plafonnées (CPU, mémoire, temps d'exécution)
- Cycle de vie court : le conteneur meurt à la fin de la tâche, sans laisser de traces persistantes non voulues
Pour une équipe PHP/Symfony, cela change la donne sur des cas concrets : générer un rapport PDF avec un agent, faire tourner un script de migration de données, ou encore laisser un agent tester des requêtes SQL complexes — tout cela peut désormais se faire dans un bac à sable, sans risquer de corrompre l'environnement de développement ou de staging.
L'analogie est directe avec ce que open_basedir ou disable_functions apportent en PHP pour restreindre l'interpréteur : le principe de moindre privilège, appliqué à l'agent.
MCP : le protocole qui structure les permissions de l'agent
L'isolation conteneur règle le problème de l'exécution. Mais il reste une question : comment l'agent sait-il à quoi il a le droit d'accéder, et comment le système le contrôle-t-il ?
C'est là qu'intervient le Model Context Protocol (MCP), un standard ouvert (initialement proposé par Anthropic, maintenant adopté plus largement) qui définit comment un agent IA peut interagir avec des outils externes de façon structurée et auditable.
Avec MCP, chaque outil exposé à l'agent est décrit explicitement : nom, paramètres, permissions. L'agent ne peut pas "inventer" un accès — il ne peut qu'utiliser ce qu'on lui a explicitement fourni via le protocole. Pour la gouvernance, c'est une rupture majeure :
- Contrôle déclaratif : on sait exactement quels outils l'agent peut utiliser, car ils sont listés dans la configuration MCP.
- Audit trail natif : chaque appel d'outil passe par le protocole, ce qui permet de loguer et monitorer toutes les actions de l'agent.
- Révocation granulaire : retirer un outil de la configuration MCP suffit à couper l'accès, sans modifier le code de l'agent.
Combinés, Docker Sandboxes et MCP forment une architecture en deux couches : MCP structure ce que l'agent peut demander, les Sandboxes contraignent ce que le code peut faire une fois lancé.
Ce que ça change pour les équipes de développement
Du point de vue d'une équipe web PHP/Symfony qui intègre des agents IA dans ses workflows, ces deux briques apportent des garanties concrètes :
En développement, un agent de pair-programming peut générer et tester du code Symfony (entités Doctrine, commandes Console, controllers) dans un Sandbox sans risquer de casser la base de données locale ou d'écraser des fichiers de configuration.
En CI/CD, un agent de revue de code ou de génération de tests peut tourner dans un conteneur éphémère, avec accès limité au dépôt via MCP, sans jamais avoir accès aux secrets de déploiement ou aux credentials de production.
En production, pour des cas comme l'exécution de scripts de traitement de données à la demande, le Sandbox garantit l'isolation réseau et la limitation des ressources — deux prérequis que les CISOs identifient comme non-négociables avant tout déploiement d'agent IA.
La gouvernance n'est plus une couche qu'on ajoute après coup : elle est architecturale, inscrite dans la façon dont l'agent est déployé.
Conclusion : l'isolation n'est pas un frein, c'est un accélérateur
L'un des freins les plus fréquents à l'adoption des agents IA en entreprise, ce n'est pas le manque d'enthousiasme — c'est l'absence de cadre de sécurité crédible. Les CISOs ne s'opposent pas à l'IA agentique ; ils s'opposent au flou.
Docker Sandboxes et MCP apportent précisément ce cadre : isolation technique éprouvée, permissions déclaratives, auditabilité native. Pour les équipes qui développent en PHP/Symfony, c'est une combinaison directement opérationnelle, compatible avec les workflows conteneurisés existants.
L'agent IA qui exécute du code n'est plus une boîte noire incontrôlable — à condition de lui construire une boîte qui, elle, l'est.
