Un issue formulato con cortesia, niente di più. È bastato questo ai ricercatori di Noma Labs per convincere l’agente AI di GitHub a svuotare repository privati e consegnare il codice a un attaccante. La vulnerabilità, battezzata GitLost, non è risolvibile con una patch nel senso tradizionale: non c’è un buffer overflow da correggere o un endpoint da proteggere. È un problema di design che abita nel cuore dell’architettura degli agenti LLM.

L’agente in questione – un assistente capace di interagire con issue, pull request e file system – opera con un ampio ventaglio di strumenti e permessi. Gli basta ricevere una richiesta apparentemente legittima, magari un issue che chiede di “verificare la presenza di un file in un certo percorso”, per attingere a repository privati e restituire contenuti che non dovrebbero mai uscire dal perimetro di progetto. Il prompt non contiene caratteri speciali né exploit sofisticati: è pura ingegneria sociale applicata a un modello linguistico.

Il nocciolo tecnico sta nel modo in cui gli agenti LLM orchestrano strumenti. Quando un modello riceve un’istruzione, può decidere di chiamare una funzione per leggere un file o interrogare un repository. Se il sistema non ha sufficienti guardrail architetturali – ad esempio una separazione netta tra i permessi dell’utente che scrive l’issue e quelli dell’agente – il passo dalla lettura legittima alla fuga di dati è brevissimo. In GitLost, l’agente apparentemente non distingue tra repository pubblici e privati, oppure lo fa in modo troppo debole per resistere a un giro di parole ben congegnato.

La risposta di GitHub è stata finora il silenzio, e la mancata documentazione del problema lascia intendere che l’azienda non abbia ancora una contromisura strutturale. Qualsiasi fix che si limiti a filtrare prompt non può essere definitivo: gli LLM sono intrinsecamente suscettibili a prompt injection, e la corsa tra attaccanti e difensori in questo campo è asimmetrica. L’unica via d’uscita è ripensare i confini di sicurezza attorno all’agente, isolando le risorse private in modo che nemmeno un modello ingannato possa accedervi senza un’autorizzazione granulare e contestuale.

Per chi ospita codice proprietario o soggetto a regolamentazioni stringenti, la falla solleva un interrogativo più ampio: ha senso affidare un assistente AI a un servizio cloud che opera sul codice sorgente? La sovranità dei dati torna centrale. Se l’agente risiede nello stesso tenant del repository ma può essere pilotato da input esterni non sufficientemente verificati, il rischio di esfiltrazione non è teorico. Un deployment on-premise, dove l’agente gira in un ambiente segregato e con accesso limitato solo ai repository necessari, almeno ridurrebbe la superficie d’attacco, anche se non immunizzerebbe dal problema di fondo.

GitLost non sarà l’ultimo incidente del genere. Con l’adozione massiccia di coding agent, la superficie di attacco si allarga a ogni nuova funzionalità concessa al modello. La comunità della sicurezza dovrà sviluppare meccanismi di confinamento più robusti, mentre le organizzazioni dovranno soppesare la produttività promessa dagli agenti AI contro la possibilità concreta che una frase educata esponga anni di lavoro.