ASI01 : détournement d’objectif d’un agent IA

Un agent reçoit un objectif, le décompose, choisit des outils, enchaîne des étapes. ASI01, première entrée du Top 10 OWASP des applications agentiques, décrit ce qui arrive quand un tiers prend la main sur cet objectif : l’agent continue de fonctionner parfaitement, avec un but qui n’est plus celui qu’on lui a donné. La cause est structurelle et ne se corrige pas : un modèle de langage ne distingue pas de façon fiable une instruction d’un contenu, parce que les deux arrivent par le même tuyau, sous la même forme, sans aucun typage.

→ Lire l’explication complète de la marmotte

Le mécanisme : pas de frontière entre instruction et donnée

Dans une application classique, les instructions sont du code et les données sont des données : le langage lui-même les sépare, et c’est précisément cette séparation que les injections SQL cassaient. Chez un agent, il n’y a plus rien à casser, parce qu’il n’y a plus de séparation. L’objectif, les consignes du prompt système, le contenu d’une page web, la sortie d’un outil, le message d’un agent pair et le document retrouvé dans une base vectorielle arrivent tous sous forme de texte, dans la même fenêtre de contexte, et c’est le modèle — c’est-à-dire une statistique — qui décide de leur statut.

Le référentiel énumère les vecteurs par lesquels un objectif se détourne : manipulation par le prompt, sorties d’outils trompeuses, artefacts malveillants, messages inter-agents forgés et données externes empoisonnées. Tous reposent sur la même propriété, et aucun ne suppose une faille logicielle au sens habituel. Il n’y a pas de dépassement de tampon à corriger, pas de version à mettre à jour : le comportement exploité est le comportement attendu. Le site consacre un éditorial entier à cette particularité, l’injection de prompt comme propriété et non comme bogue, qui explique pourquoi les correctifs annoncés n’en sont jamais tout à fait.

S’ajoute un facteur proprement agentique : la logique d’orchestration est elle-même peu gouvernée. Le plan de l’agent n’est pas un graphe validé mais une suite d’intentions reformulées à chaque tour. Une instruction insérée au bon endroit ne modifie pas seulement une réponse, elle réécrit le plan — et le plan, lui, appelle des outils.

Ce qui distingue ASI01 de ses voisins

C’est le point de délimitation que le référentiel soigne le plus, et il vaut d’être retenu : dans ASI01, l’attaquant modifie directement le but, les instructions ou le chemin de décision de l’agent, que la manipulation soit interactive ou pré-positionnée dans un document, un modèle de rapport ou une source de données.

Face à l’entrée LLM01 (injection de prompt) du Top 10 LLM, la différence est l’étendue : LLM01 altère une réponse, ASI01 redirige un objectif, une planification et un comportement sur plusieurs étapes. Le même vecteur, une conséquence d’un autre ordre.
Face à ASI06, empoisonnement de la mémoire et du contexte, la différence est la persistance : ASI06 décrit la corruption durable de ce que l’agent a stocké, ASI01 la prise de contrôle du but en cours. Les deux se succèdent souvent — une mémoire empoisonnée finit par détourner un objectif — mais le point d’entrée et le remède diffèrent.
Face à ASI10, agents voyous, la différence est la présence d’un attaquant : ASI01 suppose quelqu’un au volant, ASI10 décrit une dérive autonome qui se poursuit sans personne.

Dans la taxonomie Agentic AI — Threats & Mitigations du même projet, ASI01 correspond à T06, manipulation d’objectif, et à T07, comportements désalignés et trompeurs — celui où l’agent contourne un garde-fou ou trompe l’humain qui le surveille.

À quoi cela ressemble en production

Le cas le plus courant est l’injection indirecte : une charge d’instructions dissimulée dans un contenu que l’agent va lire de lui-même. Une page web, une pièce jointe, une fiche produit, une invitation d’agenda. L’utilisateur ne tape rien de suspect ; il demande un résumé. Le site détaille ce vecteur et ses contre-mesures dans sécuriser un corpus RAG contre l’injection indirecte, dont les conclusions s’appliquent telles quelles ici.

Le suivi d’incidents publié en annexe du référentiel recense plusieurs cas documentés. EchoLeak, en mai 2025, a montré qu’un simple courriel suffisait à déclencher chez Microsoft 365 Copilot une exfiltration de courriels, fichiers et journaux de conversation, sans clic de la victime. En février 2025, l’agent Operator d’OpenAI a été détourné par du contenu planté sur une page web, l’amenant à visiter des pages internes authentifiées et à exposer des données privées. En septembre 2025, une injection indirecte critique dans Salesforce Agentforce a permis l’exfiltration d’enregistrements clients hors de l’organisation. Dans les trois cas, l’agent n’a rien fait d’interdit : il a fait ce qu’on lui avait demandé, par quelqu’un d’autre.

Une variante plus sournoise mérite d’être nommée, parce qu’elle ne déclenche aucune alerte : la dérive progressive. Le référentiel décrit une invitation d’agenda récurrente qui injecte chaque matin une consigne de « mode discret », repondérant insensiblement les objectifs du planificateur vers les validations les moins frictionnelles — tout en restant dans les politiques déclarées. Aucune action n’est interdite, aucun seuil n’est franchi, et au bout de trois semaines l’agent approuve seul ce qu’il faisait valider le premier jour.

Détecter : suivre l’objectif, pas la prose

Le réflexe inutile consiste à demander au modèle d’expliquer pourquoi il fait ce qu’il fait. Un agent détourné produit une justification excellente : c’est son métier de produire du texte convaincant. L’explication n’est pas une preuve, elle est au mieux un indice de style.

Ce qui se surveille utilement est observable de l’extérieur. Le référentiel recommande de maintenir un identifiant stable de l’objectif actif, puis d’alerter sur tout changement d’objectif inattendu, toute séquence d’outils anormale et tout écart par rapport à une ligne de base comportementale établie — laquelle inclut l’état du but, les motifs d’appel d’outils et des propriétés invariantes du système. C’est un travail de télémétrie, pas d’introspection : les techniques sont celles de l’observabilité d’un LLM en production, appliquées au plan plutôt qu’aux réponses.

Deux signaux valent d’être câblés en priorité. Le premier est l’apparition d’un outil que cette tâche n’utilise jamais : un agent de synthèse documentaire qui se met à appeler une fonction d’envoi. Le second est la divergence entre l’intention exprimée par l’utilisateur et l’intention déduite du plan ; le référentiel demande explicitement de valider les deux avant toute action à fort impact, ce qui suppose de les représenter séparément au lieu de les confondre dans un contexte unique.

Réduire : moindre agentivité d’abord, verrous ensuite

La première mesure ne concerne pas la défense mais la conception, et c’est le principe de moindre agentivité posé en ouverture du référentiel : un agent qui n’a pas le droit d’agir ne peut pas voir son objectif détourné de manière coûteuse. Avant de durcir un agent capable d’envoyer des courriels au nom de l’entreprise, il faut se demander si cette capacité devait exister. La réflexion est développée dans le moindre privilège pour une machine qui improvise.

Ensuite viennent les verrous, et ils sont d’une simplicité décevante parce qu’il n’existe pas de solution élégante :

traiter tout contenu comme hostile, y compris les sorties d’outils et les messages de pairs, et le faire passer par les mêmes filtres que l’entrée utilisateur avant qu’il puisse influencer la sélection d’un but, un plan ou un appel d’outil ;
figer le prompt système et les objectifs : leurs modifications passent par la gestion de configuration et une approbation humaine, pas par la conversation. Les mécanismes de protection des instructions, et leurs limites, sont traités dans la fuite d’instructions des assistants personnalisés ;
exiger une confirmation sur tout écart : dès que l’action proposée sort de la tâche ou du périmètre d’origine, la décision remonte à un moteur de politique ou à un humain. Le référentiel va plus loin et demande de suspendre l’exécution sur tout glissement d’objectif inattendu, de remonter la déviation et de la journaliser ;
interposer un courtier d’actions entre le modèle et les outils, qui décide à partir de l’état observé et non du raisonnement affiché : c’est l’architecture décrite dans sécuriser les actions irréversibles des agents LLM et dans les guardrails programmatiques.

Le référentiel mentionne enfin un motif émergent qu’il nomme intent capsule : lier le but déclaré, ses contraintes et son contexte dans une enveloppe signée, attachée à chaque cycle d’exécution et vérifiée à l’usage. L’idée est bonne — rendre l’objectif infalsifiable plutôt qu’espérer qu’il ne bouge pas — et les implémentations sont encore rares. Le texte la présente comme un motif à évaluer, pas comme une recommandation mûre ; il serait honnête de la citer de la même façon dans une revue d’architecture.

Ce que ces mesures ne font pas

Aucune ne supprime la cause. Tant que les instructions et les données partagent un canal, un contenu bien construit pourra influencer un plan. Les filtres d’entrée réduisent la probabilité, pas la possibilité : ils relèvent le coût de l’attaque et attrapent les charges connues, ce qui est utile et insuffisant. Les tests d’intrusion dédiés, que le référentiel recommande de mener périodiquement sur le détournement d’objectif et sur l’efficacité réelle du retour en arrière, sont le seul moyen de savoir où en est un système donné ; le site décrit la démarche dans le red teaming d’un LLM local.

Reste une recommandation inattendue du document, et plutôt juste : intégrer les agents au programme de menace interne de l’organisation. Un agent détourné se comporte exactement comme un employé retourné — accès légitimes, gestes plausibles, horaires normaux — et les dispositifs pensés pour l’un servent pour l’autre. La différence, c’est qu’il ne demande pas d’augmentation.

🐝 Ce qui arrive si on s’en passe

Sans identifiant d’objectif suivi dans les journaux, un détournement ne laisse aucune trace distinctive : les appels d’outils sont valides, authentifiés, dans les droits, et le journal du système cible ne voit qu’une identité de service qui travaille. L’incident n’est découvert que par son effet — un destinataire étonné, une facture, une donnée retrouvée ailleurs — et la revue post-mortem se heurte alors à l’impossibilité de dater le basculement : faute d’état d’objectif enregistré, rien ne distingue la centième action légitime de la première action détournée. Sans suspension sur écart, le délai de détection se compte en cycles d’exécution de l’agent, c’est-à-dire en secondes multipliées par le nombre de tâches en file ; là où une erreur humaine produit un dégât unitaire, un objectif détourné produit un dégât par itération, jusqu’à ce que quelqu’un coupe l’alimentation.

🦫 Explication de la marmotte 🍫

Un assistant informatique autorisé à agir seul reçoit un but : « range ces factures », « réponds aux demandes de congés », « surveille ce serveur ». Pour tenir ce but, il lit des documents, consulte des sites, reçoit des messages. Le problème est qu’il ne sait pas faire la différence entre ce qu’il doit lire et ce qu’il doit faire. Tout lui arrive sous forme de phrases, et il décide au feeling.

Quelqu’un qui veut détourner cet assistant n’a donc pas besoin de pirater quoi que ce soit. Il lui suffit de placer, dans un document que l’assistant va lire, une phrase formulée comme une consigne. L’assistant la prend pour une instruction du patron et change de but, tout en continuant à travailler normalement : mêmes accès, mêmes outils, mêmes traces dans les journaux. Vu de l’extérieur, rien ne cloche.

Il n’existe pas de correctif à installer, parce que le défaut est la manière même dont ces programmes fonctionnent. On réduit donc le dégât possible plutôt que la cause : ne pas donner à l’assistant le droit de faire ce dont il n’a pas besoin, lui faire demander une validation humaine dès qu’il sort de sa tâche, et enregistrer en permanence quel but il poursuit afin qu’un changement se remarque.

Le reste est une question de surveillance ordinaire : garder la trace de ce qu’il a fait, s’étonner quand il emploie un outil qu’il n’emploie jamais, et pouvoir l’arrêter vite. Lui demander de s’expliquer ne sert à rien — un programme qui écrit des phrases convaincantes en écrira aussi pour justifier ce qu’il n’aurait pas dû faire.

Pages voisines

La citent

ASI01 : détournement d'objectif d'un agent IA

Elle cite

: les deux pages se citent l’une l’autre.