La revisione degli accessi di un agente AI è una decisione periodica e firmata su quali diritti ogni agente debba mantenere, perdere o modificare. Le banche applicano già questo ciclo alle persone: estraggono ogni autorizzazione, inviano ciascuna riga a un revisore responsabile, registrano la conferma o la revoca, rimuovono quanto revocato e conservano le prove. Gli agenti richiedono lo stesso ciclo con una voce più ampia. Un diritto di un agente comprende lo strumento, l’azione, l’importo, i dati, l’ambiente, il controllo di approvazione che precede l’azione e la data in cui il diritto termina.
Questa guida spiega come condurre la campagna. La guida ai permessi degli agenti AI spiega come progettare i diritti e la guida al controllo degli accessi copre il modello operativo dall’identità alla revoca. Questo articolo parte da diritti già concessi e spiega come un revisore certifica l’autorizzazione di ogni agente AI. Informazioni di carattere generale, aggiornate al 23 ottobre 2026; non sostituiscono la consulenza legale o di audit.
Cosa certifica il revisore
Una revisione degli accessi degli utenti chiede se una persona abbia ancora bisogno di un ruolo. La revisione di un agente pone una domanda più lunga: questo agente ha ancora bisogno di ogni azione che può compiere, con questo limite, su questi dati, con questo controllo di approvazione, sotto questo responsabile e fino a questa data? Il nome di un ruolo raramente risponde. Due agenti con lo stesso ruolo possono avere strumenti, limiti di importo ed eccezioni diversi.
Certificate l’autorità effettiva, cioè i diritti che l’agente può esercitare oggi. Confrontate quattro viste di ciascun diritto: ciò che il responsabile ha chiesto, ciò che è stato approvato, ciò che è configurato nell’identity provider, nel gateway degli strumenti e nella policy, e ciò che l’agente ha usato nel periodo di revisione. Un diritto approvato e configurato ma mai usato è un candidato alla rimozione. Un diritto usato senza approvazione è un rilievo.
| Campo | Cosa vede il revisore | Domanda a cui rispondere |
|---|---|---|
| Agente e Release | Nome dell’agente, identificativo in Agent Registry, Release corrente, responsabile | Il responsabile è ancora in carica e ancora responsabile? |
| Azione | Strumento e operazione, ad esempio payments.create_transfer | Il processo di business ha ancora bisogno di questa azione? |
| Limite | Importo per azione e per giorno, regole sulle destinazioni, limite di frequenza | È il limite più basso che consente al processo di funzionare? |
| Data Boundary | Sistemi, campi, regioni e finalità che l’agente può leggere o scrivere | L’agente legge qualcosa che non usa più? |
| Controllo di approvazione | La regola di policy che restituisce require_approval e il ruolo del revisore a cui instrada | Il controllo è ancora attivo e il ruolo è ancora corretto? |
| Credenziale | Identità, token o segreto, emittente, durata, ultimo utilizzo | La credenziale è limitata a questo agente ed è ancora necessaria? |
| Utilizzo nel periodo | Numero di azioni consentite, con avviso, approvate, respinte e bloccate | L’uso osservato corrisponde alla finalità dichiarata? |
| Data di fine | Scadenza del mandato o dell’eccezione | Il diritto dovrebbe terminare prima del previsto? |
Adottate il ciclo di ricertificazione bancario
Una campagna di ricertificazione ha una popolazione fissa, una data di riferimento fissa, revisori nominati, una scadenza e una fase di correzione che qualcuno verifica. Mantenete questa struttura. Cambiate la voce e aggiungete due test che le revisioni delle persone richiedono di rado: la prova che il controllo di approvazione instrada ancora l’azione e la prova che la revoca ferma l’azione successiva.
| Fase | Attività | Risultato |
|---|---|---|
| 1. Perimetro | Fissate la data di riferimento. Riconciliate Agent Registry con identity provider, vault dei segreti, gateway degli strumenti, registrazioni dei server MCP e log di esecuzione, così che la popolazione includa gli agenti che nessuno ha registrato. | Elenco della popolazione con la fonte di ogni voce e gli agenti trovati fuori dal registro |
| 2. Estrazione | Esportate i diritti effettivi di ogni agente come voci, con l’utilizzo nel periodo di revisione. | Estrazione firmata o con hash, con l’ora di generazione |
| 3. Assegnazione | Inviate ogni agente al suo responsabile. Inviate i diritti privilegiati e le eccezioni a un secondo revisore esterno al team proprietario. | Assegnazione dei revisori con verifica dei conflitti |
| 4. Decisione | Per ogni riga: confermare, modificare, revocare o registrare un’eccezione con data di fine. | Una decisione, un motivo, un revisore e un orario per riga |
| 5. Correzione | Applicate ogni modifica e revoca nel sistema che detiene il diritto. | Ricevuta della modifica per riga, collegata alla decisione |
| 6. Verifica | Ripetete l’estrazione e confrontate. Tentate un’azione revocata per agente in un ambiente di test o tramite una simulazione della policy. | Confronto di chiusura e un tentativo negato per ogni diritto revocato |
| 7. Chiusura | Il responsabile della campagna registra perimetro, tasso di completamento, voci scadute, rilievi e limitazioni. | Registro della campagna pronto per l’audit interno |
Fissate la frequenza in base al rischio e agli eventi
Per le entità finanziarie dell’UE soggette a DORA, la norma sulla gestione dei rischi informatici fissa una soglia minima. L’articolo 21, paragrafo 1, lettera e), del Regolamento delegato (UE) 2024/1774 della Commissione richiede procedure di gestione degli account che assegnino ruoli e responsabilità per concedere, riesaminare e revocare i diritti di accesso, che ritirino i diritti senza indebito ritardo quando non sono più necessari e che ne prevedano l’aggiornamento quando necessario e almeno una volta l’anno per i sistemi di TIC, e almeno ogni sei mesi per quelli che supportano funzioni essenziali o importanti. L’articolo 21, paragrafo 1, lettera a), richiede che i diritti seguano i principi della necessità di sapere, della necessità d’uso e del privilegio minimo, e la lettera c) richiede che gli utenti siano sempre identificabili per le azioni compiute nei sistemi di TIC.
Il regolamento riguarda i diritti di accesso agli asset di TIC in generale e non menziona gli agenti AI. Un agente che detiene credenziali per un sistema di TIC a supporto di una funzione essenziale o importante detiene diritti di accesso a quel sistema. Chiedete alla funzione compliance se la soglia dei sei mesi si applica. Molti team riesaminano gli agenti più spesso delle persone, perché un agente può usare un diritto migliaia di volte tra una campagna e l’altra.
| Profilo dell’agente | Revisione programmata | Evento che fa scattare una revisione immediata |
|---|---|---|
| Muove denaro, modifica dati dei clienti o invia comunicazioni esterne | Trimestrale | Nuovo strumento, limite più alto, nuova Release, cambio di responsabile, incidente o un andamento di azioni bloccate |
| Supporta una funzione essenziale o importante senza accesso in scrittura | Ogni sei mesi | Nuova fonte di dati, nuova regione o cambio di finalità |
| Interno, sola lettura, nessun dato personale | Annuale | Qualsiasi richiesta di accesso in scrittura |
Fate in modo che ogni decisione cambi qualcosa
Una revisione che raccoglie solo approvazioni dimostra poco. Ogni decisione deve lasciare traccia nella configurazione o in un registro delle eccezioni datato.
| Decisione | Azione conseguente | Prove |
|---|---|---|
| Confermare | Nessuna modifica. Il diritto mantiene la data di fine attuale. | Revisore, orario, motivo e la riga dell’estrazione confermata |
| Modificare | Ridurre un limite, restringere un Data Boundary, anticipare una data di fine o aggiungere un controllo di approvazione. | Valori prima e dopo, ricevuta della modifica, versione della policy |
| Revocare | Rimuovere il diritto nel sistema che lo detiene e revocare ogni credenziale che serviva solo a esso. | Ricevuta della modifica e un tentativo negato dopo la rimozione |
| Eccezione | Mantenere un diritto che viola una regola, con un controllo compensativo e una data di fine non successiva alla campagna seguente. | Titolare dell’eccezione, approvatore, controllo compensativo, scadenza |
| Nessuna risposta entro la scadenza | Escalare al superiore del responsabile. La vostra policy decide se sospendere il diritto alla scadenza finale. | Storico dell’escalation e stato finale del diritto |
Test che rilevano ciò che una firma non vede
Eseguite questi test sull’estrazione prima che i revisori la vedano e mostrate i risultati sulla voce. Trasformano un giudizio soggettivo in un rilievo con un numero.
- Diritto inutilizzato: concesso per tutto il periodo e mai esercitato. Proponete la revoca come impostazione predefinita e chiedete al responsabile di giustificarne il mantenimento.
- Uso non approvato: l’agente ha esercitato un diritto senza registro di approvazione. Aprite un rilievo prima di chiudere la campagna.
- Combinazione incompatibile: lo stesso agente può creare un beneficiario e rilasciare un pagamento, oppure redigere e approvare. Separate i diritti o affidate uno dei due lati a un ruolo umano diverso.
- Controllo mancante: una modifica della policy dall’ultima campagna ha eliminato o indebolito una regola require_approval. Confrontate le versioni della policy riga per riga.
- Autorevisione: il revisore è chi ha richiesto il diritto o chi sponsorizza l’agente. Riassegnate.
- Responsabile assente: il responsabile ha lasciato l’incarico o ha cambiato ruolo. Sospendete i nuovi diritti finché un nuovo responsabile non accetta.
- Credenziale condivisa: un unico segreto serve più agenti. L’uso non può essere attribuito, quindi la riga non può essere certificata.
- Eccezione scaduta ancora attiva: la data di fine dell’eccezione è passata e il diritto funziona ancora.
Esempio svolto: revisione trimestrale di un agente per i pagamenti
L’agente, le cifre e le identità che seguono sono sintetici. Un agente delle operazioni di tesoreria prepara e rilascia i pagamenti ai fornitori. Il periodo di revisione va dal 1° luglio al 30 settembre 2026. Il responsabile è il capo delle operazioni di tesoreria; le righe privilegiate vanno a un secondo revisore del rischio operativo.
| Voce | Osservato nel periodo | Decisione | Azione conseguente |
|---|---|---|---|
| payments.create_transfer fino a 50.000 EUR verso beneficiari esistenti | 1.412 azioni consentite, 0 bloccate | Confermare | Nessuna |
| payments.create_transfer oltre 50.000 EUR, con require_approval verso un verificatore di tesoreria | 37 richieste di approvazione: 35 approvate, 2 respinte | Confermare | Nessuna; controllo confermato nella versione corrente della policy |
| beneficiaries.create | 3 utilizzi, tutti per un progetto di onboarding fornitori concluso ad agosto | Revocare | Diritto rimosso; il tentativo in test ha restituito block |
| erp.read_invoices su tutte le controllate | Letture su due controllate su cinque | Modificare | Data Boundary ristretto alle due controllate |
| Eccezione: rilascio dei trasferimenti infragruppo prima della nuova verifica sulle sanzioni | Concessa a giugno con data di fine 30 settembre 2026 | Eccezione scaduta | Eccezione chiusa; il diritto segue ora la regola standard |
| Chiave API condivisa con l’agente di riconciliazione | L’uso non è separabile per agente | Rilievo | Nuova credenziale per agente emessa; chiave condivisa revocata |
Dove si colloca KLA in una revisione degli accessi
KLA non dispone di un modulo per le campagne di revisione degli accessi. La revisione si svolge nel vostro strumento di identity governance o in una carta di lavoro. KLA Control Plane contiene diversi dati che servono al revisore e applica la decisione di revoca sul percorso delle azioni governate. Questa sezione descrive il codice sorgente attuale.
Gli agenti che agiscono tramite l’ingresso delle azioni degli agenti di KLA operano sotto un mandato dell’agente: un record versionato con un responsabile, un principale istituzionale, strumenti, operazioni e destinazioni consentiti, finalità, ambienti, vincoli sui parametri dell’azione e un periodo di validità con data di fine obbligatoria. Chi crea un mandato non può approvarlo. L’elenco dei mandati di un agente restituisce questo perimetro con le date di validità e gli attori del ciclo di vita, e fornisce al revisore le voci di quel percorso.
La decisione di revoca corrisponde alla revoca del mandato. Solo i ruoli di amministratore del tenant e di compliance officer possono revocare, e il motivo è obbligatorio. La revoca blocca le proposte aperte collegate a quel mandato con il codice motivo mandate_revoked e annulla le relative richieste di decisione in sospeso. L’azione successiva che l’agente propone con un mandato revocato o scaduto viene rifiutata prima di essere registrata come proposta. Un’azione già ammessa può ancora completarsi. Ogni revoca viene scritta in un registro del ciclo di vita del mandato in sola aggiunta, incluso nell’esportazione delle prove.
Ogni azione governata riceve uno di quattro esiti di policy: allow, warn, require_approval o block. Questi esiti forniscono i conteggi di utilizzo della voce. Decision Desk rifiuta le decisioni del richiedente registrato, verifica il ruolo richiesto al revisore e registra la decisione con una nota e i ruoli del revisore in quel momento. I diritti detenuti fuori da KLA, come i gruppi dell’identity provider, i segreti del vault e gli account nei sistemi di destinazione, restano nei rispettivi sistemi e richiedono una propria estrazione.
Una voce certificata regge solo se l’applicazione della policy verifica la stessa identità dell’agente. Ad agosto 2026, scrivendo una regola di approvazione dei pagamenti nel nostro tenant di test, abbiamo scoperto che il perimetro per agente di una policy non era ancora applicato a runtime. Abbiamo modificato la valutazione delle policy perché verifichi a ogni chiamata l’identità dell’agente che agisce e fallisca in modo chiuso quando questa identità manca. Le nostre esecuzioni automatiche di accettazione nei tenant di test usano inoltre due identità, una per avviare un’esecuzione governata e una per decidere le relative richieste di decisione, perché Decision Desk rifiuta la decisione del richiedente e richiede un motivo per ogni decisione.
Fonti primarie
Verifica delle fonti completata il 23 ottobre 2026. Il Regolamento delegato (UE) 2024/1774 della Commissione integra il Regolamento (UE) 2022/2554 (DORA) con norme tecniche di regolamentazione sul quadro per la gestione dei rischi informatici. I riferimenti precedenti provengono dall’articolo 21, «Controllo degli accessi». Il regolamento fissa obblighi per le entità finanziarie soggette a DORA; la tabella delle frequenze, i campi della voce, i test e l’esempio di questa guida sono modelli applicativi privi di valore giuridico. Verificate con la funzione compliance quali funzioni classificate come essenziali o importanti.
Domande frequenti
Che cos’è la revisione degli accessi di un agente AI?
È una campagna periodica in cui un revisore designato decide, per ogni diritto detenuto da un agente, se confermarlo, modificarlo, revocarlo o mantenerlo come eccezione a termine. Il diritto comprende strumento, azione, importo, dati, ambiente, controllo di approvazione, credenziale e data di fine.
Con quale frequenza vanno riesaminati gli accessi di un agente AI?
Fissate la frequenza in base al rischio e aggiungete revisioni legate agli eventi. Per le entità finanziarie dell’UE soggette a DORA, il Regolamento delegato (UE) 2024/1774 richiede di aggiornare i diritti di accesso almeno una volta l’anno, e almeno ogni sei mesi per i sistemi di TIC che supportano funzioni essenziali o importanti. Gli agenti che muovono denaro o modificano dati dei clienti vengono spesso riesaminati ogni trimestre.
Chi deve riesaminare le autorizzazioni di un agente AI?
Il responsabile dell’agente riesamina i diritti ordinari. Un secondo revisore esterno al team proprietario riesamina i diritti privilegiati e le eccezioni. Chi ha richiesto un diritto non deve certificarlo.
Come si verificano e certificano i diritti di accesso di un agente AI?
Riconciliate l’intera popolazione di agenti tra registro, identity provider, segreti, gateway e log. Estraete i diritti effettivi con l’utilizzo del periodo. Inviate ogni riga a un revisore, registrate conferma, modifica, revoca o eccezione, applicate le modifiche, ripetete l’estrazione per verificarle e tentate un’azione revocata per dimostrare che viene negata.
Quali prove si aspetta un auditor da una revisione degli accessi degli agenti?
La popolazione e il modo in cui è stata riconciliata, l’estrazione con l’ora di generazione, le assegnazioni dei revisori, una decisione per riga con motivo e orario, le ricevute di ogni modifica e revoca, il confronto della nuova estrazione, i tentativi negati per i diritti revocati, il registro delle eccezioni e la chiusura della campagna con le sue limitazioni.
In cosa differisce la revisione degli accessi di un agente da quella di un utente?
Il ciclo è lo stesso. La voce è più ampia, perché un diritto di un agente include limiti di importo, perimetro dei dati, il controllo di approvazione che precede l’azione e una data di fine. I dati di utilizzo sono più ricchi, quindi diritti inutilizzati e usi non approvati si possono misurare. Anche la revoca va testata, perché un agente può agire di nuovo in pochi secondi.
Punti chiave
Conducete la campagna sugli agenti con la stessa disciplina che le banche applicano alle persone: una popolazione fissa, un revisore per ogni riga, una decisione che cambia qualcosa, una verifica che la modifica abbia avuto effetto e un registro firmato. Partite dalla checklist di revisione delle autorizzazioni, fate attraversare a un agente ad alto rischio le sette fasi e conservate il registro della campagna per il prossimo audit.