Un modello di linguaggio elabora istruzioni e dati sotto forma di testo o contenuto multimodale. Questa flessibilità crea un'ambiguità fondamentale: un documento consultato può contenere una frase che sembra un'istruzione. Un agente può quindi interpretare un dato esterno come un comando, tentare di accedere a uno strumento o rivelare informazioni.
La prompt injection non si risolve con un prompt di sistema più severo. Il modello rimane un componente probabilistico. La sicurezza consiste nel limitare i suoi poteri, isolare le fonti, verificare le azioni e impedire che un errore di interpretazione produca un impatto.
Iniezione diretta e indiretta
Un'iniezione diretta è inserita dall'utente nella conversazione per aggirare le regole. Un'iniezione indiretta è nascosta in un'email, una pagina web, un documento, un'immagine o un output di uno strumento che il sistema consulta.
L'iniezione indiretta è particolarmente importante per gli agenti: il contenuto dannoso può provenire da una fonte che l'utente crede legittima. Il modello non deve accordarle lo stesso livello di fiducia delle politiche di sistema.
Le conseguenze possibili
Secondo gli strumenti e i dati accessibili, un'iniezione può provocare:
- divulgazione di informazioni del contesto;
- invio verso una destinazione esterna;
- azione non autorizzata;
- modifica dei dati ;
- memorizzazione di un'istruzione persistente;
- uso eccessivo di una risorsa;
- risposta ingannevole;
- elusione di una convalida;
- saturazione o spesa eccessiva.
Un chatbot senza strumenti ha un raggio d’impatto più ridotto rispetto a un agente capace di inviare email o eseguire codice. Il rischio si misura dai poteri, non solo dalla probabilità di una risposta errata.
Cartografare i confini della fiducia
Lo schema deve distinguere:
- istruzioni di sistema e politiche;
- inserimento utente ;
- contenuto recuperato ;
- memoria ;
- uscite dei modelli;
- strumenti;
- segreti ;
- servizi esterni ;
- validazioni umane.
Ogni flusso specifica la sua origine, il suo livello di fiducia, le sue trasformazioni e le azioni che può influenzare. Un contenuto non affidabile non deve mai modificare una politica o un elenco di strumenti.
Strati di difesa indipendenti che limitano le conseguenze di un'iniezione rapida.
Separare istruzioni e dati
Il sistema delimita chiaramente i contenuti recuperati e indica al modello che non sono istruzioni. Questa tecnica riduce alcuni rischi, ma non è una garanzia.
La vera protezione deriva dall'architettura: anche se il modello segue un'istruzione dannosa, non possiede l'accesso o l'autorizzazione necessaria per produrre l'impatto.
Le uscite di un modello sono esse stesse inaffidabili quando alimentano uno strumento. Devono essere convalidate come qualsiasi input esterno.
Ridurre il contesto
Più il modello riceve dati, maggiore è la superficie di esposizione e il rischio di fuga. Il RAG deve recuperare solo i passaggi necessari e autorizzati. I segreti non vengono aggiunti al contesto per comodità.
La memoria conserva il minimo e ha una durata. Le conversazioni di più utenti o cartelle sono isolate. I dati vecchi vengono riletti dalla loro fonte prima di un'azione.
Progettare strumenti a minor privilegio
Uno strumento deve:
- compiere un'azione precisa;
- verificare l'identità;
- validare uno schema rigoroso;
- limitare la portata;
- applicare le regole aziendali;
- essere idempotente;
- registrare in un diario ;
- restituire un risultato strutturato.
Gli strumenti generici di shell, SQL, browser libero o richiesta HTTP arbitraria sono vietati per impostazione predefinita. Quando del codice deve essere eseguito, lo è in un ambiente isolato, effimero e senza accesso inutile alla rete.
Controllare le destinazioni
Le capacità di invio, download e pubblicazione sono canali di esfiltrazione. I destinatari, domini, bucket, URL e tipi di file sono limitati da una politica indipendente.
L'agente non può creare da solo una destinazione autorizzata. Le nuove destinazioni richiedono un'azione amministrativa separata.
Proteggere i segreti
Le chiavi non sono presenti nel prompt né restituite dagli strumenti. Un servizio lato server esegue la chiamata e limita le operazioni. I registri mascherano i segreti e i parametri sensibili.
Gli account tecnici hanno permessi minimi, una rotazione e una sorveglianza. Una presunta fuga provoca una revoca rapida.
Convalidare le uscite strutturate
Una chiamata a uno strumento deve rispettare uno schema: tipi, valori, formati, lunghezze e relazioni. I campi sconosciuti vengono rifiutati. I valori critici vengono ricalcolati o riletti dalla fonte.
Un JSON valido non è necessariamente consentito. Il motore di policy verifica utente, risorsa, importo, destinazione e contesto.
Aggiungere approvazioni proporzionate
Le azioni reversibili e deboli possono essere eseguite automaticamente. Le azioni sensibili sono visualizzate in anteprima e confermate. Le azioni ad alto impatto richiedono un'approvazione indipendente.
La validazione è legata ai parametri esatti e scade. Un'istruzione esterna non può produrre un'approvazione implicita.
Isolare la navigazione e il codice
Un agente che consulta il web o esegue codice deve usare una sandbox con:
- sistema di file effimero;
- rete limitata;
- durata e risorse limitate;
- nessuna chiave generale;
- download controllati;
- risultato filtrato;
- diario delle attività.
I documenti attivi, gli script e le macro non vengono eseguiti nel contesto principale.
Proteggere la memoria
Un'iniezione può richiedere di registrare una regola per le conversazioni future. Le scritture di memoria sono separate, limitate e talvolta soggette a convalida. Ogni elemento possiede provenienza, data, proprietario e ambito.
Il sistema può distinguere tra preferenze dell'utente, fatti verificati e riepiloghi generati. Un output del modello non diventa una verità duratura senza regola.
Controllare i connettori e MCP
Un server di strumenti remoto è un fornitore di codice e dati. Deve essere inventariato, autenticato, valutato e limitato. I metadati di uno strumento non sono automaticamente affidabili.
I token sono specifici per il server e per l’utente. I reindirizzamenti, i consensi, le variazioni di capacità e gli aggiornamenti sono monitorati. Un server non può richiedere segreti destinati a un altro.
Rilevare senza dipendere dalla rilevazione
I filtri possono individuare alcune formulazioni, domini o comportamenti. Sono utili per l’allerta, ma un attaccante può variare la forma. La politica deve rimanere sicura anche se il rilevamento fallisce.
Le anomalie di volume, destinazione, strumento, costo e rifiuto sono monitorate. Un meccanismo di interruzione disattiva rapidamente una capacità.
Testare in modo avversariale
Il red teaming copre:
- contenuto non affidabile in ogni fonte;
- tentativi di cambiamento di ruolo;
- richieste di segreto;
- utensili in catena;
- dati codificati ;
- memoria ;
- lingue e formati;
- errori e timeout;
- approvazioni ;
- destinazioni.
I test devono essere autorizzati, isolati e orientati ai controlli. I casi rilevati diventano regressioni automatizzate senza conservare dati sensibili.
Preparare l'incidente
Il piano prevede la sospensione degli strumenti, la revoca dei token, la conservazione delle prove, l'analisi delle azioni, la notifica e il ripristino. Il registro collega identità, contenuto, modello, strumenti, parametri e risultato.
Un errore di modello può scatenare un'azione aziendale; il team sicurezza e il team prodotto devono quindi condividere le procedure.
Accettare il rischio residuo
Nessuna combinazione garantisce che un modello non segua mai un’istruzione. L’obiettivo è che questo errore non permetta un'azione vietata o una fuga significativa.
Alcune capacità rimangono troppo rischiose e devono essere escluse, limitate a una proposta o riservate a un ambiente isolato.
La sicurezza viene dai confini
Un sistema sicuro considera il modello come un interprete inaffidabile, utile ma limitato. Le politiche, i diritti, le convalide e gli strumenti restano deterministici e verificabili.
Partitech può realizzare il threat modeling, progettare i controlli, mettere in sicurezza i connettori e implementare i test degli agenti e del RAG. La difesa in profondità protegge il sistema anche quando il modello sbaglia.
Parliamo del tuo progetto
Auditare la sicurezza del tuo RAG o dei tuoi agenti con Partitech. Contatta Partitech.