In un articolo precedente abbiamo affrontato le fondamenta della governance dell’AI: sovranità del dato, API governance, il ruolo degli MCP Server come nuovo livello attraverso cui i modelli incontrano l’infrastruttura. La domanda con cui chiudevamo era netta: siamo in grado di governare ciò che stiamo per abilitare?
Supponiamo di aver risposto sì al livello dell’infrastruttura, con gli MCP censiti, le API presidiate e l’agente tecnicamente in grado di operare. Resta il livello più sottile e più pericoloso, quello che nessun inventario di API cattura da solo: il runtime, cioè cosa succede, richiesta per richiesta, tra il momento in cui una persona scrive un comando all’agente e il momento in cui quel comando diventa un’azione su un sistema reale.
L’unità da autorizzare non è più l’API, è il prompt
Nell’IT tradizionale l’autorizzazione è statica e prevedibile. Un utente ha un ruolo, quel ruolo abilita certe chiamate API e la logica è cablata, con richieste note in anticipo. Con un agente AI questo modello salta perché l’utente non invoca un’API, scrive in linguaggio naturale: “fammi vedere gli alert di oggi”, “isola quel server, sembra compromesso”, “resetta la password di questo utente”. È l’agente a tradurre l’intenzione in una o più operazioni concrete. Il controllo sulla singola chiamata tecnica resta necessario, ma da solo non basta: va autorizzata anche la richiesta dell’utente, cioè l’operazione che l’agente ne ricava, prima che diventi azione.
Governare l’AI agentica significa allora inserire, tra il prompt e l’esecuzione, un punto di decisione che risponda a una domanda precisa: questo utente, con questi ruoli, ha il diritto di chiedere proprio questo?
Tre principi per un controllo solido
La policy deve vivere fuori dall’agente. La decisione di accesso non va scritta nel prompt di sistema né affidata al buon senso del modello, perché sarebbe come chiedere alla serratura di decidere chi ha la chiave. Va delegata a un motore di policy esterno e verificabile, per esempio Open Policy Agent, che mappa ogni operazione ai ruoli che la abilitano: l’agente non giudica, interroga. La verifica si applica all’operazione che l’agente intende eseguire, nel momento in cui la chiamata allo strumento sta per partire.
La decisione, inoltre, non può essere binaria. Consenti e nega non bastano: le operazioni ad alto impatto, come isolare un host, cancellare o modificare identità, richiedono un terzo stato, consenti ma con approvazione. È il punto in cui la governance smette di essere un filtro e diventa un processo. Infine, il prompt stesso può essere ostile. Prima ancora di chiedersi se l’utente è autorizzato, bisogna chiedersi se la richiesta è genuina: la prompt injection, cioè istruzioni malevole nascoste nel testo per dirottare l’agente, è il vettore d’attacco nativo di questi sistemi, catalogato in framework dedicati come MITRE ATLAS e la OWASP Top 10 per le applicazioni LLM. Le istruzioni ostili non arrivano solo dall’utente: possono essere nascoste nei dati che l’agente legge mentre lavora, come un log, un alert o un’email (prompt injection indiretta). Per questo un controllo che ispeziona sia il prompt in ingresso sia i contenuti restituiti dagli strumenti è parte integrante dell’autorizzazione, non un accessorio.
Autorizzare il prompt significa trattare ogni singola richiesta in linguaggio naturale come una decisione di sicurezza a sé stante, ispezionata e valutata contro policy esplicite, e non come un semplice testo da dare in pasto al modello.
A nome di chi: l’agente agisce per delega
Superato il controllo sul cosa, resta la domanda sul chi, ed è qui che si gioca la parte più delicata della governance agentica. Quando l’agente deve eseguire l’operazione autorizzata su un sistema a valle, per esempio interrogare il SIEM o chiamare l’MCP che espone le funzioni di un prodotto, ha due strade davanti.
La strada più comoda è che l’agente usi una propria credenziale di servizio e agisca con la sua identità. Funziona subito, ed è per questo la più diffusa, ma è anche un buco nero di responsabilità: sul sistema di destinazione ogni operazione risulterà compiuta dall’agente, l’utente reale sparisce dai log, i permessi applicati sono quelli, potenzialmente amplissimi, dell’agente, e la non ripudiabilità svanisce. In caso di incidente o di audit, alla domanda “chi ha isolato quel server?” la risposta sarebbe: un software. Una condizione inaccettabile sul piano della sicurezza e su quello della conformità.
La strada corretta è diversa: l’agente non si sostituisce all’utente, ne propaga l’identità. Non accede direttamente all’MCP con un token proprio, ma prende il token dell’utente autenticato e, attraverso un flusso standard come l’OAuth 2.0 Token Exchange definito dalla RFC 8693, chiede all’identity provider di scambiarlo con un token valido per il sistema di destinazione, sempre intestato all’utente e limitato ai permessi necessari per quell’operazione. L’agente si presenta all’MCP a nome della persona, non a nome proprio. Nel token resta comunque traccia di chi agisce per suo conto: la RFC prevede un campo apposito, il claim act, che identifica l’agente.
Le conseguenze sono concrete e vanno tutte nella direzione della governance. Sul sistema a valle l’operazione risulta compiuta per conto della persona reale, entro i suoi ruoli e la sua visibilità, non con i privilegi dell’agente. Il sistema di destinazione non si fida ciecamente, ma ri-verifica firma, emittente e destinatario del token prima di eseguire, così la delega è provata a ogni passaggio, non dichiarata. E la catena di responsabilità resta intera e dimostrabile, dall’utente che ha scritto il prompt fino all’azione finale, con l’agente registrato come tramite.
È la differenza tra un agente che diventa un super-utente onnipotente e un agente che resta un tramite fedele del diritto di chi lo usa. Non è un dettaglio implementativo, è il cuore della governance dell’identità agentica.
Propagare l’identità non basta però a fermare un agente dirottato da una prompt injection, che agirebbe comunque con i diritti dell’utente. Per questo servono permessi ristretti nel token e l’approvazione umana sulle azioni critiche.
Dalla decisione alla governance: approvazione, tracciabilità, controllo umano
Autorizzare il prompt e propagare l’identità sono i due pilastri, ma una governance matura chiude il cerchio con altri due elementi. Il primo è il controllo umano sulle azioni critiche: un agente non dovrebbe mai isolare un server o modificare le identità di un altro utente in totale autonomia. Un flusso approvativo a quattro occhi, in cui chi richiede è diverso da chi approva, reintroduce la supervisione umana esattamente dove serve, senza rallentare le operazioni ordinarie. È il terzo stato “consenti con approvazione” che diventa processo.
Il secondo è la tracciabilità end to end. Ogni passo, dal prompt alla decisione di policy, dallo scambio di token alla chiamata fino all’eventuale approvazione, va registrato in un log immutabile (append-only) e osservabile, con l’attribuzione all’utente reale e all’agente che ha agito per suo conto. Non è burocrazia: è l’unica cosa che, a incidente avvenuto, permette di ricostruire chi ha chiesto cosa, chi ha autorizzato e cosa è stato eseguito.
Perché è anche conformità, non solo buona ingegneria
Questi controlli non vivono nel vuoto, ma intercettano direttamente il quadro normativo. L’AI Act europeo, per i sistemi ad alto rischio, richiede sorveglianza umana effettiva all’articolo 14 e registrazione degli eventi con tracciabilità all’articolo 12: il flusso a quattro occhi e il log immutabile sono un modo concreto di rispondere a questi requisiti, e restano una buona pratica anche per gli agenti che non rientrano nell’alto rischio. La ISO/IEC 42001, primo standard per i sistemi di gestione dell’intelligenza artificiale, chiede governance e controlli documentabili. La NIS 2 impone ai soggetti essenziali e importanti misure di gestione del rischio, tra cui il controllo degli accessi, che valgono anche quando ad accedere ai sistemi è un agente, e ne attribuisce la responsabilità agli organi di amministrazione e direttivi. Per un quadro più ampio sugli obblighi che ne derivano, abbiamo approfondito il tema nell’articolo sulla conformità dei sistemi AI dopo il Digital Omnibus.
In sintesi, autorizzare cosa chiede l’utente e garantire a nome di chi agisce l’agente non è un raffinamento tecnico opzionale, è ciò che rende un sistema agentico difendibile davanti a un attaccante e davanti a un auditor.
L’approccio di Key Partner
In Key Partner affianchiamo le organizzazioni nel governare l’identità agentica al livello che conta davvero, quello del runtime: autorizzazione della singola richiesta contro policy esplicite e disaccoppiate, delega dell’identità dell’utente lungo l’intera catena tramite standard consolidati, controllo umano sulle azioni ad alto impatto e tracciabilità completa a supporto degli obblighi di AI Act, ISO 42001 e NIS 2.
Non si tratta di un livello di sicurezza applicato a valle, ma di un’infrastruttura di identità e autorizzazione pensata perché ogni agente faccia esattamente ciò che chi lo usa ha il diritto di chiedere, né più né meno, e perché di ogni azione resti una prova riconducibile alla persona reale.
Domande frequenti sulla governance dell’identità agentica
Perché non basta autorizzare l’agente AI a livello di API?
Perché l’utente non chiama più un’API con parametri noti in anticipo, ma scrive una richiesta in linguaggio naturale che l’agente traduce in azioni. Il controllo sulle API resta necessario, ma va affiancato da un’autorizzazione sulla richiesta e sull’operazione che l’agente ne ricava.
Cosa cambia se l’agente usa una propria credenziale invece di propagare quella dell’utente?
Con una credenziale propria dell’agente, sui sistemi a valle ogni operazione risulta compiuta dal software e non dalla persona che l’ha richiesta. Si perde la non ripudiabilità e, in caso di incidente o audit, non è più possibile risalire a chi ha effettivamente chiesto l’azione.
Che ruolo hanno l’AI Act e la ISO/IEC 42001 in questo tipo di governance?
L’AI Act richiede sorveglianza umana effettiva e registrazione tracciabile degli eventi per i sistemi ad alto rischio, mentre la ISO/IEC 42001 chiede controlli documentabili sui sistemi AI. Il flusso di approvazione a quattro occhi e l’audit trail end to end sono un modo concreto di rispondere a questi obblighi.
