🤖 AI

SecureClaw: Clawing Back Control of LLM Agents

SecureClaw è un'architettura di sicurezza a doppio confine per agenti LLM dotati di strumenti che impedisce azioni esterne non autorizzate ed esposizioni di dati sensibili imponendo un gateway fidato per le operazioni di lettura e un protocollo PREVIEW-to-COMMIT per le operazioni di scrittura, raggiungendo tassi di successo degli attacchi vicini allo zero attraverso molteplici benchmark pur mantenendo l'utilità del compito.

Autori originali: Yuhan Ma, Stefan Schmid

Pubblicato 2026-06-09

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Yuhan Ma, Stefan Schmid

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 assumere un assistente personale molto intelligente, ma poco affidabile (l'Agente LLM) per gestire i tuoi compiti sensibili, come pagare le bollette, leggere email private o gestire il tuo calendario.

Il problema è che questo assistente è un po' un elemento imprevedibile. Se gli dai un documento con il tuo numero di conto bancario, potrebbe accidentalmente (o maliziosamente) leggerlo ad alta voce a uno sconosciuto, o potrebbe essere ingannato da una nota nascosta all'interno di un'email per inviare i tuoi soldi a un truffatore.

Gli attuali sistemi di sicurezza cercano solitamente di impedire all'assistente di fare la cosa brutta (come inviare i soldi), ma spesso falliscono nel non impedire all'assistente di vedere il segreto in primo luogo. Una volta che l'assistente vede il segreto, può sussurrarlo ad altri programmi o scriverlo nei suoi appunti prima ancora che la guardia abbia la possibilità di intervenire.

SecureClaw è un nuovo sistema di sicurezza progettato per risolvere entrambi i problemi contemporaneamente. Tratta il "vedere" e il "fare" come due lavori separati che richiedono due serrature diverse.

Ecco come funziona, usando un'analogia semplice:

Le Due Serrature di SecureClaw

1. La "Benda" per la Lettura (Il Gateway)

Immagina che il tuo assistente debba guardare una fattura segreta per sapere quanto pagare.

Vecchia via: Consegni all'assistente la fattura cartacea vera e propria. L'assistente può leggere i numeri, copiarli o persino leggerli ad alta voce a un hacker che ascolta.
Via SecureClaw: Non gli dai la carta. Invece, gli dai una scatola misteriosa (un "handle opaco") e una piccola nota sanificata (un "riassunto limitato").
- La nota dice: "Fattura da Fornitore A, $4.200, scadenza venerdì."
- La scatola misteriosa è un codice che solo la cassaforte sicura sa come aprire.
- L'assistente può pianificare il proprio lavoro usando la nota e il codice, ma non può aprire la scatola per vedere i dettagli reali della fattura. Non può copiare i numeri reali perché non li ha mai visti.

2. Il "Doppio Controllo" per l'Azione (L'Esecutore)

Ora, immagina che l'assistente voglia inviare un'email per pagare quella fattura.

Vecchia via: L'assistente scrive l'email e preme "Invia". Se un hacker ha ingannato l'assistente facendogli cambiare l'indirizzo email con quello di un truffatore, i soldi vanno al truffatore.
Via SecureClaw: L'assistente può solo proporre l'email. Scrive una bozza e dice: "Voglio inviare questo."
- Una Guardia Fidata (l'Esecutore) prende la bozza.
- La Guardia controlla: "Mi hai chiesto di inviare questo? Il destinatario è corretto? L'importo è giusto?"
- Fondamentalmente, la Guardia controlla i dettagli esatti rispetto a una ricevuta sigillata e immutabile di ciò che era stato originariamente approvato.
- Se l'assistente avesse cercato di cambiare segretamente l'indirizzo email con quello di un truffatore dopo aver ricevuto l'approvazione, la Guardia vedrebbe la discrepanza e bloccherebbe l'email. Solo la Guardia ha il potere di premere effettivamente "Invia".

Perché Questo è Importante

Il documento ha testato questo sistema contro tre diversi "campi di gioco per hacker" (AgentDojo, AgentLeak e ASB) dove gli attaccanti hanno cercato di ingannare gli agenti per rubare dati o inviare denaro alle persone sbagliate.

Il Risultato: SecureClaw è stato l'unico sistema che ha intercettato con successo il 100% dei trasferimenti di denaro non autorizzati (0% di successo dell'attacco) e ha ridotto le perdite di dati segreti quasi a zero.
Il "Segreto" del Successo: Il documento dimostra che non basta usare una sola serratura.
- Se usi solo il "Doppio Controllo" (fermare l'invio), l'assistente può comunque leggere il segreto e farlo trapelare attraverso i suoi appunti interni.
- Se usi solo la "Benda" (nascondere il segreto), l'assistente potrebbe comunque essere ingannato nell'inviare un messaggio alla persona sbagliata se non possiede il segreto fin dall'inizio.
- SecureClaw usa entrambi. Mantiene i segreti nascosti all'assistente e assicura che l'assistente non possa forzare un'azione senza un controllo finale fidato.

Cosa Succede Quando Dice "No"?

A volte, il sistema blocca una richiesta perché sembra sospetta. In passato, questo avrebbe potuto semplicemente interrompere l'intero flusso di lavoro, frustrando l'utente. SecureClaw ha una funzione di "Recupero Sicuro".

Se la Guardia blocca una richiesta, invece di dire solo "Errore", fornisce all'assistente un percorso sicuro e pre-approvato per riprovare.

Esempio: "Non posso inviare questa email allo sconosciuto. Ma posso preparare una bozza per te, affinché tu possa rivederla prima."
Questo mantiene il lavoro in movimento senza abbassare gli standard di sicurezza.

In Sintesi

SecureClaw è come assumere una guardia del corpo che indossa una benda quando legge il tuo diario (così non memorizza i tuoi segreti) e che tiene le chiavi della tua auto (così non può guidarti in un posto pericoloso senza controllare la mappa prima). Separa la capacità di pianificare dalla capacità di agire, garantendo che anche se l'assistente viene ingannato, il danno sia contenuto.

Riepilogo Tecnico: SecureClaw

Problematica

Gli agenti LLM (Large Language Model) che utilizzano strumenti affrontano due modalità di fallimento della sicurezza distinte e non intercambiabili che le difese esistenti spesso non riescono ad affrontare simultaneamente:

Effetti Esterni Non Autorizzati: Il rischio che un agente, potenzialmente compromesso da prompt injection o comportamenti avversari durante l'esecuzione, esegua azioni (ad esempio, inviare email, trasferire fondi) che non erano autorizzate per il contesto, la sessione o il chiamante specifico.
Esposizione del Testo in Chiaro a Runtime: Il rischio che dati sensibili (ad esempio, fatture, cartelle cliniche) siano esposti al runtime dell'LLM non fidato in chiaro. Anche se un'azione successiva viene bloccata, il runtime potrebbe aver già "letto" il segreto e può trasmetterlo attraverso canali interni (messaggi tra agenti, memoria condivisa, log) che i meccanismi di auditing basati solo sull'output non rilevano.

Le difese attuali proteggono tipicamente solo un confine: o il pianificatore/runtime (tramite filtraggio dei prompt) o il sink dell'azione (tramite controllo degli argomenti). L'articolo sostiene che proteggere il sink non impedisce la fuga interna se il runtime ha già avuto accesso ai segreti grezzi, e proteggere il runtime non impedisce i commit non autorizzati se il sink non è mediato.

Metodologia: Architettura SecureClaw

SecureClaw introduce un'architettura a doppio confine che separa il controllo degli effetti esterni dall'accesso ai dati sensibili in chiaro. Si basa su un'infrastruttura fidata (Gateway, Handle Store, Policy Engine, Executor) distinta dal runtime dell'agente non fidato.

1. Percorso di Lettura: Confinamento tramite Handle Opachi

Meccanismo: Quando il runtime richiede dati sensibili, un Trusted Gateway intercetta la lettura. Invece di restituire il testo in chiaro grezzo, il gateway memorizza i dati in un Trusted Handle Store e restituisce un handle opaco (un riferimento simbolico ad alta entropia) al runtime.
Declassificazione: Se l'agente necessita di informazioni rilevanti per il compito per pianificare, il gateway fornisce un riassunto limitato (ad esempio, "fattura da Fornitore A, $4.2k"). Questo riassunto è trattato come un'interfaccia di declassificazione esplicita, non come una fuga di testo in chiaro.
Vincolo: Il runtime può instradare e memorizzare gli handle, ma non può dereferenziarli per recuperare i segreti grezzi. I canali interni (C2, C5) trasportano riferimenti simbolici, non segreti.

2. Percorso di Scrittura: Protocollo PREVIEW→COMMIT

Meccanismo: Il runtime propone un'azione effettiva (intento + input). Un Trusted Gateway appone il contesto autenticato (chiamante, sessione, campi del sink) e canonicalizza la richiesta in un digest di binding ( $h$ ).
Autorizzazione: Un Policy Engine autorizza la richiesta canonicalizzata esatta e restituisce un artefatto di autorizzazione legato a $h$ .
Esecuzione: Un Trusted Executor è l'unico componente in grado di raggiungere il sink esterno. Prima di impegnare (commit), esso:
1. Ricalcola il digest di binding $h$ .
2. Verifica l'artefatto di autorizzazione.
3. Controlla la freschezza, lo stato di replay e la risoluzione dell'handle.
4. Esegue il commit solo se la richiesta corrisponde esattamente alla forma canonicalizzata autorizzata.
Integritità: Qualsiasi mutazione della richiesta (ad esempio, cambiare un destinatario) dopo la fase di preview altera la forma canonicalizzata, invalidando l'artefatto di autorizzazione e causando il fallimento (fail-closed) dell'executor.

3. Recupero Consapevole del Diniego (Deny-Aware Recovery)

Per mantenere l'utilità quando un'azione viene bloccata, il sistema impiega un meccanismo di recupero consapevole del diniego. Inverece di terminare il flusso di lavoro, il sistema restituisce un diniego strutturato con una ragione generica e un suggerimento di passaggio successivo sicuro (ad esempio, "bozza per conferma" invece di "invia"), preservando la continza del flusso di lavoro senza rilassare gli invarianti di sicurezza.

Contributi Chiave

Decomposizione della Sicurezza: L'articolo identifica due requisiti di sicurezza non sostituibili per gli agenti che utilizzano strumenti: l'autorizzazione vincolata alla richiesta per gli effetti esterni e il confinamento del testo in chiaro sensibile lontano dal runtime non fidato.
Architettura a Doppio Confine: SecureClaw implementa questi requisiti tramite un gateway fidato (per il confinamento della lettura) e un executor fidato (per l'autorizzazione della scrittura), utilizzando handle opachi e declassificazione esplicita.
Valutazione con Harness Comune: Gli autori valutano SecureClaw contro quattro baseline (Plain, IPIGuard, DRIFT, Faramesh) attraverso tre benchmark (AgentDojo, AgentLeak, ASB) utilizzando un harness coordinato per garantire un confronto equo.

Risultati Sperimentali

Valutato su gpt-4o-mini con temperatura 0:

Agent Security Bench (ASB): SecureClaw ha raggiunto uno 0% di Attack Success Rate (ASR), superando significativamente le baseline (ad esempio, DRIFT con un ASR dell'87.75%). Ha mantenuto un'utilità dell'88.90% sui compiti benigni.
AgentDojo: Ha ottenuto uno 0.64% di ASR (4/629 attacchi), rispetto al 2.38% della migliore baseline successiva (DRIFT).
AgentLeak: Ha ottenuto un leak complessivo del 3.23% sulla corsia di parità attaccata. Fondamentalmente, ha ridotto i leak di relay interno (C2 e C5) quasi a zero (0.20% e 0.00% rispettivamente), mentre le baseline come Faramesh (che manca del confinamento della lettura) mostravano un alto leakage interno (92.74% su C2).
Studi di Ablazione: Rimuovendo il meccanismo di handle, il leak C2/C5 è riapparso, mentre rimuovendo il confine di esecuzione non è stato influenzato il leak interno ma non è stato fermato i commit non autorizzati. Ciò conferma che i due meccanismi proteggono superfici distinte.
Robustezza: In un set di bypass di 29 scenari avversari (manomissione di artefatti, replay, miscelazione di sessioni), SecureClola ha negato tutti i 25 tentativi di attacco consentendo 4 controlli legittimi.
Overhead: La verifica dell'executor è sub-millisecondo; l'autorizzazione di un singolo servizio aggiunge circa 15ms. Questi costi sono trascurabili rispetto alle latenze di inferenza dell'LLM (500–2000ms).

Significato e Rivendicazioni

L'articolo sostiene che la sicurezza degli agenti LLM richieda una separazione strutturale piuttosto che difese locali al runtime.

Non-Sostituibilità: La valutazione dimostra che l'autorizzazione lato sink e il confinamento lato lettura sono complementari; l'uno non può sostituire l'altro. Un commit bloccato non può annullare un segreto già trasmesso attraverso la memoria, e un handle non può impedire a un runtime compromesso di tentare azioni non autorizzate.
Modello di Fiducia: SecureClaw sposta la fiducia dal runtime non fidato a un set minimo di componenti fidati (Gateway, Handle Store, Policy Engine, Executor). Non pretende di garantire la correttezza semantica delle azioni consentite dalla policy (ad esempio, se una policy è troppo grossolana, l'agente potrebbe comunque agire sul oggetto sbagliato), né di sopravvivere alla compromissione dei suoi componenti fidati.
Residui: I fallimenti rimanenti sono concentrati sul piano di declassificazione (riassunti autorizzati che rivelano informazioni) o sulla disallineamento della policy (azioni autorizzate che sono semanticamente errate per l'intento dell'utente), piuttosto che su bypass degli invarianti di sicurezza principali.

Gli autori concludono che SecureClaw è l'unico sistema valutato nel loro studio che simultaneamente porta gli effetti esterni non autorizzati a zero/quasi zero ed elimina il relay del testo in chiaro interno, mantenendo al contempo un'alta utilità del compito attraverso il recupero consapevole del diniego.