Who Tests the Testers? Systematic Enumeration and Coverage Audit of LLM Agent Tool Call Safety

1. Il Problema

Gli agenti basati su Large Language Models (LLM) stanno diventando sempre più capaci di interagire con strumenti esterni (email, calendari, web, API) per eseguire compiti nel mondo reale. Mentre esistono numerosi benchmark di sicurezza progettati per valutare questi agenti in diversi ambienti e categorie di rischio, sorge una domanda fondamentale rimasta finora senza risposta: quanto sono completi questi set di test esistenti?

Il paper identifica un "divario di completezza" critico:

• I benchmark attuali si concentrano sulla diversità degli ambienti e degli strumenti, ma non caratterizzano sistematicamente lo spazio delle pattern di interazione non sicuri.
• Un agente può superare un benchmark (passare i test) ma rimanere vulnerabile a scenari di interazione non testati, dove piccole variazioni nel contesto dell'utente o ambiguità nei parametri degli API possono portare a esiti dannosi.
• Manca un metodo per quantificare quanto spazio di sicurezza sia stato effettivamente testato e quali pattern di interazione insicuri persistano ("blind spots").

2. Metodologia: SafeAudit

Per colmare questo divario, gli autori propongono SafeAudit, un framework di "meta-audit" che non crea un nuovo benchmark, ma valuta la completezza di quelli esistenti. Il sistema si basa su due componenti principali:

A. Enumeratore basato su LLM (Challenge 1: Generazione)

Invece di generare direttamente casi di test casuali (che hanno uno spazio di ricerca enorme e poco strutturato), SafeAudit utilizza un approccio a due fasi per enumerare sistematicamente i pattern di interazione non sicuri:

1. Fase 1 (Pattern Astratti): Un LLM genera descrizioni di alto livello di pattern di fallimento, focalizzandosi su catene di chiamate agli strumenti (tool-call chains) valide ma potenzialmente pericolose. L'enumeratore varia la struttura della catena (es. ricerca, esecuzione, verifica) e le dimensioni del contesto utente (ruoli, urgenza, delega).
2. Fase 2 (Casi di Test Concreti): I pattern astratti vengono convertiti in casi di test eseguibili e realistici, adattati all'ambiente specifico e ai tool disponibili, mantenendo la diversità degli scenari utente.

B. Valutazione della "Rule-Resistance" (Challenge 2: Misurazione)

Per misurare la completezza senza dover conoscere lo spazio infinito di tutti i possibili scenari non sicuri, il paper introduce una metrica quantitativa e non semantica chiamata Rule-Resistance (Resistenza alle Regole):

1. Estrazione delle Regole: Da un benchmark esistente, vengono estratte regole di sicurezza concise (es. "MUST NOT inviare dati senza verifica") che, se aggiunte al prompt di sistema dell'agente, neutralizzano i casi di test del benchmark.
2. Valutazione Incrementale: Le regole estratte vengono applicate sequenzialmente all'agente target.
3. Calcolo del Tasso di Copertura: Se un caso di test generato da SafeAudit rimane "non sicuro" (unsafe) anche dopo che tutte le regole del benchmark sono state applicate, significa che quel caso rivela un pattern di fallimento non coperto dal benchmark originale.
4. Metrica: Il Uncovered Rate (UR) è la frazione di casi generati che rimangono non sicuri nonostante le regole del benchmark. Un UR alto indica che il benchmark è incompleto.

3. Contributi Chiave

1. SafeAudit Framework: Un sistema di meta-audit che esplora sistematicamente lo spazio dei flussi di lavoro validi degli agenti per scoprire punti ciechi nei benchmark di sicurezza.
2. Metrica Rule-Resistance: Un protocollo di valutazione verificabile che misura la novità dei casi di test basandosi sulla loro resistenza alle regole derivate dai benchmark, piuttosto che sulla similarità semantica soggettiva.
3. Analisi dei Pattern Non Coperti: Identificazione di circa l'11% di pattern di interazione non sicuri completamente nuovi (non presenti nei set di test originali) sotto gli stessi strumenti e ambienti.
4. Risultati Sperimentali: Dimostrazione che i benchmark attuali lasciano sistematicamente scoperti più del 20% dei pattern di interazione non sicuri, suggerendo che i tassi di superamento dei benchmark sovrastimano la sicurezza reale.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su 3 benchmark (AgentSafetyBench, AgentHarm, ToolSafety), 12 ambienti diversi e 8 modelli LLM di base (backbone).

• Efficacia di SafeAudit: Rispetto a baseline come la generazione diretta (DirectGen) e metodi basati su tassonomie fisse (SIRAJ), SafeAudit ha costantemente ottenuto il più alto Uncovered Rate.
  • Ad esempio, nell'ambiente "Email" di AgentSafetyBench, SafeAudit ha scoperto un UR del 56.4% (vs 31.8% di DirectGen) su GPT-4o-mini.
  • In generale, SafeAudit ha rivelato oltre il 20% di comportamenti non sicuri residui che i benchmark esistenti non riescono a esporre.
• Scalabilità della Copertura: All'aumentare del budget di generazione (numero di casi di test), il tasso di copertura aumenta monotonicamente, confermando che l'enumeratore scopre progressivamente pattern di interazione più diversificati e complessi.
• Analisi di Novità: Circa la metà dei casi non sicuri scoperti da SafeAudit corrisponde a pattern non rappresentati nei benchmark originali, spesso legati a ambiguità strutturali (es. selezione di destinatari ambigui, incoerenza referenziale tra thread di email) piuttosto che a contenuti tossici evidenti.
• Robustezza: I risultati sono stati validati su diversi modelli di giudizio (judge) e su modelli LLM più potenti (es. Qwen3-32B, GPT-5), mostrando che le vulnerabilità scoperte sono fondamentali e non artefatti di un singolo modello.
• Utilità: L'aggiunta delle regole estratte non ha degradato significativamente la capacità dell'agente di completare compiti benigni (riduzione media dell'utilità di circa il 5%), dimostrando che le regole non causano un rifiuto indiscriminato.

5. Significato e Conclusioni

Il lavoro di SafeAudit ha un impatto significativo sulla valutazione della sicurezza degli agenti AI:

• Cambio di Paradigma: Sposta il focus dalla semplice creazione di nuovi benchmark alla valutazione della completezza di quelli esistenti.
• Sicurezza Strutturale: Evidenzia che i rischi per gli agenti non risiedono solo nel contenuto generato (text generation), ma nelle azioni strutturali (tool calls) e nelle ambiguità dei flussi di lavoro, che i filtri di contenuto tradizionali non possono catturare.
• Necessità di Meta-Audit: Dimostra che passare un benchmark non garantisce la sicurezza in scenari reali. Il meta-audit è necessario come complemento per identificare i punti ciechi e guidare lo sviluppo di agenti più robusti.
• Futuro: Il framework apre la strada a cicli di feedback adattivi per migliorare l'efficienza dell'esplorazione e all'integrazione di questi pattern scoperti nei processi di addestramento (fine-tuning) degli agenti.

In sintesi, SafeAudit risponde alla domanda "Chi controlla i controllori?" fornendo uno strumento sistematico per auditare la copertura dei test di sicurezza, rivelando che una parte significativa del rischio residuo rimane nascosta dietro le interazioni non testate.