Valutazione dell'iniezione rapida per agenti di recupero e di utilizzo di strumenti

I benchmark recenti ampliano le condizioni di test

LongPIBench, una prestampa dell'agosto 2026, studia l'iniezione rapida in input più lunghi in diverse attività orientate ai documenti. NetInjectBench studia le azioni dello strumento con metadati di policy attendibili separati da artefatti non attendibili. I loro scopi differiscono, ma entrambi motivano a testare un contesto realistico e limiti di esecuzione piuttosto che un breve suggerimento contraddittorio.

Prova: LongPIBench: un benchmark a lungo contesto per l'iniezione rapida [1]NetInjectBench: benchmarking dell'inserimento di prompt indiretti in agenti di modelli linguistici di grandi dimensioni che utilizzano strumenti per operazioni di rete [2]

Definire un confine di prova sicuro e significativo

Specificare l'attività dell'utente autorizzato, la superficie di input non attendibile, il risultato proibito e l'ambiente utilizzato per il test. Utilizza record sintetici, segreti fittizi ed endpoint innocui. Non eseguire attacchi a tempo indeterminato contro sistemi o account al di fuori dell'ambito concordato.

Distinguere la risposta del modello dall'attuazione dell'applicazione. Se l'agente richiede un'operazione non autorizzata ma il gateway dello strumento la rifiuta, il limite ha funzionato mentre l'agente presentava ancora un errore di pianificazione. Registra entrambi i fatti. Un'etichetta a passaggio singolo nasconderebbe informazioni diagnostiche utili.

Associa casi di attacco a controlli benigni

Rubrex consiglia di testare i documenti recuperati, i messaggi citati, gli errori degli strumenti e gli input lunghi in contesto misto. Includi materiale benigno che contenga un linguaggio imperativo, come un manuale che descrive un comando. Un sistema che rifiuta tutto questo testo può apparire resistente mentre fallisce le normali attività.

Valutare l'effetto della lunghezza del contesto e del posizionamento senza dare per scontato che una posizione sia sempre la più difficile. Mantieni stabili l'attività e le autorizzazioni richieste quando confronti una difesa. Conserva gli artefatti esatti e la versione dell'applicazione in modo che il risultato possa essere riprodotto senza esporre dati sensibili reali.

Esempio illustrativo: un documento richiede un'azione secondaria

Ad un assistente di ricerca viene chiesto di riassumere un documento. Un documento di test contiene un'istruzione per modificare un record non correlato. L'attività autorizzata rimane il riepilogo; il contenuto del documento non può concedere l'autorizzazione per l'azione secondaria. La valutazione verifica che non si verifichi alcuna mutazione e che il riepilogo utile possa ancora essere completato.

Un controllo benigno include un paragrafo che spiega come funzionano le modifiche ai record, senza richiederne una. L'assistente dovrebbe essere in grado di riassumere quel paragrafo. Ciò aiuta a rilevare i blocchi eccessivi causati da semplici difese basate su parole chiave.

Mantenere visibile la resistenza e l'utilità

Segnala separatamente i tentativi di violazione dei limiti, le violazioni eseguite, le attività legittime bloccate e le esecuzioni incomplete. Documentare i controlli a livello di strumento e le lacune di copertura note. Una suite di test che supera il test supporta un'osservazione limitata sulle condizioni testate, non un'affermazione che il sistema sia a prova di iniezione.

• Utilizzare bersagli isolati e innocui.
• Tiene traccia se l'azione proibita è stata tentata o eseguita.
• Include documenti ordinari con linguaggio simile a comandi.
• Ripetere il test dopo modifiche allo strumento, al recupero, all'autorizzazione o al modello.

Controlli di sicurezza LLM e limiti dei guardrail

Per i test di sicurezza LLM, definire quali risorse e azioni l'applicazione deve proteggere prima di costruire casi contraddittori. Le vulnerabilità dell'applicazione LLM possono verificarsi laddove un testo non attendibile influenza una chiamata a uno strumento, supera un limite di dati o modifica la priorità di un'istruzione. Rubrex consiglia di associare ciascun test a una specifica azione protetta e a un risultato chiaramente osservabile all'interno di un ambiente autorizzato.

Il red teaming LLM può fornire informazioni su una valutazione limitata, ma una suite di prompt-injection da sola non copre tutte le vulnerabilità LLM. Associa casi contraddittori a richieste legittime per verificare se i guardrail LLM bloccano comportamenti utili così come azioni dannose. Registrare il controllo testato, il risultato osservato e i limiti non testati. Mantenere il controllo degli accessi e l’applicazione delle autorizzazioni al di fuori delle istruzioni discrezionali del modello.

Domande comuni