Una funzionalità che risponde a domande sui documenti può recuperare testo pertinente e inviarlo a un modello di IA. Quel testo, tuttavia, non è sempre innocuo: un documento, una pagina web o un file fornito da un utente può contenere frasi che tentano di cambiare il compito, ottenere informazioni a cui non dovrebbe avere accesso o provocare un’azione. Questo rischio è noto come prompt injection nei documenti, o iniezione indiretta, perché le istruzioni arrivano all’interno del contenuto elaborato e non necessariamente nella domanda dell’utente.
La mitigazione non consiste nel trovare la frase perfetta per il messaggio di sistema. Consiste nel progettare l’applicazione in modo che il contenuto recuperato non possa modificare autorizzazioni, policy o decisioni aziendali e che una risposta del modello non sia mai un’autorizzazione sufficiente per agire.
Quale rischio occorre controllare
Un documento può contenere istruzioni esplicite, come «ignora le istruzioni precedenti», oppure testo più ingannevole, come una richiesta di rivelare dati interni. Può anche includere istruzioni nascoste in contenuti estratti da HTML, commenti, metadati o testo generato tramite OCR. Se questo materiale viene mescolato senza distinzione alle istruzioni dell’applicazione, il modello potrebbe seguirne una parte, riassumerlo in modo distorto o generare una risposta non prevista.
Il rischio dipende da ciò che la funzionalità può fare. Un assistente che redige solo una risposta da sottoporre a revisione ha un impatto diverso da uno che può consultare account, emettere rimborsi o inviare messaggi. Prima di rendere la funzionalità accessibile agli utenti, occorre definire quali informazioni può ricevere, quali risposte può produrre e quali conseguenze ne possono derivare.
La prompt injection non dimostra di per sé che i controlli di accesso dell’applicazione siano stati violati. Può però esporre informazioni incluse impropriamente nel contesto o indurre il modello a richiedere un’operazione. La protezione deve riguardare l’input, i dati disponibili e le azioni successive.
Separare dati, policy e autorizzazioni
Il contenuto recuperato deve fornire elementi utili per rispondere, non diventare una fonte di autorità. Un documento può descrivere una policy aziendale, ma l’applicazione deve stabilire separatamente se l’utente è autorizzato a consultarlo o a eseguire un’operazione correlata. Questa decisione non va delegata al testo né alla risposta generata.
- Autorizzazione prima del recupero: applica i controlli di accesso nella ricerca e filtra i documenti in base all’identità e alle autorizzazioni correnti dell’utente.
- Contesto minimo: invia solo i frammenti necessari per il compito. Non includere dati di altri account, segreti, credenziali o informazioni di cui il modello non ha bisogno.
- Policy al di fuori del modello: calcola autorizzazioni, limiti e condizioni aziendali nel codice dell’applicazione o in servizi autorizzati.
- Risposta come proposta: tratta l’output del modello come contenuto da convalidare, non come un’istruzione eseguibile.
Un’istruzione di sistema può aiutare a esprimere il comportamento previsto, per esempio indicando che il testo recuperato è materiale di riferimento. Non costituisce un confine di sicurezza: non garantisce che il modello ignori istruzioni malevole e non sostituisce i controlli di accesso, la convalida e le restrizioni tecniche.
Progettare il flusso PHP con limiti espliciti
In PHP, è opportuno separare le fasi di autorizzazione, recupero, costruzione del contesto, chiamata al modello e convalida dell’output. Questa separazione facilita il test di ogni limite e impedisce che un risultato dell’IA venga collegato direttamente a un’operazione sensibile.
Il frammento seguente è pseudocodice a scopo illustrativo, non una chiamata eseguibile a un client specifico. Il modo di costruire la richiesta e i campi accettati dipendono dall’API e dall’SDK utilizzati:
$user = $auth->currentUser();
$documents = $repository->searchAuthorized($user, $question);
$snippets = $contextBuilder->selectRelevant($documents, $maxItems);
// Pseudocodice: adatta la richiesta all’API specifica.
$response = $aiClient->answer([
'task' => 'Rispondi usando il materiale di riferimento; non autorizzare azioni.',
'untrusted_context' => $snippets,
'question' => $question,
]);
$answer = $responseValidator->validate($response);
return $answer;I nomi nell’esempio sono illustrativi. Etichettare il contesto come non attendibile aiuta a comunicarne la funzione, ma non lo isola in modo infallibile: né il formato né le istruzioni impediscono da soli al modello di seguire un’istruzione incorporata. L’effettiva separazione dipende anche dai dati inviati, dalle autorizzazioni applicate al di fuori del modello e dalle capacità disponibili.
Normalizza e limita il contenuto estratto prima di inserirlo nel contesto: imposta dimensioni massime, rimuovi i formati non necessari e tratta con cautela il testo ottenuto tramite OCR o da pagine esterne. Evita di concatenare documenti senza limiti o di includere per impostazione predefinita l’intera cronologia di una conversazione. Conserva un riferimento alla fonte di ogni frammento se ti serve spiegare o verificare la risposta, senza includere nei log il relativo contenuto sensibile.
Ridurre l’impatto di una risposta manipolata
Limita gli strumenti accessibili al modello a quelli necessari per la funzionalità specifica. Se il compito richiede solo di rispondere a domande, non concedergli strumenti di scrittura né accesso generale ai servizi interni. Se deve consultare dati, esponi un’operazione circoscritta che applichi l’autorizzazione a ogni richiesta, anziché fornire credenziali ampie o accesso arbitrario a un database.
Quando il modello propone un’azione, l’applicazione deve convalidarla in un flusso indipendente. Verifica identità, autorizzazioni, parametri, regole aziendali e condizioni correnti della risorsa al momento dell’esecuzione. Per le azioni ad alto impatto, richiedi una conferma esplicita o una revisione umana. Una risposta testuale del modello, anche se sembra sicura o cita un documento, non sostituisce tale autorizzazione.
Convalida anche l’output prima di mostrarlo o elaborarlo: verifica il formato previsto, limita la lunghezza e rifiuta campi o valori non consentiti. Se è prevista una struttura specifica, analizzane e convalidane i campi con regole deterministiche. L’escaping dell’output e le difese contro le injection in HTML, SQL o nei comandi restano necessari: la generazione tramite IA non rende attendibile il testo prodotto.
Testare gli attacchi e i comportamenti previsti
I test devono coprire l’intero flusso, non solo verificare se il modello risponde correttamente a un’istruzione di sistema. Prepara documenti benigni e documenti avversari che tentino di alterare il compito, richiedere dati non autorizzati o indurre un’azione. Includi variazioni del formato di origine, come testo estratto da HTML, documenti lunghi e contenuti in cui le istruzioni sono mescolate a informazioni legittime.
- Verifica che la ricerca non restituisca mai documenti al di fuori delle autorizzazioni dell’utente, anche quando la domanda richiede esplicitamente quei dati.
- Verifica che i documenti avversari non abilitino strumenti né modifichino le regole aziendali.
- Conferma che una risposta malformata o imprevista venga rifiutata e che un’operazione sensibile richieda un’autorizzazione indipendente.
- Valuta risposte utili e corrette su documenti benigni per rilevare se le restrizioni compromettono la funzionalità in modo inaccettabile.
- Ripeti i test quando cambiano il modello, il template delle istruzioni, il retriever, gli strumenti o il processo di estrazione.
Definisci criteri di accettazione osservabili: quali dati non devono mai comparire, quali azioni devono rimanere bloccate e come deve rispondere il sistema quando le prove non sono sufficienti. Un singolo test non garantisce la sicurezza, ma una suite ripetibile aiuta a rilevare regressioni e a confrontare le modifiche di configurazione.
Registrare segnali senza accumulare dati sensibili
Per indagare sui malfunzionamenti, registra gli identificativi delle richieste, la versione della configurazione, gli identificativi o i riferimenti interni dei documenti consultati, le decisioni di autorizzazione, gli strumenti invocati e l’esito delle convalide. Registrare un riferimento non significa archiviare il documento o i suoi frammenti. Evita di salvare frammenti sensibili, a meno che non esista una necessità concreta e siano previsti controlli specifici di accesso, protezione e conservazione.
Aggiungi metriche relative a rifiuti, errori di formato e problemi del provider per distinguere le questioni di sicurezza da quelle operative. Evita di salvare automaticamente prompt completi, documenti e risposte se contengono dati personali, segreti commerciali o informazioni regolamentate. Definisci tempi di conservazione, accesso e redazione dei dati sensibili; quando è sufficiente, registra hash, identificativi ed eventi strutturati. Assicurati che i log non diventino un nuovo canale per esporre il contenuto che la funzionalità doveva proteggere.
Checklist prima di abilitare la funzionalità
- Le autorizzazioni vengono verificate prima di recuperare ogni documento?
- Il contesto inviato è minimo, circoscritto e trattato come input non attendibile?
- Le policy e le regole aziendali vengono applicate al di fuori del modello?
- Gli strumenti sono limitati e ogni operazione verifica nuovamente l’autorizzazione?
- Le risposte vengono convalidate prima di essere mostrate o trasformate in azioni?
- Per le decisioni ad alto impatto sono previste una revisione umana o una conferma?
- Sono disponibili test avversari ripetibili e log con conservazione controllata?
Se una risposta è negativa, limita l’ambito della funzionalità oppure mantieni le azioni come proposte finché la lacuna non viene colmata. La difesa dalla prompt injection nei documenti non dipende dal fatto che il modello interpreti sempre correttamente il contenuto: dipende dal fatto che i limiti di accesso e operativi continuino a funzionare anche quando il modello sbaglia.
