AWS: il system prompt può trapelare, progettiamo per limitarne i danni

L’8 luglio 2026 AWS Security Blog ha pubblicato una guida dedicata alla fuga dei system prompt nelle applicazioni generative. Il punto di partenza è pragmatico: oggi non esiste una soluzione completa capace di garantire che un modello non riveli mai parti delle istruzioni ricevute. Gli sviluppatori dovrebbero quindi progettare assumendo che il contenuto possa essere inferito o estratto, riducendo ciò che sarebbe dannoso esporre e aggiungendo controlli in ingresso, durante l’elaborazione e sull’output.

Il system prompt contiene spesso ruolo, regole, descrizioni degli strumenti, cronologia, metadati, contesto RAG e risposte di API. Questa ricchezza lo rende utile ma anche interessante per un attaccante. L’errore più grave è trattarlo come un archivio segreto. Una frase nascosta al modello non è protetta come un valore conservato in un secret manager. Se una password o una chiave compaiono nel prompt, l’architettura ha già perso il proprio confine di sicurezza.

Assumere la possibilità di leakage non significa arrendersi. È lo stesso principio usato in altri ambiti: si progettano sistemi resilienti anche se una singola difesa fallisce. Si minimizza l’informazione, si separano responsabilità e si rilevano comportamenti anomali. Il prompt può ancora contenere istruzioni operative e contesto necessario, ma la sua esposizione non deve concedere accessi, rivelare segreti o permettere di aggirare autorizzazioni.

Il leakage è la rivelazione non prevista di istruzioni o contesto che l’applicazione invia al modello ma non intende mostrare all’utente. Può avvenire perché l’utente chiede direttamente di ripetere le regole, usa trasformazioni o lingue diverse, induce il modello a simulare debug oppure sfrutta contenuti indiretti recuperati dal sistema. Non sempre l’output è una copia esatta. Anche riassunti, frammenti o inferenze possono rivelare struttura, strumenti e logica utile a preparare attacchi successivi.

Le conseguenze dipendono dal contenuto. Scoprire il tono di un chatbot può avere impatto limitato. Conoscere nomi di strumenti, endpoint, criteri di moderazione o dettagli del contesto può facilitare abusi. Se il prompt include dati di altri utenti o informazioni proprietarie, il danno è maggiore. La valutazione deve quindi separare proprietà intellettuale, sicurezza e privacy. Non tutto ciò che è riservato ha lo stesso rischio, e non tutto ciò che è segreto dovrebbe trovarsi nel prompt.

È utile distinguere riservatezza e robustezza. Nascondere un prompt può rendere più difficile copiare un workflow, ma non rende sicuro un sistema. Un attaccante può testare il comportamento senza conoscere le istruzioni. Viceversa, un prompt leggibile può operare in un’architettura sicura se azioni e dati sono protetti da controlli esterni. La sicurezza non deve dipendere dall’oscurità del testo.

Chiavi API, password, token di sessione e credenziali vanno conservati in servizi dedicati e usati dal backend soltanto quando necessario. Il modello può richiedere un’azione attraverso un’interfaccia, ma non deve vedere il segreto che la abilita. Lo stesso vale per dati personali non pertinenti: se un campo non serve al task, non va incluso. La minimizzazione riduce contemporaneamente costo, rischio di leakage e confusione del modello.

Le descrizioni degli strumenti dovrebbero contenere solo ciò che serve a scegliere e compilare una chiamata. Dettagli infrastrutturali, endpoint interni e messaggi di errore completi possono essere mantenuti fuori dal contesto. Un gateway può tradurre una richiesta strutturata in operazione reale, applicando autenticazione e autorizzazione. Il modello vede un contratto ristretto; il sistema conserva la complessità e i segreti. Questo confine rende più semplice testare e cambiare provider.

Anche i dati proprietari usati per ragionare vanno selezionati. Il retrieval dovrebbe recuperare porzioni pertinenti e applicare permessi per utente, evitando di riversare interi repository nel prompt. Classificazione e redazione possono rimuovere elementi sensibili prima dell’invio. Se l’applicazione richiede informazioni particolarmente riservate, considerate modelli e ambienti con garanzie adeguate, ma mantenete comunque il principio: il modello riceve il minimo necessario per completare quel task.

I controlli in ingresso possono rilevare richieste note di estrazione, pattern sospetti e contenuti non ammessi. Guardrail e filtri riducono gli attacchi più semplici, ma non devono essere l’unica barriera. Linguaggio naturale e codifiche permettono infinite varianti. È più robusto limitare la lunghezza, normalizzare formati, distinguere canali e dichiarare chiaramente quale testo è dato non fidato. Quando possibile, trasformate l’input in campi strutturati invece di concatenarlo liberamente.

Il contesto recuperato da web e documenti deve essere isolato dalle istruzioni. Delimitatori e messaggi separati aiutano il modello, ma il vero controllo avviene nell’architettura. Un componente può estrarre fatti, un altro verificarli e un terzo decidere l’azione. Le informazioni esterne non dovrebbero modificare strumenti disponibili o policy. La catena è più complessa, ma riduce la possibilità che una frase nascosta in un documento controlli l’intero agente.

Per flussi ad alto rischio, impiegate modelli o chiamate distinte. Un modello legge contenuti non fidati senza accesso a strumenti e produce un riepilogo strutturato; un secondo componente usa soltanto i campi validati. La separazione non garantisce immunità, ma riduce il raggio d’azione. Applicate rate limit e limiti di costo per impedire tentativi massivi. Anche un attacco senza successo può consumare risorse o degradare il servizio.

AWS suggerisce tecniche di rilevamento come canary token inseriti nelle istruzioni. Si tratta di stringhe uniche che non dovrebbero mai apparire nell’output. Se vengono rilevate, il sistema può bloccare la risposta e generare un alert. I token non impediscono la fuga di altri frammenti e un attaccante potrebbe aggirarli, ma forniscono un segnale concreto. Vanno ruotati e gestiti evitando che diventino prevedibili o finiscano in log accessibili.

I controlli di similarità possono confrontare la risposta con parti del prompt e individuare parafrasi o copie. Le soglie richiedono taratura: troppo basse bloccano risposte legittime, troppo alte lasciano passare rivelazioni. È utile valutare separatamente sezioni sensibili e testare su un dataset di conversazioni reali anonimizzate. Il filtro deve spiegare almeno internamente perché ha bloccato, così il team può migliorare senza esporre il contenuto protetto all’utente.

La validazione dell’output dovrebbe includere schema, contenuti sensibili, destinazione e coerenza con il task. Una funzione deterministica può rimuovere campi non previsti, verificare URL e impedire che il modello restituisca istruzioni operative. Per risposte testuali, classificatori e regole possono offrire un ulteriore strato. Quando il controllo segnala un rischio, è preferibile una risposta sicura e un percorso di assistenza piuttosto che tentare infinite rigenerazioni che potrebbero ripetere l’esposizione.

Il system prompt può dire che l’agente non deve accedere a determinati dati, ma l’API deve applicare la stessa regola. Ogni tool call va associata all’identità dell’utente, allo scope del task e a una policy deterministica. Parametri sensibili vanno validati; destinatari, importi e modifiche irreversibili richiedono controlli specifici. Il modello non è un’autorità: propone una chiamata che il sistema può accettare, modificare o negare.

Usate credenziali temporanee e con minimo privilegio. Un agente che prepara una bozza non necessita del permesso di invio; uno che legge dati di progetto non deve vedere cartelle personali. Separate ambienti di test e produzione e non riutilizzate token tra utenti. Se un’injection riesce, l’impatto massimo resta limitato. Questo principio è più efficace di qualunque frase aggiunta al prompt, perché non dipende dall’interpretazione del modello.

Le approvazioni umane devono mostrare ciò che conta. Un pulsante generico ‘continua’ non basta. Il revisore deve vedere azione, destinatario, dati condivisi e conseguenza. Per operazioni ripetitive si possono usare soglie e allowlist, mantenendo conferma per eccezioni. Registrate chi ha approvato e quale versione del contenuto. Il log crea responsabilità e facilita l’analisi in caso di incidente.

Monitorate richieste ripetute di estrazione, comparsa di token sentinella, output bloccati, chiamate anomale e variazioni improvvise nel tasso di rifiuto. Correlate eventi per sessione senza raccogliere più dati del necessario. I log devono essere protetti e avere retention definita, perché possono contenere proprio i frammenti che il sistema tenta di difendere. Limitate l’accesso e mascherate credenziali e dati personali prima della persistenza.

Il piano di risposta dovrebbe prevedere disattivazione di strumenti, rotazione di segreti, aggiornamento dei prompt, blocco di pattern e comunicazione interna. Se sono coinvolti dati personali o clienti, entrano in gioco procedure legali e privacy. Definite severità e tempi prima dell’incidente. Un piccolo leakage di istruzioni generiche non va gestito come l’esposizione di dati; entrambi però devono essere registrati per identificare tendenze.

Eseguite tabletop exercise con scenari realistici. Un utente pubblica online il prompt, un token appare in una risposta o un documento induce una tool call. Verificate chi riceve l’alert, chi può intervenire e come si conferma la risoluzione. Le simulazioni rendono evidenti permessi mancanti e dipendenze. In un sistema agentico, la velocità di contenimento è parte della sicurezza tanto quanto la capacità di prevenire.

Create un inventario dei prompt e classificateli per sensibilità. Rimuovete immediatamente segreti e dati non necessari. Mappate fonti, retrieval, strumenti e output. Per ogni passaggio chiedete che cosa accade se il contenuto viene rivelato o controllato da un attaccante. Introducete guardrail, token sentinella e validazione dove producono valore, ma soprattutto spostate autorizzazioni e regole critiche nel codice. La revisione deve coinvolgere sicurezza, prodotto e proprietari dei dati.

Costruite una suite di test con richieste dirette, trasformazioni, lingue diverse e injection indirette. Misurate non solo il tasso di blocco, ma falsi positivi, latenza e impatto sull’esperienza. Ripetete i test quando cambiano modello, prompt o strumenti. Un sistema che funzionava con una versione può comportarsi diversamente con un’altra. Versionare configurazioni e risultati rende il rischio osservabile e impedisce che un aggiornamento silenzioso annulli una difesa.

La lezione di AWS è utile oltre il singolo servizio cloud: non costruite sicurezza su un segreto che il modello deve leggere. Il system prompt resta importante per qualità e orientamento, ma va considerato una componente esposta a pressione avversaria. Se la sua fuga non sblocca credenziali, dati o azioni, l’incidente è contenibile. Progettare per questo scenario permette di innovare con maggiore velocità, perché i confini non dipendono dalla perfezione probabilistica del modello.

Documentate infine il rischio residuo in un linguaggio comprensibile ai decisori. Indicate quali parti del prompt potrebbero emergere, quali difese esistono e quale sarebbe l’impatto massimo. Questa trasparenza consente di scegliere se il caso d’uso è proporzionato e quale livello di dati ammettere. La sicurezza non è la promessa di rischio zero, ma la capacità di conoscere il perimetro, ridurre l’esposizione e reagire quando una difesa non si comporta come previsto.

Rivedete questa valutazione quando cambiano modello, retrieval o strumenti. Una modifica apparentemente piccola può ampliare il contesto o concedere una nuova capacità. Collegare la revisione di sicurezza al normale processo di rilascio impedisce che le protezioni restino ferme mentre l’agente evolve.