La crittografia stabilisce chi può leggere il messaggio durante il trasferimento; il controllo degli accessi e la progettazione dell’agente stabiliscono che cosa il destinatario può fare dopo averlo letto.
Un attacco di prompt injection in un’app di messaggistica si verifica quando il testo di un messaggio tenta di indurre un assistente di IA a ignorare le proprie regole principali e a eseguire una richiesta non autorizzata. La crittografia end-to-end protegge il messaggio durante il trasferimento; tuttavia, se l’utente ha consentito a un bot di leggere la chat o il dispositivo è compromesso, la crittografia non può limitare il comportamento di quel destinatario autorizzato.
Punti chiave
- La crittografia end-to-end impedisce di leggere i messaggi durante il trasferimento, non l’uso improprio da parte di un assistente virtuale autorizzato a vedere il testo decrittografato.
- La prompt injection indiretta può nascondersi in un messaggio privato, un file, una didascalia o un contenuto citato e trasformarsi in un’istruzione durante l’elaborazione.
- Il rischio di fuga di dati da un agente di IA aumenta quando questo ha accesso contemporaneamente a chat, memoria, strumenti esterni e funzioni per inviare informazioni o eseguire operazioni.
- Separare i dati dalle istruzioni, ridurre al minimo le autorizzazioni, richiedere la conferma umana e limitare gli output sono tra i principali livelli di difesa; nessuno offre da solo una garanzia completa.
- Secondo la documentazione di Livara, le chat dirette e i gruppi privati compatibili con E2EE attivo sono crittografati end-to-end; un vecchio gruppo incompatibile può restare fuori da questa copertura. Questa protezione non garantisce il comportamento dell’assistente dopo che ha ricevuto il testo.
Come funziona la prompt injection nella messaggistica?
La prompt injection, ossia l’iniezione di istruzioni, consiste nella creazione, da parte di un attaccante, di un input che il modello linguistico accetta come istruzione anziché come dato, allontanandosi dalla propria politica principale. La guida OWASP alla prompt injection individua negli input diretti e nei contenuti esterni due vie di esposizione a questo rischio. In un sistema basato su agenti, una risposta deviata può anche portare a un uso involontario degli strumenti collegati.
In un attacco diretto, è l’utente stesso a chiedere al bot di ignorare le regole precedenti. In un attacco indiretto, l’istruzione malevola si trova in un contenuto che l’assistente legge per svolgere un altro compito: un messaggio ricevuto, un testo citato, una didascalia, un documento o l’output di uno strumento. Nel secondo caso, l’attaccante non deve condividere un account con l’agente di IA: basta che il suo contenuto raggiunga il contesto elaborato dall’agente.
Per esempio, un utente chiede all’assistente di riassumere i nuovi messaggi. Uno di essi contiene un testo che si spaccia per un’«istruzione di sistema» e chiede all’agente di interrompere il riepilogo, prelevare altre informazioni dal contesto e inviarle a una destinazione esterna. Il successo di questo scenario non è certo: dipende dal modello, dalla progettazione dell’applicazione, dagli accessi e dai controlli sugli output. Anche questa sola possibilità, però, ha rilevanza per la sicurezza di un assistente dotato di strumenti.
Occorre distinguere tra la manipolazione della risposta di un modello e l’attacco a un agente in grado di agire. Una risposta sbagliata può essere fastidiosa; un agente autorizzato a inviare messaggi, recuperare file o chiamare servizi può trasformare la stessa manipolazione in una divulgazione di dati o in un’azione indesiderata.
Perché la sicurezza di un chatbot di IA non dipende solo dalla crittografia?
La sicurezza di un chatbot di IA dipende dall’intera catena di fiducia: app di messaggistica, dispositivo, modello, memoria, strumenti, server del fornitore e politica delle autorizzazioni. La crittografia end-to-end copre solo un confine specifico: impedire la lettura dei contenuti privati nel percorso tra il mittente e i destinatari autorizzati.
Quando il messaggio raggiunge un dispositivo autorizzato, viene decrittografato per essere mostrato all’utente. Se un assistente può accedere al testo sullo stesso dispositivo o tramite una connessione autorizzata, vede i dati dopo la decrittografia. Dal punto di vista del protocollo, un bot o un’applicazione con i permessi necessari può essere un destinatario legittimo; dal punto di vista dell’utente, quello stesso destinatario può avere poteri eccessivi.
La differenza si può riassumere così: la crittografia stabilisce chi può leggere il messaggio durante il trasferimento; il controllo degli accessi e la progettazione dell’agente stabiliscono che cosa il destinatario può fare dopo averlo letto. Per comprendere il primo confine, la guida alla crittografia end-to-end e a ciò che non protegge spiega che E2EE non è un rimedio contro malware, destinatari sleali o schermi compromessi.
Anche l’espressione «messaggistica crittografata e intelligenza artificiale» non va interpretata automaticamente come sicura o insicura. Un agente locale, senza memoria persistente e privo di strumenti di output, non presenta lo stesso livello di rischio di un bot cloud con accesso alla cronologia, ai file e agli account esterni. L’architettura e l’ampiezza delle autorizzazioni determinano il risultato.
Quali rischi crea l’accesso di un assistente di IA alle chat private?
L’accesso di un assistente di IA alle chat private porta oltre un nuovo confine di fiducia contenuti prima visibili soltanto ai partecipanti umani. Il rischio principale è che l’assistente, oltre a leggere il testo, possa conservarlo, combinarlo con altri dati o inviarlo attraverso un altro canale.
Prima di attivare una funzione di questo tipo, cinque domande devono ricevere risposte chiare:
- Quali conversazioni, allegati e intervalli di tempo può leggere esattamente l’assistente?
- L’elaborazione avviene sul dispositivo oppure il contenuto viene inviato a un altro server?
- Quali dati conserva il fornitore e li utilizza per l’addestramento?
- Di quali strumenti dispone l’agente per inviare messaggi, caricare file, effettuare ricerche o eseguire operazioni?
- Ogni azione sensibile richiede la conferma esplicita dell’utente?
Il permesso di «leggere tutte le chat» per una funzione che deve soltanto riassumere un messaggio selezionato viola il principio del privilegio minimo. Questo principio prevede che ogni componente riceva solo l’accesso minimo necessario per il compito corrente. Un’autorizzazione limitata a un messaggio, una conversazione e un singolo turno riduce l’estensione del danno, anche se il contenuto di quell’ambito può comunque veicolare un attacco.
Anche i metadati sono distinti dal contenuto. Secondo la documentazione di Livara, i metadati operativi come mittente, destinazione e orari di consegna vengono memorizzati per l’instradamento e la sincronizzazione. La guida ai metadati della messaggistica e alle informazioni che rivelano illustra questo confine. Oltre al testo, un assistente può dedurre informazioni dagli schemi dei contatti e dagli orari delle comunicazioni; la politica di accesso deve quindi considerare entrambi.
Attraverso quali vie possono fuoriuscire dati da un agente di IA?
La fuga di dati da un agente di IA si verifica generalmente quando l’agente vede contenuti riservati nel proprio contesto e dispone di un mezzo per trasferirli altrove. La prompt injection da sola non sposta i dati: la fuga dipende dalla combinazione di input malevolo, accesso ai dati e canale di uscita.
Messaggi o file in uscita
L’agente può inserire informazioni in una risposta, un nuovo messaggio, una bozza, un file o una richiesta a un servizio esterno. Se il sistema invia gli output senza restrizioni o conferma dell’utente, un attaccante può cercare di dare ai dati riservati una forma apparentemente normale.
Memoria a lungo termine
Alcuni agenti conservano riepiloghi delle conversazioni, preferenze o risultati precedenti per un uso successivo. Un’istruzione malevola può tentare di inserire dati nella memoria o recuperarli in un’altra sessione. Una memoria di breve durata, l’isolamento tra utenti e la possibilità di consultarla ed eliminarla riducono il rischio, ma non eliminano gli errori del modello.
Chiamate agli strumenti
Un agente dotato di strumenti può effettuare ricerche, leggere file o eseguire altre operazioni autorizzate. La lettura dei file, l’invio di messaggi e le richieste di rete devono avere autorizzazioni separate. Anche la visualizzazione automatica di un link o il caricamento di una risorsa esterna nell’output possono creare una via di uscita per i dati: l’assenza di un pulsante «Invia» non è sufficiente da sola.
Dispositivo compromesso
Un malware con accesso sufficiente può vedere il testo visualizzato, le notifiche, la memoria dell’applicazione o gli input dell’utente. In questa situazione, l’attaccante non deve necessariamente violare la crittografia: la aggira sul dispositivo finale. Le protezioni del sistema operativo, gli aggiornamenti, il controllo degli accessi e la verifica delle applicazioni installate fanno parte della difesa, ma non sono funzionalità del protocollo di messaggistica.
Quali sono i limiti della crittografia di Livara rispetto a questa minaccia?
La documentazione sulla sicurezza di Livara descrive LVR1 per le chat dirette e LGS1 per i gruppi privati compatibili. Un vecchio gruppo incompatibile può essere esplicitamente escluso da E2EE; occorre controllare lo stato della conversazione specifica. Anche i canali pubblici non rientrano nell’ambito delle chat private E2EE.
Anche in una conversazione E2EE, se l’utente fornisce all’assistente il testo decrittografato, la crittografia del messaggio non controlla lo scopo dell’elaborazione successiva. La verifica del numero di sicurezza serve inoltre a confermare la chiave del contatto, non a individuare istruzioni malevole nel suo testo. Questo articolo riguarda una classe generale di rischi e non conferma l’esistenza né la sicurezza di una particolare integrazione di IA in Livara.
È un’illustrazione concettuale, non un’architettura verificata di Livara; i lucchetti nell’immagine non dimostrano che un assistente non possa accedere al testo selezionato.
Quale architettura limita la prompt injection nella messaggistica?
Un’architettura sicura deve trattare i messaggi ricevuti come dati non attendibili, anche se provengono da un contatto noto all’interno di una chat crittografata. La crittografia rafforza l’autenticità del canale, ma non dimostra che il contenuto del mittente sia innocuo per l’esecuzione automatica.
Separare i dati dalle istruzioni
L’applicazione deve mantenere su livelli separati le istruzioni fisse dello sviluppatore, la richiesta esplicita dell’utente e i contenuti letti dalle chat. L’avvertimento dell’NCSC sulla prompt injection sottolinea che non si deve presumere che questo problema abbia una soluzione definitiva simile a quella della SQL injection. Etichettare i contenuti come «dati non attendibili» è utile, ma i modelli linguistici non rispettano sempre questo confine semantico senza errori; la separazione deve quindi essere accompagnata da controlli esterni al modello.
Ridurre i poteri dell’agente
Un agente che riassume non ha bisogno di inviare messaggi automaticamente o leggere tutti i file. Gli strumenti devono avere elenchi di elementi consentiti, un ambito limitato, credenziali separate e scadenze brevi. Un’autorizzazione monouso per contenuti selezionati è preferibile all’accesso permanente, perché riduce sia la probabilità di accessi involontari sia l’estensione di una fuga di dati.
Verificare gli output con un controllo deterministico
Il modello non deve prendere da solo la decisione finale sull’invio di dati sensibili. Un livello non generativo può verificare destinazione, tipo di dati, volume dell’output e operazione richiesta mediante regole deterministiche. Le regole strutturali e gli elenchi delle destinazioni consentite devono essere applicati al di fuori del modello; il riconoscimento semantico di tutte le informazioni riservate può comunque fallire. Sono inoltre necessari una registrazione minima degli eventi, avvisi e la possibilità di arresto.
Richiedere la conferma umana per le azioni sensibili
Leggere una bozza non equivale a inviarla. L’invio di messaggi, la condivisione di file, l’aggiunta di membri, la modifica delle impostazioni dell’account o il trasferimento di dati a un servizio esterno devono prevedere un’anteprima chiara e una conferma consapevole. Conferme vaghe o troppo frequenti diventano un’abitudine a fare clic; l’interfaccia deve mostrare esattamente dati, destinazione e conseguenze.
Eseguire l’agente in un ambiente limitato
L’isolamento dei processi, l’accesso alla rete disabilitato per impostazione predefinita, l’archiviazione temporanea e le credenziali con ambito ristretto limitano gli effetti di un errore. Questi controlli non eliminano la prompt injection: impediscono che una risposta deviata si trasformi direttamente in un accesso esteso.
Che cosa devono fare utenti e amministratori per la sicurezza dei chatbot di IA?
Gli utenti devono considerare ogni collegamento a un’IA come un nuovo destinatario dei dati privati. Anche gli amministratori devono esaminare i flussi di dati e le operazioni dell’agente prima della distribuzione e monitorarli durante l’esecuzione.
Per uso personale:
- Seleziona solo il messaggio o il file necessario; non concedere accesso all’intera cronologia.
- Controlla dove avviene l’elaborazione, il periodo di conservazione, l’uso per l’addestramento e il metodo di cancellazione dei dati.
- Lascia disattivato l’invio automatico di messaggi o file, salvo una necessità evidente.
- Mantieni aggiornati dispositivo, browser e applicazioni e rivedi le autorizzazioni sensibili.
Per le organizzazioni:
- Redigi un modello delle minacce che consideri separatamente il mittente malevolo, il membro sleale di un gruppo, il servizio del modello, lo strumento esterno e il dispositivo compromesso.
- Registra le chiamate agli strumenti, le modifiche delle autorizzazioni, le destinazioni di output e le conferme dell’utente utilizzando la quantità minima necessaria di dati sensibili.
- Prova input ostili in messaggi, documenti, testi citati, immagini contenenti testo e contenuti recuperati.
- Definisci per ogni agente limiti alle operazioni, frequenze delle richieste, destinazioni consentite e un interruttore di arresto d’emergenza.
- Adotta un comportamento sicuro in caso di dubbio: se la politica è ambigua, l’agente deve fermarsi anziché indovinare.
Nessuna lista di controllo crea una sicurezza completa. Il risultato dipende dall’implementazione, dal modello, dalle impostazioni, dal comportamento dell’utente e dall’evoluzione dei metodi di attacco. Una buona difesa mira a ridurre i poteri, rendere visibili le deviazioni e limitare i danni.
Messaggistica crittografata e IA possono essere sicure insieme?
Sì, la messaggistica crittografata e l’IA possono funzionare insieme con un rischio controllato, purché l’assistente abbia l’accesso minimo necessario e non esegua azioni sensibili senza conferma. Tuttavia, collegare qualsiasi modello a contenuti privati crea un nuovo confine di fiducia che non deve essere nascosto dietro l’etichetta E2EE.
Una progettazione meno rischiosa mantiene il più possibile l’elaborazione sul dispositivo, limita il contesto alla selezione esplicita dell’utente, rende la memoria di breve durata e separa gli strumenti di output. Neppure l’elaborazione locale è una garanzia assoluta: un dispositivo compromesso, un modello non sicuro o autorizzazioni estese continuano a creare rischi.
L’utente deve poter capire quali dati arrivano al modello, dove viene eseguito, per quanto tempo conserva informazioni e che cosa può fare. Se un prodotto non risponde chiaramente a queste domande, espressioni come «IA privata» non devono essere considerate una prova definitiva di sicurezza.
La documentazione del protocollo o la corrispondenza dell’hash di un’applicazione non costituiscono un test di sicurezza di un assistente collegato. Prima di attivare un’integrazione, controlla separatamente le autorizzazioni e il percorso dei dati di quella specifica funzione. Anche un singolo test riuscito non copre, da solo, tutti gli input futuri.
Domande frequenti
La crittografia end-to-end blocca la prompt injection?
No. La crittografia end-to-end nasconde i messaggi agli intermediari tra il mittente e i destinatari autorizzati. Se un bot autorizzato, un’applicazione sul dispositivo o un malware ha accesso al testo decrittografato, può elaborarlo. Contenere la prompt injection richiede limiti alle autorizzazioni, agli strumenti, alla memoria e agli output dell’agente.
Riassumere chat private con l’IA è pericoloso?
Il rischio dipende dall’architettura. Il riepilogo locale di un messaggio selezionato, senza memoria né strumenti di output, ha un ambito di rischio inferiore a quello di un bot cloud con accesso permanente a tutte le chat. Prima dell’uso, controlla il luogo di elaborazione, la conservazione dei dati, l’ampiezza delle autorizzazioni e la possibilità di invio automatico.
Il messaggio di un contatto noto può contenere prompt injection?
Sì. Fidarsi dell’identità del mittente non equivale a fidarsi di tutti i suoi contenuti: il suo account potrebbe essere stato compromesso oppure potrebbe aver inoltrato inconsapevolmente un testo malevolo. Ogni contenuto letto dall’agente deve essere trattato come dato non attendibile, anche all’interno di una conversazione autenticata e crittografata.
LVR1 e LGS1 nascondono le informazioni a un assistente di IA?
Nelle conversazioni effettivamente protette da LVR1 o LGS1 con E2EE attivo, questi protocolli mirano a nascondere il contenuto agli intermediari privi delle chiavi. Se l’utente o l’applicazione permette all’assistente di leggere un messaggio decrittografato, questi protocolli non bloccano quell’accesso autorizzato. La sicurezza dell’assistente deve quindi essere valutata separatamente da quella del trasporto dei messaggi.
Qual è il primo passo per ridurre la fuga di dati da un agente di IA?
Per prima cosa, restringi l’accesso dell’agente: solo al messaggio selezionato, solo per quel turno e senza invio automatico. Prevedi poi un’anteprima e una conferma umana per le operazioni sensibili, limita le destinazioni di output e registra le chiamate agli strumenti. Questi livelli riducono il rischio, ma non offrono una garanzia assoluta.
