“Il buttafuori segue un copione. Trova una battuta che il copione non copre, e sei dentro.”
Cos'è un jailbreak
I fornitori di modelli integrano guardrail nei loro modelli: rifiuti per certe categorie di richieste. Un jailbreak è qualsiasi prompt che aggira quei guardrail: messe in scena di gioco di ruolo ("fingi di essere un'IA senza regole"), ipotesi, richieste codificate, o la scomposizione di un'attività vietata in elementi dall'aria innocua. Nuovi jailbreak appaiono di continuo; i fornitori li correggono; il ciclo continua.
Il motivo fondamentale per cui i jailbreak continuano a funzionare: l'addestramento alla sicurezza è uno strato applicato sopra un modello che fondamentalmente vuole essere utile e proseguire qualsiasi testo plausibile. I guardrail sono tendenze statistiche, non regole rigide, e una formulazione abbastanza nuova si insinua tra loro. Non esiste un metodo noto per rendere un modello utile e impenetrabile ai jailbreak.
Di chi è il problema?
Ecco il riposizionamento che la maggior parte dei team si lascia sfuggire. Se costruisci su un modello ospitato, i guardrail del fornitore riguardano soprattutto la responsabilità e il marchio del fornitore, non la sicurezza della tua applicazione. Un utente che fa il jailbreak di ChatGPT per scrivere qualcosa di offensivo è un problema di reputazione per OpenAI. La domanda che ti riguarda è diversa: cosa può davvero fare un utente attraverso la tua applicazione comportandosi male?
L'abuso che ti riguarda
Concentra i tuoi sforzi sull'abuso a livello applicativo, che ti appartiene a prescindere da quanto sono buoni i guardrail del fornitore:
- Fuga dall'ambito: portare il tuo bot di assistenza clienti ad agire come un assistente generico, bruciando i tuoi token per le attività dell'attaccante.
- Abuso di capacità: indurre il modello a usare un tool o ad accedere a dati al di fuori dell'attività prevista (è di nuovo il problema del delegato confuso).
- Esaurimento delle risorse: innescare operazioni costose (contesti enormi, lunghi cicli di agent) per far lievitare la tua fattura o degradare il servizio per gli altri.
- Output dannosi per la reputazione: il tuo assistente di marca produce contenuto che ti mette in imbarazzo, perché nella tua interfaccia parla a tuo nome.
Le difese sono le stesse misure architetturali del capitolo sull'injection, perché la minaccia è la stessa: istruzioni non attendibili che incontrano capacità. Vincola l'ambito e i tool del modello, applica limiti di frequenza e tetti di budget per utente, e verifica che output e azioni restino entro i confini previsti dall'applicazione. Non stai cercando di rendere il modello incapace di rifiutare ogni cosa cattiva al mondo. Stai cercando di assicurarti che, all'interno della tua app, possa fare solo il lavoro della tua app.
La sicurezza dei contenuti dove conta davvero
Se il tuo prodotto espone davvero una generazione aperta al pubblico sotto il tuo marchio (un assistente di scrittura, un chatbot pubblico), allora la sicurezza dei contenuti fa parte del tuo problema, e i soli guardrail del fornitore non copriranno i tuoi rischi specifici. Aggiungi uno strato di moderazione degli output (un classificatore o un'API di moderazione) calibrato sulle categorie che contano per il tuo contesto e il tuo pubblico, e registra e rivedi ciò che viene segnalato. Adatta il controllo all'esposizione reale, anziché trattare ogni app come se fosse a un jailbreak dalla catastrofe.
Una riga per ciascuno
- Un jailbreak aggira i guardrail addestrati del modello; ne appaiono di nuovi di continuo perché la sicurezza è una tendenza, non una regola rigida.
- I guardrail del fornitore riguardano soprattutto la responsabilità del fornitore. Il tuo problema è ciò che un utente può fare attraverso la tua app.
- Concentrati sull'abuso applicativo: fuga dall'ambito, abuso di capacità, esaurimento delle risorse, output dannosi per la reputazione.
- Difenditi con gli stessi controlli architetturali dell'injection; aggiungi una vera moderazione dei contenuti solo dove esponi una generazione aperta al pubblico.
Dove andare ora