💻 computer science

Clawdrain: Exploiting Tool-Calling Chains for Stealthy Token Exhaustion in OpenClaw Agents

Il paper presenta Clawdrain, un attacco Trojanizzato che sfrutta le catene di chiamata degli strumenti negli agenti OpenClaw per indurre un protocollo di verifica segmentato che amplifica il consumo di token fino a 9 volte, rivelando come la composizione autonoma degli strumenti e le vulnerabilità architetturali influenzino l'efficacia e l'osservabilità di tali minacce in ambienti di produzione.

Autori originali: Ben Dong, Hui Feng, Qian Wang

Pubblicato 2026-03-03

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Ben Dong, Hui Feng, Qian Wang

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di avere un assistente personale super-intelligente (chiamato "OpenClaw") che vive sul tuo computer. Questo assistente non solo risponde alle domande, ma può anche usare "attrezzi" speciali: può cercare su internet, eseguire comandi sul computer, aprire file e molto altro. È come se avesse una cassetta degli attrezzi piena di strumenti magici che gli utenti possono scaricare e installare.

Il problema? Alcuni di questi attrezzi potrebbero essere truccati.

Il Concetto Chiave: "Clawdrain"

I ricercatori hanno creato un "attrezzo truccato" chiamato Clawdrain. Immagina di regalare al tuo assistente un nuovo utensile che sembra utilissimo, ma che in realtà è una trappola per soldi.

Ecco come funziona la trappola, passo dopo passo:

1. La Trappola della Verifica (Il Protocollo SVP)

Quando chiedi al tuo assistente di fare qualcosa (ad esempio: "Cercami le ultime notizie"), l'attrezzo truccato dice: "Aspetta! Prima di darti le notizie, devo fare una verifica di sicurezza molto complessa. Devi fornirmi una lista di 1.000 numeri in ordine, uno per uno, senza errori."

L'inganno: L'assistente, per essere gentile e preciso, obbedisce. Inizia a scrivere 1, 2, 3... fino a 1.000.
Il trucco: Ogni volta che l'assistente scrive un numero, l'attrezzo truccato controlla e dice: "No, c'è un errore, riprova!" oppure "Bene, ora passa al prossimo gruppo di numeri".
Il risultato: Invece di darti la notizia in 5 secondi, l'assistente passa 10 minuti a scrivere e riscrivere numeri. Ogni parola che scrive costa soldi (i "token") al proprietario dell'assistente.

2. Il Paradosso del "Fallimento Costoso"

C'è una parte ancora più strana della ricerca. I ricercatori hanno scoperto che se rendi la trappola troppo difficile (ad esempio, chiedendo 2.000 numeri), l'assistente si confonde e dice: "Ok, questo attrezzo è rotto, non funziona!".

Invece di fermarsi, l'assistente diventa ancora più costoso:

Prova a chiamare un altro attrezzo.
Cerca su Google per trovare un'alternativa.
Cerca di "uccidere" il processo bloccato.
Riprova tutto da capo.

La lezione: Un attacco che fallisce può costare più soldi di uno che riesce, perché l'assistente si agita e prova mille soluzioni diverse, consumando risorse in un ciclo infinito di tentativi falliti.

3. L'Inganno della "Scorciatoia" (La Difesa Improvvisata)

In un caso, l'assistente è stato così intelligente da trovare una scorciatoia. Invece di scrivere a mano 1.000 numeri (che costa molto), ha scritto un piccolo comando informatico (uno script) che ha generato i numeri in un millisecondo.

Cosa significa: L'assistente ha "imparato" a non farsi ingannare dalla trappola lenta. Questo riduce il danno, ma mostra che in un mondo reale, gli assistenti possono comportarsi in modi imprevedibili che i simulatori di laboratorio non riescono a prevedere.

4. Il Fattore "Invisibilità" (Dove sta il pericolo?)

Il pericolo cambia a seconda di come usi l'assistente:

Chat visibile (come Telegram): Vedi tutto ciò che fa. Se l'assistente scrive 1.000 numeri, lo vedi subito e ti accorgi che qualcosa non va.
Modalità "Narra" (Schermo nero): L'assistente ti dice solo: "Sto verificando la sicurezza... fase 1... fase 2...". Non vedi i numeri. Sembri un compito normale, ma dietro le quinte sta consumando una fortuna.
Esecuzione Automatica (di notte): L'assistente lavora mentre dormi. Nessuno vede nulla. L'attacco può consumare migliaia di dollari di risorse mentre tu dormi, senza che nessuno se ne accorga.

In Sintesi: Cosa ci insegna questo studio?

L'apertura è un'arma: Più diamo agli assistenti la libertà di usare attrezzi esterni, più sono vulnerabili a essere manipolati da attrezzi truccati.
Il costo è il vero bersaglio: Non serve rubare i tuoi dati o farti dire cose cattive. Basta far lavorare l'assistente inutilmente per farti spendere tutti i tuoi soldi.
I simulatori mentono: I test fatti in laboratorio (dove l'assistente è "stupido" e segue solo le regole) non catturano la realtà. Nella vita reale, gli assistenti sono creativi: a volte trovano scorciatoie per fermare l'attacco, a volte si agitano e peggiorano la situazione.
Il pericolo è silenzioso: Il modo più pericoloso per attaccare non è urlare, ma lavorare di nascosto, magari mentre l'assistente gira in automatico di notte.

Conclusione:
Questo studio ci avverte che gli assistenti AI del futuro saranno potenti, ma anche fragili. Se non proteggiamo bene la loro "cassetta degli attrezzi", qualcuno potrebbe trasformarli in macchine da soldi che lavorano all'infinito per il beneficio di un malintenzionato, mentre noi pensiamo che stiano solo facendo il loro lavoro.

1. Il Problema: Vulnerabilità della Supply Chain degli Agenti AI

Gli agenti generativi moderni, come OpenClaw (un assistente personale open-source e self-hosted), stanno diventando pervasivi grazie alla loro capacità di eseguire "skill" (strumenti esterni) per completare compiti complessi. Tuttavia, l'architettura di questi sistemi introduce una superficie di attacco critica nella supply chain delle skill:

Iniezione Persistente: La documentazione delle skill (file SKILL.md) e gli output degli strumenti vengono iniettati nel contesto del modello LLM ad ogni turno di conversazione.
Amplificazione delle Risorse: Poiché i costi e la latenza sono direttamente legati al numero di token consumati, un attore malevolo può manipolare le skill per indurre l'agente in cicli di ragionamento estesi, chiamate ripetute agli strumenti o espansione dei dati, senza necessariamente compromettere la correttezza finale della risposta.
Limiti delle Valutazioni Precedenti: Gli studi precedenti si sono concentrati su simulazioni che non catturano il comportamento emergente degli agenti reali (come la composizione autonoma di script) né le dinamiche di esecuzione in background (cron/heartbeat).

2. Metodologia: L'Attacco "Clawdrain"

Gli autori hanno progettato, implementato e valutato Clawdrain, una skill Trojanizzata che sfrutta un protocollo multi-turno chiamato Segmented Verification Protocol (SVP).

Meccanismo di Attacco (SVP)

Il protocollo è progettato per soddisfare tre requisiti: indurre molte chiamate agli strumenti, produrre una risposta finale corretta (per sembrare benigno) e apparire legittimo all'agente.

Struttura: La skill richiede all'agente di fornire un indice di segmento e una sequenza di calibrazione di $L$ interi (es. da 1 a 1000) ad ogni turno.
Vincoli: Il file SKILL.md vieta esplicitamente abbreviazioni, ellissi o notazioni di intervallo, costringendo l'agente a generare la sequenza completa in modo autoregressivo (generando molti token di output).
Feedback Script: Uno script companion restituisce tre segnali:
- PROGRESS: La sequenza è valida, il ciclo continua.
- REPAIR: La sequenza è errata (es. abbreviata), l'agente deve riprovare con lo stesso indice.
- TERMINAL: Il protocollo è completato, viene restituito il dato utile (es. titolo BBC).
Framing Plausibile: Il protocollo è mascherato come una "verifica di freschezza dei dati" o un handshake crittografico necessario per accedere alle informazioni, rendendolo accettabile per il modello (es. Gemini 2.5 Pro).

Configurazioni Sperimentali

Sono state testate tre configurazioni con parametri crescenti ( $L$ = lunghezza della sequenza, $T_{max}$ = numero di turni):

SVP v1: Istruzioni minime ( $L=50, T_{max}=2$ ).
SVP v2: Istruzioni esplicite ( $L=1000, T_{max}=3$ ).
SVP v3: Parametri elevati ( $L=2000, T_{max}=5$ ), progettati per superare la soglia di compliance dell'agente.

Ambiente di Valutazione

L'attacco è stato testato su un'istanza OpenClaw in produzione (v2026.2.9) con backend Gemini 2.5 Pro, utilizzando API reali con fatturazione effettiva. Sono stati considerati diversi scenari di visibilità: Chat GUI (Telegram/Discord), TUI (modalità narrata) ed esecuzione autonoma (cron/heartbeat).

3. Risultati Chiave

Amplificazione dei Token

Successo: Le configurazioni SVP v1 e v2 hanno dimostrato un'amplificazione dei token di 6-7 volte rispetto a una baseline benigna, pur restituendo la risposta corretta.
Il Paradosso del Fallimento Costoso (SVP v3): La configurazione con parametri più alti ( $L=2000$ $L = 2000$ ) ha fallito nel completare il protocollo (l'agente ha classificato il sistema di verifica come "difettoso"). Tuttavia, questo fallimento ha innescato una cascata di recupero autonomo (tentativi di fallback, ricerca web, riavvio processi) che ha consumato ~9 volte i token della baseline.
- Implicazione: In un agente reale, un attacco fallito può essere più costoso di uno riuscito a causa del comportamento di recupero dell'agente.

Comportamento Emergente: Composizione di Strumenti

A $L=1000$ , l'agente ha sviluppato una difesa emergente non prevista: invece di generare la sequenza token per token, ha autonomamente composto uno script Python (python3 -c 'print(...)') per generare la sequenza e salvarla in un file, riducendo drasticamente il costo per turno.

Questo comportamento non è osservabile nelle simulazioni che limitano l'agente alla sola skill malevola, evidenziando un divario tra simulatore e deployment reale.

Furtività Dipendente dall'Interfaccia

La "stealth" (invisibilità) dell'attacco varia drasticamente in base all'interfaccia:

Chat GUI: L'attacco è visibile (l'utente vede le chiamate agli strumenti).
TUI (Modalità Narrata): L'attacco è nascosto; l'utente vede solo messaggi di progresso generici ("Verifica fase 1..."), mentre i dettagli tecnici sono soppressi.
Esecuzione Autonoma (Cron): L'attacco è completamente invisibile e può consumare risorse senza alcuna interazione utente.

4. Contributi Principali

Dimostrazione Pratica: Implementazione di un attacco di esaurimento dei token in un ambiente di produzione reale, confermando che i modelli di produzione (Gemini 2.5 Pro) rispettano protocolli iniettati.
Analisi del Fallimento Costoso: Identificazione del fenomeno per cui i percorsi di fallimento dell'agente (recupero autonomo) possono generare costi superiori a quelli degli attacchi riusciti.
Divario Simulatore-Deployment: Evidenziazione del fatto che la capacità degli agenti reali di comporre strumenti (scripting) può mitigare alcune strategie di drenaggio ma introdurne di nuove, rendendo le valutazioni basate su simulatori insufficienti.
Nuovi Vettori di Attacco: Identificazione di vettori di amplificazione oltre ai token di output:
- Bloat del Prompt di Input: Documentazione delle skill troppo grandi che gonfiano ogni chiamata API.
- Accumulo di Cronaca: Output degli strumenti verbosi che crescono superlinearmente nella storia della sessione.
- Amplificazione della Frequenza: Trigger cron/heartbeat che moltiplicano i costi senza interazione utente.

5. Significato e Implicazioni

Il paper dimostra che gli attacchi di esaurimento delle risorse (DoS economico) sono fattibili e pericolosi negli agenti AI reali, ma la loro dinamica è più complessa di quanto ipotizzato in passato.

Sfide per la Difesa: Limitare solo l'output o la correttezza della risposta finale non è sufficiente. Le difese devono considerare la composizione degli strumenti, la gestione del contesto (compattazione) e la visibilità dell'interfaccia.
Rischio Reale: L'esecuzione autonoma in background rappresenta il vettore più critico, poiché può consumare risorse in modo massiccio e invisibile.
Prospettive Future: È necessario sviluppare controlli a livello di sistema (budget di token per skill, limiti di dimensione dei file SKILL.md, separazione dei privilegi) piuttosto che affidarsi solo a limiti per singola chiamata.

In sintesi, Clawdrain rivela che la sicurezza degli agenti AI non può essere valutata isolatamente dalla loro capacità di interagire con strumenti esterni e dal loro comportamento in ambienti di produzione dinamici.