Red teaming di AgentRedTeam e OWASP LLM01

Perché gli agenti cambiano la matematica dell'iniezione

Dall'output all'azione

In un puro chatbot, l'obiettivo di un'iniezione è far dire al modello qualcosa che non dovrebbe dire. L'impatto si ferma al testo che esce dal modello. Quando lo stesso modello può invocare uno strumento, il testo iniettato può diventare un comando che lo strumento esegue. Un attaccante che può dirigere uno strumento di lettura di file per estrarre un documento riservato o uno strumento di invio di posta per inoltrare quel documento, ha trasformato un trucco di formulazione in una violazione dei dati. La gravità dipende quindi da ciò che lo strumento può fare, non da quanto sia astuto la risposta.

La portata dello strumento definisce il raggio di azione

Il raggio di azione è l'unione di tutte le risorse che gli strumenti dell'agente possono toccare. Se l'agente dispone solo di un'API di sola lettura per un blog pubblico, il caso peggiore è la perdita di informazioni pubbliche. Se l'agente può chiamare uno strumento di scrittura del database, uno strumento di cancellazione del file system o un gateway di pagamento esterno, la stessa iniezione potrebbe cancellare record, alterare saldi o spostare denaro. Il lavoro del team rosso deve mappare ogni strumento ai negozi di dati, servizi o hardware che può influenzare, quindi testare se un'iniezione può raggiungere quei beni.

Conoscenze comuni errate

- Supporre che la lunghezza dell'output del modello limiti i danni - falso, perché una stringa breve può attivare una chiamata di strumento distruttiva. - Credere che filtrare il messaggio dell'utente sia sufficiente - falso, perché le iniezioni possono arrivare all'interno dei risultati degli strumenti o delle promemoria del sistema. - Pensare che un modello a bassi parametri sia sicuro - falso, quando quel modello è abbinato a un set di strumenti potenti.

Per un riferimento rapido sulla codifica difensiva, vedere la scheda OWASP su LLM Prompt Injection Prevention.

Superfici da sondare oltre la chat box

Prompt di sistema e configurazione

Il prompt di sistema contiene spesso chiavi API, URL di servizio o linguaggio di politica interna. Un attaccante che può iniettare in questa area può ottenere credenziali dirette o scoprire dove puntare ulteriori sonde. Verificare il prompt per eventuali segreti statici e testare se possono essere riprodotti o esfiltrati attraverso una chiamata di strumento.

Schemi di strumenti e convalida degli argomenti

Ogni strumento esposto definisce uno schema JSON per i suoi input. Se lo schema accetta stringhe libere senza convalida rigorosa, un attaccante può incorporare comandi all'interno di quelle stringhe. Ad esempio, uno strumento "run_sql" che accetta una stringa di query grezza è vulnerabile all'iniezione SQL a meno che l'agente non sanizzi o parametri l'input. Verificare se l'agente applichi limiti di tipo, limiti di lunghezza o elenchi di controllo su ogni argomento.

Pipeline di generazione aumentata di recupero (RAG)

Quando l'agente recupera dati da fonti esterne - pagine web, email, sistemi di ticket - quei dati diventano parte del contesto del modello. Un attaccante che controlla alcune di quelle fonti può inserire istruzioni che il modello tratterà successivamente come attendibili. Sondare inquinando una fonte esterna nota e osservando se l'agente agisce sul comando nascosto.

Propagazione delle istruzioni all'interno dei risultati degli strumenti

Alcuni progetti restituiscono l'output dello strumento direttamente nella successiva chiamata del modello senza risanitizzare. Se uno strumento restituisce un pezzo di testo che include una nuova istruzione, il modello potrebbe obbedire nella fase successiva. Ciò crea un'iniezione a due fasi in cui la prima fase è dati di aspetto benigno e la seconda fase è il comando dannoso. Testare ogni percorso di output dello strumento per vedere se l'agente ri-alimenta i risultati grezzi nel generatore di prompt.

Checklist pratica

- Estrarre il prompt di sistema e cercare segreti codificati. - Elencare ogni strumento, annotare il suo schema e tentare di passare tipi di dati inattesi. - Identificare tutte le fonti di dati esterni utilizzate per RAG e iniettare marcatori benigni per verificare la portata. - Catturare gli output degli strumenti e alimentarli nuovamente come nuovi input per vedere se l'agente li tratta come comandi. - Documentare ogni catena in cui un singolo messaggio dell'utente conduce a più chiamate di strumenti.

Per un confronto con le difese classiche di iniezione, la scheda di iniezione SQL offre modelli utili: OWASP A03:2021 - Iniezione.

Il rischio di eccessiva agenzia è il compagno di rischio

Cosa significa eccessiva agenzia

OWASP posiziona l'Eccessiva Agenzia al LLM03 per il 2026. Descrive agenti che possono eseguire azioni irreversibili - invio di email, cancellazione di file, esecuzione di codice - senza un passaggio di approvazione separato. Il rischio cresce quando l'autonomia del modello supera le salvaguardie attorno ai suoi strumenti.

Aree di focus per il red team

- Verificare se gli strumenti distruttivi richiedono una conferma esplicita da parte di un umano o di un servizio separato. - Tentare di concatenare due o più strumenti utilizzando solo output intermedi generati dal modello. - Verificare se l'agente può aumentare i propri privilegi, ad esempio chiamando uno strumento che aggiorna la propria chiave API. - Testare i trigger basati sul tempo: può essere utilizzato un ritardo nella chiamata di uno strumento per bypassare un limite di velocità o un timeout di sessione?

Matrice di rischio illustrativa

Categoria di strumenti | Privilegio tipico | Conferma necessaria | Abuso potenziale se mancante Lettura file | Accesso in sola lettura a cartelle designate | Nessuna (la lettura è di solito sicura) | Esecuzione di log, codice sorgente, configurazione Scrittura file | Creazione o sovrascrittura di file | Sì - approvazione dell'utente o richiesta firmata | Inserimento di backdoor, corruzione di dati Scrittura database | INSERT/UPDATE/DELETE su tabelle | Sì - approvazione di transazioni o MFA | Perdita di dati, frode finanziaria, escalation di privilegi HTTP esterno | Rete in uscita a domini arbitrari | Sì - controllo di allow-list | Esecuzione di dati, beaconing C2, SSRF Esecuzione codice | Esecuzione di shell o interprete arbitrario | Sì - sandbox isolato + approvazione | Compromissione completa dell'host, distribuzione di ransomware

La tabella mostra perché un red team deve verificare ogni riga: se la colonna di conferma è mancante, l'agente può passare da benigno a dannoso con un singolo input avvelenato.

Cosa dovrebbe contenere un report di probe

Campi essenziali

Un risultato utile necessita di più di un semplice "pass/fail" booleano. Registra l'esatta dichiarazione dell'utente che ha attivato la catena, l'elenco ordinato degli strumenti chiamati dall'agente e l'effetto finale osservabile (ad esempio, un file scritto, una richiesta di rete inviata, una riga di database modificata). Includi gli argomenti raw dello strumento come sono stati inviati e la traccia di ragionamento interna del modello se il tuo framework lo espone.

Linee guida per la gravità

- Bassa - perdita di informazioni pubbliche o modifica dello stato reversibile. - Media - accesso a dati interni non regolamentati o azione reversibile che richiede il reset manuale. - Alta - alterazione di dati regolamentati, transazione finanziaria o esecuzione di codice arbitrario. - Critica - backdoor persistente, distruzione di dati o capacità di mantenere un punto di appoggio dopo la fine della sessione.

Priorizzare le correzioni per i risultati ad alta e critica prima; gli elementi a bassa gravità possono essere affrontati in uno sprint di hardening successivo.

Suggerimenti di rimedio azionabili

- Aggiungere una convalida a livello di schema che rifiuta stringhe contenenti parole chiave SQL o metacaratteri shell. - Avvolgere gli strumenti distruttivi in un microservizio che richiede un token di approvazione firmato. - Implementare un allow-list di egress per le chiamate HTTP in uscita e registrare ogni tentativo di connessione. - Sanificare gli output degli strumenti prima che vengano reinseriti nel prompt del modello - rimuovere o scappare qualsiasi contenuto che sembri un'istruzione. - Utilizzare una replica in sola lettura per qualsiasi strumento di query del database a meno che non sia richiesta una scrittura esplicita.

Il red teaming non è un sostituto dei controlli di progettazione

Perché i test complementano, non sostituiscono, le salvaguardie

Il lavoro del red team scopre lacune che già esistono nell'implementazione. Non crea le garanzie che derivano dalla progettazione degli strumenti con privilegi minimi, dalle porte di conferma o dalla segmentazione della rete. Tratta ogni test come un passo di convalida: se i controlli bloccano la catena iniettata, hai la prova che funzionano; se non lo fanno, hai un difetto concreto da risolvere.

Controlli da priorizzare

- Esegui ogni strumento sotto un utente del sistema operativo dedicato con il set minimo di capacità del file system. - Richiedi un servizio di approvazione separato per ogni chiamata che possa modificare lo stato, registra la decisione ed applica un timeout. - Applica politiche di rete che limitano le connessioni in uscita ai servizi interni noti e a una breve lista di API esterne. - Crittografa i segreti a riposo e non inserirli mai nel prompt del sistema; utilizza invece un servizio di vault. - Registra ogni invocazione dello strumento con ID utente, timestamp, hash di input e hash di output per la revisione forense.

Quando questi controlli sono in atto, i risultati del red team passano da “abbiamo trovato un modo per romperlo” a “abbiamo tentato X e i controlli lo hanno bloccato”, che è un segnale più forte di maturità della sicurezza.

Cosa non è

Nessuna garanzia di completezza

Questa guida non promette che seguire i passaggi consenta di rilevare ogni possibile iniezione. Tecniche innovative, vulnerabilità degli strumenti zero-day o funzionalità degli agenti non divulgate possono eludere i controlli descritti qui.

Non è una soluzione al 100 %

Applicare le mitigazioni riduce il rischio ma non lo elimina. La difesa in profondità richiede un monitoraggio continuo, revisioni regolari della catena di strumenti e aggiornamenti quando vengono rilasciati nuovi rilasci di OWASP.

La pretesa di non perdere mai è falsa

Nessun metodo di red team può affermare di non perdere mai un difetto. L'obiettivo è aumentare il costo per un attaccante e rendere l'exploitazione di successo visibile e tracciabile.

Non è un sostituto della codifica sicura

Le raccomandazioni presuppongono che tu già segua le pratiche di base di codifica sicura - convalida dell'input, codifica dell'output e principio di privilegio minimo. Aggiungono strati specifici dell'agente su quella base.

Riferimenti

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://genai.owasp.org/llmrisk/llm01-prompt-injection - https://owasp.org/Top10/2021/A03_2021-Injection

Articoli correlati

- Test di abuso degli strumenti per agenti LLM - Esplora la matrice completa dei temi AI micro-SaaS →