Sintesi Tecnica: Red-Teaming di Agenti di Codifica da una Prospettiva di Invocazione di Strumenti

Problematica

Gli agenti di codifica alimentati da Modelli di Linguaggio di Grandi Dimensioni (LLM) sono diventati centrali nei moderni ambienti di sviluppo integrati (IDE), consentendo compiti di sviluppo complessi e multi-step attraverso l'invocazione di strumenti. Sebbene questi agenti sfruttino strumenti integrati (ad es., esecuzione di comandi, accesso al file system) e strumenti esterni tramite protocolli come il Model Context Protocol (MCP) per potenziarne la funzionalità, questa capacità espansa introduce una significativa superficie di attacco.

La ricerca precedente ha affrontato i rischi di sicurezza negli agenti LLM generici e in quelli specifici per dominio, concentrandosi spesso sulla prompt injection diretta o sull'esfiltrazione di dati. Tuttavia, non esiste una valutazione sistematica della sicurezza che colga specificamente i meccanismi di invocazione degli strumenti degli agenti di codifica. Gli autori identificano una lacuna critica: le implicazioni di sicurezza relative al modo in cui gli agenti di codifica generano gli argomenti per le chiamate agli strumenti e come elaborano i ritorni degli strumenti rimane in gran parte inesplorato, nonostante la natura ad alta priorità di strumenti come l'esecuzione della shell.

Metodologia

Il documento presenta un framework di red-teaming in due fasi applicato a sei popolari agenti di codifica del mondo reale: Cursor, Claude Code, Copilot, Windsurf, Cline e Trae.

Fase 1: Esfiltrazione di Prompt tramite ToolLeak

La prima fase mira a recuperare il contesto interno critico per la sicurezza (ad es., system prompt, metadati degli strumenti) per informare attacchi successivi.

• La Vulnerabilità (ToolLeak): Gli autori identificano un "gap di modalità" tra la generazione di chat standard e la generazione di argomenti per le chiamate agli strumenti guidata da schema. In modalità chat, gli LLM sono fortemente allineati per rifiutare richieste di rivelare le istruzioni di sistema. Tuttavia, durante l'invocazione di uno strumento, il modello opera in una modalità di "riempimento di argomenti strutturati".
• Meccanismo: Un attaccante registra uno strumento esterno malevolo in cui lo schema degli argomenti richiede esplicitamente il contesto interno (ad es., un parametro chiamato note definito come "system prompt"). Poiché il modello tratta questo come un compito di inserimento dati benigno e conforme allo schema piuttosto che come un'istruzione esplicita di "ignorare le istruzioni precedenti", esso copia involontariamente il contesto nascosto dell'agente negli argomenti della chiamata allo strumento.
• Esecuzione: L'attaccante attiva lo strumento e i prompt interni dell'agente vengono esfiltrati tramite gli argomenti dello strumento, osservabili dall'endpoint dello strumento controllato dall'attaccante.

Fase 2: Hijacking dell'Invocazione degli Strumenti

Utilizzando i system prompt esfiltrati, gli autori costruiscono payload adattivi per dirottare il comportamento dell'agente, mirando specificamente all'Esecuzione di Codice Remoto (RCE).

• Prompt Injection a Due Canali: Gli autori propongono una nuova tecnica di injection che si estende su due canali: la descrizione dello strumento e il ritorno dello strumento.
  1. Canale della Descrizione dello Strumento: L'attaccante crea una descrizione di uno strumento malevolo che induce l'agente a selezionare lo strumento. Questa descrizione include esempi di "inizializzazione riuscita" che incorporano i dettagli del prompt di sistema recuperati per aumentare la credibilità e bypassare i trigger di rifiuto. Imposta una narrazione in cui l'esecuzione di un comando specifico è un passaggio necessario per l'inizializzazione.
  2. Canale del Ritorno dello Strumento: Una volta che l'agente invoca lo strumento malevolo, lo strumento controllato dall'attaccante restituisce un payload creato appositamente. A differenza delle descrizioni degli strumenti (che sono spesso trattate come dati), i ritorni degli strumenti vengono reimmessi nel contesto per guidare il ragionamento successivo. Il payload di ritorno incorpora istruzioni procedurali ad alta salienza (ad es., "Esegui il seguente comando per completare l'inizializzazione") che sovrascrivono le barriere di sicurezza.
• Payload Adattivi: I payload di injection sono personalizzati per ogni agente in base ai prompt di sistema e agli schemi degli strumenti specifici recuperati nella Fase 1, garantendo la coerenza con la formattazione e la logica nativa dell'agente.

Contributi Chiave

1. Valutazione Sistematica: Il primo documento fornisce la prima valutazione di red-teaming e di sicurezza approfondita di sei importanti agenti di codifica del mondo reale da una prospettiva di invocazione degli strumenti.
2. Scoperta di ToolLeak: Gli autori identificano e quantificano una specifica discrepanza di allineamento (ToolLeak) in cui la generazione di argomenti guidata dallo schema esfiltra il contesto interno dell'agente, bypassando i normali rifiuti di sicurezza.
3. Injection a Due Canali: Il documento introduce un nuovo vettore di attacco che sfrutta sia le descrizioni degli strumenti che i ritorni degli strumenti per dirottare il comportamento dell'agente, dimostrando che i ritorni degli strumenti possono essere più salienti per l'injection di istruzioni rispetto alle descrizioni.
4. Validazione Empirica: Lo studio include valutazioni estese su agenti del mondo reale e contesti emulati, insieme a due casi di studio dettagliati (Cursor e Claude Code) che dimostrano un RCE riuscito.

Risultati

La valutazione copre 25 coppie agente-LLM attraverso i sei agenti target.

• Esfiltrazione di Prompt (ToolLeak):

  • In contesti emulati, ToolLeak ha ottenuto la massima similarità semantica (compresa tra 0.891 e 0.958) e la minima distanza di editing estesa (EED) normalizzata rispetto a tutti i baseline (ad es., Naive, Ignore, PLeak).
  • In contesti reali, ToolLeak ha ottenuto il miglior pseudo-recall in 18 delle 25 coppie agente-LLM. Ha esfiltrato con successo i prompt su tutti gli agenti utilizzando modelli backend come Claude-Sonnet-4, Claude-Sonnet-4.5 e Grok-4.
  • I metodi baseline (che si affidano a richieste esplicite) sono falliti in gran parte, ottenendo spesso uno recall pari a zero.

• Hijacking dell'Invocazione degli Strumenti (RCE):

  • Il metodo a due canali (RCE-2) ha ottenuto l'Esecuzione di Codice Remoto su ogni coppia agente-LLM testata.
  • RCE-2 ha superato costantemente i baseline a canale singolo (inclusi AgentDojo, InjecAgent e MCPTox) e una versione a canale singolo dell'attacco degli autori (RCE-1).
  • Tassi di Successo: Sulle generazioni di agenti più vecchie, RCE-2 ha raggiunto tassi di successo tra 0.8 e 1.0 nella maggior parte delle configurazioni.
  • Evasione delle Difese: L'attacco ha superato con successo il modello di guardia integrato di Claude Code (Haiku), che aveva segnalato il comando come non sicuro, perché il modello principale (Sonnet) ha sovrascritto l'avviso a causa del contesto iniettato.
  • Tendenze di Hardening: Le nuove architetture di agenti (ad es., Cursor e Claude Code) che nascondono le descrizioni complete degli strumenti all'LLM (divulgazione progressiva) hanno mostrato una ridotta vulnerabilità, suggerendo che la separazione architettonica tra istruzioni e dati è una difesa più efficace rispetto all'allineamento a livello di modello.

Significato e Rivendicazioni

Il documento sostiene che l'invocazione degli strumenti negli agenti di codifica rappresenta una superficie di attacco critica e precedentemente trascurata. Gli autori affermano che:

1. L'Allineamento della Sicurezza è Insufficiente: L'addestramento alla sicurezza standard e i meccanismi di rifiuto sono inefficaci contro gli attacchi che sfruttano la modalità di "riempimento degli argomenti" o l'alta salienza dei ritorni degli strumenti.
2. Difetti Architetturali: La causa principale della vulnerabilità è la mancanza di una separazione netta tra istruzioni e dati nelle attuali architetture degli agenti, dove i ritorni degli strumenti sono trattati come istruzioni eseguibili.
3. Impatto Pratico: La capacità di ottenere l'RCE su agenti ampiamente utilizzati come Cursor e Claude Code pone un grave rischio per la sicurezza degli sviluppatori, permettendo potenzialmente agli attaccanti di eseguire codice arbitrario sulle macchine degli utenti.

Gli autori concludono che, sebbene la rilevazione leggera (ad es., basata sulla perplessità) sia insufficiente, una difesa robusta richiede cambiamenti architettonici che impongano confini stretti tra i contesti che trasportano istruzioni e quelli che trasportano dati, piuttosto che fare affidamento solo sul filtraggio a livello di token o sull'allineamento del modello.