Agents d’IA : prompt injection et contrôles hors modèle

Des instructions malveillantes insérées dans des contenus ordinaires peuvent amener des agents d’IA à tenter des actions sensibles. Deux incidents récents, dont un fichier AGENTS.md trouvé chez un client et une fuite de jeton chez Cline, illustrent le risque. Des spécialistes recommandent d’isoler les identités, de limiter les privilèges et d’exiger des autorisations indépendantes, tout en renforçant la traçabilité pour suivre ce que l’agent a touché.

Tracer chaque action pour circonscrire l’incident

Afin d’assurer une réponse appropriée, il est nécessaire que les journaux associent la requête d’origine ainsi que les informations extraites aux appels d’outils, aux identifiants employés, aux modifications réalisées et aux opérations de délégation. En l’absence de ces traces, il n’est plus possible de déterminer avec exactitude quels systèmes ont été touchés ou si une activité non autorisée se poursuit. Bobby Kuzma souligne que si les journaux n’indiquent pas l’identité des délégants et la nature des délégations, l’équipe ne parvient pas à délimiter l’incident. Lors de la gestion d’un incident, il incombe aux intervenants de suivre l’ensemble des tâches subséquentes, de retirer les accès délégués et de repérer tout nouveau droit d’accès accordé pendant l’événement, car interrompre uniquement l’agent à l’origine peut laisser d’autres processus actifs. Le confinement implique également une vérification de la mémoire partagée et de l’état persistant pour détecter d’éventuelles instructions malveillantes, et l’investigation peut inclure le code généré, les fichiers et les index de récupération avant toute reprise des workflows.

Des cas concrets révèlent les angles morts opérationnels

En octobre, Forever Security a signalé la détection d’un fichier AGENTS.md contenant des instructions malveillantes dans le répertoire de téléchargements d’un client. Un agent de codage a ensuite suivi ces instructions et tenté d’installer un package malveillant, mais le dispositif de surveillance a empêché l’exécution. L’origine du fichier reste inconnue ; des essais réalisés par la suite ont permis de reproduire des attaques visant des agents de codage, lors de démonstrations séparées de l’incident stoppé. L’action malveillante était dissimulée sous l’apparence de recommandations d’ingénierie habituelles. En février, Cline a indiqué qu’un processus automatisé de revue d’issues pouvait exposer des identifiants de publication via un cache partagé. Une personne extérieure non autorisée s’est alors servie d’un jeton compromis pour publier un package modifié ; selon Cline, aucun code malveillant n’a été distribué et aucune donnée utilisateur n’a été subtilisée.

Qualifier et mesurer : du prompt réussi à l’impact réel

Pyry Åvist recommande d’évaluer si un contenu malveillant a atteint l’agent, s’il a été suivi et si une action sensible a effectivement abouti. Il estime que considérer chaque prompt de laboratoire réussi comme une violation brouille la compréhension du risque. Distinguer les résultats permet aussi d’identifier quelles défenses ont tenu : une tentative d’installation non autorisée bloquée par un contrôle de point de terminaison n’a pas les mêmes conséquences qu’une installation aboutie.

Autoriser en dehors du modèle et limiter les privilèges

Bobby Kuzma soutient que les contrôles doivent rester efficaces même si l’agent accepte les consignes d’un attaquant, en concevant les systèmes comme si le modèle exécuterait ces demandes. Cela passe par des identités séparées pour les agents, des crédentiels de courte durée limités aux tâches, l’éloignement des secrets permanents des environnements d’exécution et des restrictions sortantes pour bloquer les transferts non autorisés. Diana Kelley met en avant la nécessité de distinguer l’action sollicitée par le modèle de la validation effectuée par le système. Pyry Åvist conseille de dissocier les droits de lecture de ceux d’écriture, de limiter les possibilités d’exécution et d’imposer des validations indépendantes pour des actes majeurs tels que la publication de code ou la modification des droits ; l’accès à un document ne devrait pas permettre d’installer des logiciels ou de récupérer des secrets sans rapport. Kevin Surace suggère, pour les opérations sensibles, d’exiger une validation biométrique basée sur le matériel, réalisée en dehors du modèle et associée à la transaction concernée, une solution qui ne fait toutefois pas l’objet d’un consensus parmi les experts.

Pourquoi les agents cèdent : confusion des rôles et absence de mémoire

En exécutant des tâches routinières avec des accès légitimes, les agents peuvent rencontrer des instructions injectées dans des supports qu’ils devraient traiter uniquement comme des données, ce qui brouille l’analyse et l’exécution. Les modèles ne tirent pas de leçon d’une tentative avortée et peuvent repartir d’une page blanche à chaque requête. Les campagnes adverses tirent parti d’instructions insérées dans le contexte de traitement, gagnant une crédibilité apparente par usurpation de sources de confiance, création d’urgence ou présentation d’étapes malveillantes comme nécessaires. Le mélange d’instructions fiables et de réponses d’outils non fiables dans le même contexte complique le filtrage, qui peut réduire l’exposition sans suffire, d’où la nécessité de contrôles indépendants. Considérer ces attaques comme de l’ingénierie sociale aide à choisir des garde-fous comme la séparation des tâches et la segmentation, alors que les décisions d’architecture et la capacité de retraçage conditionnent la différence entre incident contenu et atteinte à la chaîne d’approvisionnement. La délégation entre agents ouvre aussi une voie de propagation, et l’évaluation doit inclure la reconnaissance et l’influence exercées sur les approbateurs du travail de l’agent.