Transparence IA : ce texte a été généré avec des systèmes d’intelligence artificielle dans la chaîne éditoriale du Relieur. XÉDRIA assume sa publication.
Le point de départ
Un document externe contient une consigne cachée qui pousse l’agent à exporter une information ou à ignorer une règle. On pourrait traiter ça comme un simple réglage d’outil. Ce serait rater le sujet : un agent peut interpréter comme instruction du contenu qu’il était seulement censé lire. Le risque ne vient donc pas uniquement du prompt écrit par l’utilisateur.
Ce que les sources permettent de dire
Quelques faits récents évitent de raisonner dans le vide. Le NIST constate un large accord sur le fait que les agents introduisent des menaces nouvelles. Les principes fondamentaux de cybersécurité restent valables, mais doivent être adaptés aux systèmes capables d’agir et d’enchaîner des outils. Microsoft Research étudie des mécanismes de planification sensibles à la sécurité pour conserver de l’autonomie tout en limitant les effets des injections de prompt et des flux d’information non souhaités. Il faut résister à la tentation de transformer un signal de marché en vérité locale. Ce qui compte vient ensuite : l’observation du processus.
Là où le raisonnement devient plus difficile
Un agent change la nature du risque parce qu’il peut agir, enchaîner des outils et répéter une action sans attendre une nouvelle consigne. Le socle reste connu : identité, moindre privilège, journalisation, contrôle. L’agent rend simplement ces sujets plus dynamiques. La sécurité est plus solide quand chaque étape possède une limite et une trace, plutôt que lorsqu’un filtre tente de tout rattraper à la fin. Le nœud du problème tient dans cette phrase : Un agent peut interpréter comme instruction du contenu qu’il était seulement censé lire. Le risque ne vient donc pas uniquement du prompt écrit par l’utilisateur. C’est une manière classique de fabriquer du débit sans fabriquer davantage de valeur.
Il faut éviter un raccourci assez tentant. Le bon niveau de prudence se décide sur les conséquences, pas sur la sophistication technique. Un document externe contient une consigne cachée qui pousse l’agent à exporter une information ou à ignorer une règle. La bonne question dépend donc du contexte, de la fréquence et surtout du coût d’une erreur.
Ce que ça change dans une organisation
Le premier contrôle que je mettrais sur la table serait simple : séparer données et instructions, filtrer les actions et demander validation pour les effets sensibles. Demande enfin si la personne responsable comprend encore comment le résultat a été obtenu. La vitesse sans lisibilité devient vite une dette.
Construire un contrôle qui tient
Attribuer une identité et des droits distincts à chaque agent qui agit réellement. On pourrait l’ignorer. Ce serait souvent la meilleure manière de recréer la charge un peu plus loin dans le processus.
Limiter les actions à ce qui est nécessaire et imposer une validation pour les effets sensibles. L’intérêt est surtout de créer un critère observable. Si personne ne peut dire si ce point est respecté, la règle restera décorative.
Journaliser suffisamment pour reconstruire une action sans transformer les logs en copie intégrale des données. Le but n’est pas d’ajouter une couche de procédure. C’est de rendre visible la décision qui existait déjà, souvent de manière implicite.
Tester les scénarios d’abus, l’arrêt d’urgence et la révocation des accès avant la mise en production. Il faut alors sortir de la démonstration et suivre ce qui arrive réellement au dossier après la première réponse.
Ce qu’il ne faut pas conclure trop vite
Aucun contrôle unique ne garantit la sécurité d’un agent. Les mesures doivent être adaptées au périmètre, aux données, aux outils accessibles et aux conséquences possibles. Les scénarios d’abus et d’incident font partie du fonctionnement normal à préparer.
Si je devais ramener tout l’article à une décision, ce serait celle-ci : séparer données et instructions, filtrer les actions et demander validation pour les effets sensibles. C’est moins spectaculaire qu’une démo, mais beaucoup plus utile pour faire tenir l’usage dans le temps.
Construire un scénario de défense réaliste
Le test le plus utile n’est pas de demander à l’agent s’il sait résister à une phrase manifestement hostile. Place plutôt l’instruction malveillante dans ce qu’il considère comme une source normale : une pièce jointe, une page web, une note importée ou un document partagé. Puis observe s’il distingue correctement ce contenu des instructions de son propriétaire.
Ensuite, limite l’impact. Même si l’agent se fait tromper, il ne devrait pas pouvoir transformer une lecture en action critique sans contrôle supplémentaire. Lire une pièce jointe ne doit pas donner automatiquement le droit d’envoyer un message, de modifier une base ou de transmettre un secret. C’est là que les permissions minimales deviennent plus importantes que la qualité du filtre de texte.
Je testerais aussi les chemins indirects. Un document peut demander à l’agent d’aller chercher une autre ressource, qui contient elle-même une instruction. Une attaque peut donc traverser plusieurs étapes avant d’atteindre l’action sensible. Les journaux doivent permettre de reconstruire ce chemin, pas seulement d’afficher la dernière commande exécutée.
Enfin, fais le test avec une personne métier. Elle connaît les documents qui semblent normaux et les actions qui seraient vraiment dangereuses. La sécurité d’un agent ne se réduit pas à une liste technique de mots interdits. Elle dépend de la séparation entre données et instructions, de l’identité de l’agent, de ses droits et de la capacité à interrompre le scénario avant qu’une mauvaise lecture devienne une mauvaise action.
Sources vérifiées
Ce qui a servi de point de départ
- NIST, Security Considerations for AI Agents 2026-05-18
- Microsoft Research, Optimizing Agent Planning for Security and Autonomy 2026-02-01
Les sources servent à établir les faits cités et le contexte. Les recommandations pratiques et l’analyse éditoriale sont celles d’IA BLOG.