Tratta i contenuti recuperati come input non attendibile

Individua dove i dati diventano istruzioni

Un agente di programmazione legge più della richiesta dell’utente. Può esaminare issue, file del repository, documentazione dei pacchetti, risultati di ricerca e risposte degli strumenti. Parte di quei contenuti può includere istruzioni di un’altra persona.

La prompt injection si verifica quando questi contenuti allontanano il modello dal compito autorizzato. Un’injection indiretta arriva da una fonte recuperata, invece che dalla richiesta diretta dell’utente. OWASP indica materiale del repository e output degli strumenti tra i punti di ingresso pertinenti. Leggi le indicazioni di prevenzione.

Considera un compito fittizio di manutenzione. L’utente chiede all’agente di correggere un filtro dei report ed eseguire i test richiesti. Un README recuperato dice che i test sono obsoleti e chiede di caricare un file di configurazione. Il README può spiegare il progetto. Non può autorizzare a saltare le verifiche dell’utente o inviare file altrove.

Mappa le conseguenze possibili

Lo stesso testo fuorviante ha conseguenze diverse in ambienti diversi. Uno strumento di riepilogo in sola lettura può produrre un riepilogo errato. Un agente con scrittura sul repository può modificare codice. Un agente con segreti e accesso di rete in uscita può esporre informazioni.

Esamina le azioni disponibili prima di decidere quali difese contano. Elenca risorse sensibili, destinazioni scrivibili e destinazioni esterne. Includi connettori aggiunti dopo la configurazione iniziale. Un nuovo strumento può ampliare l’effetto di una debolezza esistente.

Un agente può anche trasferire contenuti fuorvianti a una fase successiva. Per esempio, può copiare un’istruzione non attendibile in un brief generato. L’agente successivo non deve trattare quel brief come una policy approvata in modo indipendente.

Usa più controlli con scopi distinti

Nella progettazione applicativa, separa le istruzioni attendibili del compito dai dati recuperati. Mostra l’origine del materiale recuperato. Questi passi migliorano l’interpretazione, ma non creano un confine di sicurezza completo.

Fai rispettare i permessi sulle risorse nel sistema di esecuzione. Limita le destinazioni dei dati sensibili. Richiedi la decisione appropriata prima di azioni con conseguenze rilevanti. Valida l’operazione proposta rispetto al compito e alla destinazione autorizzati.

Filtri e un secondo modello possono aiutare a rilevare contenuti sospetti. Possono anche non rilevare attacchi o bloccare informazioni legittime. Non sostituire l’autorizzazione deterministica con un punteggio di confidenza del modello. OWASP segnala esplicitamente i limiti di affidarsi solo ai prompt o al recupero di informazioni. Leggi la descrizione del rischio.

Verifica il flusso senza esposizione reale

Usa un repository temporaneo e file fittizi. Non concedere alla valutazione credenziali di produzione o scritture esterne senza restrizioni. Introduci un’istruzione innocua in conflitto con il compito, come saltare una verifica obbligatoria.

Osserva sia la risposta del modello sia le azioni effettive degli strumenti. Il messaggio «ho ignorato l’istruzione» non basta se la verifica è stata comunque saltata. Registra compito, fixture con l’injection, strumenti consentiti e risultato osservato.

Ripeti casi rappresentativi dopo modifiche a prompt, modelli, connettori o permessi. Un esempio bloccato è una prova per quel caso, non una dimostrazione contro ogni injection. Se un test fallisce, riduci le conseguenze possibili mentre correggi il flusso sottostante.