La Documentazione che Ti Tradisce: Vulnerabilità Nascoste nei File Accessibili all'AI
Il Pericolo Silenzioso Nascosto in Piena Vista
Di attacchi tramite prompt injection e avvelenamento dei modelli linguistici se n'è parlato parecchio. Ma c'è una minaccia che non ha ricevuto abbastanza attenzione: la documentazione che diventa obsoleta e diventa un vettore di attacco.
Un team di ricercatori ha scoperto qualcosa di preoccupante. Hanno analizzato i file llms.txt e llms-full.txt — formati di documentazione leggibili dalle macchine, pensati per aiutare i sistemi AI a comprendere i siti web. Quello che hanno trovato era allarmante. Su migliaia di domini di contractor della difesa, aziende Fortune 500 e big tech, hanno scoperto 120 file che rimandavano a nomi di pacchetti o domini che non esistono più.
Il concetto dell'attacco è elegante nella sua semplicità. Un attacker non ha bisogno di violare un sistema. Deve solo aspettare.
Come Funziona Davvero l'Attacco
Immaginiamo questo scenario: uno sviluppatore usa un agente AI per configurare un progetto. L'agente legge il file llms.txt dell'azienda per le istruzioni di installazione, trova un riferimento a una dipendenza chiamata cool-utils-lib, e — dato che l'agente ha i permessi per eseguire comandi del package manager — la installa.
Il problema? Quel nome di pacchetto non è mai stato registrato. Fino a quando l'attacker non l'ha registrato.
Nel loro esperimento controllato, i ricercatori hanno fatto esattamente questo. Hanno reclamato alcuni di questi nomi abbandonati, caricato pacchetti "phone home" benigni (progettati solo per registrare quando venivano acceduti), e hanno aspettato. I risultati erano impressionanti: meno di un'ora dopo la pubblicazione, un'azienda Fortune 500 aveva già installato uno dei loro pacchetti. Nei giorni successivi, "una dozzina di altre" organizzazioni hanno fatto contatto.
Non era un attacco reale — i pacchetti erano innocui, nessun sistema di produzione è stato compromesso. Ma la raggiungibilità è stata dimostrata. La surface di attacco è reale.
Perché gli Agenti AI Peggiorano le Cose
Ecco cosa rende tutto questo particolarmente pericoloso: la sicurezza tradizionale assume che siano gli utenti a prendere le decisioni. Se dai a qualcuno un documento con istruzioni sbagliate, potrebbe seguirle. Ma gli esseri umani spesso notano errori evidenti, fanno domande di chiarimento, o si accorgono quando qualcosa non torna.
Gli agenti AI funzionano diversamente. Trattano la documentazione come verità eseguibile. Se il tuo llms.txt dice "run npm install legacy-widget", l'agente spesso lo fa e basta — senza chiedersi se quel pacchetto esiste ancora, chi ne è il proprietario, o se è quello giusto.
I ricercatori hanno testato diversi agenti — Claude, OpenAI Codex e Hermes di Nous Research — e tutti hanno seguito i riferimenti problematici. Non è un difetto specifico di un vendor. È un problema sistemico creato dalla combinazione di:
- Documentazione non mantenuta che diventa obsoleta
- Agenti AI configurati con permessi di esecuzione che si fidano ciecamente della documentazione
- La reclamabilità di nomi di pacchetti abbandonati nei registri pubblici
Cosa Puoi Fare
Le raccomandazioni dei ricercatori sono pratiche e attuabili:
1. Controlla regolarmente i tuoi file llms.txt
Se la tua organizzazione pubblica documentazione leggibile dall'AI, tratta i riferimenti ai pacchetti come tratti le dipendenze del codice. Verifica che ogni pacchetto, dominio o comando menzionato punti davvero a una risorsa legittima e attuale. Un semplice errore di battitura nella documentazione può diventare un'infrastruttura reclamabile.
2. Implementa checkpoint di approvazione per le azioni degli agenti
Non permettere agli agenti AI di eseguire comandi shell o installare dipendenze automaticamente. Richiedi step di approvazione espliciti. La documentazione dovrebbe essere materiale di riferimento, non un runbook.
3. Monitora i registri dei pacchetti per i sosia
Valuta di impostare alert per nomi di pacchetti simili alle tue dipendenze interne. Il rilevamento precoce ti dà una finestra per reclamare i nomi prima che lo faccia qualcun altro.
Il Quadro Più Ampio
Questa ricerca evidenzia qualcosa di importante sul passaggio allo sviluppo assistito dall'AI: il modello di fiducia è cambiato, ma le nostre pratiche non lo hanno ancora raggiunto.
Quando gli sviluppatori lavoravano da soli, la documentazione era una guida. Quando gli agenti AI lavorano accanto agli sviluppatori, la documentazione diventa un'API. E come ogni API, ha bisogno di validazione, versionamento e attenzione alla sicurezza.
La buona notizia? È un problema risolvibile. A differenza di molte vulnerabilità di sicurezza, le correzioni qui sono semplici — documenta meglio, fidati di meno, verifica di più. La sfida è costruire l'abitudine di trattare la documentazione leggibile dall'AI con lo stesso rigore che applichiamo al codice di produzione.
Man mano che gli agenti AI di coding diventano più integrati nei flussi di lavoro di sviluppo, aspettiamoci di vedere più ricerche come questa emergere. Gli attacchi non arrivano direttamente per i tuoi modelli o i tuoi dati. A volte aspettano pazientemente nella tua documentazione, pazienti come un refuso.