Autrefois signal d’un risque d’exploitation, le « tiercé trio mortel » de Willison décrit les opérations de base de chaque agent d’IA aujourd’hui. En conséquence, la sécurité des agents n’est plus architecturale. Voici ce qu’il faut surveiller à la place.
En juin 2025, Simon Willison, l’ingénieur qui a inventé le terme « injection rapide », a publié un avertissement qui a largement circulé au sein de la communauté de la sécurité. Il l’a appelé le trio mortel – trois capacités qui, lorsqu’elles sont combinées dans un seul agent d’IA, créent une voie presque garantie vers l’exploitation par injection indirecte rapide : l’accès aux données privées ; exposition à du contenu non fiable ; la capacité de communiquer avec l’extérieur.
Le cadrage était net et utile. Si votre agent lit votre courrier électronique, ingère du contenu Web arbitraire et peut émettre des requêtes sortantes, un attaquant qui intègre des instructions malveillantes n’importe où dans ce pipeline de contenu peut demander à l’agent d’exfiltrer vos données sans que vous le sachiez. Willison a illustré ce point avec une longue liste d’exploits réels en production : Microsoft 365 Copilot, le serveur MCP de GitHub, GitLab Duo, Slack AI, Google Bard, Amazon Q. La même classe d’attaque, encore et encore.
Le trio a fonctionné comme un signal car, à l’époque, les agents avaient pour la plupart une portée étroite. Un agent capable d’effectuer seulement une ou deux des activités mortelles du tiercé trio pourrait être considéré comme présentant un risque plus faible. Éviter la combinaison semblait être une stratégie de conception viable.
Cette fenêtre s’est fermée compte tenu de ce que les praticiens déploient aujourd’hui : un agent d’assistance en contact avec le client lit l’historique des tickets et les enregistrements des clients, ingère les messages des utilisateurs et les fichiers joints, et appelle les CRM, les API de remboursement ou les systèmes de billetterie. Une IA de messagerie lit votre boîte de réception et votre calendrier, traite les messages entrants provenant d’étrangers et envoie des réponses en votre nom.
Plutôt que de constituer des cas extrêmes ou des déploiements mal conçus, ce sont les agents que les entreprises et les particuliers souhaitent réellement, et ce sont ceux vers lesquels les fournisseurs s’orientent.
Trifecta mortel comme configuration par défaut
Ross McKerchar, RSSI chez Sophos, l’a clairement exprimé dans un article publié en mai : « les capacités que les praticiens souhaitent réellement (lire mes données, comprendre le contexte externe, agir) s’enfoncent fermement dans un territoire dangereux. Il ne s’agit pas d’une mauvaise configuration ; c’est le coût architectural de l’utilité. » Il a raison. Un agent sans accès aux données privées est inutile, celui qui ne peut pas traiter le contenu externe est isolé et celui qui ne peut pas communiquer avec l’extérieur est inerte. Supprimez n’importe quelle partie du tiercé gagnant et vous obtenez quelque chose de plus proche d’un champ de recherche que d’un agent.
Si chaque architecture d’agent légitime présente les trois propriétés du trio, le trio n’est plus un indicateur significatif de risque élevé. C’est la configuration par défaut. Le traiter comme un signal d’alarme revient à traiter la résolution DNS comme un signal de compromission du réseau. Techniquement vrai dans certains modèles de menace, mais universellement présent dans chaque déploiement réel.
L’article de McKerchar définit la réponse comme une « réduction du rayon d’explosion » : une philosophie opérationnelle raisonnable, mais qui accepte le trio comme une condition donnée plutôt que comme une condition évitable. C’est une décision raisonnable. La question est de savoir ce qui vient après l’acceptation.
L’équipe de sécurité de Meta est arrivée à la même conclusion dans l’autre sens. En octobre 2025, ils ont publié la « Règle de deux », un cadre qui recommande aux agents de ne pas satisfaire plus de deux des trois propriétés du trio en une seule session, l’approbation d’un humain étant requise si les trois sont nécessaires. Willison lui-même a approuvé le cadre comme « le meilleur conseil pratique pour créer aujourd’hui des systèmes d’agents sécurisés basés sur LLM ».
La section sur les limitations de Meta admet cependant que de nombreux cas d’utilisation recherchés ne s’adapteront pas parfaitement au cadre et que « les conceptions qui satisfont à la règle de deux des agents peuvent toujours être sujettes à l’échec ». Il ne s’agit pas d’une critique du framework mais d’une confirmation que le problème a dépassé la solution au niveau de l’architecture.
L’ampleur de l’exposition n’est plus théorique. L’analyse effectuée par Google en avril 2026 dans le référentiel Common Crawl a révélé des tentatives d’injection rapides dans des pages Web publiques, allant des canulars aux charges utiles d’exfiltration de données, avec des tentatives malveillantes en hausse de 32 % entre novembre 2025 et février 2026. Google a noté que la sophistication reste faible pour l’instant, mais a signalé cette tendance comme un signal d’intérêt croissant des attaquants.
L’environnement contre lequel le trio mettait en garde est arrivé.
Comment détective un agent compromis
Si le trio décrit presque tous les agents déployés, les praticiens ont besoin de signaux qui distinguent un comportement compromis du fonctionnement normal au sein d’un système présentant un trio. Cela signifie passer des évaluations au niveau de l’architecture à la détection comportementale à l’exécution.
Les preuves de production sont arrivées en grappe. Du 7 au 15 janvier 2026, des chercheurs ont divulgué des exploits contre quatre outils de productivité d’IA distincts en huit jours : IBM Bob, Superhuman AI, Notion AI et Claude Cowork d’Anthropic. Chacun a utilisé une injection rapide indirecte pour exfiltrer les données via un canal auquel l’agent avait un accès légitime. Dans le cas de Cowork, une invite cachée intégrée dans un document téléchargé a demandé à l’agent d’exfiltrer les fichiers via le propre domaine API d’Anthropic sur liste blanche, invisible à tout contrôle de périmètre et impossible à distinguer du comportement normal de l’agent jusqu’à ce que les données aient déjà disparu. Dans tous ces cas, le tiercé trio n’était pas un facteur de risque mais la condition opératoire.
Voici ce qu’il vaut la peine d’observer pour détecter qu’un agent a été compromis.
Anomalies de suivi des instructions. Un agent compromis ne fait généralement pas quelque chose de structurellement différent d’un agent sain. Suivre les instructions est sa fonction normale. La différence réside dans les instructions qu’il suit. Recherchez les actions d’agent qui n’ont aucune correspondance plausible avec une tâche initiée par l’utilisateur. Un agent à qui il a été demandé de résumer un rapport trimestriel, mais qui tente ensuite d’envoyer une requête DNS sortante vers un domaine inconnu, n’a pas spontanément décidé de le faire. Quelque chose dans le contenu qu’il a ingéré le lui a dit.
Séquences d’appels d’outils qui brisent la topologie attendue. Dans un système d’agents bien conçu, le graphique des appels d’outils pour une tâche donnée doit être relativement prévisible. Un agent de codage invoqué pour corriger un bug doit toucher des fichiers, exécuter des tests, peut-être vérifier la documentation. Il ne devrait pas s’agir d’API de messagerie ou de calendrier. Les séquences d’appels d’outils qui dépassent les limites attendues du flux de travail méritent d’être signalées, même lorsque chaque appel individuel semble légitime en soi.
Exfiltration via des canaux à faible bande passante. L’attaque classique d’exfiltration par injection rapide achemine les données volées via un mécanisme auquel l’agent a un accès légitime : une URL d’image rendue avec des paramètres de requête codés, un appel API avec des données intégrées dans un paramètre, un lien dans un document généré. Cela ne ressemble pas à du vol de données isolément ; ils ressemblent à la sortie normale d’un agent. La détection nécessite de corréler les données auxquelles l’agent a eu accès avec ce qu’il a intégré dans sa sortie. Cela nécessite une visibilité de bout en bout sur les actions de l’agent, et pas seulement sur la réponse finale.
Accès aux informations d’identification et secrets en dehors du champ d’application de la tâche. Si un agent ayant un accès légitime à un magasin de secrets ou à un coffre de clés touche des informations d’identification qui n’ont aucun rapport avec la tâche en cours, c’est un signal. Un agent corrigeant un bogue de rendu React ne devrait probablement pas lire les informations d’identification AWS. La portée du moindre privilège est ici la défense architecturale, mais la surveillance de l’accès aux informations d’identification hors portée est la couche de détection qui détecte les échecs dans cette portée.
Anomalies d’écriture en mémoire. Les agents dotés d’une mémoire persistante constituent une surface d’attaque croissante. Une entrée de mémoire empoisonnée qui ressemble à un contexte utilisateur légitime mais contient des instructions de déclenchement dormantes peut persister au fil des sessions et se déclencher longtemps après l’injection initiale. La surveillance des écritures en mémoire contenant du contenu de type instruction, ou des écritures effectuées au cours de sessions ayant ingéré du contenu non fiable, mérite d’être ajoutée à tout pipeline d’observabilité d’agent.
Le runtime seul peut répondre à la menace de redirection des agents
Pour les praticiens exploitant l’infrastructure des agents de production, le tiercé trio mortel vous dit ce que vous savez : vos agents sont exposés. La question est de savoir quoi faire à ce sujet.
Les réponses se trouvent au niveau de la couche d’exécution, et non au niveau de la couche d’architecture. C’est là que résident l’EDR et le SIEM pour l’infrastructure traditionnelle : les agents ont besoin de la même instrumentation, et la plupart des déploiements ne l’ont pas encore. Traces d’exécution complètes à chaque appel d’agent. Détection d’anomalies d’appel d’outil. Criblage d’entrée lors de l’ingestion. Surveillance de l’accès aux informations d’identification limitée au contexte de la tâche. Audit d’écriture en mémoire. Pas un attaquant humain qui se connecte. Un agent qui a été discrètement redirigé.
Le trio de Willison était la bonne alarme pour le moment, c’était l’année dernière. Presque tous les agents de production correspondent désormais à ce profil. Pour cette raison, seule la détection des anomalies d’exécution peut potentiellement fournir une défense adéquate. Les signaux ci-dessus sont un bon point de départ.
