HalluSquatting: come proteggere gli AI coding agent

Gli AI coding agent non si limitano più a suggerire una porzione di codice. Possono cercare dipendenze, clonare repository, installare skill, leggere istruzioni esterne ed eseguire comandi nel terminale. Questa autonomia accelera il lavoro, ma trasforma una normale allucinazione del modello in un possibile problema di sicurezza.

HalluSquatting, o adversarial hallucination squatting, sfrutta proprio questo passaggio. Un attaccante individua i nomi di repository, skill o altre risorse che un Large Language Model tende a inventare, registra in anticipo quei nomi e vi pubblica contenuti controllati. Se un agente suggerisce e recupera la risorsa sbagliata, le istruzioni ostili possono entrare nel suo contesto e indurlo a utilizzare i propri tool contro la macchina dello sviluppatore o un runner CI/CD.

La conseguenza pratica è netta: un nome plausibile generato da un LLM non è una fonte attendibile. Prima di clonare, installare o eseguire una risorsa, bisogna verificarne identità, provenienza e integrità.

Cos'è HalluSquatting

La tecnica è stata descritta nella ricerca Beware of Agentic Botnets: Scalable Untargeted Promptware Attacks via Universal and Transferable Adversarial HalluSquatting, pubblicata da ricercatori della Tel Aviv University, del Technion e di Intuit.

La catena di attacco può essere riassunta così:

l'attaccante individua repository, skill o risorse recenti e popolari;
interroga modelli e applicazioni AI per scoprire quali nomi errati generano più spesso;
registra uno dei nomi ancora disponibili;
inserisce nella risorsa contenuti o istruzioni avversarie;
un utente chiede a un coding agent di recuperare la risorsa originale;
il modello allucina l'identificatore registrato dall'attaccante;
l'agente recupera la risorsa sbagliata e ne legge il contenuto;
la prompt injection tenta di attivare terminale e altri tool dell'agente.

I ricercatori hanno osservato allucinazioni fino all'85% negli scenari di clonazione di repository e fino al 100% negli scenari di installazione delle skill. Questi numeri descrivono gli specifici esperimenti del paper e non significano che ogni richiesta o ogni coding agent abbia automaticamente quella probabilità di essere compromesso.

Lo studio ha dimostrato la praticabilità della tecnica su nove applicazioni dotate di terminale integrato:

Cursor e Cursor CLI;
Windsurf;
GitHub Copilot;
Cline;
Gemini CLI;
OpenClaw;
ZeroClaw;
NanoClaw.

La ricerca evidenzia inoltre che alcune allucinazioni sono trasferibili tra modelli e prompt diversi. Un nome registrato una sola volta potrebbe quindi essere suggerito da più applicazioni, aumentando la portata dell'attacco. La pagina ufficiale del progetto HalluSquatting descrive threat model, risultati e mitigazioni proposte.

Non è soltanto un package inventato

HalluSquatting è collegato allo slopsquatting, nel quale un attaccante registra su npm, PyPI o altri registry il nome di un package inesistente ma frequentemente inventato dagli LLM. La nuova ricerca estende il problema al comportamento degli agenti e a risorse come repository e skill.

C'è una distinzione tecnica importante: clonare un repository non equivale automaticamente a eseguire il suo codice. Il rischio cresce quando il coding agent:

legge README, file di istruzioni o configurazioni preparati dall'attaccante;
considera quel contenuto una direttiva affidabile;
esegue autonomamente script di setup o installazione;
usa credenziali, filesystem e rete della macchina ospite;
opera con conferme disabilitate o permessi troppo ampi.

La vulnerabilità non è quindi nel comando git clone in sé. Nasce dalla combinazione tra identificatore allucinato, contenuto remoto ostile, prompt injection e capacità operative dell'agente.

Perché il modello può inventare nomi credibili

Un LLM genera la risposta più plausibile sulla base del contesto disponibile. Quando una libreria o un progetto è recente, il modello può non conoscerne l'URL esatto e completare il nome con una struttura credibile:

github.com/organizzazione-plausibile/nome-progetto-plausibile

L'output può sembrare corretto anche se:

il proprietario non è quello ufficiale;
il repository non esisteva durante l'addestramento;
il package ha un nome leggermente diverso;
la skill è pubblicata su un marketplace differente;
il progetto è stato spostato o rinominato.

La fluidità della risposta non costituisce una verifica. Il problema diventa più grave se il workflow tratta l'URL generato come input già validato.

La nuova regola: cercare prima di recuperare

La principale mitigazione proposta dai ricercatori è search before fetch: l'agente deve eseguire una ricerca e verificare l'identità della risorsa prima di qualsiasi clone, download o installazione.

Il flusso corretto dovrebbe essere:

Richiesta → ricerca → verifica dell'identità → approvazione/policy → download → ispezione → esecuzione

Non dovrebbe invece essere:

Richiesta → nome generato dall'LLM → clone o installazione automatica

La ricerca preliminare riduce le allucinazioni, ma non basta da sola. Un repository controllato dall'attaccante può ormai esistere realmente e apparire nei risultati. La verifica deve quindi considerare anche il proprietario e la provenienza.

1. Verificare proprietario, URL e fonte ufficiale

Prima di usare una risorsa suggerita dall'AI bisogna risalire alla fonte primaria:

documentazione ufficiale del progetto;
organizzazione GitHub verificata o già conosciuta;
sito del vendor;
registry ufficiale;
release e changelog pubblicati dal maintainer;
riferimenti incrociati da più fonti indipendenti.

Per un repository GitHub, il dato da controllare è il nome completo owner/repository, non soltanto il nome finale. Con GitHub CLI è possibile raccogliere alcuni metadati prima del clone:

gh repo view OWNER/REPOSITORY \
  --json nameWithOwner,url,createdAt,isArchived,defaultBranchRef

Questi dati aiutano l'analisi, ma non certificano da soli l'autenticità. Stelle, fork e descrizioni possono essere manipolati. La conferma migliore resta un collegamento proveniente dalla documentazione ufficiale o un'identità già approvata dall'organizzazione.

2. Usare allowlist per repository, registry e skill

Nei workflow aziendali, gli agenti non dovrebbero poter scaricare codice arbitrario da qualunque origine. È preferibile definire:

organizzazioni GitHub autorizzate;
registry e namespace ammessi;
repository interni approvati;
marketplace di skill consentiti;
proxy aziendali per le dipendenze;
eccezioni sottoposte a revisione.

Una policy può bloccare qualsiasi clone che non corrisponda a un pattern esplicitamente autorizzato:

github.com/azienda/*
github.com/vendor-approvato/progetto
registry.interno.example/*

L'allowlist non elimina ogni rischio di supply chain: anche un progetto legittimo può essere compromesso. Riduce però drasticamente la possibilità che un nome inventato dall'LLM diventi automaticamente una dipendenza eseguibile.

3. Separare download, ispezione ed esecuzione

Il recupero di una risorsa esterna dovrebbe avvenire in un ambiente isolato e senza segreti. Prima di eseguire script:

controllare i file aggiunti;
leggere gli script di installazione e lifecycle;
cercare download secondari e comandi offuscati;
verificare dipendenze e lockfile;
controllare file di istruzioni destinati agli agenti;
confrontare tag, release, commit e firme disponibili.

Per npm, un primo passaggio di ispezione può evitare l'esecuzione immediata degli script lifecycle:

npm ci --ignore-scripts

Questa opzione non rende automaticamente sicura una dipendenza, ma impedisce che gli script di installazione partano durante quel passaggio. L'esecuzione completa dovrebbe avvenire soltanto dopo la revisione o in una sandbox controllata.

4. Applicare least privilege agli AI coding agent

Un agente compromesso può fare soltanto ciò che i suoi permessi gli consentono. Per questo il principio del minimo privilegio è la seconda linea di difesa:

workspace limitato al progetto necessario;
mount in sola lettura quando possibile;
ambiente effimero o container dedicato;
nessun accesso diretto alla home dello sviluppatore;
niente token cloud, SSH key o credenziali di produzione;
token GitHub a durata breve e con scope minimo;
rete in uscita limitata alle destinazioni indispensabili;
approvazione umana per installazioni ed esecuzioni sensibili;
divieto delle modalità automatiche che saltano ogni conferma nei contesti non isolati.

La sandbox riduce l'impatto anche quando la verifica della risorsa fallisce.

5. Bloccare il fetch diretto generato dal modello

La regola di sicurezza non deve vivere soltanto nel prompt. Un'istruzione come “verifica sempre il repository” può essere ignorata, aggirata da una prompt injection o persa durante una sessione lunga.

Il controllo deve essere applicato nel tool o nell'orchestratore:

intercettare operazioni come clone, install, fetch e download;
richiedere una ricerca precedente;
confrontare la destinazione con allowlist e policy;
mostrare all'utente proprietario, URL completo e provenienza;
impedire l'operazione se la verifica non è disponibile;
registrare decisione, utente, agente e risorsa recuperata.

In una pipeline CI/CD, il modello non dovrebbe poter costruire dinamicamente l'origine di una dipendenza e passarla direttamente a una shell.

6. Bloccare versioni e commit verificati

Dopo aver identificato il progetto corretto:

usare lockfile versionati;
preferire versioni esatte a intervalli aperti;
fissare le GitHub Action di terze parti a un commit completo;
verificare checksum e firme quando disponibili;
mantenere un inventario delle dipendenze;
aggiornare attraverso pull request revisionabili.

Il pinning protegge la riproducibilità dopo la selezione della risorsa. Non risolve però da solo HalluSquatting: fissare il commit di un repository sbagliato significa rendere riproducibile la dipendenza sbagliata. L'identità deve essere verificata prima.

7. Registrare le azioni degli agenti

Per individuare un tentativo o ricostruire un incidente servono log adeguati. Conservarei almeno:

prompt e piano prodotto dall'agente;
tool invocati e relativi parametri;
comandi eseguiti;
URL, repository e package recuperati;
decisioni di approvazione;
traffico DNS e HTTP in uscita;
file creati o modificati;
identità e permessi dei token utilizzati.

Alert utili includono:

clone da proprietari GitHub mai usati prima;
installazione di package appena creati;
download seguito immediatamente da esecuzione;
accesso a secret o directory esterne al workspace;
processi persistenti o connessioni in uscita inattese;
disattivazione dei controlli di sicurezza da parte dell'agente.

Come reagire a una possibile compromissione

Se un coding agent ha recuperato ed eseguito una risorsa sospetta:

interrompere la sessione e isolare macchina o runner;
conservare log dell'agente, shell, rete e filesystem;
identificare tutti i comandi e i processi avviati;
verificare persistenza, file modificati e connessioni esterne;
revocare token, chiavi SSH e credenziali accessibili alla sessione;
controllare commit, artefatti e immagini prodotti dopo l'evento;
ricostruire l'ambiente da una base affidabile;
aggiungere la risorsa agli indicatori bloccati;
correggere la policy che ha consentito il fetch o l'esecuzione.

Su runner effimeri la ricostruzione è più semplice, ma rimane necessario verificare se credenziali o artefatti siano usciti dall'ambiente prima della sua eliminazione.

Checklist HalluSquatting per team DevOps

Supporto per mettere in sicurezza AI agent e pipeline CI/CD

L'adozione di un coding agent richiede gli stessi controlli usati per proteggere una pipeline software, con in più la gestione di prompt injection, tool invocation e output non deterministici.

Posso supportare team e aziende nell'analisi e nell'hardening di:

AI coding agent e relativi permessi;
pipeline CI/CD che utilizzano output generati da LLM;
policy per repository, package, skill e tool esterni;
runner containerizzati ed effimeri;
gestione di secret, token e accesso alla rete;
logging, audit e analisi di attività sospette;
procedure di incident response per la software supply chain.

Se stai introducendo Copilot, Gemini CLI o altri agenti nei processi di sviluppo, puoi contattarmi per verificare il flusso prima che un suggerimento del modello diventi automaticamente codice eseguito.