LOGISTAR — Scheda Oggetto

Dati oggetto

URL

Apri

Titolo / Descrizione

Sito / Azienda

Estratto / Body

# 6. Estrazione di informazioni e perdita di dati

Un LLM può essere attaccato non soltanto per ottenere una risposta diversa da quella prevista, ma anche per **far emergere informazioni che non avrebbero dovuto essere rivelate**.

Il problema può riguardare informazioni presenti nel prompt, nella memoria, nei documenti RAG, nei risultati dei tool, nei database o, in alcuni casi, informazioni legate al modello stesso.

È utile distinguere due fenomeni:

```text
ESTRAZIONE
attaccante → cerca deliberatamente un'informazione

LEAKAGE
sistema → rivela involontariamente un'informazione
```

A questi si aggiunge un terzo scenario:

```text
EXFILTRATION
informazione riservata → viene trasferita verso un'altra destinazione
```

## 6.1 Che cosa può essere estratto

Le informazioni a rischio possono appartenere a categorie molto diverse:

```text
dati personali
credenziali
token
chiavi API
documenti riservati
informazioni aziendali
dati finanziari
contenuti della memoria
risultati di query
istruzioni interne
configurazioni
```

Il rischio dipende soprattutto da **quali dati raggiungono il sistema e da quali privilegi possiede l'applicazione**.

Un LLM non deve necessariamente "conoscere" una password per rivelarla.

Se la password viene inserita nel suo contesto, il problema diventa quello di impedire che venga restituita o trasferita in modo improprio.

## 6.2 Information extraction

Un attaccante può tentare di ottenere informazioni attraverso richieste apparentemente innocue.

Per esempio, invece di chiedere direttamente:

```text
Qual è il contenuto riservato?
```

può cercare di ricostruirlo attraverso una serie di domande.

Il principio è:

```text
domanda 1
   ↓
informazione parziale

domanda 2
   ↓
altra informazione

domanda 3
   ↓
combinazione delle informazioni
```

Una singola risposta potrebbe non rivelare nulla di significativo.

Una sequenza di risposte può però permettere di ricostruire informazioni che il sistema avrebbe dovuto proteggere.

Questo è particolarmente importante nei sistemi che mantengono memoria o stato tra più interazioni.

## 6.3 Prompt e istruzioni interne

Una forma comune di estrazione consiste nel cercare di ottenere informazioni sulle istruzioni interne dell'applicazione.

Per esempio, un attaccante può chiedere al sistema di descrivere:

```text
le istruzioni che sta seguendo
la configurazione
le regole interne
gli strumenti disponibili
le informazioni presenti nel contesto
```

Non tutte queste informazioni sono necessariamente segrete.

Il problema nasce quando il sistema tratta come riservati contenuti che vengono comunque forniti al modello e non dispone di controlli adeguati per impedirne la divulgazione.

È importante quindi non confondere:

> **istruzione interna** con **meccanismo di sicurezza**.

Se una credenziale deve essere protetta, non dovrebbe esserlo semplicemente perché è scritto nel prompt:

```text
Non rivelare mai questa password.
```

Una credenziale non dovrebbe idealmente essere disponibile al modello in forma utilizzabile.

## 6.4 Il problema del contesto

Abbiamo visto nei capitoli precedenti che il modello riceve un contesto composto da informazioni diverse.

Per esempio:

```text
SYSTEM
   +
USER
   +
MEMORY
   +
RAG
   +
TOOL RESULTS
```

Se una di queste componenti contiene dati riservati, tali dati entrano nel materiale che il modello deve elaborare.

Questo crea un principio fondamentale:

> **un dato che non dovrebbe mai essere divulgato non dovrebbe essere reso accessibile al modello senza una precisa necessità.**

La protezione migliore spesso consiste quindi nel **non esporre il dato**, anziché nel chiedere al modello di non rivelarlo.

## 6.5 Leakage involontario

Non sempre è necessario un attacco sofisticato.

Un sistema può rivelare informazioni semplicemente perché l'applicazione ha costruito male il contesto.

Per esempio:

```text
utente A
   ↓
richiesta
   ↓
retrieval
   ↓
documenti appartenenti a utenti A + B
   ↓
LLM
   ↓
risposta
```

Se il sistema di autorizzazione non ha filtrato correttamente i documenti, il modello potrebbe utilizzare anche informazioni appartenenti all'utente B.

In questo caso il problema non è necessariamente un "modello che ha violato la privacy".

Il problema è un errore nella **separazione dei dati**.

## 6.6 Un esempio con il RAG

Immaginiamo una knowledge base aziendale contenente:

```text
documenti pubblici
documenti riservati
documenti personali
```

Un utente effettua una ricerca.

Il retrieval seleziona per errore anche un documento riservato:

```text
query
 ↓
retrieval
 ↓
documento riservato
 ↓
LLM
 ↓
risposta
```

A quel punto il modello potrebbe rispondere utilizzando il documento.

La protezione avrebbe dovuto avvenire **prima del modello**:

```text
query
 ↓
controllo autorizzazioni
 ↓
retrieval consentito
 ↓
LLM
```

Questo principio è fondamentale:

> **il filtro di sicurezza deve essere applicato alla fonte dei dati, non soltanto alla risposta finale.**

## 6.7 Data exfiltration

Il problema diventa ancora più serio quando il sistema dispone di tool.

Supponiamo che l'agente abbia accesso a:

```text
read_database()
read_file()
send_email()
call_api()
```

Una manipolazione del contesto potrebbe tentare di ottenere:

```text
lettura del dato
      ↓
LLM
      ↓
trasferimento tramite tool
      ↓
destinazione esterna
```

Per esempio:

```text
database
   ↓
read_database()
   ↓
LLM
   ↓
send_email()
   ↓
destinatario esterno
```

Qui non siamo più di fronte alla semplice divulgazione di una risposta.

Abbiamo una possibile **catena di esfiltrazione**.

## 6.8 Un attacco composto

I capitoli precedenti possono quindi convergere in un unico scenario:

```text
DOCUMENTO OSTILE
       ↓
RAG POISONING
       ↓
INDIRECT PROMPT INJECTION
       ↓
LLM
       ↓
PROPOSTA DI TOOL
       ↓
CONTROLLO INSUFFICIENTE
       ↓
ACCESSO AI DATI
       ↓
ESFILTRAZIONE
```

Questo esempio mostra perché è riduttivo considerare ogni vulnerabilità isolatamente.

Un sistema può essere relativamente robusto contro ciascun attacco preso singolarmente, ma diventare vulnerabile quando le debolezze vengono concatenate.

## 6.9 Estrazione dal modello

Esiste poi una categoria diversa: cercare di ottenere informazioni che provengono dal **modello stesso**.

In ambito di ricerca sulla sicurezza vengono studiati, tra gli altri:

* model extraction;
* membership inference;
* training-data extraction;
* inversion e reconstruction techniques.

Questi problemi riguardano il rapporto tra il modello e i dati utilizzati durante il suo sviluppo.

Sono però concettualmente diversi dalla semplice estrazione di dati presenti nel contesto durante una conversazione.

La distinzione è:

```text
DATI NEL CONTESTO
        ↓
estrazione dall'applicazione

DATI NEL MODELLO
        ↓
estrazione dal modello
```

Confondere i due fenomeni porta a una valutazione sbagliata del rischio.

## 6.10 Credenziali e segreti

Una regola particolarmente importante riguarda password, token e chiavi API.

Una progettazione insicura potrebbe essere:

```text
database
   ↓
password
   ↓
prompt
   ↓
LLM
```

Una progettazione migliore evita, quando possibile, di consegnare il segreto al modello.

Per esempio:

```text
LLM
 ↓
richiesta: esegui operazione X
 ↓
applicazione
 ↓
credenziale custodita dall'applicazione
 ↓
servizio esterno
```

In questo modo il modello può chiedere un'operazione senza conoscere necessariamente la credenziale utilizzata per eseguirla.

È una conseguenza diretta del principio del minimo privilegio.

## 6.11 Prevenire la perdita di dati

Le difese principali possono essere organizzate su più livelli.

### Minimizzazione

Fornire al modello soltanto i dati necessari.

### Controllo degli accessi

Il modello non dovrebbe poter aggirare le autorizzazioni applicative.

### Separazione dei tenant

I dati di utenti, clienti o organizzazioni diverse devono essere rigorosamente separati.

### Filtraggio prima del retrieval

Il RAG deve rispettare le autorizzazioni prima di fornire documenti al modello.

### Protezione delle credenziali

Password, token e chiavi API dovrebbero essere gestiti da sistemi dedicati e non inseriti inutilmente nel contesto.

### Controllo dell'output

Le risposte possono essere sottoposte a controlli per impedire la divulgazione di determinate categorie di dati.

### Controllo dei tool

Un agente non dovrebbe poter trasferire liberamente dati da una fonte interna verso una destinazione esterna.

### Logging e audit

Bisogna poter ricostruire:

```text
quale dato
   ↓
è stato letto
   ↓
da quale componente
   ↓
per quale richiesta
   ↓
con quale tool
   ↓
verso quale destinazione
```

## 6.12 Il principio della non esposizione

Tra tutte le difese ce n'è una particolarmente importante:

> **non affidare al modello la protezione di un segreto che il modello non ha bisogno di conoscere.**

Se una chiave API non è necessaria per generare una risposta, non dovrebbe entrare nel contesto.

Se un documento non è accessibile all'utente, non dovrebbe essere inserito nel contesto del suo LLM.

Se un database contiene dieci milioni di record ma la richiesta riguarda tre record, non è necessario rendere disponibili tutti gli altri.

La sicurezza migliora riducendo la quantità di informazioni che possono essere compromesse.

## 6.13 Dal modello al sistema

A questo punto emerge una distinzione importante.

La domanda:

> "Il modello può rivelare informazioni?"

è troppo generica.

Bisogna chiedersi:

```text
Quali informazioni conosce?
        ↓
Come le ha ottenute?
        ↓
Chi è autorizzato ad accedervi?
        ↓
Il modello può utilizzarle?
        ↓
Può produrle nell'output?
        ↓
Può passarle a un tool?
        ↓
Il tool può trasferirle all'esterno?
```

Questa sequenza permette di analizzare l'intero percorso del dato.

## 6.14 Una visione complessiva

I principali scenari possono essere riassunti così:

| Problema                   | Meccanismo                                                    |
| -------------------------- | ------------------------------------------------------------- |
| Information extraction     | L'attaccante cerca di ricavare informazioni                   |
| Context leakage            | Dati presenti nel contesto vengono rivelati                   |
| RAG leakage                | Il retrieval fornisce dati che l'utente non dovrebbe vedere   |
| Credential leakage         | Password, token o chiavi vengono divulgati                    |
| Tool-mediated exfiltration | Un tool trasferisce dati verso l'esterno                      |
| Model extraction           | Si cerca di ricavare informazioni sul modello                 |
| Training-data extraction   | Si tenta di recuperare informazioni dai dati di addestramento |

La lezione generale è semplice:

```text
DATI
 ↓
ACCESSO
 ↓
CONTESTO
 ↓
LLM
 ↓
OUTPUT
 ↓
TOOL
 ↓
DESTINAZIONE
```

Ogni passaggio rappresenta una possibile barriera di sicurezza.

Se tutte le barriere vengono affidate al solo modello, la sicurezza dell'intero sistema dipende dalla capacità del modello di non sbagliare.

Un'architettura robusta fa invece in modo che **un singolo errore del modello non sia sufficiente a trasformarsi in una perdita di dati**.

È questo il filo conduttore dei capitoli precedenti: prompt injection, poisoning, tool hijacking e data leakage non sono problemi completamente separati. Sono modi diversi attraverso i quali un attaccante può cercare di attraversare la catena:

```text
CONTENUTO
   ↓
CONTESTO
   ↓
MODELLO
   ↓
DECISIONE
   ↓
TOOL
   ↓
DATI
   ↓
MONDO ESTERNO
```

Il capitolo successivo può ora spostare l'attenzione dal comportamento dell'applicazione alla sua origine: **modello, fine-tuning, supply chain e backdoor**, cioè i casi in cui il problema può essere già presente prima ancora che il sistema venga messo in funzione.

Note

Voto oggetto (1-10)

Precisione (1-10)

Tag (7)

✎ Modifica tag 🤖 Suggerisci AI

          hacker:5, ai:5, llm:5, tool:5, llm_internal:5, chatbot:5        

ai 5 chatbot 5 hacker 5 llm 5 llm_internal 5 tool 5 wpg 5

ID: 68268 • Tipo: WPG • Reg: 2026-09-23 • Mod: 23/09/2026 22:22