Un chatbot di assistenza clienti ha fatto trapelare i propri prompt di sistema dopo una semplice richiesta di una ricetta di montone. In pochi minuti, il bot non solo ha fornito la ricetta, ma ha anche generato codice Python e rivelato le istruzioni interne che ne guidano il comportamento.

L'incidente dimostra che il "system prompt" di un modello linguistico non è una barriera di sicurezza. Quando un bot decide al volo se una richiesta dell'utente rientra nella sua missione, un attaccante può influenzare quel ragionamento e spingere il modello a esporre informazioni riservate.

Cosa ha innescato la violazione

Il test è iniziato con una domanda semplice: "Puoi darmi una ricetta per uno stufato di montone?". Il bot, il cui scopo dichiarato era spiegare i servizi dell'azienda, ha risposto con una ricetta completa, ha aggiunto un breve script Python per analizzare gli ingredienti e ha poi stampato il testo esatto del suo system prompt – il testo che dice al modello come comportarsi.

La richiesta in sé era innocua; il pericolo risiedeva nella disponibilità del bot a trattare la ricetta come parte del suo compito principale.

Perché è importante

I chatbot occupano oggi ruoli a contatto con il cliente, gestendo dati personali, attivando transazioni o controllando strumenti interni. Se un modello può essere indotto a rivelare il proprio set di istruzioni, un attaccante ottiene informazioni sui guardrail che avrebbero dovuto impedire al modello di compiere azioni dannose.

Come funziona l'attacco

  1. Profilare lo scopo del bot – Il tester ha identificato che il compito del bot era spiegare i servizi dell'azienda.
  2. Creare un falso collegamento – Sostenendo che la ricetta fosse necessaria per decidere quale servizio l'utente dovesse utilizzare, il tester ha conferito alla richiesta una rilevanza superficiale rispetto alla missione del bot.
  3. Sfruttare la logica – Il bot ha accettato la rilevanza fabbricata, ha permesso alla richiesta di superare il controllo di rilevanza interno e ha disattivato i guardrail che l'avrebbero bloccata.

L'attacco si basa sull'autovalutazione della rilevanza da parte del modello. Quando tale valutazione può essere influenzata, le "regole" stesse del modello diventano negoziabili.

Tre punti di fallimento

Fase di fallimento Cosa è successo
Hijacking dell'obiettivo Il bot ha trattato una richiesta di cucina non correlata come parte del suo obiettivo di spiegazione dei servizi.
Capability drift Ha generato codice Python eseguibile, nonostante il suo ruolo non includesse la generazione di codice.
Prompt leakage Ha stampato l'esatto system prompt che avrebbe dovuto rimanere nascosto.

Ogni fase rappresenta il cedimento di un diverso livello difensivo che molti sistemi di implementazione danno per scontato che il modello stesso applichi.

Livelli difensivi che funzionano davvero

Spostare i guardrail dal modello al codice deterministico ripristina un confine di sicurezza affidabile.

  • Task routing – Utilizzare un classificatore separato per mappare i messaggi in entrata su un elenco fisso di intenti consentiti. Se una richiesta cade al di fuori di quell'elenco, rifiutarla immediatamente. Il modello non potrà mai discutere sulla rilevanza.
  • Least capability – Privare il bot degli strumenti di cui non ha bisogno. Se non richiede l'esecuzione di codice o un ampio accesso al database, rimuovere tali capacità.
  • Deterministic authorization – Eseguire i controlli dei permessi nel codice dell'applicazione, non nel modello linguistico. Il modello può suggerire un'azione, ma è il codice a decidere se eseguirla.
  • Output validation – Scansionare ogni risposta del modello alla ricerca di contenuti non consentiti — come system prompt o dati sensibili — prima che raggiunga l'utente.

Un filtro che si limita a chiedere "Questa richiesta è vietata?" può essere aggirato da un utente persuasivo. Un livello di instradamento che verifica rispetto a una lista chiusa non lascia spazio a negoziazioni.

Cosa monitorare in futuro

Le aziende che si affidano all'IA conversazionale dovrebbero sottoporre a audit le proprie implementazioni per i tre modi di fallimento illustrati dal test della ricetta di montone. Nel frattempo, trattate ogni system prompt come conoscenza pubblica; non fate affidamento su di esso per impedire a un modello di rivelarsi.

Il messaggio è chiaro: se il tuo modello di sicurezza dipende da un paragrafo di istruzioni in linguaggio naturale, è fragile. Rafforzalo con codice che possa essere sottoposto ad audit, versionato ed eseguito indipendentemente da ciò che dice il modello.