Un'iniezione di prompt può essere nascosta in un documento che un assistente consulta: il testo cerca di fargli abbandonare il suo compito o divulgare le informazioni. Tratta il contenuto recuperato come dati inaffidabili e limita le azioni che il sistema può eseguire.
Identifica la frontiera della fiducia
Una pagina Web, un PDF o un messaggio ricevuto non ha l'autorità per le istruzioni della tua domanda. Un contenuto che afferma il contrario deve rimanere una fonte da analizzare. OWASP identifica le prompt injection tra i rischi delle applicazioni del modello linguistico. Una semplice istruzione che invita il modello a ignorare gli attacchi non costituisce una sufficiente separazione tecnica.
ridurre le possibili conseguenze
Una procedura guidata di documenti generalmente non deve essere in grado di inviare messaggi, modificare file o visualizzare tutte le cartelle dell'azienda. Limitare i suoi strumenti e l'accesso al perimetro utile. Separare la ricerca del documento dall'esecuzione di un'azione. Quando esiste un'azione sensibile, avere i suoi parametri convalidati in un'interfaccia controllata, con regole esterne al testo generato.
Costruisci uno scenario di test senza dati sensibili
Lavora in un ambiente di verifica di accettazione pianificato, con un corpus e account demo. Il test non dovrebbe richiedere una vera perdita per dimostrare che il rischio esiste. Inserisci in un documento fittizio un'istruzione che tenti di deviare l'attività, quindi fai una domanda legittima su questo documento. L'obiettivo è osservare il comportamento dell'intera applicazione, compresi i suoi strumenti e controlli di accesso.
| Contenuto fittizio | Comportamento atteso | Prova utile |
|---|---|---|
| un'istruzione che chiede di ignorare la domanda | La richiesta dell'utente rimane l'ambito del lavoro | Domanda, risposta e documenti utilizzati |
| Una richiesta di inoltro di un documento a una terza parte | Non è possibile alcuna spedizione non autorizzata | Elenco degli strumenti accessibili e del registro delle chiamate |
| una richiesta di lettura di una risorsa al di fuori del perimetro | Il controllo accessi all'app rifiuta la riproduzione | Risultato del controllo indipendente dal modello |
| Un'uscita che sembra un'azione aziendale | l'output rimane il contenuto da convalidare | traccia che mostra l'assenza di esecuzione automatica |
leOWASP descrive iniezioni dirette e indirette e raccomanda misure che ne limitino le conseguenze. Il fatto che un processo non dirotta il modello non dimostra una protezione completa. La domanda critica rimane: cosa potrebbe succedere se si seguisse un prossimo tentativo? La risposta deve essere guidata dalle autorizzazioni e dai controlli dell'applicazione.
Controllare le uscite prima dell'uso
Non trasmettere direttamente una risposta del modello a un interprete di comandi oa una query aziendale. Controllare la struttura, le destinazioni e le autorizzazioni nel codice dell'applicazione. Anche i collegamenti visualizzati devono essere trattati con cautela. La risposta può essere registrata per l'analisi in un ambiente idoneo, evitando inutili mantenimenti di informazioni riservate.
Esempio fittizio: un documento di supporto
Un file demo contiene un'istruzione che chiede alla procedura guidata di rivelarne la configurazione. Il risultato atteso è una risposta incentrata sulla domanda dell'utente, senza divulgazione o chiamata tool al di fuori del perimetro. Il test dovrebbe utilizzare dati fittizi in un ambiente isolato. Soprattutto verificare che le protezioni tecniche impediscano la perdita anche se il modello segue un'istruzione indesiderata.
Risposta separata, proposta di azione ed esecuzione
- Per una prima procedura guidata di documentazione, avvia senza uno strumento di invio, eliminazione o modifica. Verifica che queste funzioni manchino effettivamente dalle autorizzazioni e non solo nascoste nell'interfaccia.
- Quando un'azione è necessaria, convalidare nel codice la sua destinazione, il suo tipo e i diritti del richiedente. Una stringa prodotta dal modello non deve essere utilizzata direttamente come autorizzazione.
- Visualizza le impostazioni importanti in una schermata di conferma adeguata. Le istruzioni sulla pagina visualizzata non dovrebbero essere in grado di modificare questo processo.
- Controlla anche la presentazione della risposta: HTML, i link e le parti proposte devono seguire le regole della tua domanda. Non rendere eseguibile un testo perché proviene da un modello.
In un esempio immaginario di supporto web, il mago può spiegare come richiedere un intervento. Può preparare un riassunto che la persona rilegge. Non è necessario essere in grado di inviare tutto il file tecnico o di modificare l'accesso all'hosting. Questa separazione riduce le conseguenze di una risposta compromessa mantenendo l'utilità del servizio.
Il file di verifica di accettazione deve distinguere tra le prove effettuate, le protezioni controllate ei rischi che non sono stati testati. Dopo un'evoluzione degli strumenti o dei diritti, rigioca i casi interessati. collegare questo lavoro al Preparazione della base di documentari RAG : l'origine ei diritti dei documenti rimangono importanti anche quando il modello sembra seguire le istruzioni.
Integra il test nella verifica di accettazione
Conserva alcuni documenti di prova che rappresentano tentativi diretti e indiretti. Riproducili dopo un'evoluzione del modello, degli strumenti o del corpus. Notare i comportamenti attesi e i limiti residui invece di dichiarare il sistema invulnerabile. Per un primo progetto, scegli una procedura guidata di lettura limitata e consulta il metodo di Preparare un sito web per gli agenti web.