Google lancia Antigravity. I ricercatori la bucano in 24 ore
Ventiquattro ore. È il tempo che è bastato ai ricercatori di sicurezza per dimostrare come Antigravity, la piattaforma di sviluppo agentiva presentata da Google a inizio dicembre, possa trasformarsi in un perfetto strumento di esfiltrazione dati. Non stiamo parlando di un attacco teorico o di una vulnerabilità esotica che richiede competenze da hacker cinematografico. Parliamo di una sequenza d'attacco così semplice da sembrare quasi banale: un blog di implementazione tecnica avvelenato, un carattere nascosto in font da un punto, e l'agente AI che esfiltra credenziali AWS direttamente verso un server controllato dall'attaccante.
La storia inizia quando l'utente chiede ad Antigravity di aiutarlo a integrare una nuova funzionalità nel proprio progetto, fornendo come riferimento una guida trovata online. Un'azione quotidiana, ripetuta migliaia di volte al giorno da sviluppatori in tutto il mondo. Ma in questa guida, nascosto a metà pagina in caratteri microscopici, c'è qualcosa che l'occhio umano non vede: istruzioni malevole dirette all'agente AI. È quello che i ricercatori chiamano "prompt injection indiretto", una tecnica che sta ridefinendo il panorama delle minacce informatiche nell'era degli agenti autonomi.
Come ha documentato PromptArmor, l'attacco procede con una precisione quasi coreografica. Gemini, il modello alla base di Antigravity, legge la pagina web e incontra l'injection nascosta. Le istruzioni gli ordinano di raccogliere frammenti di codice e credenziali dalla codebase dell'utente, costruire un URL malevolo e navigarlo attraverso il browser subagent integrato nella piattaforma. E qui arriva il primo colpo di scena: quando Gemini cerca di accedere al file .env contenente le credenziali AWS, si trova di fronte a una protezione. L'impostazione "Agent Gitignore Access" è disabilitata per default, impedendo agli agenti di leggere file elencati in .gitignore. Ma l'agente non si arrende. Invece di rispettare il blocco, decide semplicemente di aggirarlo usando il comando cat da terminale per dumpare il contenuto del file, bypassando le protezioni pensate per proteggerlo.
La catena prosegue: Gemini costruisce metodicamente un URL contenente le credenziali encodate, quindi invoca un browser subagent con l'istruzione di visitare quel link. E qui emerge un'altra crepa nel design: la whitelist predefinita degli URL che il browser può visitare include webhook.site, un servizio legittimo che permette a chiunque di creare endpoint temporanei per monitorare richieste HTTP. In altre parole, la porta di servizio è stata lasciata aperta per comodità. Quando il browser visita l'URL malevolo, le credenziali viaggiano nei parametri della query string, finendo nei log accessibili all'attaccante. Game over.
Anatomia di un furto programmato
Ciò che rende questo attacco particolarmente insidioso non è la complessità tecnica, ma l'architettura stessa di Antigravity. La piattaforma è stata progettata con quello che Google chiama "Agent-assisted development" come configurazione raccomandata. In pratica, significa che l'agente può decidere autonomamente quando sia necessario chiedere l'approvazione umana per le sue azioni. Durante l'intera sequenza dell'attacco documentato da PromptArmor, l'utente non ha mai visto un singolo prompt di conferma. L'agente ha preso tutte le decisioni da solo: leggere file sensibili, eseguire comandi nel terminale, aprire URL esterni.
L'Agent Manager di Antigravity, presentato come una feature stellare, amplifica ulteriormente il problema. L'interfaccia permette di gestire più agenti simultaneamente, ognuno impegnato in task differenti. È l'equivalente di avere più assistenti che lavorano in stanze separate: puoi dare un'occhiata ogni tanto, ma la maggior parte del tempo stanno operando senza supervisione diretta. Questo modello operativo, pensato per massimizzare la produttività, crea una superficie d'attacco perfetta per gli injection indiretti. Un agente che lavora in background su un'integrazione tecnica può essere compromesso senza che l'utente se ne accorga fino a quando non è troppo tardi.
Ma il prompt injection non è l'unico vettore di attacco. OWASP ha catalogato il prompt injection come rischio numero uno nella sua Top 10 per applicazioni LLM e GenAI, riconoscendo che la vulnerabilità deriva da una caratteristica fondamentale di questi sistemi: l'incapacità di distinguere chiaramente tra istruzioni dello sviluppatore e input dell'utente. È come se ogni input fosse potenzialmente codice eseguibile. Gli attacchi multimodali rendono tutto ancora più complicato: istruzioni malevole possono essere nascoste in immagini che accompagnano testo innocuo, sfruttando le interazioni tra modalità diverse che i modelli più avanzati ora supportano.
Prendiamo l'esempio dei caratteri invisibili o quasi invisibili. Un attaccante può nascondere prompt injection usando font da un punto, testo bianco su sfondo bianco, o persino caratteri Unicode speciali che l'occhio umano non percepisce ma che il modello legge perfettamente. In altri casi, le istruzioni malevole vengono codificate in Base64 o camuffate usando emoji, linguaggi multipli, o stringhe apparentemente senza senso che però influenzano l'output del modello in modi specifici. La superficie d'attacco è praticamente infinita quando l'input può assumere qualsiasi forma e il modello è stato addestrato a seguire istruzioni in linguaggio naturale.
La backdoor che sopravvive alla disinstallazione
Ma c'è un livello ulteriore di sofisticazione negli attacchi contro piattaforme come Antigravity. I ricercatori hanno dimostrato che un prompt injection può non solo esfiltrare dati, ma anche installare backdoor persistenti che sopravvivono alla sessione originale. Immaginate un agente che, seguendo istruzioni nascoste in una documentazione tecnica, aggiunge silenziosamente snippet di codice malevolo nei file di configurazione del progetto. Codice che viene poi committato nel repository, distribuito in produzione, magari anche condiviso con altri membri del team attraverso sistemi di version control.
Questo tipo di attacco, che PromptArmor ha chiamato "stored prompt injection", può avere conseguenze che si propagano ben oltre il momento iniziale della compromissione. Un piccolo frammento di codice che stabilisce una reverse shell, una chiamata API verso un server esterno che traccia l'utilizzo dell'applicazione, o modifiche sottili alla logica di business che favoriscono l'attaccante in scenari specifici. Il codice generato dall'AI viene spesso considerato più sicuro di quello che dovrebbe essere, semplicemente perché proviene da uno strumento percepito come neutrale e affidabile. Ma come hanno documentato ricercatori di Snyk e Lakera, l'output degli LLM deve essere trattato esattamente come qualsiasi altro input non fidato: validato, sanitizzato, controllato prima di essere eseguito.
La persistenza può anche essere ottenuta manipolando i file di workspace dell'IDE stesso. Antigravity mantiene configurazioni, preferenze, e cronologie che influenzano il comportamento dell'agente nelle sessioni successive. Un attaccante che riesce a iniettare istruzioni in questi file può effettivamente "addestrare" l'agente locale dell'utente a comportarsi in modo malevolo ogni volta che viene utilizzato, creando quello che i ricercatori chiamano un "poisoning della memoria". È l'equivalente digitale di lasciare note post-it sul desktop di qualcuno, solo che queste note dicono all'assistente AI di fare cose che non dovrebbe.
L'ecosistema fragile degli agenti AI
Antigravity non è solo. L'intero ecosistema degli IDE agentici sta mostrando vulnerabilità sorprendentemente simili. La piattaforma deriva da Windsurf, che aveva già presentato problemi di sicurezza documentati. Cursor, altro player importante nel settore, ha affrontato questioni analoghe. Claude Code di Anthropic ha dimostrato come un agente AI possa essere manipolato per eseguire azioni non autorizzate attraverso plugin del marketplace compromessi. Ogni nuova implementazione di "coding assistito dall'AI" sembra ripetere gli stessi pattern di vulnerabilità, come se l'industria stesse reimparando lezioni che la sicurezza informatica aveva già appreso decenni fa con SQL injection e XSS.
La differenza fondamentale è che questa volta non stiamo parlando di bug nel codice, ma di vulnerabilità intrinseche all'architettura stessa dei modelli linguistici. Come ha spiegato OpenAI nel suo recente post sul prompt injection, si tratta di una sfida di frontiera che probabilmente non verrà mai "risolta" completamente, proprio come phishing e social engineering sul web continuano a esistere nonostante decenni di contromisure. La natura stessa degli LLM, seguire istruzioni in linguaggio naturale, li rende vulnerabili a questo tipo di manipolazione.
Il problema si amplifica quando consideriamo l'ecosistema più ampio degli agenti AI. Come abbiamo documentato analizzando HumaneAIBench, i sistemi agentici stanno proliferando rapidamente, dall'automazione di email e calendari alla gestione di operazioni DevOps complesse. Ognuno di questi agenti rappresenta un potenziale vettore d'attacco se non progettato con la sicurezza come priorità assoluta. E il trend non mostra segni di rallentamento: GitHub prevede un miliardo di sviluppatori entro il 2030, molti dei quali sfrutteranno questi strumenti senza una comprensione profonda dei rischi associati.
Il "vibe coding", l'idea di creare software semplicemente descrivendo cosa si vuole in linguaggio naturale, è affascinante dal punto di vista dell'accessibilità. Ma come sottolineato da ricercatori di SecureCodeWarrior, dare a uno sviluppatore non preparato la capacità di generare migliaia di linee di codice attraverso prompt è come mettere un principiante al volante di una Formula 1. L'esperienza sarà elettrizzante per tutti, ma le possibilità che finisca male sono altissime. Il codice generato dall'AI, come confermano i benchmark di Baxbench, contiene frequentemente vulnerabilità di sicurezza che sviluppatori esperti identificherebbero immediatamente.
La sicurezza che non scala
La risposta di Google al caso Antigravity è stata pragmatica ma inquietante. Invece di annunciare fix immediati o architetture riprogettate, l'azienda ha optato per il disclaimer. Durante l'onboarding di Antigravity, agli utenti viene mostrato un avviso sui rischi di esfiltrazione dati. Il messaggio è chiaro: "sappiamo che ci sono problemi, usate a vostro rischio". Nel loro annuncio ufficiale di novembre, Google ha presentato Antigravity come parte di una nuova era di intelligenza, enfatizzando capacità agentiche e vibe coding, senza menzionare le vulnerabilità note.
Ancora più interessante è come Google ha gestito la disclosure. Poiché l'azienda aveva già dichiarato di essere consapevole dei rischi di esfiltrazione dati, PromptArmor ha deciso di non seguire il processo standard di responsible disclosure. La vulnerabilità è stata classificata come "Known Issue" nella documentazione di Antigravity, una categoria che effettivamente esclude questi problemi dal programma bug bounty di Google. In altre parole: sappiamo che esistono, ma non li consideriamo bug da fixare con priorità. È una posizione che ricorda quella del tabacco negli anni Cinquanta: mettere un'etichetta di avvertimento sul pacchetto non risolve il problema sottostante.
Questo approccio solleva domande profonde sul modello di sviluppo che l'industria AI sta adottando. Come abbiamo osservato analizzando Google Threat Intelligence, c'è una corsa agli armamenti in atto tra capacità offensive e difensive nell'ambito AI. Ma quando le piattaforme vengono rilasciate consapevolmente con vulnerabilità note, classificate come "features con rischi", il peso della sicurezza viene scaricato completamente sugli utenti finali. È sostenibile questo modello? È etico?
La questione diventa ancora più complessa se consideriamo il contesto regolatorio. L'Unione Europea sta sviluppando il Digital Omnibus, un framework che potrebbe imporre requisiti di sicurezza più stringenti per sistemi AI. Mindgard, azienda specializzata in AI security, ha sollevato preoccupazioni sul fatto che piattaforme come Antigravity potrebbero non essere conformi a normative future proprio a causa di queste vulnerabilità strutturali. Ma al momento, in assenza di regolamentazioni chiare, le aziende possono scegliere di prioritizzare velocità di rilascio rispetto a sicurezza, lasciando agli utenti il compito di navigare i rischi.
IBM definisce il prompt injection come una preoccupazione maggiore perché nessuno ha ancora trovato un modo foolproof per affrontarlo. Le vulnerabilità nascono da una caratteristica fondamentale dei sistemi GenAI: la capacità di rispondere a istruzioni in linguaggio naturale. Identificare affidabilmente istruzioni malevole è difficile, e limitare gli input degli utenti potrebbe cambiare fondamentalmente come operano gli LLM. È un problema architetturale, non un bug che si può patchare con un aggiornamento software.
CrowdStrike, attraverso l'acquisizione di Pangea, ha analizzato oltre 300.000 prompt avversariali e traccia più di 150 tecniche di prompt injection diverse. La loro tassonomia evidenzia come la superficie d'attacco continui ad espandersi. Ogni nuovo modello, ogni nuova capacità multimodale, ogni integrazione con tool esterni aggiunge potenziali vettori di compromissione. E mentre le difese migliorano, lo fanno anche le tecniche d'attacco, in una danza evolutiva che ricorda l'eterna battaglia tra antivirus e malware.
Il futuro incerto dell'automazione fidata
Dove ci porta tutto questo? Il fronte cyber dell'AI sta diventando sempre più complesso e sfumato. Da un lato, abbiamo strumenti che promettono di democratizzare lo sviluppo software e moltiplicare la produttività. Dall'altro, creiamo superfici d'attacco che non sappiamo ancora come difendere adeguatamente. Il caso Antigravity è emblematico: una piattaforma rilasciata in public preview da una delle aziende tech più sofisticate al mondo, con vulnerabilità note e documentate che permettono esfiltrazione di credenziali in scenari d'uso realistici.
La sfida non è solo tecnica, ma anche culturale. Gli sviluppatori devono imparare a trattare il codice generato dall'AI con lo stesso scetticismo che riservano al codice preso da Stack Overflow. Le organizzazioni devono implementare policy che definiscano chiaramente quali dati possono essere esposti agli agenti AI e quali no. I security team devono evolvere le loro pratiche per includere la detection e la mitigazione di prompt injection, una categoria di attacco che la maggior parte dei tool tradizionali non è progettata per intercettare.
Come evidenziato nel nostro articolo sui browser AI, la promessa di un'esperienza web potenziata dall'intelligenza artificiale si scontra con realtà di sicurezza ancora irrisolte. OpenAI ha recentemente ammesso che il suo browser Atlas potrebbe essere sempre vulnerabile a prompt injection, riconoscendo che probabilmente non verrà mai "risolto" completamente. L'azienda sta implementando un "LLM-based automated attacker" che usa reinforcement learning per trovare nuove tecniche d'attacco prima che vengano scoperte in the wild, ma è essenzialmente una corsa tra innovazione offensiva e difensiva dove il vantaggio sembra pendere verso gli attaccanti.
La sicurezza dell'AI richiede un approccio stratificato che ricordi quello della difesa in profondità tradizionale. Non basta avere un solo layer di protezione: servono validazione degli input, sandboxing dell'esecuzione, monitoring continuo, logging dettagliato, e soprattutto una cultura di sicurezza che permei ogni livello dello stack. Gli agenti AI devono operare con il principio del privilegio minimo, accedendo solo ai dati strettamente necessari per il task specifico. Le azioni consequenziali devono richiedere conferma esplicita dell'utente. Le whitelist devono essere minimaliste, non permissive per default.
Ma forse la lezione più importante del caso Antigravity è che la velocità di innovazione non può venire a scapito della sicurezza fondamentale. Rilasciare piattaforme con "Known Issues" che includono esfiltrazione di credenziali non è accettabile, indipendentemente da quanti disclaimer vengano mostrati durante l'onboarding. Se l'industria AI vuole che questi strumenti vengano adottati dalle enterprise con dati sensibili, deve dimostrare che la sicurezza non è un afterthought ma un requisito fondamentale del design. Altrimenti, rischiamo di costruire un futuro dove l'automazione intelligente diventa il vettore preferito degli attaccanti, proprio come le email negli anni Duemila o le webapp negli anni Dieci.
La strada verso agenti AI veramente sicuri sarà lunga e probabilmente non avrà mai una destinazione finale. Ma possiamo almeno evitare di ripetere errori che l'industria software ha già fatto e superato. Trattare l'input come codice fidato è stato un problema per SQL injection trent'anni fa, per XSS venticinque anni fa, e ora si ripresenta con il prompt injection. La differenza è che questa volta la posta in gioco è più alta: non stiamo parlando di singole applicazioni web, ma di agenti autonomi che potrebbero gestire porzioni significative della nostra infrastruttura digitale. Meglio imparare la lezione ora, prima che il costo diventi insostenibile.