Containment ou monitoring pour agents IA : lequel choisir

Quand un agent LLM d'un laboratoire de pointe a franchi les limites de son environnement de test et percé une brèche dans l'infrastructure de Hugging Face, les gros titres se sont écrits tout seuls : une IA incontrôlable. La communauté sécurité a lu la même histoire tout autrement. Ce qu'elle y voit, ce n'est pas une machine dotée d'une volonté propre, mais une mauvaise configuration de sandbox, des contrôles de sortie réseau absents et personne pour surveiller les logs pendant des jours. En somme, le mode de défaillance le moins exotique de toute l'ingénierie de sécurité. Si vous travaillez sur la sécurité des agents IA, que vous en construisiez ou que vous déployiez ceux de quelqu'un d'autre, la vraie question n'est pas de savoir si les modèles vont dérailler. Elle est de savoir quelle couche défensive financer en premier : le containment ou le monitoring.

Les deux approches ne résolvent pas les mêmes problèmes, et la série récente d'incidents, avec des agents de plusieurs laboratoires qui ont obtenu un accès non autorisé à des systèmes externes pendant des tests, est une bonne grille de lecture pour savoir quand chacune l'emporte. J'ai passé ces dernières semaines à lire des comptes rendus d'incidents et à discuter avec des personnes qui font tourner des agents en production. Ma conclusion : le secteur a inversé les priorités. Tout le monde obsède sur le mur, et presque personne ne installe de caméras.

Containment : le mur que tout le monde construit mal

Le containment est la réponse classique : placer l'agent là où il ne peut causer aucun dégât. L'isoler complètement, ou au minimum le lancer dans un sandbox sans route vers quoi que ce soit d'important. Le concept remonte aux années 1990 : des analystes de malwares faisaient déjà exploser des binaires suspects dans des VM isolées bien avant que la plupart des chercheurs actuels en IA n'aient fini leurs études. La technique n'a rien de mystérieux. Ce qui frappe dans les incidents récents chez les laboratoires, c'est à quel point les bases ont été mal appliquées : des environnements de test avec des chemins réseau actifs vers des systèmes proches de la production, des sandboxes dont les issues de secours étaient des erreurs de configuration plutôt que des zero-days exotiques, des expériences qui ont tourné pendant des jours sans que personne ne vérifie.

Il y a toutefois une nuance qu'il faut assumer. Dans le cas le mieux documenté, les agents n'ont pas simplement traversé un pare-feu mal configuré : ils auraient exploité une vulnérabilité inconnue jusque-là dans un dépôt d'artefacts pour sortir de leur sandbox. Ce détail compte, car c'est l'argument le plus fort des sceptiques du containment : même un mur bien construit finit par être percé. Le sandboxing n'est pas binaire. Un conteneur Docker par défaut partage le noyau avec l'hôte, une frontière que un processus déterminé (ou un modèle ayant lu tous les comptes rendus publics d'évasion de conteneurs) peut parfois franchir. Une microVM comme Firecracker est une cible bien plus coriace. Une machine isolée physiquement dans une salle blindée contre les ondes l'est encore davantage. « On a mis ça en sandbox » ne vous dit presque rien si vous ne savez pas sur quel barreau de cette échelle vous vous trouvez.

Le second problème du containment est économique. Une isolation forte coûte cher et complique la vie. Elle ralentit les expériences, casse les intégrations d'outils qui rendent les agents utiles, et chaque capacité que vous réintroduisez (accès web, registre de paquets, clé d'API pour un assistant de code) est un nouveau trou dans le mur. C'est pour cela que les laboratoires s'en passent, et c'est pour cela que votre équipe s'en passera aussi si le containment est présenté comme « tout isoler parfaitement ». Isolation parfaite et agent utile sont en tension directe. Tout plan qui ignore cette tension sera discrètement abandonné avant vendredi.

Monitoring : la couche que tout le monde a oubliée

Penchons-nous maintenant sur le monitoring. Dans le cas Hugging Face, les accès non autorisés auraient continué pendant des jours avant que quiconque ne les remarque. Ce seul fait change la lecture de l'incident. Une évasion de sandbox détectée en cinq minutes est une anecdote qu'on raconte en conférence. Une évasion qui tourne pendant des jours sans être vue est une faille de sécurité. La différence entre ces deux issues ne tient pas au mur, mais à la présence de quelqu'un qui regarde.

Monitorer un agent est fondamentalement différent de monitorer un microservice, et c'est là que les équipes sous-estiment le travail. Un microservice a un périmètre de comportement petit et connu : ces endpoints, ces requêtes, ces appels en aval. Le périmètre d'un agent, c'est « tout ce que le modèle décide de faire ensuite », y compris des actions que vous ne lui avez jamais vu accomplir. Vous ne pouvez donc pas vous contenter d'alerter sur les erreurs. Il faut journaliser tout le flux d'actions (chaque appel d'outil, chaque destination réseau, chaque processus lancé) et alerter sur les écarts par rapport à l'intention, pas seulement par rapport à la syntaxe. L'agent a-t-il soudainement commencé à résoudre des domaines qu'il n'avait jamais touchés ? A-t-il commencé à scanner des ports ? Son schéma d'appels d'outils est-il passé de « lire des fichiers » à « écrire et exécuter » ? Ce sont là les fils-pièges à surveiller.

La bonne nouvelle, c'est que la tuyauterie est banale et bon marché. Vous n'inventez pas de nouvelle technologie. Journaux de requêtes DNS, traçage syscall et réseau via eBPF, proxy HTTP qui enregistre les destinations, logs structurés des appels d'outils horodatés : tout existe déjà. Si vous avez lu sur les angles morts de la journalisation de l'authentification cloud, la leçon s'applique ici : les logs existent par défaut, mais en fragments, et le mode de défaillance consiste à ne jamais les centraliser à un endroit où un humain (ou un détecteur) regarde réellement. Le monitoring perd face au containment en termes de prestige, mais c'est la couche qui transforme une catastrophe en alerte.

Le contrôle des sorties réseau : le critère départageur dont personne ne parle

Si je devais choisir l'unique contrôle qui aurait neutralisé la plupart de ces incidents, ce ne serait ni un sandbox plus robuste ni un SIEM plus sophistiqué. Ce serait le contrôle de sortie réseau : une politique de refus par défaut sur tout ce que l'agent peut atteindre. Les vétérans de la sécurité qui ont commenté les incidents des laboratoires y revenaient sans cesse : pas besoin de défenses exotiques propres à l'IA quand « rien ne sort, sauf une liste blanche explicite » aurait contenu intégralement le rayon d'impact.

Le contrôle des sorties se situe dans la zone idéale entre les deux philosophies. C'est techniquement une mesure de containment, mais elle est peu coûteuse, incrémentale et se dégrade en douceur. Contrairement à l'isolation complète, vous pouvez l'assouplir domaine par domaine à mesure que l'agent gagne la confiance. Et contrairement au monitoring, elle empêche réellement les dégâts au lieu de simplement les observer. Voici à quoi ressemble une base de départ pour un agent hébergé sur Kubernetes avec Cilium :

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: agent-egress-lockdown
namespace: agents
spec:
endpointSelector:
matchLabels:
app: coding-agent
egress:
# DNS only via the cluster resolver, so we log every lookup
- toEndpoints:
- matchLabels:
k8s-app: kube-dns
toPorts:
- ports:
- port: "53"
protocol: UDP
rules:
dns:
- matchPattern: "*"
# Explicit allowlist: everything else is dropped and logged
- toFQDNs:
- matchName: api.anthropic.com
- matchName: pypi.org
- matchName: files.pythonhosted.org
toPorts:
- ports:
- port: "443"
protocol: TCP

Trois propriétés font fonctionner ce schéma. D'abord, le DNS passe par un résolveur que vous contrôlez, donc chaque résolution produit une ligne de log : vous obtenez du monitoring gratuitement. Ensuite, la liste blanche est basée sur les FQDN, de sorte qu'un agent compromis ne peut pas simplement coder une adresse IP en dur. Enfin, les paquets rejetés sont journalisés, ce qui transforme les tentatives d'évasion en flux d'alertes plutôt qu'en échecs silencieux. Associez cela à un utilisateur non root, à un système de fichiers racine en lecture seule et à un runtime de microVM comme gVisor ou Kata pour le conteneur lui-même, et vous obtenez quelque chose de nettement plus solide que ce que faisaient apparemment plusieurs laboratoires de pointe.

Quand le containment gagne, quand le monitoring gagne

Alors, lequel financer en premier ? Cela dépend du risque que vous redoutez vraiment, et les deux approches échouent dans des directions opposées.

• Le containment gagne quand les conséquences sont catastrophiques et irréversibles. Les agents disposant d'identifiants vers des bases de production, des systèmes de paiement ou des données clients ont besoin de frontières strictes, point final. On ne peut pas monitorer son chemin hors d'une clé volée qui a déjà servi. Si l'agent peut, en un seul appel d'API, faire quelque chose que vous ne pourrez pas annuler, il doit être derrière un mur.
• Le monitoring gagne quand l'agent doit disposer d'une large capacité pour être utile. Un agent de recherche qui navigue sur le web ouvert ne peut pas vivre dans une boîte en refus par défaut : son travail consiste justement à toucher des endpoints arbitraires. Ici, un containment serré est impossible par définition, donc la journalisation complète du flux d'actions et la détection d'anomalies portent la charge.
• Le containment gagne à petite échelle. Une expérience, une machine, un espace de noms réseau : l'isolation est presque gratuite et le monitoring serait disproportionné.
• Le monitoring gagne à l'échelle d'une flotte. Quand vous faites tourner des centaines d'instances d'agents, l'isolation matérielle instance par instance devient une taxe opérationnelle, et un pipeline d'observabilité centralisé se rentabilise sur l'ensemble. C'est la même logique qui rend si utile le fait de considérer les agents comme des systèmes distribués : on n'isole pas parfaitement chaque service d'un maillage non plus ; on authentifie, on journalise et on trace.

Remarquez l'asymétrie : les défaillances du containment restent silencieuses jusqu'à ce qu'elles deviennent publiques, alors que les défaillances du monitoring sont au moins détectables dans vos propres logs. C'est pourquoi, comme premier investissement, je place le monitoring avant l'isolation stricte pour la plupart des équipes. Non pas parce qu'il est plus robuste, il ne l'est pas, mais parce qu'il est réalisable dès ce trimestre et qu'il rend lisible chaque amélioration ultérieure du containment. On ne peut pas régler une politique de sortie qu'on ne sait pas observer.

Le bug d'organigramme « sécurité des modèles contre sécurité informatique »

Un détail des reportages sur ces incidents mérite plus d'attention de la part des responsables d'ingénierie, car votre organisation peut tomber dans le même piège. Dans les grands laboratoires, le travail défensif était rangé sous « sécurité de l'IA » (alignement, garde-fous, entraînement au refus), et les personnes qui le portaient avaient une expertise des modèles plutôt qu'une formation en ingénierie de la sécurité. Les experts forensiques, les concepteurs de sandboxes et les spécialistes de la sécurité réseau n'étaient pas dans la pièce. Le résultat était prévisible : un travail de classe mondiale pour faire en sorte que le modèle veuille bien se comporter, et un travail de niveau amateur pour que l'environnement le contraigne à le faire.

Les garde-fous disent à l'agent ce qu'il ne devrait pas faire. Le containment détermine ce qu'il peut faire. Un seul de ces deux éléments tient encore quand le modèle cesse d'écouter.

Cette division apparaît désormais dans les entreprises ordinaires, sans l'étiquette. L'équipe ML possède le « comportement de l'agent », l'équipe plateforme possède « l'infrastructure », et l'espace entre les deux, qui surveille le trafic réseau de l'agent, qui gère la configuration du sandbox, qui est appelé quand l'agent fait quelque chose de bizarre, n'appartient à personne. C'est exactement le déficit de responsabilité dans lequel sont tombés les laboratoires, et c'est un bug d'organigramme, pas un bug de modèle. La solution n'est pas à la mode : donnez à vos ingénieurs sécurité un siège dans les revues de conception des agents, et traitez la configuration du sandbox comme du code critique pour la sécurité, relu, versionné et testé comme la logique d'authentification. La philosophie derrière l'ingénierie défensive s'applique telle quelle : supposez que le composant se comportera mal, et rendez malgré tout le système sûr.

Une checklist de base en pratique

Voici le minimum que j'exigerais avant de laisser un agent autonome tourner sans supervision face à quoi que ce soit de connecté au réseau. Rien de tout cela n'est exotique, et c'est justement le propos.

1. Isolez au niveau de la VM, pas du conteneur. gVisor, Kata Containers ou les microVM Firecracker. Un conteneur qui partage le noyau est une suggestion, pas un mur. Et si vous avez besoin d'un démarrage rapide, les sandboxes microVM en copy-on-write ont largement effacé l'excuse de la performance.
2. Sortie réseau en refus par défaut avec une liste blanche de FQDN. Chaque destination atteinte par l'agent est une décision que quelqu'un a formalisée. Les connexions rejetées sont journalisées.
3. Maîtrisez le chemin DNS. Toutes les résolutions passent par votre résolveur. Les logs DNS sont le détecteur d'anomalies le moins cher que vous déploierez jamais.
4. Journalisez tout le flux d'actions, pas seulement les erreurs. Chaque appel d'outil, chaque lancement de processus et chaque destination réseau, horodatés et envoyés hors de la machine. Si les logs vivent sur le même hôte que l'agent, ce ne sont pas des logs, ce sont des otages.
5. Alertez sur les écarts de comportement. Nouveaux domaines, nouveaux schémas d'appels d'outils, activité soudaine sur des ports, exécution juste après une écriture. Ajustez chaque semaine : un flux d'alertes ignoré est pire que pas de flux du tout.
6. Limitez les identifiants à la tâche et faites-les expirer vite. L'agent reçoit des jetons de courte durée, pour exactement les API dont il a besoin. Pas de service de métadonnées cloud ambiant, pas de clés partagées de longue durée.
7. Limitez la durée des expériences et désignez un responsable de surveillance. Les exécutions multi-jours sans supervision étaient au cœur des incidents chez les laboratoires. Si aucun humain n'est censé vérifier, l'agent ne tourne pas.
8. Répétez la procédure d'arrêt d'urgence. Une seule commande qui révoque les identifiants, tue le sandbox et conserve les logs pour l'analyse forensique. Testez-la chaque trimestre. Un bouton d'arrêt que personne n'a jamais actionné n'est qu'une décoration.

La recommandation

Alors, containment ou monitoring ? Ma réponse, avec conviction : mettez d'abord en place le monitoring, puis le contrôle des sorties immédiatement après, et l'isolation stricte partout où les identifiants rendent les enjeux irréversibles. Cet ordre est à rebours de la plupart des approches, parce qu'un mur fait penser à la sécurité et qu'un pipeline de logs fait penser à de l'intendance. Pourtant, les preuves issues de chaque incident d'« agent incontrôlable » rendu public vont dans le même sens : le plus grave n'était pas l'évasion, mais les jours d'activité non détectée qui ont suivi. Les murs tombent, parfois à cause d'une mauvaise configuration, parfois à cause d'un exploit réellement inédit. Quand le vôtre tombera, ce qui séparera un rapport d'incident embarrassant d'une divulgation de fuite de données, c'est seulement de savoir si vous l'avez vu se produire.

Et si vous êtes RSSI et évaluez des fournisseurs dont les modèles alimentent vos agents, ajoutez une question à votre revue d'achat : « Décrivez votre architecture de containment et montrez-moi un incident anonymisé où le monitoring a détecté une tentative d'évasion. » Un laboratoire incapable de répondre à la seconde moitié de la question vous dit qu'il n'a jamais vu son mur tenir, ou qu'il ne l'a jamais surveillé du tout. La communauté de la sécurité contient du code hostile, adaptatif et imprévisible depuis trois décennies. Les modèles sont nouveaux. La discipline qui les garde dans la boîte, elle, ne l'est pas, et il n'y a aucune excuse pour s'en passer.