Una recente ricerca condotta 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 di intelligenza artificiale con privilegi limitati sarebbe riuscito a influenzare un secondo agente dotato di autorizzazioni elevate, aprendo potenziali scenari di attacco alla supply chain del software.

La vulnerabilità è stata riscontrata nel repository GitHub di Google Agent Development Kit (ADK) per Python, un toolkit open source ampiamente utilizzato per lo sviluppo e la distribuzione di agenti AI. Secondo i ricercatori, il progetto ha superato i 90 milioni di download, evidenziando l’ampio impatto che un eventuale problema di sicurezza potrebbe avere ben oltre il singolo repository.

Google ha provveduto a correggere il difetto dopo la segnalazione da parte di Pillar Security, ma ha deciso di non riconoscere una ricompensa economica attraverso il proprio programma di bug bounty. L’azienda motiva questa decisione sostenendo che lo scenario di attacco richiede un elemento di social engineering, condizione che esclude il caso dalle vulnerabilità premiabili. Nonostante ciò, Google ha riconosciuto il merito della scoperta ai ricercatori.

L’aspetto più rilevante emerso da questa vicenda è che, per la prima volta, si osserva concretamente come gli agenti AI possano diventare essi stessi vettori di attacco all’interno delle moderne pipeline di sviluppo. In questi contesti, strumenti basati sull’intelligenza artificiale vengono sempre più spesso impiegati per classificare le issue, analizzare le 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 adeguatamente conto di questi scenari. Fino all’avvento degli agenti AI autonomi, tali situazioni semplicemente non esistevano. Le organizzazioni stanno adottando rapidamente questi strumenti, mentre le metodologie di sicurezza continuano a basarsi su paradigmi costruiti attorno agli utenti umani o alle tradizionali applicazioni software.

L’origine del problema risiedeva nell’architettura stessa del repository. Erano presenti due classi distinte di agenti AI, ciascuna con privilegi differenti, ma accomunate da un confine di fiducia che, secondo i ricercatori, risultava eccessivamente permissivo. Il primo agente era pubblico e si attivava automaticamente quando un utente apriva una issue o 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.

Un dettaglio significativo è rappresentato dal fatto che l’intera logica di funzionamento dei workflow era pubblicamente consultabile. Analizzando il repository, un attaccante poteva comprendere come gli agenti interagissero tra loro e costruire un prompt in grado di sfruttare questa relazione. Come osserva lo stesso Lisichkin, in queste ore non sono necessarie competenze particolarmente avanzate per sviluppare un attacco di questo tipo; è sufficiente conoscere il funzionamento della prompt injection oppure affidarsi a un altro modello AI per generare il payload necessario.

L’attacco descritto dai ricercatori si sviluppa in più fasi. 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 consente 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. Mountain View ritiene che questo elemento riduca sensibilmente la gravità pratica della vulnerabilità.

La ricerca evidenzia tuttavia 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 inoltre essere limitato esclusivamente alle operazioni strettamente necessarie, evitando che un agente possa influenzarne un altro attraverso meccanismi impliciti di fiducia.

* Contenuto realizzato con l’ausilio di sistemi di intelligenza artificiale.