La meilleure défense contre un agent IA piraté ? Parfois, le saborder gentiment avant qu’il ne fasse une bêtise. Le principe, baptisé « context bombing », détourne la logique de la prompt injection. Au lieu de forcer un agent à exécuter une commande malveillante, on l’ensevelit sous du contenu trompeur pour le pousser à s’immobiliser avant tout dégât.
La contre-mesure débarque alors que les agents IA, surtout ceux qui naviguent sur le web ou pilotent des outils connectés, ont déjà collectionné les démonstrations de prompt injection indirecte. Fin juin, Ars Technica documentait une recherche montrant qu’un site pouvait plonger un navigateur IA dans un état de « dream world » où les garde-fous cessent de s’appliquer. Le modèle avale le contenu hostile comme un morceau de son contexte, puis obéit à des instructions qui ne viennent ni de l’utilisateur ni du système.
Points clés
- Le context bombing ensevelit un agent IA sous du contenu trompeur pour le figer avant toute action dommageable
- La prompt injection indirecte exploite la frontière poreuse entre données lues et instructions exécutées
- Les défenses clés restent le moindre privilège, la confirmation humaine et l’isolement des exécutions
- Aucun remède universel : la sécurité dépend autant des permissions accordées que du modèle lui-même
Le contexte, cette porte d’entrée
Le problème de fond ne bouge pas : un agent lit des données, puis décide d’agir. Quand ces données cachent des consignes, la frontière entre information et instruction devient poreuse. Les attaquants visent précisément cette zone grise. Ils glissent leurs ordres dans des pages web, des documents ou des résultats d’outils que l’agent ingère ensuite dans sa fenêtre de contexte.
Le context bombing prend cette mécanique à revers. Plutôt que d’arracher un comportement utile à l’agent, les défenseurs l’encombrent de bruit, de contradictions et de signaux qui le sortent de son état opérationnel. Le but n’est pas de « nettoyer » le prompt mais de rendre l’attaque inexploitable, voire de pousser l’agent à décrocher tout seul avant d’envoyer un mail, d’exécuter une commande ou d’exfiltrer des données.
Des garde-fous qui misent sur la limitation des dégâts
Les recommandations de sécurité sur les agents convergent toutes vers la même boussole : réduire les permissions, isoler les outils, confirmer les actions sensibles et limiter les sorties réseau. La logique est bête comme chou. Si une injection passe malgré tout, elle ne doit pas hériter d’un accès large aux données, aux identifiants ou aux canaux d’exécution.
- Moindre privilège pour les agents et leurs outils ;
- Validation stricte des paramètres avant toute action ;
- Confirmation humaine pour les opérations irréversibles ;
- Allowlist des destinations autorisées en sortie réseau ;
- Isolement des exécutions dans des environnements cloisonnés.
Dans ce décor, le context bombing n’a rien d’un remède miracle. C’est une tactique d’appoint, taillée pour gagner du temps et contenir un agent compromis. Le constat technique reste implacable : dès qu’un système lit du contenu non fiable et peut agir dessus, la sécurité dépend autant des permissions accordées que du modèle lui-même. Un agent sans garde-fou, c’est un stagiaire trop obéissant à qui l’on aurait confié les clés du serveur.
