Una recente ricerca pubblicata da Pillar Security ha individuato quello che viene definito il primo metodo di sfruttamento “agent-to-agent” osservato in un contesto reale. In pratica, un agente AI con privilegi limitati sarebbe riuscito a influenzarne un secondo dotato di autorizzazioni elevate, aprendo la strada a un potenziale attacco alla supply chain del software.

La vulnerabilità interessava il repository GitHub di Google Agent Development Kit (ADK) per Python, toolkit open source utilizzato per sviluppare e distribuire agenti AI e adottato su larga scala dalla comunità degli sviluppatori. Secondo i ricercatori, il progetto ha superato i 90 milioni di download, un dato che evidenzia quanto un eventuale problema di sicurezza possa avere ripercussioni ben oltre il singolo repository.

Google ha corretto il difetto dopo la segnalazione, ma ha deciso di non riconoscere una ricompensa economica attraverso il proprio programma di bug bounty. L’azienda ritiene infatti che lo scenario di attacco richieda un elemento di social engineering, condizione che esclude il caso dalle vulnerabilità premiabili. La correzione è comunque stata distribuita e Google ha attribuito il merito della scoperta ai ricercatori.

L’aspetto davvero interessante della vicenda è che per la prima volta emerge in modo concreto come gli agenti AI possano diventare essi stessi vettori di attacco all’interno di pipeline di sviluppo moderne, dove strumenti basati sull’intelligenza artificiale vengono sempre più spesso impiegati per classificare issue, analizzare pull request, generare revisioni automatiche del codice e supportare i maintainer nelle attività quotidiane.

Secondo Dan Lisichkin, ricercatore di Pillar Security che ha individuato la vulnerabilità, gli attuali modelli di threat modeling non tengono ancora conto di questi scenari perché, fino all’arrivo degli agenti AI autonomi, semplicemente non esistevano. Le organizzazioni stanno adottando questi strumenti con estrema rapidità, mentre le metodologie di sicurezza continuano a ragionare secondo paradigmi costruiti attorno agli utenti umani o alle tradizionali applicazioni software.

L’origine del problema risiedeva nell’architettura stessa del repository. Erano infatti presenti due differenti classi di agenti AI, ciascuna con privilegi diversi, ma accomunate da un confine di fiducia che, secondo i ricercatori, risultava troppo permissivo. Il primo agente era pubblico e si attivava automaticamente quando un utente apriva una issue oppure una pull request. Il secondo, invece, era riservato ai maintainer del progetto e disponeva di autorizzazioni decisamente più elevate.

Attraverso una tecnica di prompt injection, il team di Pillar Security è riuscito a manipolare il comportamento dell’agente pubblico inducendolo ad attivare il workflow del secondo agente privilegiato. In altre parole, il sistema di automazione finiva per considerare attendibili istruzioni che, in realtà, erano state costruite da un soggetto esterno con finalità malevole.

agente AI supply chain

Il dettaglio più significativo riguarda il fatto che l’intera logica di funzionamento dei workflow fosse pubblicamente consultabile. Analizzando il repository, un attaccante poteva comprendere come gli agenti interagissero tra loro e costruire un prompt capace di sfruttare questa relazione. Come osserva lo stesso Lisichkin, oggi non servono competenze particolarmente avanzate per sviluppare un attacco di questo tipo, ma è sufficiente conoscere il funzionamento della prompt injection oppure affidarsi a un altro modello AI per generare il payload necessario.

Naturalmente, non si tratta di un attacco immediato, visto che lo scenario ipotizzato richiede una fase preliminare durante la quale l’aggressore costruisce la propria reputazione contribuendo legittimamente al progetto open source. Una volta conquistata la fiducia dei maintainer, diventa possibile avviare la sequenza malevola.

L’attacco descritto dai ricercatori si sviluppa in più fasi:

  • L’aggressore invia inizialmente una pull request apparentemente innocua che contiene una modifica realmente utile insieme a un elemento nascosto, come una dipendenza compromessa o un file di configurazione alterato
  • L’agente pubblico analizza automaticamente la richiesta e la contrassegna per la revisione utilizzando un token GitHub con permessi sufficienti ad avviare workflow protetti
  • Successivamente, viene aperta una seconda pull request contenente il prompt di manipolazione. A questo punto l’agente di triage genera automaticamente il passaggio verso l’agente privilegiato, che interpreta l’interazione come se fosse stata richiesta da un collaboratore autorizzato

Il risultato finale è la creazione di una catena di eventi apparentemente legittima, nella quale sembra che un maintainer abbia richiesto una revisione, che il sistema AI l’abbia eseguita e che l’abbia perfino approvata, quando in realtà nessuna di queste operazioni è mai stata effettuata da un essere umano.

Google ha precisato che lo scenario individuato non permette l’inserimento automatico di codice dannoso nel progetto. L’attacco consentirebbe infatti di manipolare una pull request sfruttando un token GitHub con permessi di scrittura, ma sarebbe comunque necessario l’intervento finale di un maintainer per autorizzarne il merge. Secondo Mountain View questo elemento riduce sensibilmente la gravità pratica della vulnerabilità.

La ricerca, tuttavia, evidenzia un problema più ampio. Molte organizzazioni stanno introducendo agenti AI all’interno delle pipeline CI/CD per automatizzare processi sempre più critici. Se questi sistemi condividono credenziali, contesti operativi o relazioni di fiducia poco rigorose, un agente con privilegi limitati potrebbe diventare il punto di ingresso per compromettere workflow molto più sensibili.

Per Lisichkin la semplice separazione tra agenti non è più sufficiente. Ogni agente dovrebbe possedere una propria identità digitale, con autorizzazioni chiaramente definite e indipendenti, seguendo gli stessi principi del modello Zero Trust già adottato nelle moderne infrastrutture IT. L’accesso alle risorse dovrebbe essere inoltre limitato esclusivamente alle operazioni strettamente necessarie, evitando che un agente possa influenzarne un altro attraverso meccanismi impliciti di fiducia.

(Immagine in apertura: Shutterstock)