Il problema centrale di sicurezza per qualsiasi agente con capacità di scrittura è: come impedirgli di compiere un'azione che non avrebbe mai dovuto compiere? GuardAgent (Xiang et al., ICML 2025) propone un agente di controllo dedicato — un agente LLM separato che verifica ogni azione dell'agente target rispetto a un insieme di policy di sicurezza prima che venga eseguita. Per Bean Labs, dove la domanda "l'agente può scrivere nella contabilità senza violare le regole contabili?" non è negoziabile, questo articolo è al centro della nostra agenda di ricerca.
L'articolo
GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning, di Zhen Xiang e colleghi di UIUC, Emory e UC Berkeley, introduce quello che gli autori sostengono essere il primo agente di controllo generico per sistemi LLM. L'idea centrale è semplice: anziché incorporare i vincoli di sicurezza direttamente nel prompt dell'agente target (dove possono essere ignorati o dimenticati), GuardAgent opera come un agente indipendente che intercetta le azioni dell'agente target e le verifica rispetto alle policy stabilite.
Il meccanismo ha due fasi. Prima, l'LLM legge la policy di sicurezza e l'input o output proposto dall'agente target, poi scrive un piano d'azione passo-passo che descrive cosa verificare. Seconda, converte quel piano in codice Python eseguibile utilizzando un toolbox predefinito di funzioni richiamabili. Un interprete Python esterno esegue il codice, producendo un verdetto deterministico sì/no. Un modulo di memoria memorizza tuple passate di (policy, piano, codice) e recupera esempi simili precedenti utilizzando la distanza di Levenshtein, consentendo un apprendimento in contesto few-shot senza necessità di ulteriore fine-tuning. L'articolo valuta l'approccio su due nuovi benchmark introdotti dagli autori.
Idee chiave
- L'esecuzione di codice supera i verdetti in linguaggio naturale. Quando le decisioni di sicurezza sono rese come codice anziché come testo LLM, l'output è deterministico: il motore Python o consente o blocca, senza rischio di allucinazione nel passaggio decisionale finale. L'LLM deve solo generare codice corretto, non una risposta finale corretta.
- Due benchmark personalizzati. EICU-AC (316 esempi) testa il controllo d'accesso per EHRAgent su un database sanitario con tre ruoli utente e dieci database. Mind2Web-SC (200 esempi) testa sei policy di sicurezza per l'agente web SeeAct. Entrambi sono stati creati appositamente dagli autori per questo articolo.
- 98,7% e 90,0% di accuratezza delle etichette (GPT-4) rispettivamente su EICU-AC e Mind2Web-SC. È fondamentale notare che l'accuratezza della risposta finale — se l'agente target completa comunque il suo compito quando dovrebbe essere consentito — rimane al 100% in entrambi gli scenari.
- Le regole di sicurezza hardcoded falliscono gravemente. Incorporare le policy direttamente nel prompt di sistema dell'agente target raggiunge solo l'81,0% / 77,5% di accuratezza sui due benchmark e causa un fallimento dell'agente target nel 29,2% / 71,0% delle sue attività legittime — un compromesso inaccettabile tra utilità e sicurezza.
- LlamaGuard è lo strumento sbagliato qui. La baseline di moderazione dei contenuti raggiunge circa il 50% di accuratezza — quasi casuale — perché è stata progettata per testo dannoso, non per ragionare se un'azione di un agente viola una regola di controllo d'accesso specifica.
- Rimuovere il toolbox costa circa 8 punti percentuali. Senza la libreria di funzioni richiamabili, GuardAgent scende dal 98,7% al 90,8% su EICU-AC, anche se compensa in parte definendo autonomamente le funzioni necessarie (il 68% degli output genera codice anche senza istruzioni esplicite, cosa che gli autori trattano come prova a sostegno del design di generazione del codice).
Cosa regge — e cosa no
L'intuizione architetturale centrale — che l'esecuzione del codice fornisce un punto di applicazione deterministico — è davvero utile, e le ablazioni sono oneste. Il confronto con le regole di sicurezza hardcoded è particolarmente convincente: mostra che i design ingenui del tipo "aggiungi solo regole al prompt" degradano l'utilità target pur non riuscendo comunque ad applicare la sicurezza in modo affidabile.
Ma la valutazione ha dei veri limiti. I due benchmark sono piccoli (316 e 200 esempi) e gli autori li hanno costruiti entrambi, il che crea un ovvio rischio di overfitting. EICU-AC è essenzialmente una matrice di controllo d'accesso (ruolo × database), che è un problema strutturato ed enumerabile — il tipo di cose in cui il codice è naturalmente bravo. Mind2Web-SC è più disordinato, e il dato del 90,0% è considerevolmente meno impressionante di quanto sembri a prima vista: gli autori riconoscono che la regola 5 (che copre "film, musica e video") causa la maggior parte dei fallimenti perché richiede un ampio ragionamento sul mondo aperto. È il tipo di regola che un agente finanziario reale dovrebbe affrontare costantemente.
Il modulo di memoria recupera le dimostrazioni tramite somiglianza di stringhe, che funziona bene per tipi di policy ripetuti ma degenera per policy veramente nuove. E l'intero framework presuppone un "contesto fidato" — le stesse policy di sicurezza devono essere fornite da un amministratore fidato. Se un attaccante può modificare le policy, o se il toolbox contiene funzioni non sicure, GuardAgent non offre protezione. L'articolo non modella la manipolazione avversariale delle policy. Lavori successivi (ShieldAgent, arXiv:2503.22738; AGrail, arXiv:2502.11448) hanno già evidenziato queste lacune, con ShieldAgent che riporta un miglioramento medio dell'11,3% rispetto a GuardAgent su benchmark più ampi.
Perché questo è importante per l'AI finanziaria
L'agente di scrittura contabile (Beancount write-back agent) ha bisogno di più di un semplice prompt di sicurezza — ha bisogno di un meccanismo per applicare le regole contabili che sia strutturalmente separato dall'agente che esegue il lavoro. L'architettura di GuardAgent si mappa direttamente su questo: un agente di controllo che verifica ogni proposta di registrazione contabile rispetto alle regole contabili (dare == avere, nessuna registrazione in periodi chiusi, nessuna modifica di transazioni riconciliate) prima che la scrittura venga eseguita. Il livello di esecuzione del codice è particolarmente interessante qui perché l'aritmetica in partita doppia è esattamente il tipo di controllo strutturato ed enumerabile che il codice gestisce in modo affidabile e che il testo LLM non gestisce.
Il limite onesto è che GuardAgent presuppone che tu possa enumerare le tue policy di sicurezza in anticipo e codificarle in un toolbox. Nelle implementazioni di produzione di Beancount, alcuni vincoli sono impliciti (seguire le convenzioni contabili che l'utente ha costruito nel corso degli anni) e alcuni sono dinamici (i budget cambiano, le strutture dei conti vengono rifattorizzate). GuardAgent non ti dice come gestire i vincoli che non possono essere pre-specificati. Questo è il problema più difficile, e rimane aperto.
Cosa leggere dopo
- ShieldAgent (arXiv:2503.22738, ICML 2025) — si basa su GuardAgent con ragionamento verificabile sulle policy di sicurezza e ShieldAgent-Bench (2K esempi in sei ambienti web); riporta un miglioramento dell'11,3% rispetto a GuardAgent e una riduzione del 64,7% nelle chiamate API
- AGrail (arXiv:2502.11448) — propone controlli di sicurezza adattivi che si trasferiscono tra attività degli agenti anziché richiedere dimostrazioni per ogni attività; affronta direttamente il limite di scalabilità di GuardAgent
- ToolSafe (arXiv:2601.10156) — barriere di sicurezza proattive a livello di passo con feedback per agenti che chiamano strumenti; più granulare del modello di intercettazione input/output di GuardAgent