🤖 AI

Oracle Poisoning: Corrupting Knowledge Graphs to Weaponise AI Agent Reasoning

Questo articolo introduce e valida empiricamente l'"Avvelenamento dell'Oracolo", un nuovo vettore di attacco in cui gli avversari corrompono grafi della conoscenza strutturati per indurre agenti di intelligenza artificiale a trarre conclusioni errate tramite ragionamenti altrimenti validi, dimostrando che i modelli attuali affidano universalmente fiducia ai dati avvelenati quando accessibili tramite protocolli di utilizzo degli strumenti e evidenziando lacune critiche nella valutazione nei test inline.

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

Pubblicato 2026-05-12

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

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

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

L'Idea Centrale: La Trappola del "Bibliotecario Fidato"

Immagina di avere un assistente AI brillante (l'"Agente") che ti aiuta a scrivere codice o a verificare la presenza di falle di sicurezza. Questo assistente è incredibilmente intelligente e ragiona perfettamente. Tuttavia, ha una debolezza maggiore: è cieco al mondo esterno.

Per svolgere il suo lavoro, l'AI si affida interamente a una vasta libreria digitale strutturata chiamata Grafo della Conoscenza. Pensa a questo grafo come a una mappa gigante dell'intera base di codice del tuo software, che mostra come ogni pezzo di codice si colleghi a ogni altro.

L'AI tratta questa mappa come un Oracolo—una fonte di verità assoluta. Non mette in discussione la mappa; presume che sia accurata al 100%. Se la mappa dice "La Funzione A chiama la Funzione B", l'AI lo crede senza verificare una seconda fonte.

Oracle Poisoning è l'attacco in cui un malintenzionato si infila nella libreria e modifica la mappa. Non rompe il cervello dell'AI; non inganna l'AI con parole confuse. Invece, altera silenziosamente i fatti sulla mappa. Poiché l'AI è così brava a ragionare, prende questi nuovi fatti falsi e trae una conclusione perfettamente logica—ma completamente errata.

L'Analogia: La Grotta di Platone e il Muro delle Ombre

Gli autori paragonano questo alla Grotta di Platone.

Il Prigioniero: L'Agente AI.
Il Muro: Il Grafo della Conoscenza.
Le Ombre: Le risposte che l'AI ottiene quando pone domande al grafo.
La Catena: Il protocollo (chiamato MCP) che lega l'AI al muro, costringendola ad accettare le ombre come realtà.

Se un attaccante dipinge un'ombra falsa sul muro, il prigioniero (l'AI) la studierà, la analizzerà perfettamente e concluderà: "Quello è una vera tigre", anche se è solo un dipinto. Più il prigioniero è intelligente, più la sua conclusione errata sarà dettagliata e convincente.

Come Funziona l'Attacco (Il "Come Fare")

I ricercatori hanno testato questo su un sistema reale con 42 milioni di nodi (una vasta libreria digitale). Hanno scoperto che un attaccante ha solo bisogno di apportare piccoli cambiamenti chirurgici alla mappa per ingannare l'AI.

Hanno dimostrato sei modi per farlo:

Il Pacchetto Falso: Creare un pacchetto software falso nella libreria che sembra l'"ultima versione, più sicura", ingannando l'AI a consigliarlo.
Il Sanitizzatore Invisibile: Aggiungere una funzione "guardia di sicurezza" falsa alla mappa che in realtà non esiste nel codice reale. L'AI la vede sulla mappa e conclude: "Ah, questo codice è sicuro!", quando in realtà è vulnerabile.
Lo Scambio di Proprietà: Modificare i dettagli di un pezzo di codice reale sulla mappa (ad esempio, cambiando un'etichetta da "non verificato" a "approvato per la sicurezza") senza creare un nuovo elemento falso.

Il Risultato: L'AI, ragionando perfettamente basandosi sui nuovi dati, dice con sicurezza agli sviluppatori: "Questo codice è sicuro" o "Usa questa nuova libreria", portandoli direttamente in una trappola.

La "Sofisticazione" dell'Attaccante

Il documento ha scoperto qualcosa di sorprendente: non devi essere un hacker geniale per riuscirci.

Livello 0 (Naive): Se i dati falsi sembrano sospetti (ad esempio, chiamati "hacker_tool_v1"), l'AI li ignora.
Livello 1 (Base): Se sembrano okay ma hanno piccoli errori, l'AI viene talvolta ingannata.
Livello 2 (Competente): Se i dati falsi seguono le regole di denominazione standard e sembrano professionali, il 100% dei modelli AI testati è stato completamente ingannato.

Non è una questione di se l'AI può essere ingannata, ma di quanto sforzo l'attaccante deve spendere. Un attaccante competente può ingannare anche i modelli AI più intelligenti il 100% delle volte.

La Sorpresa della "Modalità di Consegna"

I ricercatori hanno scoperto un difetto critico nel modo in cui solitamente testiamo la sicurezza dell'AI.

Test Inline: Se mostri i dati falsi all'AI come un semplice messaggio di testo, alcuni modelli (come GPT-5.1) dicono: "Questo sembra sospetto" e lo rifiutano.
Test di Utilizzo degli Strumenti: Se l'AI riceve gli stessi dati falsi attraverso la sua connessione ufficiale "strumento" (il modo in cui funziona nella vita reale), lo crede al 100%.

La Lezione: Testare la sicurezza dell'AI semplicemente chiacchierando con essa (inline) dà una falsa sensazione di sicurezza. Quando l'AI usa i suoi strumenti per cercare dati, abbassa completamente la guardia.

Come Difendersi

Il documento ha testato diverse difese e ha scoperto che nessun singolo "proiettile d'argento" funziona, ma una combinazione aiuta:

Accesso in Sola Lettura (La Migliore Difesa): Se blocchi il Grafo della Conoscenza in modo che l'AI (e l'attaccante) possa solo leggere la mappa ma mai scrivere su di essa, l'attacco è impossibile. Questa è la correzione più efficace.
Verifica Incrociata: Se l'AI è costretta a controllare la mappa contro una seconda fonte (come i file di codice effettivi), può scoprire la menzogna. Se la mappa dice "Sicuro" ma il file di codice dice "Vulnerabile", l'AI si confonde e smette di fidarsi della mappa.
L'"Avvocato del Diavolo": Chiedere all'AI: "Questi dati potrebbero essere falsi?" aiuta, ma solo se sei molto specifico su come potrebbero essere falsi. Chiedere semplicemente "Ne sei sicuro?" generalmente non funziona.
Tracciamento della Cronologia: Tenere un registro di ciò che è cambiato sulla mappa aiuta a rilevare nuovi elementi falsi, ma fallisce nel catturare quando un attaccante semplicemente modifica i dettagli di un elemento esistente.

Riepilogo

Oracle Poisoning è un nuovo tipo di hacking in cui l'attaccante corrompe i dati di cui l'AI si fida, non l'AI stessa. Poiché l'AI è così brava a seguire la logica, costruisce felicemente una casa di carte su una fondazione di menzogne. Il documento dimostra che in un contesto reale, quasi ogni modello AI testato crederà a queste menzogne se arrivano attraverso un canale di strumenti fidato, e l'unica soluzione affidabile è impedire all'AI di poter scrivere sulla propria base di conoscenza.

Riepilogo Tecnico: Avvelenamento dell'Oracolo – Corruzione delle Knowledge Graph per Armiizzare il Ragionamento degli Agenti AI

Definizione del Problema

Il documento introduce l'Avvelenamento dell'Oracolo, una nuova classe di attacchi rivolta agli agenti AI che si affidano a knowledge graph (KG) strutturati come fonti dati attendibili tramite protocolli di utilizzo degli strumenti (specificamente il Protocollo di Contesto del Modello, o MCP). A differenza dell'injection di prompt, che manipola le istruzioni di un agente, o dell'avvelenamento RAG, che corrompe i corpora di recupero, l'Avvelenamento dell'Oracolo corrompe i dati stessi.

La vulnerabilità fondamentale risiede nel "modello di fiducia dell'oracolo": gli agenti AI trattano i risultati delle query provenienti da una knowledge graph come verità assoluta, ragionando su questi fatti senza verifica indipendente. Un avversario in grado di modificare il grafo (inserendo nodi, creando archi o alterando proprietà) può indurre un agente a eseguire un ragionamento logico e coerente basato su fatti fabbricati, portando a conclusioni errate e potenzialmente pericolose. Questo attacco si distingue dai lavori precedenti sull'avvelenamento dello spazio di embedding (ad es. ROAR) perché prende di mira le strutture grezze del grafo interrogate direttamente tramite linguaggi come Cypher, aggirando completamente i livelli di embedding.

Metodologia

Gli autori hanno condotto la prima dimostrazione empirica di questo attacco contro una knowledge graph di codice su scala produttiva contenente circa 42 milioni di nodi.

Modello di Sistema: Una knowledge graph Neo4j 5.x collegata ad agenti AI tramite MCP v1.0. Il grafo codifica catene di chiamate di funzione, dipendenze e telemetria.
Profilo dell'Attaccante: Un insider con accesso in scrittura al database del grafo (spesso dovuto a sessioni di database condivise prive di RBAC per utente) o un attaccante esterno che compromette la pipeline di ingestione.
Vettori di Attacco: Sono stati progettati sei scenari:
1. Fork-for-a-Package: Creazione di nodi di pacchetto falsi per suggerire librerie malevole come versioni "ultime".
2. Catena di Dipendenze Transitive: Fabbricazione di percorsi di dipendenza per legittimare librerie malevole.
3. Evasione della Sicurezza del Call Graph: Iniezione di sanificatori di sicurezza inesistenti nei call graph per convincere gli agenti che le vulnerabilità siano mitigate.
4. Reindirizzamento della Telemetria: Modifica degli archi di telemetria per nascondere eventi di sicurezza.
5. Avvelenamento della Generazione di Codice: Piantagione di pattern di codice vulnerabili come "migliori pratiche consolidate".
6. Modifica delle Proprietà: Alterazione delle proprietà su nodi legittimi esistenti (ad es. cambiare sanitizationType in "conforme OWASP") senza creare nuovi nodi.
Protocollo di Valutazione:
- Modelli: Nove modelli di tre fornitori (OpenAI, Anthropic, Google) testati con $N=30$ prove per modello.
- Modalità di Consegna: La valutazione primaria ha utilizzato l'utilizzo reale degli strumenti SDK (invocazione autonoma dell'agente), con una consegna di testo inline secondaria per un confronto controllato.
- Livelli di Sofisticazione: Gli attacchi variavano da L0 (ingenuo) a L3 (esperto), con L2 che rappresenta un attaccante competente che utilizza convenzioni di denominazione corrette e riferimenti OWASP.
- Metriche: Tassi di fiducia (accettazione dei dati avvelenati), gradienti di sofisticazione dell'attaccante ed efficacia delle difese.

Risultati Chiave

1. Suscettibilità Universale nell'Utilizzo degli Strumenti

Sotto l'utilizzo reale degli strumenti SDK con sofisticazione moderata dell'attaccante (L2), ogni modello testato ha fidato dei dati avvelenati al 100%.

269 su 270 prove valide hanno accettato affermazioni di sicurezza fabbricate (ad es. confermare che l'iniezione SQL fosse mitigata quando non lo era).
Questo risultato è valso per tutti e nove i modelli e per due scenari di attacco distinti (Squatting di Pacchetti ed Evasione del Call Graph).
La Modifica delle Proprietà (Scenario 6) è stata particolarmente efficace, raggiungendo una fiducia quasi universale (96,6–100%) anche quando la cronologia del grafo era preservata, poiché i modelli interpretavano le modifiche alle proprietà come normali aggiornamenti software.

2. Il Confondimento della Modalità di Consegna

Una scoperta critica è che la valutazione inline produce falsi negativi per modelli specifici.

GPT-5.1 ha mostrato 0% di fiducia quando i dati avvelenati erano presentati come testo inline, ma 100% di fiducia quando consegnati tramite l'utilizzo reale di strumenti agenziali.
Ciò indica che il canale di fiducia (risposta dello strumento MCP) abbassa significativamente la soglia di scetticismo dell'agente rispetto all'input di testo diretto. Le valutazioni inline potrebbero sottostimare la suscettibilità agenziale.

3. Gradiente di Sofisticazione dell'Attaccante

L'attacco presenta un "punto di rottura" discreto.

L0/L1 (Ingenuo/Base): I tassi di fiducia erano bassi (0–32%).
L2 (Competente): I tassi di fiducia sono schizzati al 100% per tutti i modelli sotto l'utilizzo degli strumenti.
Questo riformula l'attacco: non è una questione di se un modello possa essere ingannato, ma del minimo sforzo richiesto. Un attaccante competente (L2) è sufficiente per compromettere qualsiasi modello testato.

4. Valutazione delle Difese (Framework VUT)

Gli autori hanno valutato le difese sotto un framework Visibilità–Comprensione–Tracciabilità (VUT):

Visibilità (Cronologia del Grafo): Efficace contro la creazione di nodi (gli agenti segnalavano nuovi nodi) ma inefficace contro la modifica delle proprietà (gli agenti accettavano le modifiche come aggiornamenti validi).
Comprensione (Dibattito/Verifica):
- Avvocato del Diavolo Nominato: Altamente efficace sotto l'utilizzo degli strumenti SDK (tasso di intercettazione 96,7–100%) ma meno in inline.
- Avvocato del Diavolo Cieco: Operativamente inutile (il tasso di intercettazione è uguale al tasso di falsi positivi).
- Irrigidimento del Prompt di Sistema: Ha avuto zero effetto; gli agenti riconoscevano le istruzioni ma fidavano comunque dei dati.
- Verifica Incrociata Multi-strumento: La difesa architetturale più efficace. Quando gli agenti potevano incrociare il KG con uno strumento di ricerca del codice sorgente, la fiducia cieca è crollata dal 100% a 0–25%.
Tracciabilità (Controllo degli Accessi): Il controllo degli accessi in sola lettura per le sessioni MCP è stata l'unica difesa che ha eliminato completamente il vettore di mutazione diretta, indipendentemente dal modello utilizzato.

Significato e Affermazioni

Il documento afferma di fornire la prima dimostrazione empirica di avvelenamento di knowledge graph contro un sistema agenziale su scala produttiva (42M di nodi). La sua importanza risiede in:

Definizione di una Nuova Classe di Attacchi: L'Avvelenamento dell'Oracolo è distinto dall'injection di prompt, dall'avvelenamento RAG e dall'avvelenamento dei dati durante l'addestramento. Sfrutta la fiducia al momento dell'inferenza nei risultati di query strutturati consegnati tramite l'utilizzo degli strumenti.
Realtà su Scala Produttiva: A differenza dei precedenti studi basati su laboratorio, questo attacco è stato dimostrato su un sistema live di livello aziendale, dimostrando che la vulnerabilità non è teorica ma sfruttabile in ambienti reali.
Vulnerabilità Architetturale: L'attacco sfrutta un'assunzione architetturale fondamentale (fiducia nelle fonti dati) piuttosto che un bug di implementazione specifico. Le precondizioni strutturali (accesso in scrittura, mancanza di provenienza, fiducia nei risultati) persistono su più piattaforme (Sourcegraph, Semgrep, CodeQL, Qodana), suggerendo che il rischio è sistemico per l'ecosistema delle knowledge graph.
Correzione Metodologica: Il documento sostiene che le valutazioni di sicurezza per gli agenti AI devono andare oltre i test di testo inline per passare a pipeline reali di utilizzo degli strumenti, poiché la modalità di consegna è un confondimento di primo ordine che può mascherare vulnerabilità critiche.

Gli autori concludono che, sebbene nessuna singola difesa sia una "bacchetta magica", è richiesto un approccio stratificato che combini controllo degli accessi in sola lettura (Tracciabilità), verifica incrociata multi-strumento (Comprensione) e registrazione degli audit (Visibilità) per mitigare il rischio.