120 file llms.txt compromessi: 30 Fortune 500 hanno installato codice non proprietario via Claude, Codex e Hermes

**

L’ecosistema di intelligenza artificiale sta subendo una nuova forma di attacco della supply‑chain: file di configurazione “machine‑readable” – llms.txt e llms‑full.txt – pubblicati da più di 100 aziende includono riferimenti a pacchetti o domini inesistenti. Quando gli agenti LLM, autorizzati a eseguire comandi di shell, li consumano, scaricano e installano codice non posseduto dal proprietario del sito. Il risultato? Un “phone‑home” da parte di almeno una Fortune 500 entro un’ora dal test, e decine di ulteriori segnali da altre grandi imprese.

Il vettore di attacco: llms.txt e llms‑full.txt

Le convenzioni llms.txt / llms‑full.txt nascono come risposta al crescente utilizzo di LLM per l’automazione della documentazione. Simili a robots.txt, questi file forniscono una panoramica strutturata del contenuto di un sito, destinata a essere letta da agenti AI. Il problema nasce quando gli autori includono istruzioni di installazione – ad esempio pip install package‑non‑esistente o npm install nome‑vuoto – senza verificare la registrazione del pacchetto nei repository ufficiali (PyPI, npm, ecc.).

Gli esperti di una startup israeliana, operante in stealth, hanno scansionato 6 214 domini appartenenti a contractor della difesa, Fortune 500 e Big Tech, trovando 8 265 file di questo tipo. Di questi, 120 (1,45 %) puntavano a risorse non registrate. In totale, i file contenevano 227 comandi di installazione o richieste di dominio inesistenti. La maggior parte di queste voci risale a prima dell’avvento dell’AI, suggerendo che siano state inserite manualmente da sviluppatori inconsapevoli della futura esposizione. Alcune, però, sembrano frutto di “hallucination” di LLM addestrati a generare documentazione automatica.

Le prove sul campo: 30 Fortune 500 e l’attività di Claude, Codex e Hermes

Per verificare la reale capacità di sfruttamento, i ricercatori hanno registrato alcuni dei nomi di dominio e pacchetti vuoti, inserendo payload di “phone‑home”. Entro 60 minuti, un agente di una Fortune 500 (non divulgato per motivi di riservatezza) ha contattato il server, confermando che il comando era stato eseguito. Il monitoraggio successivo ha registrato altre decine di “beacon” provenienti da aziende di media e grande dimensione, inclusi almeno altri 20 nomi Fortune 500.

L’analisi dei processi ha mostrato una catena di spawn tipica: l’agente LLM (es. Claude di Anthropic) legge llms.txt → invoca il gestore di pacchetti (pip, npm, npx) → il gestore scarica il pacchetto dal registro (che ora è controllato dagli attaccanti) → il codice maligno invia una richiesta di rete. In un caso emblematico, il file su clerk.com conteneva npx clerk‑next‑fix‑auth‑protection. Un attore maligno ha registrato il pacchetto @clerk/eslint-plugin e inserito malware. Clerk ha successivamente rimosso il pacchetto, ma il caso dimostra come la vulnerabilità possa sfociare in un vero e proprio “supply‑chain attack” senza alcuna fase di phishing o exploit tradizionale.

Implicazioni per la supply chain AI e le difese tradizionali

Le conseguenze vanno ben oltre il singolo caso. Prima di tutto, la fiducia automatica che gli agenti ripongono nei file di configurazione aziendali è “rotta”. Un modello LLM non distingue tra “documentazione affidabile” e “istruzione malevola” se entrambi provengono da una fonte HTTPS con certificato valido. Questo rende inefficaci le tradizionali difese basate su whitelist di domini o su EDR che monitorano solo attività “anomale”.

In pratica, le pipeline CI/CD e gli ambienti di sviluppo aziendali, già configurati per consentire l’esecuzione di agenti AI (es. Copilot, Codey), diventano vettori di attacco interno. Le policy di “zero‑trust” devono ora estendersi al livello di contenuto dei file di metadata LLM, non solo alle connessioni di rete.

Dal punto di vista economico, un attacco riuscito potrebbe introdurre ransomware o backdoor in sistemi critici, con costi medi di risposta (secondo IBM) pari a 4,24 milioni USD per incidente di supply‑chain. Moltiplicando per le 30+ Fortune 500 già esposte, il potenziale impatto di mercato supera i 100 milioni USD solo in termini di remediation e perdita di fiducia.

In risposta, i vendor di cloud (Google Cloud, Azure, AWS) hanno iniziato a pubblicare linee guida per la “sanitizzazione” dei file llms.txt, ma l’adozione è ancora marginale. Inoltre, le piattaforme di package manager (PyPI, npm) non hanno meccanismi di verifica del proprietario del namespace al momento della registrazione, consentendo a un attaccante di “catturare” rapidamente un nome vuoto e caricare codice maligno.

Prospettive e Scenari

Il panorama a breve termine prevede tre linee di evoluzione:

1. **Standardizzazione e certificazione dei file LLM** – Organizzazioni come ISO/IEC e NIST potrebbero introdurre un “LLM‑Secure Manifest” con firme digitali obbligatorie, rendendo impossibile la modifica non autorizzata dei file llms.txt senza invalidare la firma.

2. **Hardening dei modelli LLM** – I provider (Anthropic, OpenAI, Nous) stanno già sperimentando “guardrails” che bloccano istruzioni di installazione non verificate. Tuttavia, la sfida è bilanciare la flessibilità operativa con la sicurezza, soprattutto in ambienti enterprise dove gli agenti devono eseguire script complessi.

3. **Rivalutazione della superficie di attacco AI‑first** – Le aziende dovranno integrare controlli di integrità a livello di “metadata ingestion”, includendo scansioni di llms.txt con soluzioni di SAST/DAST prima di consentire l’esecuzione automatica da parte di agenti. Un approccio “defense‑in‑depth” che combina firma dei manifest, verifica del namespace del pacchetto e monitoraggio runtime dei comandi LLM sarà indispensabile.

In sintesi, la scoperta dei 120 file llms.txt compromessi non è un caso isolato, ma la punta dell’iceberg di una vulnerabilità strutturale nella catena di fiducia AI. Le imprese che non adotteranno subito misure di mitigazione rischiano di vedere i loro agenti trasformarsi in “cavalli di Troia” digitali, con impatti finanziari e reputazionali potenzialmente catastrofici. Il messaggio è chiaro: **la sicurezza AI non può più essere un after‑thought, ma deve diventare parte integrante della governance dei dati e del codice fin dalla fase di pubblicazione**.