Les frameworks d'agents IA transforment l'injection de prompt en défaillance de sécurité

Google News a mis en avant cette semaine un argument de sécurité sans détour : l'injection de prompt n'est pas la faille fondamentale, malgré des années de défenses conçues autour d'elle. La défaillance plus profonde se situe dans les frameworks d'agents IA qui transforment des sorties de modèle incertaines en actions privilégiées.

Cette distinction modifie ce que les équipes d'ingénierie doivent sécuriser. Un chatbot manipulé peut produire des absurdités. Un agent manipulé peut lire des fichiers privés, appeler des API, modifier du code, envoyer des messages ou contaminer une mémoire partagée.

L'analyse de The Register remet en cause une hypothèse familière. Les développeurs considèrent souvent le texte malveillant comme la vulnérabilité et un prompting plus robuste comme le remède. La question la plus déterminante est ce que le système environnant autorise après que le modèle a accepté ce texte.

Il ne s'agit pas d'affirmer que l'injection de prompt est inoffensive. Elle reste un moyen fiable d'influencer les modèles par des requêtes directes ou du contenu externe non fiable. Toutefois, l'injection ne devient une compromission opérationnelle que lorsque l'architecture fournit l'autorité, les données et un chemin d'exécution.

L'affrontement qui se dessine est donc clair. D'un côté, on compte sur les modèles pour reconnaître les instructions dangereuses dans un langage ambigu. De l'autre, on suppose que cette reconnaissance finira par échouer et on limite ce que tout modèle compromis peut accomplir.

Google News place le framework d'agents au centre

Le changement important est un déplacement de la responsabilité, du comportement du modèle vers l'architecture du système.

L'injection de prompt a généralement été décrite comme un problème de sécurité des modèles. Un attaquant place des instructions dans un prompt, un document, un site web, un e-mail, une image ou une réponse d'outil. Le modèle suit alors ces instructions au lieu de la demande réelle de l'utilisateur.

Cette description est exacte, mais incomplète. Elle identifie la méthode utilisée pour influencer le modèle sans identifier la défaillance de contrôle qui produit des dommages réels. Un texte non fiable ne peut pas, à lui seul, supprimer un fichier, récupérer l'enregistrement d'un client ou publier du code source.

Un framework d'agents fournit ces capacités. Il relie un modèle à des outils, des identifiants, une mémoire, des bases de données, des navigateurs, des interpréteurs de code et d'autres agents. Il peut également décider si le modèle peut agir sans nouvelle autorisation humaine.

L'architecture peut transformer une interprétation erronée en une séquence d'effets de bord. Une page web empoisonnée devient une requête d'outil. La requête d'outil devient une interrogation de base de données. Le contenu récupéré apparaît ensuite dans un message sortant généré par le même agent.

L'injection indirecte de prompt est particulièrement importante ici. L'attaquant n'a pas besoin d'accéder à l'interface de chat. Des instructions malveillantes peuvent attendre dans le contenu que l'agent rencontre au cours d'une mission ordinaire.

Un agent de recherche pourrait rencontrer les instructions sur une page web. Un assistant de programmation pourrait les trouver dans la description d'un ticket ou dans un fichier de dépôt. Un agent bureautique pourrait les ingérer depuis un e-mail, une invitation de calendrier ou un document partagé.

Dans chaque cas, le modèle fait face à un difficile problème de classification. Il doit distinguer un texte qui décrit une instruction d'un texte auquel il doit obéir. Les deux arrivent sous forme de jetons de langage naturel dans le contexte de travail du modèle.

La définition du risque par OWASP reconnaît les injections directes et indirectes. Elle note également que l'impact dépend fortement du contexte métier et du degré d'autonomie accordé au modèle.

Cette dernière condition compte davantage qu'elle n'en a l'air. La même phrase malveillante peut produire des résultats radicalement différents selon deux déploiements. Un outil de synthèse en lecture seule pourrait générer un paragraphe corrompu, tandis qu'un agent privilégié pourrait exposer des informations confidentielles.

Google News est utile comme canal de découverte pour ce débat, mais n'en constitue pas l'autorité de référence. Le titre renvoie à un ensemble plus vaste de travaux sur la sécurité qui considère de plus en plus le détournement d'agents comme une menace architecturale.

NIST décrit le détournement d'agents comme une injection indirecte de prompt qui pousse un agent à exécuter des actions nuisibles non prévues. Ses évaluations du détournement utilisent des espaces de travail simulés, des services de voyage, des systèmes de messagerie et des outils bancaires.

Ces environnements montrent pourquoi la sécurité des agents diffère de la sûreté des chatbots. Le modèle ne se contente pas de répondre à une question. Il sélectionne des actions dans un flux de travail qui comporte des autorisations et des conséquences réelles.

Ce recadrage affine également le signalement des vulnérabilités. « Injection de prompt » décrit la manière dont l'influence est entrée dans le système. Une constatation de sécurité utile doit aussi identifier l'impact qui en résulte, comme un accès non autorisé aux données ou une exécution de code non approuvée.

Les équipes de sécurité traditionnelles font déjà des distinctions similaires. Une entrée contrôlée par l'utilisateur n'est pas automatiquement une compromission. La vulnérabilité apparaît lorsque le logiciel transmet cette entrée à un interpréteur non sécurisé ou lui accorde sa confiance au-delà d'une frontière de sécurité.

Les modèles de langage compliquent l'analogie, car les instructions et les données partagent une représentation souple. Il n'existe pas d'équivalent universel à une requête de base de données paramétrée pour chaque tâche en langage naturel. Cela rend le confinement autour du modèle encore plus important.

L'événement clé est donc conceptuel, mais opérationnellement significatif. Le travail de sécurité s'éloigne des promesses de filtrage parfait des instructions. Il s'oriente vers des limites qui restent efficaces après que le modèle a pris la mauvaise décision.

L'injection de prompt est le déclencheur, pas le rayon d'impact

Une instruction injectée crée de l'influence, tandis que le framework détermine si cette influence devient un incident.

Considérons un agent chargé d'examiner les tickets de support entrants. Il doit accéder au texte des tickets, aux informations client et peut-être à une base de connaissances interne. Il pourrait aussi disposer d'outils pour émettre des remboursements ou envoyer des messages relatifs aux comptes.

Un attaquant place une instruction cachée dans un ticket. L'instruction demande à l'agent de récupérer le dossier d'un autre client et de l'inclure dans une réponse. Le modèle suit cette directive tout en pensant exécuter le flux de travail qui lui a été assigné.

Plusieurs défaillances doivent survenir avant que les données ne quittent l'entreprise. L'agent doit recevoir un accès plus large que ce que le ticket en cours exige. Sa couche d'outils doit accepter des paramètres générés par le modèle. L'action sortante doit se poursuivre sans autorisation indépendante.

Le texte malveillant a déclenché la chaîne. Il n'a pas créé les autorisations excessives, les frontières de données manquantes ou l'absence de mécanisme d'approbation. Ces décisions relevaient de l'application et du framework.

Cette distinction est centrale pour la sécurité des agents IA. Un système doit supposer que le jugement du modèle est faillible, en particulier lorsque le modèle traite du contenu contrôlé par un attaquant. Les contrôles de sécurité doivent rester en dehors de cette boucle de jugement.

Les schémas d'outils ne résolvent pas le problème à eux seuls. Un schéma peut exiger une adresse e-mail ou un identifiant de document valide. Il ne peut pas déterminer si le modèle a une raison légitime de contacter cette adresse ou de récupérer ce document.

Une action malveillante bien formée reste malveillante. Le framework doit appliquer des politiques liées à l'identité de l'utilisateur, à la propriété des données, au périmètre de la tâche, à la provenance et à l'état d'autorisation actuel.

La provenance consiste à enregistrer l'origine des informations et à préserver cette étiquette tout au long du flux de travail. Le contenu d'une page web inconnue ne devrait pas acquérir un statut fiable parce qu'un agent l'a résumé.

Cette règle devient plus difficile à appliquer dans les systèmes multi-agents. Un modèle peut rechercher un sujet, un autre planifier une réponse et un troisième exécuter des outils. Les instructions malveillantes peuvent être transformées à mesure que les sorties passent entre eux.

L'agent destinataire peut voir un texte soigné sans voir la source non fiable qui l'a influencé. Si le framework abandonne la provenance, le blanchiment de l'instruction par un autre agent peut accroître de fait son autorité.

La mémoire persistante crée une autre voie. Un attaquant peut convaincre un agent d'enregistrer une règle nuisible, un fait erroné ou une préférence modifiée. Des sessions ultérieures peuvent récupérer cette entrée après la disparition du contenu malveillant initial.

Les équipes qui construisent une base de connaissances personnelle sont confrontées à une question de confiance connexe. Les informations récupérées doivent conserver leur source et leur contexte d'accès, en particulier lorsqu'un agent peut agir sur elles.

La mémoire ne doit pas devenir un plan de contrôle invisible. Les opérations d'écriture ont besoin de contraintes, de traces d'audit et d'une séparation claire entre les préférences approuvées par l'utilisateur et les observations générées par le modèle.

La navigation ajoute son propre risque. Une page peut contenir des instructions visibles, du texte caché, des métadonnées, du contenu d'image ou du matériel adversarial conçu pour un modèle plutôt que pour une personne. L'agent traite ce contenu parce que la navigation est sa fonction prévue.

Google a indiqué surveiller le web public à la recherche de schémas connus d'injection indirecte. Ses recherches sur les menaces web ont traité ces schémas comme une priorité, car les agents de navigation consomment régulièrement des pages contrôlées par des attaquants.

Cela crée un compromis structurel. Plus l'accès d'un agent à l'information s'élargit, plus il rencontrera de contenu non fiable. Plus il reçoit d'autorité, plus l'impact potentiel d'une interprétation erronée est important.

Éliminer tout contenu externe rendrait de nombreux agents inutiles. Accorder à tout contenu externe la même influence les rend dangereux. Les frameworks doivent préserver l'utilité tout en imposant des frontières que le langage seul ne peut garantir.

Cela implique de séparer la planification de l'autorisation. Un modèle peut proposer une action, en expliquer la raison et préparer les paramètres. Un service de politiques déterministe doit décider si l'action est autorisée.

La décision doit tenir compte de l'utilisateur actuel, de la tâche demandée, de la ressource cible, de la sensibilité des données et de la provenance du contenu. Les actions à fort impact doivent exiger une confirmation qui montre clairement ce qui va se produire.

La confirmation ne doit pas être entièrement rédigée par le modèle potentiellement compromis. Sinon, un attaquant peut influencer à la fois l'action proposée et la description présentée à l'utilisateur.

Une interface digne de confiance doit construire les détails critiques à partir de paramètres d'outil validés. Elle doit identifier la destination, les enregistrements affectés, les autorisations demandées et toutes les données prévues pour quitter le système.

C'est ainsi que le rayon d'impact devient mesurable. Même si l'injection de prompt réussit au niveau du langage, l'attaquant rencontre des contrôles distincts à chaque frontière importante.

Le résultat ressemble davantage à la sécurité applicative mature qu'à une ingénierie astucieuse des prompts. Le moindre privilège, l'isolation, l'autorisation explicite, la validation des sorties, la journalisation et la réponse aux incidents restent essentiels.

Pourquoi des prompts système plus robustes ne peuvent pas porter la frontière de sécurité

Le renforcement des prompts réduit les attaques réussies, mais les défaillances résiduelles le rendent inadapté comme couche finale d'autorisation.

Les prompts système peuvent demander à un agent d'ignorer les instructions trouvées dans du contenu externe. Ils peuvent étiqueter les sources comme non fiables et rappeler au modèle de suivre uniquement l'objectif de l'utilisateur.

Ces mesures méritent d'être utilisées. Elles peuvent bloquer des attaques simples, réduire les écarts accidentels et obliger les adversaires à fournir davantage d'efforts. Elles aident également les modèles à expliquer un contenu suspect au lieu d'agir immédiatement.

Des chercheurs de Google ont testé les prompts de sécurité dans un framework de programmation multi-agents. Leur étude multi-agents a couvert plus de 150 scénarios d’attaque à un tour et 32 scénarios à plusieurs tours.

Un mécanisme de renforcement de sécurité d’environ 500 tokens a fait passer les taux d’échec à un tour de 19,48 % à 2,60 %. Les taux d’échec à plusieurs tours sont passés de 75 % à 46,88 %.

Ces résultats plaident en faveur du renforcement des prompts tout en révélant sa limite. Un taux d’échec de 46,88 % sur plusieurs tours reste inacceptable lorsqu’un agent peut exécuter du code, accéder à des identifiants ou modifier des ressources de production.

Même le taux plus faible à un tour crée un risque important à grande échelle. Les interactions répétées offrent aux adversaires davantage d’occasions, et les attaquants peuvent adapter leur langage après avoir observé le comportement du modèle.

L’étude a également constaté que les attaques réussies se sont orientées vers des enveloppes fonctionnelles. Ces attaques dissimulent une intention malveillante dans des tâches qui ressemblent à des fonctions d’agent ordinaires. Les instructions statiques peinent à les rejeter sans bloquer également le travail légitime.

C’est le problème central lorsqu’on place la frontière de sécurité à l’intérieur du modèle. Le modèle doit interpréter une demande ouverte tout en prédisant si cette demande enfreint une autre instruction tout aussi ouverte.

Il n’évalue pas une règle d’autorisation stable comme un système d’exploitation vérifie l’accès à un fichier. Il produit une réponse probabiliste influencée par chaque token pertinent de son contexte.

Expliquer l’injection de prompt uniquement comme le fait d’« ignorer les instructions précédentes » passe à côté de cette ambiguïté. Les attaques efficaces n’annoncent pas toujours un conflit. Elles peuvent présenter un faux contexte, imiter le langage d’un flux de travail de confiance ou répartir leur intention sur plusieurs étapes.

Un agent chargé de revoir du code peut rencontrer un texte qui semble décrire un test requis. Ce test télécharge ou exécute discrètement un composant externe. Chaque étape prise isolément peut paraître plausible dans un flux de développement.

Un agent de navigation peut se voir dire qu’une action précise est nécessaire pour accéder à la page demandée. Un assistant bureautique pourrait lire un document affirmant que la politique de l’entreprise exige le transfert de contenu pour examen de conformité.

Le modèle ne possède pas une connaissance indépendante des politiques réelles de chaque organisation. Si le framework autorise des affirmations générées par le modèle à autoriser des actions générées par le modèle, le système devient circulaire.

Les filtres rencontrent une limite similaire. Un détecteur peut rechercher des formulations connues ou estimer si un texte semble adversarial. Les attaquants peuvent paraphraser des instructions, fragmenter des charges utiles, les dissimuler dans différents formats ou les faire ressembler à des données normales.

Bloquer chaque phrase impérative détruirait les flux de travail courants. Les documents, e-mails, commentaires de code et tickets de support contiennent légitimement des instructions. L’agent doit souvent comprendre ces instructions sans les adopter comme ses propres objectifs.

Le fine-tuning peut améliorer la résistance, mais il ne supprime pas le conflit architectural. Les modèles doivent toujours interpréter un langage non fiable, et de nouveaux schémas d’attaque peuvent se situer hors de leur distribution d’entraînement.

La génération augmentée par récupération ne supprime pas non plus le conflit. Le RAG récupère des contenus externes et les ajoute au contexte du modèle. Si la source est empoisonnée, la récupération peut transmettre l’instruction de l’attaquant précisément lorsqu’elle semble pertinente.

Les mises à niveau de modèles peuvent même modifier le risque de manière inattendue. Un modèle plus capable pourrait mieux détecter les attaques, mais il pourrait aussi utiliser les outils plus efficacement après la réussite d’une attaque.

C’est pourquoi les scores de benchmark nécessitent du contexte. Un modèle qui rejette la plupart des injections dans une suite de tests fixe n’établit pas qu’un agent déployé est sûr. Les systèmes réels contiennent des outils personnalisés, des autorisations, de la mémoire et des intégrations.

L’objectif défensif devrait être l’échec contrôlé. Lorsque le modèle classe mal un contenu, le système environnant doit contenir les conséquences, rendre visible la tentative et préserver les éléments probants pour examen.

Un agent en lecture seule peut toujours induire un utilisateur en erreur, la qualité des sorties reste donc importante. Toutefois, les conséquences les plus graves apparaissent généralement lorsque les frameworks combinent un raisonnement incertain à une autorité sans limites.

Les prompts de sécurité doivent donc s’inscrire dans une conception en couches. Ils constituent un contrôle parmi d’autres, et non celui qui décide si des données privées franchissent une frontière ou si du code exécutable atteint un poste de travail.

La sécurité des agents IA dépend des capacités, du contexte et du consentement

Les frameworks devraient traiter le modèle comme un planificateur non fiable dont les propositions exigent des contrôles applicables.

Le premier contrôle architectural consiste à minimiser les capacités. Un agent ne devrait recevoir que les outils nécessaires à la tâche en cours, et non toutes les intégrations disponibles pour l’utilisateur ou l’organisation.

Un résumeur de calendrier a rarement besoin de l’autorisation d’envoyer des e-mails. Un assistant de recherche n’a pas automatiquement besoin d’un accès au shell. Un réviseur de code peut avoir besoin d’accéder au dépôt en lecture sans être autorisé à fusionner des changements.

Le principe statique du moindre privilège est utile, mais des autorisations spécifiques à la tâche sont préférables. Un outil peut devenir disponible pour une opération limitée, puis disparaître une fois cette opération terminée.

Les identifiants devraient également rester hors du contexte du modèle. Le modèle devrait demander une opération par l’intermédiaire d’un courtier plutôt que de manipuler directement des secrets réutilisables. Les journaux devraient masquer les tokens sensibles dans les prompts et les réponses des outils.

Le deuxième contrôle est l’autorisation contextuelle. Les vérifications d’accès traditionnelles répondent souvent à la question de savoir si un utilisateur peut accéder à une ressource. Les systèmes d’agents doivent aussi déterminer si cet accès soutient la demande actuelle de l’utilisateur.

Un utilisateur qui peut lire deux comptes clients n’a pas nécessairement autorisé un agent à les combiner. Un développeur disposant d’un accès au déploiement n’a pas autorisé chaque agent de revue de code à déployer.

L’intention ne peut pas être parfaitement déduite du langage, mais les frameworks peuvent la restreindre au moyen de déclarations explicites de tâche. Ils peuvent lier les outils à un objectif déclaré, à un ensemble de ressources, à une fenêtre temporelle et à un flux de données autorisé.

Le troisième contrôle est le consentement pour les actions ayant des conséquences. L’approbation humaine est particulièrement importante avant d’envoyer des informations à l’extérieur, de dépenser de l’argent, de modifier des accès, de supprimer des données ou d’exécuter du code non fiable.

Le consentement doit être significatif. Des fenêtres contextuelles vagues et répétées entraînent les utilisateurs à approuver sans examiner. L’interface devrait identifier l’action exacte et mettre en évidence les écarts par rapport à la tâche initiale.

Les actions réversibles et à faible risque peuvent utiliser des contrôles plus légers. Les actions à haut risque ou irréversibles exigent une confirmation plus forte et, en entreprise, potentiellement un second approbateur.

Le quatrième contrôle est l’isolation. L’exécution de code devrait se dérouler dans un sandbox avec un accès restreint au réseau, au système de fichiers et aux identifiants. Les sessions de navigateur devraient séparer les pages non fiables de l’état sensible des applications.

Les sorties des outils devraient être traitées comme des données plutôt que comme des instructions automatiquement fiables. Les frameworks devraient valider la taille, le format, la destination et le contenu autorisé des sorties avant de les renvoyer au modèle.

Le cinquième contrôle est la préservation de la provenance. Chaque document, message, page web, élément de mémoire et réponse d’agent devrait porter son origine et sa classification de confiance.

Lorsqu’un agent résume une page non fiable, le résumé doit rester non fiable. La transformation ne devrait pas effacer la filiation. Un moteur de politiques en aval peut alors empêcher des contenus peu fiables d’autoriser des actions à fort impact.

Le sixième contrôle est la séparation entre proposition et exécution. Un planificateur peut décider qu’un e-mail devrait être envoyé, mais un composant distinct devrait valider les destinataires et les pièces jointes.

Cette séparation limite les attaques de deputy confus. Un deputy confus survient lorsqu’un système disposant d’une autorité légitime est manipulé pour utiliser cette autorité au service de l’objectif de quelqu’un d’autre.

Le septième contrôle est l’observabilité. Les équipes ont besoin de traces indiquant quelle source a influencé une décision, quel modèle a proposé une action, quelle politique l’a autorisée et quel outil l’a exécutée.

Sans ces traces, une organisation ne peut pas reconstituer un incident impliquant un agent. Les journaux d’applications ordinaires peuvent enregistrer des appels d’API tout en omettant le prompt, le contenu récupéré, l’état de la mémoire et les messages entre agents.

La surveillance devrait également se concentrer sur les comportements. Les signaux d’alerte comprennent des combinaisons inhabituelles de ressources, des échecs d’autorisation répétés, de nouvelles destinations sortantes, des écritures mémoire inattendues ou des outils utilisés hors de leur séquence normale.

Le huitième contrôle est le test adversarial sur des flux de travail complets. Tester uniquement le modèle de base ignore le framework où résident les autorisations et les effets de bord.

L’approche du NIST utilise des outils et des tâches réalistes, car la sécurité des agents est contextuelle. Un modèle peut résister à une attaque dans une discussion simple, puis échouer lorsque la même instruction apparaît dans un objet métier d’apparence fiable.

Les équipes de red team devraient placer du contenu malveillant dans chaque source qu’un agent consomme. Cela inclut les sites web, e-mails, documents, dépôts de code, outils de suivi des problèmes, métadonnées d’outils, résultats de recherche et mémoires partagées.

Elles devraient également tester les parcours à plusieurs tours et à plusieurs agents. Une commande directe bloquée peut réussir après avoir été reformulée par un agent intermédiaire ou stockée pour une récupération ultérieure.

L’objectif n’est pas de publier un taux unique de réussite des injections de prompt. Il s’agit d’identifier quelles injections réussies atteignent des données sensibles, des outils privilégiés ou des opérations irréversibles.

Cela permet une meilleure priorisation. Une injection fréquente qui ne corrompt qu’un brouillon temporaire mérite de l’attention. Une injection plus rare qui atteint des identifiants de production exige d’abord des contrôles plus robustes.

OWASP recommande le moindre privilège, la séparation des contenus externes, l’approbation humaine, la validation des sorties et les tests adversariaux. Ces mesures reflètent un modèle de défense en profondeur plutôt qu’une confiance accordée à un seul détecteur.

La taxonomie des attaques plus large du NIST souligne également la nécessité de gérer les conséquences en parallèle de l’identification des attaques. Cette approche convient aux systèmes d’agents, car une prévention complète reste incertaine.

Aucun de ces contrôles ne rend le modèle digne de confiance. Ils rendent le système moins dépendant de la fiabilité du modèle, ce qui constitue un objectif d’ingénierie plus défendable.

Ce que les lecteurs de Google News devraient surveiller ensuite

Les preuves décisives viendront des paramètres par défaut des frameworks, d’un confinement mesurable et de rapports d’incidents transparents.

Le premier signal est de savoir si les principaux frameworks font de l’exécution restreinte le comportement par défaut. Les contrôles de sandboxing et d’autorisation facultatifs aident les équipes expérimentées, mais les valeurs par défaut façonnent des milliers de déploiements ordinaires.

Observez comment les plateformes d’agents gèrent l’attribution des outils, l’accès réseau, les écritures dans le système de fichiers et les identifiants réutilisables. Un framework qui expose d’abord de larges capacités et documente le renforcement ensuite conserve le risque sous-jacent.

Le meilleur comportement par défaut n’accorderait automatiquement aucun outil sensible. Les développeurs ajouteraient des capacités étroitement délimitées tout en voyant les conséquences de chaque autorisation.

Le deuxième signal est de savoir si les évaluations mesurent l’impact de bout en bout. Les taux de rejet des attaques sont utiles, mais ils ne révèlent pas si une attaque réussie a atteint des données confidentielles ou mené à bien une action dangereuse.

De meilleures évaluations feront état à la fois de la compromission du modèle et de la compromission du système. Elles distingueront une réponse manipulée d’une lecture non autorisée, d’un transfert sortant, d’une exécution de code ou d’une modification persistante de la mémoire.

Elles devraient également publier des résultats sur des tentatives répétées. Une défense qui réussit une fois mais échoue après plusieurs variantes offre une protection limitée dans un service exposé à Internet.

Les résultats de la recherche de Google illustrent ce besoin. Le renforcement des prompts a considérablement amélioré la résistance, mais les attaques à plusieurs tours ont conservé un taux d’échec élevé. Les contrôles architecturaux déterminent ce que signifient ces échecs résiduels.

Le troisième signal concerne la qualité de la divulgation. Les incidents propres à l’IA manquent souvent des éléments habituels de la gestion traditionnelle des vulnérabilités. Les équipes peuvent recevoir un article de blog d’un fournisseur sans identifiant standard, plage de versions affectées ni voie de remédiation claire.

Les fournisseurs de frameworks devraient publier des avis de sécurité décrivant l’intégralité de la chaîne d’attaque. Les utilisateurs doivent connaître la source de contenu requise, le comportement du modèle, les autorisations, les outils, les versions affectées et les mesures d’atténuation disponibles.

De vagues affirmations selon lesquelles un modèle aurait reçu des « protections supplémentaires » ne suffisent pas. Les clients doivent comprendre si le fournisseur a modifié le modèle, la politique du framework, le système d’autorisations, le sandbox ou le flux d’approbation des utilisateurs.

La même norme devrait s’appliquer aux décisions liées aux programmes de bug bounty. Si un rapport démontre une injection de prompt sans effet significatif, une faible gravité peut être justifiée. Si l’injection permet d’atteindre une action privilégiée, la rejeter comme un comportement attendu du modèle revient à éviter le véritable problème.

Google News continuera de mettre en avant des démonstrations d’injection de prompt, car elles sont frappantes et faciles à reproduire. Certaines ne seront que des jailbreaks mineurs, tandis que d’autres révéleront de graves défaillances des frameworks.

Les lecteurs devraient distinguer trois questions. L’attaquant a-t-il influencé le modèle ? Quelle capacité est devenue disponible après cette influence ? Quel contrôle indépendant aurait dû empêcher l’action qui en a résulté ?

Cette séquence produit une évaluation des risques plus utile que de se demander si l’injection de prompt a enfin été résolue. Les éléments actuels ne permettent pas de supposer l’existence d’une solution universelle.

Les développeurs devraient examiner chaque chemin entre du contenu non fiable et des outils sensibles. Les acheteurs en entreprise devraient exiger des autorisations limitées à la tâche, la traçabilité de provenance, le sandboxing, des contrôles d’approbation et des registres d’exécution auditables.

Les travailleurs du savoir devraient vérifier à quoi un agent peut accéder avant de connecter leurs e-mails, fichiers, calendriers et systèmes professionnels. La commodité augmente rapidement lorsque ces sources sont combinées, mais le rayon d’impact potentiel aussi.

Le renversement central reste simple. L’injection de prompt est le déclencheur, tandis que le framework fournit la portée, l’autorité et la persistance. Ne traiter que le déclencheur laisse la machinerie dangereuse inchangée.

La prochaine fois qu’un titre de Google News annoncera le détournement d’un nouvel agent, regardez au-delà des mots malveillants. Demandez-vous quel outil les a exécutés, quelle autorisation les a permis et pourquoi aucun contrôle distinct n’est intervenu.

C’est l’épreuve que les concepteurs d’agents doivent désormais réussir. Le système peut-il rester sûr après que son modèle a été persuadé, désorienté ou simplement s’est trompé ? Si la réponse dépend uniquement d’un meilleur prompt, le framework porte toujours le bug.