Oltre cento siti aziendali pubblicano file di documentazione destinati agli agenti AI che contengono comandi di installazione verso pacchetti che nessuno ha mai pubblicato. Alcune decine di aziende, fra cui diverse Fortune 500, hanno effettivamente eseguito il codice che un gruppo di ricercatori ha piazzato in quei nomi liberi per dimostrarlo. Almeno un sito, per una configurazione sbagliata, indirizzava chiunque lo leggesse, umano o macchina, verso malware vero e gi� attivo.
La ricerca, condotta da una startup israeliana in incognito, ha scansionato 6.214 domini vivi appartenenti ad appaltatori della difesa, aziende Fortune 500 e big tech, e vi ha trovato 8.265 file llms.txt e llms-full.txt, la convenzione emergente con cui un sito offre alle macchine un riassunto dei propri contenuti e della propria struttura, l’equivalente per gli agenti del robots.txt dei motori di ricerca (molti siti ospitano entrambe le varianti). Di quei file, 120, ciascuno su un sito diverso, rimandavano a pacchetti o a nomi di dominio non registrati, per un totale di 227 comandi. I ricercatori hanno allora registrato una manciata di quei nomi liberi e vi hanno ospitato pacchetti che, una volta eseguiti, contattavano un loro server: la prima risposta � arrivata entro un’ora, da una Fortune 500, e col passare del tempo se ne sono aggiunte qualche decina, da altre grandi aziende e da startup.
Il richiamo registrava anche la catena dei processi che avevano generato ciascuna installazione, ed � da l� che sono emersi i nomi degli agenti coinvolti: Claude, Codex di OpenAI e Hermes di Nous Research. La sequenza si chiude solo quando un agente di coding ha il permesso di eseguire comandi shell e tratta il file come documentazione di installazione autorevole: a quel punto scarica il pacchetto e lo esegue, senza che nessuno gli abbia chiesto di verificare a chi appartenga quel nome. Il problema, rilevano i ricercatori, � proprio il fatto che gli agenti trattano la documentazione dei fornitori come verit� acquisita e non la mettono in discussione, e non lo fanno nemmeno gli umani che li supervisionano.
Il pacchetto malevolo nella documentazione di Clerk
Su clerk.com, sito legittimo dell’omonima azienda, i ricercatori hanno trovato un file per gli agenti che conteneva la riga npx clerk-next-fix-auth-protection. A differenza di un comando di installazione ordinario, npx scarica il pacchetto nella cache di npm ed esegue il binario che quel pacchetto espone, senza aggiungerlo al manifesto delle dipendenze del progetto. Quando i ricercatori sono andati a controllare, lo spazio prima vuoto risultava gi� occupato: qualcuno aveva rivendicato il nome e vi ospitava malware attivo.
Clerk ha nel frattempo corretto il problema, e ha precisato che un agente il quale avesse gi� installato un binario incluso nel pacchetto @clerk/eslint-plugin non correva rischi, mentre negli altri casi il pacchetto malevolo veniva installato davvero. Se ci siano state infezioni reali non � chiaro. “Il comando somigliava esattamente a qualcosa che il fornitore avrebbe distribuito, perch� stava nel file di istruzioni del fornitore”, hanno scritto i ricercatori. “Mancava solo il nome nel registro: ogni livello di fiducia era intatto tranne l’unico che nessuno aveva pensato di controllare”.
Come quelle voci sbagliate siano finite nei file non � chiaro. In molti casi precedono l’era degli agenti, perch� erano gi� presenti in documentazione non destinata alle macchine, il che indica una scrittura manuale da parte di persone; per le altre i ricercatori sospettano una generazione automatica, da parte di modelli che hanno allucinato il nome del pacchetto oppure che, esattamente come gli agenti che oggi leggono quei file, non hanno saputo distinguere un’istruzione legittima da una illegittima. Non sempre si tratta di pacchetti: in un caso il file suggeriva il framework di test Citrus per le prove di integrazione rimandando a un dominio mai registrato, che chiunque pu� comprare per piantarci istruzioni proprie.
Perch� nessun allarme � scattato
Agli occhi di un EDR o di un proxy aziendale la scena � quella di uno sviluppatore che lancia un gestore di pacchetti legittimo: un pip install da pypi.org, dominio che ogni proxy aziendale ha gi� in lista bianca, con come processo padre l’agente di coding che l’azienda ha installato di proposito. Nessuna anomalia rilevata, nessun avviso generato. Il punto di rottura sta pi� a monte, nello scarto fra l’istruzione e la sua esecuzione, dove nessuno degli strumenti in campo sta guardando.
Il file non deve nemmeno stare sul sito dell’azienda che poi esegue il comando. Gli agenti raccolgono contesto dalla documentazione di un partner, dal riferimento all’SDK di un fornitore, dalla guida di installazione di un progetto della comunit�, e se quel terzo rimanda a un pacchetto non rivendicato la catena funziona identica. La fiducia, in altre parole, si trasmette lungo tutti i passaggi senza che nessuno la verifichi in nessuno di essi.
Un’istruzione benigna che diventa pericolosa dopo
L’intento malevolo, in questa vicenda, non � presente nel momento in cui l’istruzione viene scritta, e qui sta la differenza con le iniezioni di prompt gi� note. In una prompt injection qualcuno pianta deliberatamente istruzioni malevole, in questo caso invece l’istruzione pu� essere del tutto benigna e provenire da una fonte legittima, come appunto la documentazione di un’azienda vera, senza alcun attore malevolo nel momento in cui � stata scritta: il pericolo arriva dopo, quando il pacchetto o il dominio a cui rimanda viene abbandonato e qualcun altro lo rivendica.
Il controllo che manca � meccanico: ogni nome citato in un file destinato agli agenti si pu� risolvere contro il registro che lo servirebbe, npm o PyPI per i pacchetti, RDAP per gli host, ed � esattamente ci� che i ricercatori hanno automatizzato. Nella lista di quello che guardano, accanto ai pacchetti mai pubblicati e ai domini liberi, ci sono anche i comandi che un assistente eseguir�, le chiavi e gli endpoint lasciati nelle pagine, e le istruzioni scritte per il modello invece che per il lettore. Le istruzioni, esplicite o implicite, stanno per� ovunque un agente passi, e i file llms.txt sono soltanto quelli che le aziende pubblicano di propria iniziativa.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
