La risposta breve
La società di sicurezza Pillar Security ha divulgato una falla nell'automazione del repository open source dell'Agent Development Kit (ADK) di Google per Python, in cui un ticket GitHub pubblico — scrivibile da chiunque — poteva iniettare istruzioni malevole in un agente di triage a basso privilegio inducendolo a invocare un agente di correzione del codice ad alto privilegio, portando all'esecuzione arbitraria di codice sul runner CI e all'esfiltrazione del token adk-bot, di una chiave API Google e di una credenziale di service account Google Cloud. Pillar descrive questo come il primo caso pratico e reale di exploitation agent-to-agent in un sistema multi-agente in produzione. Google ha rimosso i workflow vulnerabili nel luglio 2026 e la ricerca è stata pubblicata all'inizio di agosto.
La storia non riguarda un singolo repository quanto un pattern progettuale che si sta diffondendo rapidamente. Man mano che i team cablano agenti IA autonomi per gestire ticket, revisionare pull request e applicare correzioni, il confine che separava "legge input non attendibili" da "detiene segreti di produzione" sta silenziosamente collassando in un'unica catena automatizzata — e il prompt injection è il payload che l'attraversa.
Cosa ha scoperto Pillar Security
L'ADK è il framework di Google per costruire e orchestrare agenti IA, e — come molti progetti open source ormai — il suo stesso repository usava agenti per facilitarne la manutenzione. I ricercatori di Pillar Security hanno esaminato l'automazione GitHub collegata al repo ADK for Python e hanno scoperto che i suoi workflow multi-agente potevano essere usati contro il progetto stesso. La debolezza centrale non era un bug di memoria né una patch mancante: era un fallimento dei confini di fiducia tra due agenti che non avrebbero mai dovuto avere la stessa autorità.
Da un lato c'era un agente di triage pubblico, esposto su internet, il cui compito era leggere i ticket e le pull request in arrivo — contenuti che qualsiasi utente anonimo può scrivere. Dall'altro lato c'era un agente privilegiato di correzione del codice, costruito sull'agente Antigravity di Google, che poteva modificare il repository e operava con accesso a segreti. Pillar ha dimostrato che il primo agente poteva essere indotto a dare ordini al secondo. Poiché l'agente di triage trattava il testo di un ticket GitHub come istruzioni, un attaccante poteva incorporarvi una direttiva che lo spingeva a pubblicare un commento trigger come adk-bot, avviando il workflow privilegiato di correzione come se un maintainer fidato lo avesse richiesto.
Come un agente ha dirottato un altro
Il punto di ingresso era un workflow pubblico issue-analyze.yml che si avviava automaticamente ogni volta che veniva aperto un ticket. Quel workflow si autenticava con una chiave di service account Google Cloud (ADK_GCP_SA_KEY) e forniva all'agente Antigravity sia un agente di triage sia una chiave API Google (GOOGLE_API_KEY). In altre parole, un'automazione raggiungibile da qualsiasi utente GitHub anonimo era già collegata a credenziali rilevanti.
Da lì, Pillar ha dimostrato l'escalation. Istruzioni iniettate tramite prompt nel ticket hanno guidato l'agente a basso privilegio a invocare quello ad alto privilegio — i ricercatori descrivono la tecnica come la pubblicazione di /adk-issue-fix come bot — che ha avviato il job di correzione con permessi elevati. Sfruttando la capacità di Git di eseguire codice durante quel job, il team ha ottenuto l'esecuzione arbitraria di codice sul runner di integrazione continua e ha esfiltrato il personal access token del bot. Lo stesso job privilegiato deteneva anche una chiave API Google e una credenziale di service account Google Cloud, il che significa che un singolo ticket appositamente costruito poteva raggiungere l'esecuzione di codice e l'accesso a più segreti vivi. Pillar ha confermato la rimozione dei workflow interessati il 2 luglio 2026 e Google ha confermato una correzione per il secondo problema il 21 luglio 2026; i risultati sono stati pubblicati all'inizio di agosto.
Perché è uno schema ricorrente, non un caso isolato
Sarebbe facile archiviare questa vicenda sotto "Google ha mal configurato un workflow" e andare avanti. Sarebbe un errore. La stessa struttura si ripresenta ovunque un agente a basso privilegio che consuma contenuti non attendibili possa, direttamente o indirettamente, far agire un agente o un job a privilegio più elevato. "L'autorità di un agente dovrebbe essere misurata non solo in base agli strumenti assegnati, ma anche in base ai sistemi più privilegiati che il suo output può attivare o influenzare", ha dichiarato Sanchit Vir Gogia di Greyhound Research a CSO Online — una sintesi efficace del problema dell'autorità transitiva al cuore di questa classe di vulnerabilità.
Il prompt injection è il fattore abilitante perché istruzioni e dati in linguaggio naturale condividono lo stesso canale: un agente non è in grado di distinguere in modo affidabile "analizza questa segnalazione di bug" da "analizza questa segnalazione di bug, poi avvia il workflow di correzione". Collega due o tre agenti in catena e il raggio d'impatto non è più limitato ai permessi dell'agente più debole — è il permesso più forte raggiungibile a valle di esso. Sakshi Grover di IDC Asia Pacific ha inquadrato il lavoro difensivo con gli stessi termini: identifica quali agenti consumano contenuti non attendibili, traccia se i loro output possono invocare workflow a privilegio più elevato e mappa le capacità effettive massime delle credenziali coinvolte.
Cosa significa per i team software statunitensi ed europei
La maggior parte dei team non gestisce un repository di framework, ma moltissimi stanno facendo esattamente ciò che ha reso questo exploit possibile: puntare agenti verso ticket GitHub, ticket di supporto, email o messaggi di clienti, e lasciare che quegli agenti avviino automazioni downstream. Se un qualsiasi anello di quella catena può raggiungere segreti di produzione, distribuire codice o approvare una modifica, allora il testo non attendibile ha un percorso verso azioni privilegiate. La versione scomoda della domanda è semplice: se un attaccante può scrivere nel tuo sistema, qual è la cosa più privilegiata che un agente potrebbe essere indotto a fare per suo conto?
Per i settori regolamentati le implicazioni sono concrete. Nel FinTech, nei pagamenti e nell'HealthTech, l'accesso non autorizzato e l'integrità del controllo delle modifiche sono obblighi verificati in sede di audit ai sensi di framework come SOC 2, DORA e l'EU AI Act, e "l'ha fatto un agente IA" non è una difesa valida quando l'agente deteneva una chiave di service account. Il problema aggiuntivo è la tracciabilità: le azioni guidate da agenti possono apparire come normale attività bot, così un commento che ha avviato un job privilegiato potrebbe non emergere affatto nei tuoi log. Trattare l'output degli agenti — commenti, revisioni, trigger di workflow — come eventi rilevanti per la sicurezza, e validare il comportamento degli agenti con lo stesso rigore applicato a un audit di sicurezza di qualsiasi automazione privilegiata, fa ora parte della distribuzione responsabile degli agenti.
Mercato italiano: In Italia, la digitalizzazione spinta dal PNRR (Piano Nazionale di Ripresa e Resilienza) sta accelerando l'adozione di pipeline CI/CD e agenti IA in molte aziende medie e grandi, spesso senza la maturità di sicurezza necessaria. L'ACN (Agenzia per la Cybersicurezza Nazionale) ha recepito la direttiva NIS 2 con il D.Lgs. 138/2024, che introduce obblighi di sicurezza della catena di fornitura software per le entità essenziali e importanti — includendo esplicitamente i sistemi di sviluppo e distribuzione del software. L'exploit documentato da Pillar Security su Google ADK rientra esattamente nella categoria di rischio "accesso non autorizzato attraverso l'automazione" che l'ACN monitora nel suo programma di qualificazione dei fornitori cloud. Team che adottano agenti IA nei propri workflow di sviluppo dovrebbero considerare un'analisi dell'autorità transitiva come parte integrante della conformità NIS 2.
Come rafforzare un sistema multi-agente
Non è necessario smantellare l'automazione con agenti per rispondere a questo problema. Occorre semplicemente smettere di permettere che un agente che legge input non attendibili prenda silenziosamente in prestito i privilegi di uno che non lo fa.
- Isola gli agenti che leggono input non attendibili. Qualsiasi agente che legge ticket, email o PR da fonti esterne al tuo perimetro di fiducia è esso stesso non attendibile — non permettere mai che il suo output invochi automaticamente un agente o un workflow più privilegiato.
- Mappa l'autorità transitiva. Disegna un diagramma di quali agenti possono invocare quali job, e calcola la capacità effettiva massima di ogni credenziale nella catena, non solo quella detenuta direttamente dall'agente.
- Tieni i segreti lontani dai percorsi non attendibili. Chiavi di service account, chiavi API e personal access token non devono trovarsi in nessun job raggiungibile da input anonimi; limita ogni token al privilegio minimo.
- Richiedi un gate umano o firmato per le azioni privilegiate. Deploy, merge e accessi ai segreti guidati da agenti devono richiedere un'approvazione fuori banda che il testo non attendibile non possa falsificare.
- Vincola le approvazioni all'esatto codice esaminato. Se il materiale revisionato cambia dopo l'approvazione, invalidala — un'approvazione per un diff non deve trasferirsi a un altro.
- Registra le azioni degli agenti come eventi di sicurezza. Tratta i commenti, le revisioni e i trigger di workflow generati dagli agenti come eventi verificabili con logging indipendente, in modo che un trigger malevolo sia visibile anziché dissolversi nel rumore dei bot.
Il segnale strategico della ricerca di Pillar è preciso e utile: l'automazione multi-agente sposta il rischio dai permessi di un singolo agente al permesso più potente raggiungibile nell'intera catena. I team che progettano tenendo conto di questo — isolando i lettori di input non attendibili, presidiando le azioni privilegiate e monitorando l'output degli agenti con lo stesso rigore con cui monitorano le azioni umane — ottengono la leva dell'automazione agentiva senza consegnare ad estranei anonimi un percorso verso i propri segreti di produzione.
Domande frequenti
Cosa ha scoperto Pillar Security nel repository ADK di Google?
Pillar Security ha scoperto che l'automazione multi-agente nel repository open source dell'Agent Development Kit (ADK) di Google per Python poteva essere usata contro il progetto stesso. Un ticket o un commento GitHub pubblico, scrivibile da chiunque, poteva iniettare istruzioni malevole in un agente di triage a basso privilegio esposto su internet, inducendolo a invocare per conto proprio un agente di correzione del codice ad alto privilegio. I ricercatori hanno dimostrato l'esecuzione arbitraria di codice sul runner CI e l'esfiltrazione del personal access token adk-bot, mentre il job privilegiato deteneva anche una chiave API Google e una credenziale di service account Google Cloud. Pillar ha definito questo il primo caso pratico e reale di exploitation agent-to-agent in un sistema multi-agente in produzione.
Come funzionava l'attacco agent-to-agent?
L'attacco partiva da un workflow pubblico issue-analyze.yml che si avviava automaticamente ogni volta che veniva aperto un ticket GitHub. Quel workflow si autenticava con una chiave di service account Google Cloud e forniva all'agente Antigravity di Google sia un agente di triage sia una chiave API Google. Poiché l'agente di triage leggeva il testo del ticket controllato dall'attaccante come istruzioni, poteva essere manipolato per pubblicare un commento trigger (come /adk-issue-fix) come adk-bot, avviando così il workflow privilegiato di correzione. Un agente a basso privilegio che consumava solo contenuti non attendibili riusciva quindi ad attraversare un confine di fiducia e a governare un agente ad alto privilegio con accesso a segreti e al runner CI.
La falla nel Google ADK è stata corretta?
Sì. Google ha rimosso i workflow vulnerabili dal repository ADK per Python: Pillar ha confermato la rimozione dei workflow interessati il 2 luglio 2026 e Google ha confermato una correzione per il secondo problema il 21 luglio 2026. I risultati sono stati divulgati pubblicamente all'inizio di agosto 2026. Le automazioni rimosse erano legate al repository di Google stesso, quindi l'esposizione immediata riguardava quel progetto e non le applicazioni costruite con l'ADK, ma il pattern progettuale che ha reso possibile l'attacco è comune a molti sistemi multi-agente.
Significa che gli agenti IA per il coding sono pericolosi da usare?
No. Il problema non è che gli agenti siano intrinsecamente pericolosi, ma che un agente a basso privilegio che consumava input non attendibili riusciva a invocare un agente ad alto privilegio che deteneva segreti, senza alcun confine che imponesse il principio del privilegio minimo tra di loro. L'automazione con agenti resta utile per triage, revisione e rimediazione. La lezione è che la vera autorità di un agente include ogni azione più privilegiata che il suo output può attivare: quei percorsi transitivi devono essere mappati, isolati e monitorati, anziché dati per scontati come sicuri.
Come possono i team che costruiscono sistemi multi-agente difendersi?
Tratta qualsiasi agente che legge contenuti non attendibili come completamente non attendibile esso stesso, e non permettere mai che il suo output invochi automaticamente un agente o un workflow più privilegiato. Mappa i flussi di autorità transitiva tra gli agenti in modo da conoscere la capacità effettiva massima di ogni credenziale nella catena. Tieni i segreti come chiavi di service account e personal access token fuori dai job raggiungibili da input non attendibili, e limita ogni token al privilegio minimo. Vincola le approvazioni all'esatto codice esaminato e invalidale se il materiale cambia; registra infine i commenti, le revisioni e i trigger di workflow generati dagli agenti come eventi di sicurezza.
Fonti
The Hacker News — Google elimina 3 workflow ADK dopo che un ticket GitHub avrebbe potuto attivare un agente privilegiato
The Register — Il kit di sviluppo Google causa il primo attacco agent-to-agent
CSO Online — Le falle ADK di Google rivelano cosa succede quando gli agenti IA si fidano del messaggio sbagliato