🤖 AI

Oracle Poisoning: Corrupting Knowledge Graphs to Weaponise AI Agent Reasoning

Cet article présente et valide empiriquement l'« empoisonnement d'oracle », un nouveau vecteur d'attaque par lequel des adversaires corrompent des graphes de connaissances structurés pour contraindre des agents d'IA à tirer des conclusions erronées via un raisonnement par ailleurs valide, démontrant que les modèles actuels font systématiquement confiance aux données empoisonnées lorsqu'elles sont accessibles via des protocoles d'utilisation d'outils et mettant en évidence des lacunes critiques dans les tests intégrés.

Auteurs originaux : Ben Kereopa-Yorke, Guillermo Diaz, Holly Wright, Reagan Johnston, Ron F. Del Rosario, Timothy Lynar

Publié 2026-05-12

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Ben Kereopa-Yorke, Guillermo Diaz, Holly Wright, Reagan Johnston, Ron F. Del Rosario, Timothy Lynar

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

L'idée centrale : Le piège du « Bibliothécaire de confiance »

Imaginez que vous avez un assistant IA brillant (l'« Agent ») qui vous aide à écrire du code ou à vérifier des failles de sécurité. Cet assistant est incroyablement intelligent et raisonne parfaitement. Cependant, il présente une faiblesse majeure : il est aveugle au monde extérieur.

Pour accomplir sa tâche, l'IA s'appuie entièrement sur une immense bibliothèque numérique structurée appelée Graphique de Connaissance. Imaginez ce graphique comme une carte géante de l'ensemble de votre base de code logiciel, montrant comment chaque morceau de code est connecté à tous les autres.

L'IA traite cette carte comme un Oracle—une source de vérité absolue. Elle ne remet pas en question la carte ; elle suppose que la carte est 100 % exacte. Si la carte indique que « la Fonction A appelle la Fonction B », l'IA le croit sans vérifier une deuxième source.

Oracle Poisoning est l'attaque où un mauvais acteur s'infiltre dans la bibliothèque et modifie la carte. Ils ne brisent pas le cerveau de l'IA ; ils ne trompent pas l'IA avec des mots confus. Au lieu de cela, ils altèrent silencieusement les faits sur la carte. Parce que l'IA est si bonne pour raisonner, elle prend ces nouveaux faits faux et tire une conclusion parfaitement logique—mais complètement erronée.

L'analogie : La Caverne de Platon et le mur des ombres

Les auteurs comparent cela à la Caverne de Platon.

Le Prisonnier : L'Agent IA.
Le Mur : Le Graphique de Connaissance.
Les Ombres : Les réponses que l'IA obtient lorsqu'elle pose des questions au graphique.
La Chaîne : Le protocole (appelé MCP) qui lie l'IA au mur, la forçant à accepter les ombres comme réalité.

Si un attaquant peint une fausse ombre sur le mur, le prisonnier (l'IA) l'étudiera, l'analysera parfaitement et conclura : « C'est un vrai tigre », même s'il ne s'agit que d'une peinture. Plus le prisonnier est intelligent, plus sa conclusion erronée sera détaillée et convaincante.

Comment fonctionne l'attaque (Le « Comment faire »)

Les chercheurs ont testé cela sur un système réel comportant 42 millions de nœuds (une bibliothèque numérique massive). Ils ont découvert qu'un attaquant n'a besoin que de faire des changements minuscules et chirurgicaux sur la carte pour tromper l'IA.

Ils ont démontré six façons de le faire :

Le Faux Paquet : Créer un faux paquet logiciel dans la bibliothèque qui ressemble à la « dernière version, la plus sécurisée », trompant l'IA pour qu'elle le recommande.
Le Désinfectant Invisible : Ajouter une fausse fonction « garde de sécurité » sur la carte qui n'existe pas réellement dans le code. L'IA la voit sur la carte et conclut : « Ah, ce code est sûr ! » alors qu'il est en réalité vulnérable.
L'Échange de Propriété : Modifier les détails d'un vrai morceau de code sur la carte (par exemple, changer une étiquette de « non vérifié » à « approuvé sécurité ») sans créer de nouvel élément faux.

Le Résultat : L'IA, raisonnant parfaitement sur la base des nouvelles données, indique avec confiance aux développeurs : « Ce code est sûr » ou « Utilisez cette nouvelle bibliothèque », les menant directement dans un piège.

La « Sophistication » de l'attaquant

Le papier a révélé quelque chose de surprenant : vous n'avez pas besoin d'être un hacker génie pour y parvenir.

Niveau 0 (Naïf) : Si les données falsifiées semblent suspectes (par exemple, nommées « hacker_tool_v1 »), l'IA les ignore.
Niveau 1 (Basique) : Si elles semblent correctes mais comportent de petites erreurs, l'IA est parfois trompée.
Niveau 2 (Compétent) : Si les données falsifiées suivent les règles de nommage standard et semblent professionnelles, 100 % des modèles d'IA testés ont été complètement trompés.

Il ne s'agit pas de savoir si l'IA peut être trompée, mais de combien d'efforts l'attaquant doit fournir. Un attaquant compétent peut tromper même les modèles d'IA les plus intelligents 100 % du temps.

La surprise du « Mode de livraison »

Les chercheurs ont découvert une faille critique dans la façon dont nous testons habituellement la sécurité de l'IA.

Tests en ligne (Inline) : Si vous montrez les données falsifiées à l'IA sous forme de simple message texte, certains modèles (comme GPT-5.1) disent : « Cela semble suspect » et le rejettent.
Tests d'utilisation d'outils : Si l'IA reçoit les mêmes données falsifiées via sa connexion officielle « outil » (la façon dont elle fonctionne dans la vie réelle), elle lui fait confiance à 100 %.

La Leçon : Tester la sécurité de l'IA simplement en discutant avec elle (en ligne) donne un faux sentiment de sécurité. Lorsque l'IA utilise ses outils pour consulter des données, elle baisse complètement sa garde.

Comment se défendre contre cela

Le papier a testé plusieurs défenses et a constaté qu'aucune « solution miracle » unique ne fonctionne, mais qu'une combinaison aide :

Accès en lecture seule (La meilleure défense) : Si vous verrouillez le Graphique de Connaissance pour que l'IA (et l'attaquant) ne puisse que lire la carte mais jamais écrire dessus, l'attaque devient impossible. C'est la correction la plus efficace.
Recoupement : Si l'IA est contrainte de vérifier la carte contre une deuxième source (comme les fichiers de code réels), elle peut repérer le mensonge. Si la carte dit « Sûr » mais que le fichier de code dit « Vulnérable », l'IA est confuse et cesse de faire confiance à la carte.
Le « Avocat du Diable » : Demander à l'IA : « Ces données pourraient-elles être falsifiées ? » aide, mais seulement si vous êtes très spécifique sur comment elles pourraient être falsifiées. Demander simplement « Es-tu sûr ? » ne fonctionne généralement pas.
Suivi de l'historique : Conserver un journal des changements sur la carte aide à détecter les nouveaux éléments falsifiés, mais cela échoue à attraper un attaquant qui modifie simplement les détails d'un élément existant.

Résumé

Oracle Poisoning est un nouveau type de piratage où l'attaquant corrompt les données en lesquelles l'IA fait confiance, et non l'IA elle-même. Parce que l'IA est si bonne pour suivre la logique, elle construit joyeusement une maison de cartes sur un fondement de mensonges. Le papier prouve que dans un contexte réel, presque tous les modèles d'IA testés croiront ces mensonges s'ils arrivent via un canal d'outil de confiance, et la seule correction fiable est d'empêcher l'IA d'écrire dans sa propre base de connaissances.

Résumé technique : Empoisonnement de l'Oracle – Corrompre les graphes de connaissances pour armer le raisonnement des agents IA

Définition du problème

L'article introduit l'Empoisonnement de l'Oracle, une nouvelle classe d'attaques visant les agents IA qui s'appuient sur des graphes de connaissances (KG) structurés en tant que sources de données fiables via des protocoles d'utilisation d'outils (spécifiquement le Protocole de Contexte de Modèle, ou MCP). Contrairement à l'injection de prompt, qui manipule les instructions d'un agent, ou à l'empoisonnement RAG, qui corrompt les corpus de récupération, l'Empoisonnement de l'Oracle corrompt les données elles-mêmes.

La vulnérabilité centrale réside dans le « modèle de confiance de l'oracle » : les agents IA traitent les résultats de requêtes provenant d'un graphe de connaissances comme une vérité fondamentale, raisonnant à partir de ces faits sans vérification indépendante. Un adversaire capable de modifier le graphe (en insérant des nœuds, en créant des arêtes ou en altérant des propriétés) peut amener un agent à effectuer un raisonnement logique et valide basé sur des faits fabriqués, conduisant à des conclusions incorrectes et potentiellement dangereuses. Cette attaque se distingue des travaux antérieurs sur l'empoisonnement de l'espace d'incorporation (par exemple, ROAR) car elle vise les structures brutes du graphe interrogées directement via des langages comme Cypher, contournant entièrement les couches d'incorporation.

Méthodologie

Les auteurs ont réalisé la première démonstration empirique de cette attaque contre un graphe de connaissances de code à l'échelle de la production contenant environ 42 millions de nœuds.

Modèle système : Un graphe de connaissances Neo4j 5.x connecté à des agents IA via MCP v1.0. Le graphe encode les chaînes d'appels de fonctions, les dépendances et la télémétrie.
Profil de l'attaquant : Un initié disposant d'un accès en écriture à la base de données du graphe (souvent dû à des sessions de base de données partagées manquant de RBAC par utilisateur) ou un attaquant externe compromettant le pipeline d'ingestion.
Vecteurs d'attaque : Six scénarios ont été conçus :
1. Fork-for-a-Package : Création de faux nœuds de packages pour suggérer des bibliothèques malveillantes comme étant des versions « récentes ».
2. Chaîne de dépendance transitive : Fabrication de chemins de dépendance pour légitimer des bibliothèques malveillantes.
3. Évasion de la sécurité du graphe d'appels : Injection de nettoyeurs de sécurité inexistants dans les graphes d'appels pour convaincre les agents que les vulnérabilités sont atténuées.
4. Reroutage de la télémétrie : Modification des arêtes de télémétrie pour masquer les événements de sécurité.
5. Empoisonnement de la génération de code : Plantage de modèles de code vulnérables comme « meilleures pratiques établies ».
6. Modification de propriétés : Altération des propriétés sur des nœuds légitimes existants (par exemple, changer sanitizationType en « conforme OWASP ») sans créer de nouveaux nœuds.
Protocole d'évaluation :
- Modèles : Neuf modèles de trois fournisseurs (OpenAI, Anthropic, Google) testés avec $N=30$ essais par modèle.
- Modes de livraison : L'évaluation principale utilisait l'utilisation d'outils SDK réelle (invocation autonome d'agent), avec une livraison de texte en ligne secondaire pour une comparaison contrôlée.
- Niveaux de sophistication : Les attaques variaient de L0 (naïve) à L3 (expert), L2 représentant un attaquant compétent utilisant des conventions de nommage correctes et des références OWASP.
- Métriques : Taux de confiance (acceptation des données empoisonnées), gradients de sophistication de l'attaquant et efficacité de la défense.

Résultats clés

1. Susceptibilité universelle sous utilisation d'outils

Sous une utilisation réelle d'outils SDK avec une sophistication modérée de l'attaquant (L2), chaque modèle testé a fait confiance aux données empoisonnées à 100 %.

269 essais valides sur 270 ont accepté des affirmations de sécurité fabriquées (par exemple, confirmer qu'une injection SQL était atténuée alors qu'elle ne l'était pas).
Ce résultat s'est maintenu pour les neuf modèles et deux scénarios d'attaque distincts (Squatting de package et Évasion du graphe d'appels).
La Modification de propriétés (Scénario 6) s'est révélée particulièrement efficace, atteignant une confiance quasi universelle (96,6–100 %) même lorsque l'historique du graphe était préservé, car les modèles interprétaient les changements de propriétés comme des mises à jour logicielles normales.

2. Le biais du mode de livraison

Une découverte critique est que l'évaluation en ligne produit des faux négatifs pour des modèles spécifiques.

GPT-5.1 a montré 0 % de confiance lorsque les données empoisonnées étaient présentées sous forme de texte en ligne, mais 100 % de confiance lorsqu'elles étaient livrées via une utilisation d'outils d'agent réelle.
Cela indique que le canal de confiance (réponse d'outil MCP) abaisse considérablement le seuil de scepticisme de l'agent par rapport à une entrée textuelle directe. Les évaluations en ligne peuvent sous-estimer la susceptibilité des agents.

3. Gradient de sophistication de l'attaquant

L'attaque présente un « point de rupture » discret.

L0/L1 (Naïf/Basique) : Les taux de confiance étaient faibles (0–32 %).
L2 (Compétent) : Les taux de confiance ont bondi à 100 % pour tous les modèles sous utilisation d'outils.
Cela reformule l'attaque : il ne s'agit pas de savoir si un modèle peut être trompé, mais du minimum d'effort requis. Un attaquant compétent (L2) suffit à compromettre tout modèle testé.

4. Évaluation de la défense (Cadre VUT)

Les auteurs ont évalué les défenses sous un cadre Visibilité–Compréhension–Traçabilité (VUT) :

Visibilité (Historique du graphe) : Efficace contre la création de nœuds (les agents signalaient les nouveaux nœuds) mais inefficace contre la modification de propriétés (les agents acceptaient les changements comme des mises à jour valides).
Compréhension (Débat/Vérification) :
- Avocat du Diable nommé : Très efficace sous utilisation d'outils SDK (taux de détection de 96,7–100 %) mais moins en ligne.
- Avocat du Diable aveugle : Inutile opérationnellement (taux de détection égal au taux de faux positifs).
- Durcissement du prompt système : N'a eu aucun effet ; les agents reconnaissaient les instructions mais faisaient toujours confiance aux données.
- Vérification croisée multi-outils : La défense architecturale la plus efficace. Lorsque les agents pouvaient vérifier le KG avec un outil de recherche de code source, la confiance aveugle s'est effondrée de 100 % à 0–25 %.
Traçabilité (Contrôle d'accès) : Le contrôle d'accès en lecture seule pour les sessions MCP était la seule défense qui éliminait complètement le vecteur de mutation directe, indépendamment du modèle utilisé.

Importance et affirmations

L'article prétend fournir la première démonstration empirique d'empoisonnement de graphe de connaissances contre un système d'agent à l'échelle de la production (42 millions de nœuds). Son importance réside dans :

Définition d'une nouvelle classe d'attaque : L'Empoisonnement de l'Oracle se distingue de l'injection de prompt, de l'empoisonnement RAG et de l'empoisonnement de données lors de l'entraînement. Il exploite la confiance au moment de l'inférence dans les résultats de requêtes structurées livrés via l'utilisation d'outils.
Réalité à l'échelle de la production : Contrairement aux études antérieures basées en laboratoire, cette attaque a été démontrée sur un système en direct de niveau entreprise, prouvant que la vulnérabilité n'est pas théorique mais exploitable dans des environnements réels.
Vulnérabilité architecturale : L'attaque exploite une hypothèse architecturale fondamentale (confiance dans les sources de données) plutôt qu'un bug d'implémentation spécifique. Les prérequis structurels (accès en écriture, absence de provenance, confiance dans les résultats) persistent sur plusieurs plateformes (Sourcegraph, Semgrep, CodeQL, Qodana), suggérant que le risque est systémique à l'écosystème des graphes de connaissances.
Correction méthodologique : L'article soutient que les évaluations de sécurité pour les agents IA doivent dépasser les tests de texte en ligne pour atteindre des pipelines d'utilisation d'outils réels, car le mode de livraison est un facteur de confusion de premier ordre qui peut masquer des vulnérabilités critiques.

Les auteurs concluent que, bien qu'aucune défense unique ne soit une « solution miracle », une approche en couches combinant le contrôle d'accès en lecture seule (Traçabilité), la vérification croisée multi-outils (Compréhension) et la journalisation des audits (Visibilité) est nécessaire pour atténuer le risque.