Perché gli agenti ampliano la superficie di attacco
Un chatbot classico riceve un messaggio e genera una risposta. Un agente di IA può anche chiamare API, leggere file, interrogare database, inviare email o avviare azioni.
Questo trasforma un errore di prompt in un rischio operativo reale. Il problema non è più solo una risposta sbagliata, ma un accesso o una trasmissione di dati non autorizzati.
La sicurezza va quindi progettata a livello di strumenti, permessi e dati, non solo nel prompt di sistema.
La prompt injection può causare fughe di dati
Un contenuto esterno può contenere istruzioni pensate per manipolare l’agente: un documento, un’email, una pagina web, un ticket di supporto o un risultato RAG.
Se l’agente tratta queste istruzioni come affidabili, può rivelare informazioni, usare uno strumento non previsto o allontanarsi dal compito richiesto.
Ogni contenuto recuperato va considerato non affidabile, le istruzioni di sistema devono restare separate dai dati e gli strumenti disponibili vanno limitati rigorosamente.
Applicare il privilegio minimo agli strumenti dell’agente
Un agente che deve solo leggere lo stato di un ordine non ha bisogno di un accesso generico in scrittura all’intero database.
Ogni strumento deve esporre una sola operazione di business precisa, con parametri limitati, controlli di autorizzazione lato server e validazione.
Le credenziali usate dall’agente devono avere meno privilegi di un amministratore umano, mai di più.
Evitare fughe tra tenant nel RAG
In un SaaS multi-tenant, il filtro per organizzazione deve essere applicato prima della ricerca vettoriale, non dopo aver già recuperato i documenti.
La similarità semantica non deve mai bastare a rendere accessibile un documento. L’autorizzazione di business prevale sempre sulla similarità.
I test devono includere scenari di fuga tra tenant, perché un bug di filtraggio può esporre dati senza generare alcuna eccezione tecnica.
Non inviare segreti al modello
Token OAuth, chiavi API, password, stringhe di connessione e segreti tecnici non devono mai essere inseriti nel contesto del modello.
Gli strumenti devono usare le proprie credenziali lato server e restituire solo il risultato di business necessario.
Quando un agente agisce per conto di un utente, un’autorizzazione delegata e limitata nel tempo è preferibile all’esposizione diretta di un segreto.
Registrare senza ricreare la fuga nei log
I log sono essenziali per capire il comportamento di un agente, ma possono diventare una fonte di fuga se ogni prompt e ogni risposta vengono salvati in chiaro.
Meglio privilegiare identificativi di correlazione, metadati, decisioni, nomi degli strumenti e stati, mascherando le informazioni personali o sensibili.
I log che hanno davvero bisogno del contenuto devono avere periodi di conservazione brevi e controlli di accesso più rigorosi.
Coinvolgere una persona nelle azioni sensibili
Cancellazione di dati, trasferimenti finanziari, modifiche dei permessi, invii massivi o divulgazione di documenti sensibili non dovrebbero essere eseguiti automaticamente sulla sola base dell’output di un modello.
L’agente può preparare l’azione, spiegare cosa farà e chiedere una conferma esplicita prima dell’esecuzione.
Questa validazione riduce notevolmente l’impatto di allucinazioni, prompt injection o contesto errato.
