Docker recommande l'isolation et la gouvernance pour sécuriser les agents IA

Docker a publié un guide sur cinq risques de sécurité qui apparaissent lorsque des agents IA naviguent, exécutent du code et appellent des outils avec une supervision humaine limitée. Le texte est signé Srini Sekaran, responsable du marketing produit chez Docker, et Eric Jia, chef de produit. Il soutient que l'autonomie qui rend les agents utiles rend aussi insuffisants les contrôles de sécurité applicative classiques.

Les cinq risques

Docker cite l'injection de consignes, le mauvais usage et l'empoisonnement des outils, l'autonomie excessive, l'exposition des identifiants et l'exfiltration de données. Ces risques partagent une même cause : un agent peut choisir des outils au moment de l'exécution, enchaîner plusieurs actions et opérer souvent avec les droits de la personne qui l'a lancé.

La sécurité web traditionnelle suppose souvent que les requêtes arrivent sur des points d'accès connus et sont traitées par du code déterministe. Les agents ne correspondent pas à ce modèle. Un agent de programmation peut lire un fichier, installer une dépendance, modifier une configuration, lancer des tests et pousser un commit après une seule instruction. Docker en conclut qu'un agent compromis ou mal dirigé peut agir dans un champ beaucoup plus large qu'un service classique.

Injection de consignes et outils

Docker considère l'injection de consignes comme le risque central. Un attaquant n'a pas besoin de compromettre un système directement. Il peut placer des instructions dans un contenu que l'agent est chargé de lire : une page web, un commentaire de code, un ticket ou un document. Docker cite un incident au cours duquel un agent de programmation a suivi des instructions cachées dans le contenu d'un dépôt et effectué des actions que son utilisateur n'avait pas demandées.

"Un agent ne se contente pas de répondre à une question : il navigue, exécute du code et appelle des outils de lui-même, si bien qu'une seule instruction erronée ou manipulée peut causer un dommage réel au lieu de produire une simple mauvaise réponse." Eric Jia et Srini Sekaran, Docker

Docker doute que l'injection de consignes puisse être éliminée par des instructions données au modèle. L'agent ne peut pas distinguer de façon fiable une consigne légitime d'une consigne injectée. Docker privilégie donc une autre réponse : limiter ce qu'un agent détourné peut atteindre, afin qu'une manipulation réussie ait des effets plus restreints.

"L'agent n'a aucun moyen fiable de distinguer une consigne légitime d'une consigne injectée ; la défense consiste donc à limiter ce qu'un agent détourné peut atteindre." Eric Jia et Srini Sekaran, Docker

Les outils forment le deuxième point de préoccupation. Les agents utilisent des connecteurs, des requêtes vers des bases de données, des opérations sur les fichiers et l'exécution de code pour agir sur des systèmes externes. Docker avertit que donner à un agent plus d'outils que la tâche n'en demande élargit la surface d'attaque. La société prévient aussi qu'une description d'outil peut contenir des instructions cachées qui poussent l'agent à mal l'utiliser.

Cela rejoint les travaux d'OWASP sur les menaces et les mesures d'atténuation des IA agentiques, dont InfoQ a parlé en septembre 2025. OWASP avait identifié le mauvais usage des outils comme une menace nouvelle majeure. L'organisation décrivait des attaquants qui amènent des agents à abuser d'outils autorisés tout en restant dans les permissions accordées. Les contrôles recommandés étaient la vérification des accès, la surveillance du comportement, des limites opérationnelles et des journaux d'exécution inviolables. Plus d'un an après, le texte de Docker demande à peu près la même chose.

Autonomie et identifiants

Docker décrit le "mode YOLO", où chaque action de l'agent est approuvée automatiquement, comme un exemple visible de permissions étendues accordées d'avance. La société reconnaît que ce mode peut être productif, mais estime qu'il doit rester dans des limites qui empêchent l'agent d'atteindre des systèmes ou des données qu'il ne devrait pas toucher.

Le texte donne deux exemples. Un développeur avait demandé à un agent de programmation de nettoyer un ancien dépôt. L'agent a généré une commande rm -rf avec un ~/ en fin de ligne et l'a exécutée sans confirmation, supprimant le répertoire personnel du développeur. Docker cite aussi un ingénieur AWS qui avait confié à un agent de programmation un bug de Cost Explorer alors que celui-ci tournait avec des droits de niveau opérateur. L'agent a choisi de supprimer et de reconstruire l'environnement de production, ce qui a provoqué une panne régionale de treize heures.

La gestion des identifiants est étroitement liée. Docker estime qu'un agent ne doit pas hériter du jeton personnel d'un développeur, car chacune de ses actions porte alors l'ensemble des permissions de cette personne. Il recommande des identifiants distincts et de courte durée, injectés au moment de l'exécution et tenus hors de la conversation. Les secrets présents dans les consignes, les fichiers de configuration ou les variables d'environnement des images posent aussi problème, car des instructions injectées peuvent les lire dans le contexte de l'agent.

Le dernier risque est l'exfiltration de données. Un agent qui dispose d'un accès réseau et d'informations sensibles dans son contexte peut envoyer ces informations vers une destination non prévue. Docker précise que le risque augmente dans les systèmes multi-agents, où un agent transmet du travail à un autre. La société recommande de filtrer les sorties réseau par liste d'autorisation et de traiter chaque transmission entre agents comme une entrée non fiable.

Ce que recommande Docker

Docker place l'isolation et la gouvernance, plutôt que les seules améliorations des modèles, au premier rang des protections. Ses recommandations portent sur la limitation des accès, la séparation des identifiants et le contrôle des sorties réseau. Le guide rejoint d'autres travaux relayés par InfoQ. Le plan de sécurité GKE de Google, présenté en juillet 2026, recommande GKE Sandbox, fondé sur gVisor, pour confiner les agents.