Quand un agent IA peut déclencher des milliers d'actions sans que vous le sachiez
Un agent LLM branché sur vos outils internes peut, en quelques secondes, lire des fichiers, appeler des API, modifier des données ou supprimer des ressources. Ce n'est pas une hypothèse d'école : Docker a comptabilisé plus de 17 600 appels d'outils distincts dans ses analyses de comportements d'agents. À cette échelle, une seule instruction ambiguë ou une injection de prompt bien placée suffit à provoquer des dégâts difficilement réversibles.
Le vrai problème n'est pas la puissance des modèles. C'est l'absence d'isolation entre le raisonnement du modèle et l'exécution réelle sur votre infrastructure.
MCP et la surface d'attaque qu'il ouvre
Le protocole MCP (Model Context Protocol), standardisé par Anthropic, s'est imposé comme la façon la plus courante d'exposer des outils à un agent. Un serveur MCP publie des fonctions, l'agent les appelle, le résultat remonte dans le contexte. Simple, efficace... et structurellement risqué si l'exécution n'est pas cloisonnée.
Deux vecteurs concentrent l'essentiel des risques :
- L'injection de prompt indirecte : un contenu externe lu par l'agent (un fichier, une page web, un message) peut contenir des instructions malveillantes qui détournent le comportement du modèle. L'agent croit suivre vos consignes ; il exécute en réalité celles d'un attaquant.
- L'escalade de permissions : si un outil s'exécute avec les droits de l'utilisateur courant ou du processus parent, une erreur de logique dans l'agent suffit à accéder à des ressources qu'il n'aurait jamais dû toucher.
Ces deux problèmes partagent la même cause racine : l'exécution des outils se fait dans le même espace de confiance que le reste du système.
Docker Sandboxes : l'isolation comme primitive de sécurité
La réponse de Docker à ce constat est architecturale. Plutôt que de filtrer les appels après coup ou de restreindre les permissions par configuration, Docker Sandboxes isole chaque exécution d'outil dans un environnement éphémère et cloisonné.
Concrètement, cela signifie :
- Chaque appel MCP s'exécute dans un conteneur isolé, sans accès au système de fichiers de l'hôte ni aux variables d'environnement sensibles.
- L'environnement est détruit après l'exécution : aucune persistance non désirée, aucun effet de bord qui traverse les appels.
- Les secrets (clés API, credentials) sont injectés de façon contrôlée, sans passer dans le contexte du modèle.
Cette approche traite la sécurité comme une propriété du système, pas comme une règle à faire appliquer par le modèle lui-même. Demander à un LLM de ne pas faire certaines choses, c'est espérer qu'il ne sera jamais trompé. Isoler son environnement d'exécution, c'est rendre la question moins pertinente.
Ce que ça change concrètement pour une architecture Symfony/PHP
Si vous orchestrez des agents depuis une application Symfony, l'intégration de sandboxes d'exécution modifie la façon dont vous exposez vos outils MCP.
Plusieurs points méritent attention :
- Découplage entre le serveur MCP et votre application : votre serveur MCP n'a plus besoin de tourner dans le même processus que votre application Symfony. Il peut vivre dans un conteneur dédié, avec des permissions minimales.
- Gestion explicite des secrets : les credentials nécessaires à un outil sont passés à l'environnement d'exécution au moment du besoin, pas stockés dans le contexte de l'agent.
- Observabilité des appels : chaque exécution isolée peut être loguée, tracée et auditée indépendamment. Vous savez exactement ce qu'un agent a fait, dans quel ordre et avec quels paramètres.
- Résilience aux erreurs : un outil qui plante ou produit un comportement inattendu n'affecte pas les autres appels en cours. L'isolation contient le rayon d'impact.
L'effort d'intégration dépend de votre stack existante, mais le principe reste simple : si un outil peut modifier un état ou accéder à une ressource sensible, son exécution doit être isolée par défaut.
Sécurité agentique : une question d'architecture, pas de paramétrage
L'article original de Docker (disponible sur docker.com) pose le diagnostic avec netteté : la sécurité des agents est un problème de systèmes. On ne résout pas un problème structurel avec des garde-fous logiciels posés par-dessus une architecture mal pensée.
Cela rejoint un principe que les équipes sérieuses appliquent depuis longtemps en sécurité applicative : réduire la surface d'attaque en amont vaut toujours mieux que détecter les incidents en aval. Avec les agents IA, ce principe prend une dimension supplémentaire, parce que le comportement d'un modèle est probabiliste par nature. On ne peut pas garantir qu'il ne sera jamais manipulé. On peut garantir que, s'il l'est, les conséquences restent contenues.
Déployer des agents sans isolation, c'est choisir de faire confiance à un composant qui, par construction, ne peut pas être entièrement prévisible. Déployer des agents avec isolation, c'est accepter cette imprévisibilité tout en décidant qu'elle ne doit pas atteindre votre infrastructure.
