Nel teatro sempre più affollato dell’intelligenza artificiale applicata allo sviluppo software, la notizia che Google abbia corretto una vulnerabilità critica nella propria piattaforma Antigravity non sorprende quanto dovrebbe, e forse è proprio questo il problema. Il bug, individuato dalla società di cybersecurity Pillar Security, non è un semplice incidente di percorso, ma un sintomo strutturale di una tensione irrisolta tra automazione e controllo, tra promessa di produttività e realtà operativa. In altre parole, il futuro che vendiamo agli sviluppatori ha iniziato a comportarsi come il passato che fingevamo di aver superato, solo con più marketing e meno visibilità sugli effetti collaterali.
La dinamica tecnica della vulnerabilità è tanto banale quanto inquietante. Il tool find_by_name, integrato nell’ambiente Antigravity, accettava input dell’utente e lo passava direttamente a un’utility da linea di comando senza alcuna validazione. In un contesto tradizionale, questo sarebbe classificato come errore da manuale, quasi un esercizio di base nei corsi di sicurezza applicativa. Inserito però in un sistema agentico, capace di eseguire azioni autonome, il difetto assume un’altra dimensione. Il prompt injection, quella tecnica apparentemente accademica che molti liquidavano come curiosità da conferenza, diventa improvvisamente un vettore operativo di esecuzione remota di codice. Tradotto in termini meno eleganti, basta un input ben costruito per trasformare una funzione di ricerca in un grimaldello digitale.
Il passaggio chiave, quello che dovrebbe far alzare più di un sopracciglio nei board aziendali, riguarda la concatenazione delle capacità. Antigravity non si limita a cercare file, ma può anche crearli. Questa combinazione consente di costruire una catena d’attacco completa, in cui uno script malevolo viene prima generato e poi eseguito attraverso una funzione apparentemente innocua. Non serve interazione dell’utente una volta che il prompt injection è stato iniettato nel flusso operativo. L’automazione, che doveva ridurre il carico cognitivo degli sviluppatori, elimina anche l’ultimo baluardo umano di controllo. Il risultato è un sistema che esegue fedelmente istruzioni che nessuno ha realmente autorizzato.
Chi osserva il fenomeno con un minimo di memoria storica noterà un déjà-vu quasi fastidioso. La storia dell’informatica è costellata di vulnerabilità dovute a input non validati, dalle SQL injection degli anni Novanta fino alle command injection nei sistemi Unix-like. La differenza oggi non è nella natura del problema, ma nella superficie d’attacco. Gli agenti AI amplificano esponenzialmente il raggio d’azione di un errore banale. Se ieri una vulnerabilità comprometteva un’applicazione, oggi può compromettere un intero flusso di sviluppo, con effetti a cascata su repository, pipeline CI/CD e ambienti di produzione.
Nel frattempo, OpenAI aveva già lanciato un avvertimento simile, quasi profetico, riguardo ai propri agenti integrati in ChatGPT. Quando un sistema AI viene connesso a fonti esterne, che siano email, file o account aziendali, l’accesso ai dati sensibili diventa parte del suo perimetro operativo. Il problema non è solo cosa l’AI può fare, ma cosa può essere indotta a fare. Il prompt injection sfrutta esattamente questa ambiguità, mimetizzandosi tra input legittimi e istruzioni malevole, in un gioco di prestigio semantico che le macchine non sono ancora in grado di distinguere con affidabilità.
La dimostrazione pratica fornita dai ricercatori è quasi ironica nella sua semplicità. Uno script che apre la calcolatrice del sistema. Un gesto innocuo, quasi comico, ma sufficiente a dimostrare che il confine tra ricerca e esecuzione è stato violato. Nella sicurezza informatica, questi proof-of-concept minimalisti hanno sempre avuto un valore simbolico. Non servono a fare danni, servono a dimostrare che i danni sono possibili. È la versione digitale del canarino nella miniera, e il fatto che continuiamo a ignorarlo suggerisce una certa ostinazione culturale.
La questione più interessante, però, non è tecnica ma strategica. Le piattaforme come Antigravity rappresentano il tentativo delle big tech di trasformare lo sviluppo software in un processo sempre più autonomo, quasi industrializzato. L’idea è seducente: meno codice scritto manualmente, più orchestrazione di agenti intelligenti che generano, testano e distribuiscono software. Il problema è che ogni livello di astrazione introduce nuove opacità. Quando un sistema diventa troppo complesso per essere compreso nei suoi dettagli operativi, la sicurezza smette di essere una proprietà intrinseca e diventa un atto di fede.
Le osservazioni di Pillar Security colpiscono nel segno quando affermano che l’industria deve spostarsi da un approccio basato sulla sanitizzazione a uno basato sull’isolamento dell’esecuzione. È un cambio di paradigma che molti considerano costoso, se non addirittura impraticabile su larga scala. Isolare ogni comando che interagisce con una shell significa ripensare l’architettura dei sistemi, introdurre sandboxing rigorosi, accettare una perdita di performance e una maggiore complessità operativa. In altre parole, significa fare esattamente ciò che il mercato tende a evitare finché non diventa inevitabile.
Il contesto economico aggiunge un ulteriore livello di cinismo. Le aziende competono per rilasciare funzionalità agentiche sempre più avanzate, alimentando un ciclo di hype che premia la velocità più della robustezza. In questo scenario, la sicurezza diventa una variabile subordinata, spesso relegata a patch successive e comunicazioni postume. Il fatto che Google abbia riconosciuto e corretto il problema in tempi relativamente rapidi è positivo, ma non cambia la dinamica di fondo. La vulnerabilità è esistita, è stata sfruttabile, e avrebbe potuto essere scoperta da attori meno benevoli.
Un osservatore più malizioso potrebbe sostenere che siamo entrati in una fase in cui le vulnerabilità non sono più anomalie, ma effetti collaterali inevitabili di sistemi sempre più autonomi. Non è un pensiero rassicurante, ma è difficile ignorare la frequenza con cui emergono problemi simili. Il cosiddetto “CopyPasta License Attack”, documentato da altre società di sicurezza, dimostra come file apparentemente innocui possano diventare vettori di infezione su larga scala, sfruttando la tendenza degli assistenti AI a copiare e integrare contenuti senza una verifica critica.
La vera domanda, quella che pochi sembrano voler affrontare apertamente, riguarda la sostenibilità di questo modello. Quanto possiamo spingere l’automazione prima che il costo della sicurezza superi i benefici della produttività? È una domanda scomoda, perché mette in discussione la narrativa dominante secondo cui l’AI è una leva inevitabile di efficienza. La realtà è più sfumata. L’AI aumenta la produttività, ma amplifica anche gli errori. Riduce il lavoro umano, ma elimina anche i controlli impliciti che quel lavoro garantiva.
Nel frattempo, gli sviluppatori si trovano in una posizione paradossale. Da un lato, vengono incoraggiati a fidarsi degli strumenti AI, a delegare compiti sempre più complessi, a integrare agenti nei propri workflow quotidiani. Dall’altro, sono chiamati a gestire le conseguenze di sistemi che non controllano pienamente. È una tensione che ricorda quella delle prime fasi del cloud computing, quando le aziende migravano infrastrutture critiche senza comprendere appieno le implicazioni di sicurezza. La differenza è che questa volta la velocità di adozione è molto più alta, e il margine di errore molto più sottile.
Una frase, tra le tante che circolano nei report di sicurezza, merita di essere isolata perché sintetizza il problema meglio di qualsiasi analisi: ogni parametro che raggiunge una shell è un potenziale punto di iniezione. È una verità banale, quasi ovvia, e proprio per questo spesso ignorata. Nel mondo dell’AI agentica, quella banalità diventa una bomba a orologeria. Ogni interfaccia, ogni tool, ogni integrazione rappresenta una possibile superficie d’attacco. Non esiste scorciatoia algoritmica che possa eliminare questo rischio.
Il caso Antigravity non segna una svolta, ma una conferma. L’industria dell’intelligenza artificiale sta entrando in una fase in cui la sicurezza non può più essere trattata come un accessorio. Le promesse della Silicon Valley, sempre più ambiziose e sempre meno verificabili, si scontrano con una realtà tecnica che non ammette scorciatoie. La storia insegna che ogni rivoluzione tecnologica porta con sé una fase di euforia seguita da una fase di consolidamento, in cui le inefficienze vengono eliminate e le vulnerabilità corrette. Siamo probabilmente ancora nella prima fase, quella in cui tutto sembra possibile e niente è completamente sotto controllo.
Chi guida aziende tecnologiche oggi dovrebbe porsi una domanda semplice, quasi brutale: stiamo costruendo sistemi che funzionano, o sistemi che speriamo funzionino? La differenza, nel lungo periodo, è ciò che separa le piattaforme destinate a diventare infrastrutture critiche da quelle che finiranno come note a piè di pagina nei report di sicurezza. Nel frattempo, gli attaccanti non aspettano. Non leggono i comunicati stampa, non partecipano ai keynote, non si lasciano impressionare dalle demo. Osservano, testano, sfruttano. E, a giudicare da casi come questo, trovano spesso terreno fertile.
Report: https://www.pillar.security/blog/prompt-injection-leads-to-rce-and-sandbox-escape-in-antigravity