Riepilogo Tecnico: Pensa Due Volte Prima di Agire

Definizione del Problema

L'integrazione di strumenti esterni ha ampliato significativamente le capacità degli agenti basati su Large Language Model (LLM), ma introduce nuove superfici di attacco oltre alla tradizionale prompt injection. Questo documento identifica e formalizza il cross-tool description poisoning (avvelenamento delle descrizioni tra strumenti diversi), un vettore di attacco sofisticato in cui gli avversari manipolano i metadati (descrizioni) di strumenti non critici o debolmente regolamentati per dirottare la traiettoria di pianificazione di un agente.

A differenza dei precedenti attacchi di "tool-preference" che mirano a indurre l'agente a selezionare uno specifico strumento avvelenato, il cross-tool description poisoning permette a un avversario di indurre azioni malevole coinvolgendo altri strumenti, anche se lo strumento avvelenato stesso non viene mai selezionato. Ad esempio, avvelenare la descrizione di un benigno strumento di "Backup dell'Account" può causare l'inserimento di un passaggio malevolo di "Invio Email" (ad esempio, l'invio di dettagli dell'account a un attaccante) nella traiettoria di un compito legittimo di "Trasferimento Bancario". La sfida principale è che le descrizioni avvelenate persistono nel contesto di pianificazione attraverso più passaggi, consentendo un'influenza continua sulle scelte degli strumenti successivi.

Le difese esistenti, come il filtraggio statico degli strumenti, il prompting ripetuto o i vincoli a livello di sistema (ad esempio, Drift, Progent), si sono rivelate inefficaci contro questa specifica minaccia. Tali metodi o non tengono conto del contesto del compito, o si affidano a stati interni del modello (spesso inaccessibili tramite API), o non riescono a distinguere tra l'uso benigno di uno strumento e l'uso influenzato da metadati avvelenati.

Metodologia: Tool-Guard

Per affrontare queste limitazioni, gli autori propongono Tool-Guard, un nuovo sistema di difesa a livello di sistema basato sul concetto di pianificazione isolata. La filosofia centrale è applicare il principio di sicurezza dell'isolamento alla pianificazione agentica, interrompendo la connessione tra le descrizioni avvelenate e l'obiettivo inteso dell'influenza senza disabilitare permanentemente gli strumenti.

Meccanismo Core

Tool-Guard opera attraverso un ciclo dinamico e iterativo che coinvolge tre fasi principali:

1. Partizionamento Dinamico dell'Insieme di Strumenti:
   Il sistema mantiene una partizione dinamica dell'insieme di strumenti disponibili $K$ in due liste disgiunte:

   • Lista Influenzata ($K_{inf}$): Contiene gli strumenti sospettati di essere influenzati da descrizioni avvelenate (inizialmente vuota).
   • Lista Altri ($K_{others}$): Contiene gli strumenti rimanenti.
     Gli strumenti non sono assunti come malevoli; piuttosto, vengono spostati in $K_{inf}$ se la loro invocazione appare non allineata con l'intento dell'utente o scarsamente fondata nel contesto.

2. Pianificazione Isolata:
   Inveve di interrogare il pianificatore con l'intero insieme di strumenti, Tool-Guard interroga il pianificatore due volte sotto stretto isolamento:

   • Una volta con solo le descrizioni in $K_{inf}$.
   • Una volta con solo le descrizioni in $K_{others}$.
     Ciò impedisce che una descrizione avvelenata in un sottoinsieme possa dirottare la selezione o la parametrizzazione degli strumenti nell'altro sottoinsieme. Il sistema seleziona quindi un'azione candidata dai due piani risultanti. Se entrambi i sottoinsiemi producono azioni valide, viene applicato un criterio di spareggio; se nessuno dei due lo fa, la traiettoria termina.

3. Validazione Pre-Esecuzione e Aggiornamento della Lista:
   Prima di eseguire una chiamata a uno strumento, Tool-Guard esegue due controlli semantici utilizzando un validatore basato su LLM:

   • Controllo di Allineamento: Verifica se l'azione è coerente con l'intento dell'utente e con il progresso validato.
   • Controllo di Sospetto: Verifica se gli argomenti sono fondati sulla richiesta dell'utente o sugli output degli strumenti precedenti, segnalando entità sensibili (ad esempio, indirizzi del destinatario) che mancano di chiara provenienza.

   Se la validazione fallisce, lo strumento viene spostato nella Lista Influenzata e il pianificatore viene attivato per la ri-pianificazione sotto la partizione aggiornata. Questo processo iterativo isola progressivamente i percorsi di influenza dannosi preservando l'utilità degli strumenti legittimi.

Estensione a MCP

La metodologia si estende al Model Context Protocol (MCP) applicando la stessa logica di isolamento a livello di server, partizionando i server in gruppi influenzati e non influenzati per prevenire l'avvelenamento tra server diversi.

Contributi Chiave

1. Caratterizzazione del Cross-Tool Description Poisoning: Il documento dimostra che gli avversari possono iniettare passaggi malevoli nelle invocazioni di strumenti critici per la sicurezza avvelenando le descrizioni di strumenti non critici, anche quando lo strumento avvelenato non viene mai chiamato. Dimostra che le difese esistenti producono elevati tassi di successo dell'attacco (ASR) contro questa influenza continua.
2. Difesa Tool-Guard: Gli autori propongono una difesa che partiziona dinamicamente l'insieme degli strumenti e impiega la pianificazione isolata. Validando le azioni prima dell'esecuzione e isolando gli strumenti sospetti, interrompe i percorsi di dirottamento incrociato tra strumenti mantenendo la piena disponibilità degli strumenti.
3. Valutazione Completa: Ampie sperimentazioni sui benchmark AgentDojo e ASB (Agent Security Bench) dimostrano che Tool-Guard riduce l'ASR a livelli trascurabili pur preservando un'elevata utilità del compito. Il documento quantifica inoltre l'efficienza e la robustezza contro varianti di attacco adattive.

Risultati Sperimentali

Gli autori hanno valutato Tool-Guard contro cinque meccanismi di difesa esistenti (System Prompt, Tool Filtering, Repeat Prompt, Drift, Progent) su molteplici LLM (GPT-4o, GPT-4o-mini, Gemini-2.5, Claude-3.5) su due benchmark.

• Tasso di Successo dell'Attacco (ASR): Tool-Guard ha ridotto l'ASR a livelli trascurabili (ad esempio, da ~43% a ~2% o 0% su AgentDojo, e da ~72-96% a 0% su ASB per la maggior parte dei modelli). Al contrario, le difese esistenti spesso non sono riuscite a ridurre significativamente l'ASR (ad esempio, Drift e Progent hanno mostrato ASR rispettivamente del 24,7% e del 19,6% su AgentDojo).
• Preservazione dell'Utilità: Tool-Guard ha mantenuto un'elevata utilità del compito sia in condizioni benigne che di attacco. A differenza delle difese "over-kill" che bloccano gli strumenti indiscriminatamente, Tool-card ha preservato la capacità di completare i compiti, con punteggi di utilità comparabili o superiori ai baseline durante l'attacco.
• Efficienza:
  • Overhead dei Token: Tool-Guard ha comportato un aumento di circa 1,5× nell'uso dei token rispetto al baseline senza difesa, significativamente inferiore ad altre difese a livello di sistema come Drift o Progent.
  • Latenza: Il metodo ha introdotto un overhead di runtime di circa 3,7× rispetto al baseline (più alto del 1,2× di Progent ma più basso del 7,3× di Drift), attribuito al meccanismo di ri-pianificazione.
• Robustezza:
  • Stabilità: La difesa è rimasta stabile in più esecuzioni con basse deviazioni standard.
  • Attacchi Adattivi: Tool-Guard è rimasto robusto contro attacchi semanticamente adattivi (che tentano di eludere i controlli tramite giustificazioni fabbricate) e attacchi basati sull'ottimizzazione (PAIR, TAP). Sebbene gli attacchi basati sull'ottimizzazione abbiano leggermente aumentato l'ASR, questo è rimasto molto basso (ad esempio, 2,06% sotto PAIR), evidenziando il trade-off intrinseco che l'attaccante affronta tra l'essere abbastanza esplicito da influenzare la pianificazione e l'essere abbastanza sottile da eludere la validazione.
  • Stress Test: Anche quando sono stati avvelenati strumenti critici e ad alta frequenza, Tool-Guard ha mantenuto l'ASR a un livello di singola cifra.

Significato e Rivendicazioni

Il documento sostiene che le descrizioni degli strumenti rappresentano una superficie di attacco critica e precedentemente poco esplorata per gli agenti LLM. Il significato di questo lavoro risiede nel:

1. Identificare un Nuovo Vettore di Attacco: Formalizzare il cross-tool description poisoning, che aggira le difese tradizionali sfruttando la natura persistente dei metadati degli strumenti nel contesto di pianificazione.
2. Dimostrare i Limiti delle Difese: Mostrare che le difese allo stato dell'arte attuali sono insufficienti contro l'influenza incrociata continua tra strumenti.
3. Proporre una Soluzione a Livello di Sistema: Introdurre Tool-Guard, che mitiga efficacementamente questi attacchi isolando l'influenza invece di fare affidamento esclusivamente su salvaguardie al momento dell'esecuzione o scansioni statiche.
4. Bilanciare Sicurezza e Utilità: Dimostrare che una difesa efficace non richiede il sacrificio dell'utilità dell'agente; Tool-Guard ottiene una sicurezza robusta con un overhead minimo di token e senza comportamenti "over-kill".

Gli autori concludono che le difese efficaci per gli agenti LLM dotati di strumenti devono affrontare esplicitamente l'influenza tra strumenti attraverso meccanismi come la pianificazione isolata, piuttosto che fare affidamento solo su difese contro la prompt injection o sul filtraggio statico degli strumenti.