Estrazione di informazioni e perdita di dati

# 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.