L'autorizzazione si sposta sul dato

Terzo e ultimo articolo della serie sulla sicurezza agentica. Il primo: l'agente AI come utenza privilegiata. Il secondo: la lethal trifecta e il triangolo del fuoco.

Dai primi due pezzi di questa serie discende una conclusione scomoda. L'agente è un'utenza privilegiata che non si comporta come le utenze che sappiamo governare, e la difesa contro la prompt injection non può essere probabilistica. Se non puoi garantire comesi comporterà l'agente, la conseguenza logica è una sola: smetti di difendere il comportamento e difendi il dato.

Il controllo è nel posto sbagliato

Nell'architettura che quasi tutti stanno costruendo, l'autorizzazione vive nell'applicazione e nel token dell'agente. È l'agente — o il tool che invoca — a decidere se una certa informazione può essere letta e a chi può essere mostrata. Finché gli agenti sono due e i tool cinque, sembra gestibile. Poi arrivano il decimo agente e il trentesimo tool, e i punti in cui il controllo va scritto, testato e mantenuto diventano il prodotto delle due cifre. Ogni nuovo strumento è un nuovo perimetro da presidiare, e ne basta uno configurato male perché tutto il resto non conti.

Il dato, invece, è uno solo. Sta in un numero limitato di posti: qualche database, un data warehouse, un object store, il gestionale. Spostare lì l'enforcement significa scrivere la regola una volta e vederla applicata a chiunque interroghi — umano, applicazione, agente, oggi e fra sei mesi, anche a quell'integrazione che nessuno ricordava di aver lasciata attiva.

Cosa significa data-centric, in pratica

Non è un concetto astratto: sono controlli che i database in produzione hanno già da anni, e che quasi nessuno ha esteso agli agenti.

Row-level security — il database filtra le righe prima che la query restituisca qualcosa. L'agente che interroga il CRM per conto di un commerciale vede i clienti di quel commerciale: non perché l'abbiamo istruito a comportarsi bene, ma perché le altre righe non esistono nella risposta.
Masking a livello di colonna — i campi sensibili tornano redatti anche dentro una query legittima. L'agente che calcola statistiche sugli ordini riceve il fatturato, non l'IBAN e non il codice fiscale.
Tokenizzazione e pseudonimizzazione — l'identificativo diretto è sostituito da un riferimento privo di significato; la ri-identificazione richiede un passaggio separato e tracciato, che l'agente non ha motivo di poter fare.
ABAC — la decisione di accesso non si appoggia a un ruolo statico ma agli attributi in gioco. NIST la definisce come la valutazione di attributi di soggetto, oggetto, operazione richiesta e — dove serve — condizioni ambientali, rispetto a una policy. Per un agente sono esattamente le domande giuste: per conto di chi sta agendo, su quale dato, per fare cosa, da dove.

La differenza rispetto ai guardrail è netta e vale la pena dirla esplicitamente: l'agente non sceglie di non guardare — non vede. Se una prompt injection lo convince a esfiltrare i dati dei clienti, esfiltra le righe a cui aveva diritto. L'incidente resta, ma il perimetro del danno è quello che abbiamo deciso noi a tavolino, non quello che ha deciso l'attaccante.

Identità propagata, non service account

Tutto questo però funziona a una condizione: che il dato sappia per conto di chista rispondendo. È il punto in cui la maggior parte dei deployment agentici cade oggi. L'agente si collega al database con un service account unico, spesso generoso, e da lì in poi il controllo per utente è finito: qualunque cosa arrivi in fondo alla catena, arriva con la stessa identità onnipotente.

L'alternativa esiste ed è standard: l'identità dell'utente che ha originato la richiesta viene propagata lungo la catena — è il meccanismo del token exchange OAuth 2.0 (RFC 8693) — e l'agente non può eccedere i permessi di quell'utente. Non è teoria da whitepaper: l'Identity & Privilege Abuse è la terza voce della OWASP Top 10 for Agentic Applications 2026, e la raccomandazione della stessa OWASP è di definire profili per-strumento che limitino permessi, accesso ai dati e funzionalità al minimo necessario. Vale la pena notare come sia lo stesso principio che avevamo incontrato parlando di agente come utenza privilegiata, ma applicato un livello più in basso: non al badge dell'agente, alla serratura della porta.

Il GDPR chiedeva già questo

Chi si occupa di protezione dei dati avrà riconosciuto il discorso: non è una novità dell'era agentica, è l'articolo 5(1)(c) del GDPR — i dati trattati devono essere adeguati, pertinenti e limitati a quanto necessario — e l'articolo 25, protezione dei dati fin dalla progettazione e per impostazione predefinita.

Un agente che si collega con un service account onnipotente e riceve l'intera tabella clienti per rispondere a una domanda su un singolo ordine viola la minimizzazione, indipendentemente da come si comporta poi. Il masking dei campi speciali e la row-level security non sono compliance aggiuntiva da mettere sopra al progetto: sono la misura tecnica che l'articolo 25 chiede, applicata nel punto in cui è verificabile. Nel linguaggio dell'articolo 32, la pseudonimizzazione è citata per nome fra le misure adeguate. Chi imposta bene i controlli sul dato non sta facendo due lavori: ne sta facendo uno che vale per la sicurezza e per l'accountability.

Cinque mosse per lunedì mattina

Inventario: quali datastore toccano gli agenti, con quali credenziali. Nella maggior parte dei casi la lista è più lunga di quanto si ricordi.
Row-level security attiva sui datastore agentici, non solo su quelli con utenti umani davanti.
Masking per default su identificativi diretti e categorie particolari (art. 9): si sblocca il campo quando serve davvero, non il contrario.
Niente service account condivisi fra agenti: identità propagata dell'utente, o almeno un'identità per agente con il suo profilo di accesso.
Audit al livello del dato: quale agente ha letto cosa, per conto di chi, quando. È l'unica traccia che regge se un giorno bisogna ricostruire un incidente.

Le tre lezioni della serie

Chiudendo il cerchio: l'agente AI è un'utenza privilegiata, e come tale va identificato, autorizzato e revocato. Il rischio agentico si legge come un triangolo — dati privati, contenuto non fidato, canale di uscita — e la difesa consiste nello spezzarne un lato. E quando il comportamento dell'agente non è garantibile, il permesso deve vivere nel dato.

Il filo comune è che nessuna delle tre è una misura sul modello. Sono tutte e tre misure sull'architettura, verificabili a tavolino, indipendenti da quale LLM ci sarà sotto fra sei mesi. È una buona notizia: significa che la sicurezza agentica non richiede di inseguire lo stato dell'arte dell'AI, ma di applicare bene cose che sappiamo già fare.