hacker e LLM

Se con “hacker degli LLM” intendi persone che cercano di attaccare o manipolare sistemi basati su modelli linguistici, devi distinguere almeno quattro minacce.

1. Prompt injection

Qualcuno inserisce un testo apparentemente innocuo che contiene istruzioni per il modello, ad esempio:

«Ignora le istruzioni precedenti e fai X.»

È particolarmente pericoloso quando l'LLM può accedere a file, database, email, browser o altri strumenti.

Difesa: considera qualsiasi testo proveniente dall'esterno come dato non affidabile, non come istruzione.

---

2. Furto delle API key

Una chiave API dell'LLM rubata può permettere a qualcuno di utilizzare il tuo account a tue spese.

Difesa:

• mai inserire le chiavi nel codice pubblicato;
• mai metterle in prompt o documenti;
• conservarle in variabili d'ambiente/secret manager;
• limitarne i permessi quando il servizio lo consente;
• impostare limiti di spesa e monitoraggio;
• cambiarle immediatamente se sospetti una fuga.

---

3. LLM con accesso a strumenti

È il rischio più serio.

Un LLM che può soltanto rispondere ha una superficie d'attacco relativamente limitata.

Un LLM che può:

leggere file
      ↓
eseguire programmi
      ↓
accedere a Internet
      ↓
modificare dati
      ↓
inviare email

può invece diventare un intermediario attraverso cui un attaccante cerca di raggiungere il sistema.

La regola fondamentale è:

non dare al modello più potere di quello strettamente necessario.

E soprattutto non affidargli direttamente operazioni irreversibili o amministrative.

---

4. Documenti e pagine Web malevole

Anche senza parlare direttamente con l'LLM, un aggressore può cercare di inserire istruzioni nascoste dentro:

• pagine Web;
• PDF;
• email;
• documenti;
• immagini;
• dati recuperati tramite RAG.

Il modello potrebbe leggerle e interpretarle erroneamente come istruzioni.

Per questo bisogna mantenere una separazione rigorosa:

istruzioni del sistema → dati dell'utente → dati recuperati da Internet/documenti.

Non devono avere automaticamente lo stesso livello di autorità.

---

La regola d'oro

Io userei questo principio:

Non fidarti dell'LLM, anche quando è il tuo LLM.

Non perché sia necessariamente “cattivo”, ma perché può essere manipolato, può sbagliare e può interpretare un dato come un'istruzione.

Quindi:

             LLM
              │
       ┌──────┴──────┐
       │             │
     input         output
       │             │
   VALIDAZIONE    VALIDAZIONE
       │             │
       └──────┬──────┘
              │
           SISTEMA

Il modello suggerisce; il programma che sta intorno al modello controlla.

Se vuoi una protezione molto robusta

Pensa a cinque barriere:

1. Autenticazione — chi può utilizzare il sistema.
2. Autorizzazione — cosa può fare ciascun utente.
3. Isolamento — cosa può raggiungere l'LLM.
4. Validazione — controllo degli input e degli output.
5. Logging e limiti — registrazione delle operazioni e possibilità di bloccare comportamenti anomali.

Anche se una barriera viene aggirata, le altre dovrebbero impedire che l'attacco diventi una compromissione completa.