Oracle poisoning : corrompre le graphe de connaissances sur lequel raisonne un agent
Un article publié sur arXiv le 10 mai 2026 définit l'Oracle Poisoning : corrompez le graphe de connaissances qu'un agent interroge à l'exécution et il tire de fausses conclusions par un raisonnement correct. Sur neuf modèles, la confiance dans les données empoisonnées a atteint 100 % en requêtes agentiques dirigées.
De quoi s’agit-il ?
Le 10 mai 2026, les chercheurs Ben Kereopa-Yorke, Guillermo Diaz, Holly Wright, Reagan Johnston, Ron F. Del Rosario et Timothy Lynar ont publié Oracle Poisoning: Corrupting Knowledge Graphs to Weaponise AI Agent Reasoning (arXiv:2605.09822, cs.CR/cs.AI). Ils définissent l’Oracle Poisoning comme une classe d’attaque où un adversaire corrompt un graphe de connaissances structuré qu’un agent IA interroge à l’exécution via le tool-use, de sorte que l’agent aboutit à des conclusions erronées par un raisonnement correct.
La distinction avec la prompt injection est essentielle. La prompt injection altère les instructions de l’agent ; l’Oracle Poisoning altère les données sur lesquelles l’agent raisonne. Le modèle n’est jamais poussé à mal se comporter : il récupère fidèlement un fait depuis un outil de confiance et raisonne sainement à partir de lui. Le fait est simplement faux. C’est la même famille de problème d’intégrité que celle explorée pour la récupération sur graphe par des travaux comme KEPo (empoisonnement par évolution de connaissances du RAG sur graphe, ACM Web Conference 2026), mais démontrée ici contre un système agentique à l’échelle de la production, et non sur un benchmark.
Comment ça marche
De nombreux agents traitent désormais un graphe de connaissances comme un oracle faisant autorité : un appel d’outil renvoie des nœuds et des arêtes (entités, relations, affirmations), et l’agent intègre ces résultats dans sa réponse. L’article étudie un graphe de connaissances de code de 42 millions de nœuds en production et présente six scénarios d’attaque où un adversaire modifie le contenu du graphe — par exemple en injectant l’affirmation fabriquée qu’un composant est sûr.
L’évaluation utilise du tool-use SDK réel sur neuf modèles de trois fournisseurs (N=30 par modèle) : le modèle invoque de façon autonome un outil de requête sur le graphe et raisonne à partir des résultats. Les constats :
- Requêtes dirigées : chaque modèle testé a accepté les données empoisonnées à 100 % dès que l’attaquant atteignait une « sophistication modérée » (niveau L2). Dans 269 des 270 essais valides, les modèles ont accepté des affirmations de sécurité fabriquées.
- Invites ouvertes : la confiance chute à 3–55 %, ce que les auteurs signalent comme un biais de formulation — en rapportant honnêtement les deux conditions plutôt qu’en sélectionnant la plus flatteuse.
- Un gradient de sophistication avec points de bascule : la confiance passe de 0 % à 100 % au-delà d’un niveau de compétence minimal, reformulant la question en combien d’efforts il faut, et non si l’attaque fonctionne.
- Le mode de livraison est un biais de premier ordre. Évaluer la même charge en mode inline peut produire des faux négatifs : GPT-5.1 montre 0 % de confiance en inline, mais 100 % sous tool-use agentique simulé et réel. Tester un modèle dans une fenêtre de chat ne dit pas comment son agent se comportera.
Aucune chaîne d’exploitation n’est nécessaire pour comprendre la leçon, et aucune n’est reproduite ici : le mécanisme relève de l’intégrité des données, pas d’une invite habile.
Pourquoi c’est important
Les systèmes agentiques sous-traitent de plus en plus la « vérité de terrain » à des couches de récupération — graphes de connaissances, bases vectorielles, wikis internes — en supposant que les données récupérées sont dignes de confiance. L’Oracle Poisoning montre que cette hypothèse est porteuse et largement non protégée. Si un attaquant peut écrire dans l’oracle, l’agent devient un relais confiant et bien argumenté des affirmations de l’attaquant, et les défenses habituelles (alignement, hiérarchies d’instructions, filtres anti-injection) ne s’activent jamais puisqu’aucune instruction n’a été injectée.
Les auteurs notent que l’attaque semble se généraliser à l’écosystème des graphes de connaissances, d’après l’analyse de quatre plateformes supplémentaires. La surface d’exposition concrète se situe partout où un agent dispose, ou peut être orienté vers, un magasin de connaissances partagé et mutable — graphes d’intelligence de code, CMDB, graphes de threat intel, corpus RAG avec chemins d’écriture.
Défenses
L’article évalue cinq défenses et reconnaît franchement qu’une seule est décisive :
- Le contrôle d’accès en lecture seule élimine le vecteur de mutation directe — si les agents et les rédacteurs non fiables ne peuvent pas modifier l’oracle, le chemin d’attaque le plus net se ferme. Traitez le graphe de connaissances comme un magasin privilégié, avec autorisation d’écriture stricte et journalisation d’audit.
- Les quatre autres défenses sont partielles et dépendantes du modèle ; ne misez pas sur une seule. Superposez-les.
- Provenance et intégrité du contenu du graphe : signez ou attribuez les affirmations, tracez qui a écrit chaque nœud/arête, et exposez la confiance/la source à l’étape de raisonnement au lieu de présenter les faits récupérés comme une vérité inconditionnelle.
- Testez en tool-use réel, pas en inline. Comme le mode de livraison inverse les résultats, les évaluations de sécurité et les exercices de red team doivent exercer le vrai chemin agentique, sinon ils rapporteront des faux négatifs.
- Contraignez la confiance dans les affirmations récupérées : exigez une corroboration pour les assertions à fort impact (par exemple « X est sûr »), et gardez un humain dans la boucle pour les décisions qui reposent sur un seul fait récupéré.
État
| Élément | Valeur |
|---|---|
| Article | Oracle Poisoning (arXiv:2605.09822) |
| Publié | 10 mai 2026 |
| Classe | Empoisonnement de graphe/oracle (distinct de la prompt injection) |
| Testé | 9 modèles, 3 fournisseurs, graphe de code de 42 M de nœuds |
| Résultat phare | 100 % de confiance dans les données empoisonnées en requêtes agentiques dirigées (L2) |
| Défense la plus forte | Contrôle d’accès en lecture seule (les autres partielles, dépendantes du modèle) |
Date clé : 10 mai 2026 — première démonstration empirique d’un empoisonnement de graphe de connaissances contre un système agentique à l’échelle de la production. Cet article résume des travaux de recherche publics à des fins défensives et ne reproduit aucune charge d’attaque.