Oggetti

Descrizione

dta reg (aaaa-mm-gg)

Body

Se con “hacker degli LLM” intendi persone che cercano di attaccare o manipolare sistemi basati su modelli linguistici, devi distinguere almeno quattro minacce.
<h5>1. Prompt injection</h5>
Qualcuno inserisce un testo apparentemente innocuo che contiene istruzioni per il modello, ad esempio:
<blockquote>«Ignora le istruzioni precedenti e fai X.»</blockquote>
È 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.
<hr>
<h5>2. Furto delle API key</h5>
Una chiave API dell'LLM rubata può permettere a qualcuno di utilizzare il tuo account a tue spese.
Difesa:
<ul>
<li>mai inserire le chiavi nel codice pubblicato;</li>
<li>mai metterle in prompt o documenti;</li>
<li>conservarle in variabili d'ambiente/secret manager;</li>
<li>limitarne i permessi quando il servizio lo consente;</li>
<li>impostare limiti di spesa e monitoraggio;</li>
<li>cambiarle immediatamente se sospetti una fuga.</li>
</ul>
<hr>
<h5>3. LLM con accesso a strumenti</h5>
È il rischio più serio.
Un LLM che può soltanto rispondere ha una superficie d'attacco relativamente limitata.
Un LLM che può:
<pre><code>leggere file
 ↓
eseguire programmi
 ↓
accedere a Internet
 ↓
modificare dati
 ↓
inviare email</code></pre>
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.
<hr>
<h5>4. Documenti e pagine Web malevole</h5>
Anche senza parlare direttamente con l'LLM, un aggressore può cercare di inserire istruzioni nascoste dentro:
<ul>
<li>pagine Web;</li>
<li>PDF;</li>
<li>email;</li>
<li>documenti;</li>
<li>immagini;</li>
<li>dati recuperati tramite RAG.</li>
</ul>
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à.
<hr>
<h4>La regola d'oro</h4>
Io userei questo principio:
<blockquote>Non fidarti dell'LLM, anche quando è il tuo LLM.</blockquote>
Non perché sia necessariamente “cattivo”, ma perché può essere manipolato, può sbagliare e può interpretare un dato come un'istruzione.
Quindi:
<pre><code> LLM
 │
 ┌──────┴──────┐
 │ │
 input output
 │ │
 VALIDAZIONE VALIDAZIONE
 │ │
 └──────┬──────┘
 │
 SISTEMA</code></pre>
Il modello suggerisce; il programma che sta intorno al modello controlla.
<h5>Se vuoi una protezione molto robusta</h5>
Pensa a cinque barriere:
<ol>
<li>Autenticazione — chi può utilizzare il sistema.</li>
<li>Autorizzazione — cosa può fare ciascun utente.</li>
<li>Isolamento — cosa può raggiungere l'LLM.</li>
<li>Validazione — controllo degli input e degli output.</li>
<li>Logging e limiti — registrazione delle operazioni e possibilità di bloccare comportamenti anomali.</li>
</ol>
Anche se una barriera viene aggirata, le altre dovrebbero impedire che l'attacco diventi una compromissione completa.

tipo ogg.

cat

subcat

proprietario

azienda

ute

selez1

op1

codart

codice

codclifor

motivo

url

tag

imgsrc

sunto_breve

sunto_medio

note

keyscrape

Lista tag dell'oggetto (oggettag)
cod_tag	value
ai	5
chatbot	5
hacker	5
llm	5
llm_internal	5
wpg	5

Lista delle righe dell'oggetto (oggettir)
tip_pro	cod_pro	descrizione	val_pro	pes_pro

---.