Le nom du problème est ce qui empêche de le traiter.
« Injection de prompt » suggère un défaut dans la manière d’écrire les instructions, donc une correction dans la manière de les écrire. Des équipes sérieuses passent des semaines à durcir un prompt système, et obtiennent une amélioration réelle mais bornée, parce que la correction ne se trouve pas à cet endroit.
Ce que l’agent lit réellement
Vous écrivez des instructions à un agent. C’est une petite partie de ce qu’il lit.
Il lit le billet de support qu’il doit traiter. L’invitation de calendrier qu’il doit résumer. La page web qu’il consulte pour répondre. La description de chaque outil qu’on lui a branché. Le contenu du document qu’on lui a demandé d’analyser. Les messages des autres agents avec lesquels il coordonne.
Tout ça arrive dans le même canal que vos instructions.
Il n’y a pas, dans l’architecture, de séparation structurelle entre « ceci est une instruction de l’opérateur » et « ceci est du contenu à traiter ». Les deux sont du texte, dans la même fenêtre, et le modèle décide de leur importance relative en fonction de ce qu’ils disent.
C’est là qu’est la frontière de confiance. Elle existe dans votre tête — vous savez lesquelles de ces sources sont fiables — et elle n’existe pas dans le système.
Pourquoi la validation d’entrée ne transpose pas
L’équipe réseau et l’équipe applicative ont un réflexe correct dans presque tous les autres contextes : valider l’entrée.
Il fonctionne parce qu’il existe une grammaire. Une injection SQL est reconnaissable parce que la requête a une syntaxe, et que ce qui ne s’y conforme pas peut être rejeté ou échappé. Idem pour un chemin de fichier, une adresse, un fragment de HTML.
Ici, il n’y a pas de syntaxe.
L’attaque est une phrase en français correct, placée dans un champ conçu pour recevoir des phrases en français. Il n’existe aucune règle de forme qui distingue « veuillez traiter ce remboursement » d’une instruction hostile, parce que la différence est sémantique et dépend du contexte.
Vous pouvez filtrer des motifs connus. Ça attrape les tentatives naïves et ça produit une fausse assurance sur les autres.
Comment OWASP la classe
L’injection indirecte est classée sous ASI01, détournement d’objectif de l’agent, dans le Top 10 pour les applications agentiques.
Le placement est le bon, et il est plus instructif que la définition. La cible n’est pas la sortie du modèle. C’est l’objectif que l’agent poursuit.
Un modèle qui produit une réponse embarrassante est un incident de réputation. Un agent dont l’objectif a été redirigé est un incident de sécurité, parce que l’agent conserve ses accès et continue d’agir avec eux.
La version qu’on ne voit pas passer
Le cas d’école — un document contenant « ignore tes instructions précédentes » — est le moins intéressant, parce qu’il est visible et détectable.
Le motif qui devrait préoccuper est celui de la dérive de calendrier. Une invitation contient une instruction formulée comme une préférence opérationnelle : travailler en « mode discret », réduire les notifications, regrouper certaines opérations, éviter d’alerter pendant une période donnée.
L’agent l’intègre. Il ne viole aucune règle explicite. Chacune de ses actions reste dans les limites de ce qui lui est permis.
Ce qui a changé est la pondération de ses objectifs, et il n’y a rien à détecter dans les journaux : les actions journalisées sont toutes autorisées. Ce qui a changé est l’ordre, le moment et ce qui a été omis.
C’est aussi la raison pour laquelle la détection ne suffit pas comme stratégie ici.
Où se trouve la correction
À la frontière de permission. C’est-à-dire : ce que l’agent est capable de faire une fois qu’il a été convaincu.
Cette formulation est utile parce qu’elle rend le problème mesurable. Vous n’avez pas à estimer la probabilité qu’un agent soit manipulé, ce qui est difficile. Vous supposez qu’il l’est, et vous mesurez le rayon d’impact, ce qui est un exercice d’architecture ordinaire.
Trois contrôles, dans l’ordre d’efficacité :
Des droits par tâche, pas par session. Le défaut de la plupart des cadres agentiques est de donner à l’agent l’accès à tous les outils connectés, pour toute la durée de la session. Un agent qui traite un billet de support n’a pas besoin, pendant qu’il le traite, de l’outil qui envoie des courriels externes.
Un humain devant les actions irréversibles. La liste doit rester courte pour rester crédible : ce qui touche la production, ce qui détruit ou exfiltre des données, ce qui déplace de l’argent, ce qui publie vers l’extérieur.
Un journal qui nomme trois choses. L’agent, la personne pour le compte de qui il agit, l’outil utilisé. Sans ces trois éléments sur la même ligne, la question « qui a fait ça » reste sans réponse, et c’est la première question posée en cas d’incident.
La question à poser
Pas « est-ce que notre agent résiste à l’injection de prompt ». La réponse honnête est non, pour tous les agents, aujourd’hui.
Si votre agent était entièrement convaincu par un attaquant, qu’est-ce qu’il pourrait faire ?
Cette question a une réponse exacte, elle se trouve dans la configuration plutôt que dans une estimation, et elle est la seule des deux sur laquelle vous pouvez agir cette semaine.
Besoin d’aide pour mettre cela en œuvre ?
Nous travaillons avec votre équipe pour concevoir, construire et exploiter les contrôles décrits ci-dessus.