Il ricercatore di sicurezza Dan Lisichkin, di Pillar Security, ha fatto nel repository dell'Agent Development Kit di Google una cosa mai dimostrata pubblicamente prima: ha usato un agente di IA per attaccarne un altro.
L'impianto è ordinario, ed è proprio questo a renderlo interessante. Il repository google/adk-python, che i manutentori dichiarano a oltre 90 milioni di download, fa girare agenti sulle proprie pull request. Uno di questi è un revisore esposto al pubblico, raggiungibile dal contributo di chiunque. Lavora con un token di accesso personale da collaboratore, quindi modesto. Un altro agente sta più all'interno, con privilegi da manutentore.
Il meccanismo
Una pull request non è solo codice. Ha un titolo, un corpo, un diff e dei commenti, e tutto questo è testo che un agente legge. Lisichkin ha inserito una prompt injection in quel testo. Il revisore a basso privilegio l'ha letto e, invece di limitarsi a revisionare, ha agito in un modo che ha attivato l'agente a privilegio alto.
In senso stretto non si era rotto nulla. Ogni agente ha fatto ciò per cui era stato costruito. Il revisore ha letto input non fidato, perché è il suo mestiere. Il secondo agente si è fidato di un segnale proveniente dall'interno del repository, perché l'interno dovrebbe essere sicuro. Ciò che nessuno aveva scritto è il confine tra i due, e un confine non scritto non viene applicato.
Google ha corretto e ha rifiutato di pagare
È il passaggio su cui vale la pena fermarsi, perché entrambe le parti hanno un argomento vero.
Google ha risolto il problema. Google ha anche rifiutato il premio, dicendo che non ricompensa le segnalazioni di vulnerabilità che richiedono ingegneria sociale per rendere possibile una compromissione della catena di fornitura, e sottolineando che un manutentore deve comunque cliccare su "unisci", dato che le pull request non vengono unite automaticamente dopo la revisione di un bot.
Non è una scappatoia. È corretto sul piano dei fatti: la catena si chiude solo se una persona accetta una pull request malevola. Molte scale di gravità riducono, a ragione, il peso delle scoperte che hanno bisogno della collaborazione di un essere umano.
Anche la replica del ricercatore è corretta, e riguarda la progettazione più che la gravità. La sua posizione, con le sue parole, è che gli agenti dovrebbero avere una propria identità, che stabilisce a quali risorse è loro consentito accedere e in che modo è loro consentito interagire con quelle risorse. Un agente che prende in prestito il token di una persona eredita i permessi di una persona, e nessuna fase di revisione compensa questo.
Non serve scegliere un vincitore. La lettura onesta è che questo exploit preciso ha avuto bisogno di un errore umano, e che l'architettura che mette in luce non ne avrà bisogno per essere un problema la prossima volta.
Perché "serve comunque un umano che unisca" invecchierà male
Che un manutentore debba unire è una barriera reale oggi. Ed è una barriera che l'intero settore sta lavorando in questo momento a rimuovere.
La direzione di marcia nello sviluppo agentico va verso meno punti di controllo umani, non di più. Ogni regola di unione automatica, ogni politica del tipo "il bot ha approvato, quindi entra", ogni pipeline in cui l'output di un agente alimenta un altro agente senza nessuno in mezzo, toglie esattamente il passaggio su cui Google conta. La mitigazione è organizzativa, e le mitigazioni organizzative si degradano.
Cosa fare nel proprio repository
Niente di tutto questo richiede la scala di Google. Se fai girare agenti sui tuoi repository:
- Dai a ogni agente una propria identità. Condividere un token di accesso personale tra una persona e un bot, o tra due bot, significa non poter più restringere né revocare nulla in modo indipendente, e non poter più dire da un registro di audit chi ha fatto cosa.
- Restringi il token al compito. Un revisore deve leggere un diff e scrivere un commento. Non gli serve accesso in scrittura ai rami.
- Tratta come portatore di istruzioni tutto ciò che un agente legge dall'esterno. Il testo di una pull request scritto da uno sconosciuto merita la stessa diffidenza di un campo di modulo su un sito pubblico. La nostra guida sulla sicurezza degli agenti IA copre lo schema generale.
- Non lasciare che l'output di un agente sia l'innesco fidato di un altro. Se l'agente B agisce sulla parola dell'agente A, allora chi controlla l'input di A controlla B.
Da non confondere con i pacchetti litellm
Un incidente distinto tocca lo stesso ecosistema e viene spesso mescolato a questo. A marzo 2026 versioni malevole di litellm, la 1.82.7 e la 1.82.8, sono state pubblicate su PyPI tramite credenziali di manutentore compromesse, in una finestra di circa tre ore. Chi installava google-adk con le estensioni durante quella finestra se le portava a casa.
È una classica compromissione di dipendenza: credenziali rubate, pacchetto avvelenato, finestra breve. Non ha nulla a che vedere con agenti che si parlano tra loro. Sono entrambi incidenti di catena di fornitura, ma le difese sono diverse, e trattarli come un'unica storia porta a correggerne uno credendo di aver coperto l'altro.
Cosa portarsi via
La scoperta è modesta nell'impatto immediato e grande in ciò che segnala. Un agente non è uno strumento che parte quando premi un pulsante. È un attore che legge, decide e agisce, e nel momento in cui ne hai due nello stesso repository con privilegi diversi, hai un confine di fiducia, che tu l'abbia progettato o no.
Dai agli agenti un'identità prima di dare loro dei permessi.
Fonti
- Ricerca di Pillar Security, riportata da The Register, 3 agosto 2026.
