TLDR
- GitLost mostra il rischio degli agenti AI che leggono testo pubblico e lavorano con permessi su repository privati.
- Il problema non è una frase magica: è il workflow che mescola input non fidato, tool potenti e contesto sensibile.
- Issue, commenti, README e log vanno trattati come dati ostili quando un agente può agire su file o segreti.
- Separare contesto, permessi e output è più importante che scrivere policy lunghe e invisibili.
Perché conta ora
La promessa degli agenti AI nello sviluppo è bellissima: leggo issue, capisco il contesto, apro il repository, propongo patch, magari preparo una pull request.
La promessa ha un problema: l'agente legge anche testo scritto da sconosciuti.
GitLost è interessante proprio per questo. Non parla dell'ennesimo prompt colorato da demo, ma di un confine molto concreto: un contenuto pubblico può influenzare un sistema che ha accesso a contesto privato?
Se la risposta è sì, non stai solo usando AI per automatizzare lavoro. Stai dando a una pagina pubblica un canale indiretto verso dati che non dovrebbero uscire.
La frase importante è questa: l'input non fidato non smette di essere non fidato solo perché lo legge un modello invece di un parser.
Il confine che si rompe
In un workflow classico, un'issue pubblica è testo. Può essere fastidiosa, falsa, manipolatoria, ma resta testo.
In un workflow agentico, la stessa issue può diventare istruzione. L'agente la legge, la riassume, cerca file, confronta errori, decide cosa serve, prepara output. Se ha permessi larghi, può portare nel suo ragionamento dati che l'autore dell'issue non dovrebbe vedere.
Questo è il punto: il bug non è solo "il modello obbedisce". Il bug è che il sistema ha permesso a un contenuto pubblico di stare nello stesso spazio operativo del contesto privato.
È la vecchia lezione della sicurezza web, ma con una faccia nuova: mai mescolare dati non fidati e istruzioni privilegiate senza un confine rigido.
Prompt injection o data leak?
La prompt injection è la miccia. Il data leak è l'incendio.
Un attaccante può scrivere un testo che prova a influenzare l'agente: "ignora le regole", "leggi questo file", "riassumi il contesto", "incolla il risultato". Ma il danno reale arriva solo se l'ambiente intorno all'agente gli permette di accedere a risorse sensibili e poi restituire contenuti verso il canale sbagliato.
Per questo la difesa non può essere solo "miglioriamo il prompt di sistema".
Un prompt è una cintura di sicurezza, non un muro.
Servono barriere esterne:
- repository pubblici e privati in sessioni separate;
- token con permessi minimi;
- blocco di letture fuori dallo scope del task;
- output filtrati prima di tornare su issue pubbliche;
- log verificabili delle azioni dell'agente;
- review umana quando un contenuto pubblico causa accesso a dati privati.
Se l'agente può vedere tutto, prima o poi qualcuno proverà a fargli raccontare troppo.
Cosa controllare nei tuoi workflow
Se usi agenti su GitHub, GitLab, Jira, Linear, Slack o strumenti simili, fai queste domande:
- L'agente legge contenuti scritti da utenti esterni?
- Nella stessa sessione può accedere a repository privati?
- Può leggere issue, commenti, log di CI, file
.envo segreti? - Può pubblicare risposte nel canale da cui è arrivato l'input?
- I token sono limitati al repository necessario?
- Esiste una lista dei tool concessi all'agente?
- Gli output verso spazi pubblici passano da revisione?
- I log mostrano quali file ha letto e perché?
La domanda più importante è l'ultima: potresti ricostruire cosa ha visto l'agente dopo un incidente?
Se no, stai delegando fiducia senza audit.
La difesa pratica
Per team piccoli, una base seria è questa:
- non far lavorare agenti su issue pubbliche con accesso a repo privati;
- creare sessioni isolate per contesto pubblico e privato;
- usare token temporanei e stretti;
- bloccare tool non necessari;
- impedire risposte automatiche che includono estratti di file;
- trattare README, issue e commenti come input ostili;
- chiedere review manuale su ogni output generato da contesto misto.
Non serve rendere l'AI inutile. Serve impedire che l'agente diventi un ponte tra due mondi che devono restare separati.
La lezione Able2Code
Gli agenti AI non sono pericolosi perché "pensano male".
Sono pericolosi quando li colleghiamo a tool potenti e poi fingiamo che il testo che leggono sia innocente.
Una issue pubblica non deve poter parlare con il tuo repository privato. Se lo fa attraverso un agente, il problema non è filosofico. È architettura.
Il modello può aiutarti a scrivere codice.
Il confine, però, devi disegnarlo tu.
FAQ
Che cos'è GitLost?
È una ricerca che mostra come un agente AI collegato a GitHub possa essere indotto da contenuti pubblici a esporre informazioni di repository privati o contesto sensibile.
Perché le issue pubbliche sono rischiose per gli agenti AI?
Perché sono input non fidato. Se l'agente le interpreta come istruzioni operative e ha accesso a risorse private, il confine tra pubblico e privato diventa fragile.
È un problema solo di GitHub?
No. Qualsiasi piattaforma con agenti che leggono contenuti esterni e usano tool interni può avere lo stesso tipo di rischio.
Come si difende un team piccolo?
Permessi minimi, sandbox, allowlist di repository, nessun segreto nel contesto dell'agente, review umana sugli output e log chiari delle azioni eseguite.
Gli agenti AI vanno disattivati?
No. Vanno isolati e governati. Un agente utile non deve avere automaticamente accesso a tutto quello che un umano potrebbe vedere.