Governance degli agenti di intelligenza artificiale: un quadro di riferimento per i team aziendali

Introduzione

In breve: la governance degli agenti IA è l’insieme dei controlli relativi a identità, politiche, monitoraggio e audit che mantengono gli agenti autonomi entro limiti di sicurezza. La governance IT tradizionale è stata concepita per software che seguono regole fisse, quindi non tiene conto del modo in cui gli agenti decidono, richiamano strumenti e accedono ai dati in modo autonomo. Questa guida illustra cos’è la governance degli agenti, i rischi che affronta e un quadro di riferimento che è possibile implementare prima che gli agenti vengano integrati nei flussi di lavoro critici.

Un agente di IA è in grado di leggere un ticket, interrogare tre sistemi interni, redigere una risposta e aggiornare un record senza che un essere umano intervenga in nessuna fase. È proprio questa autonomia il punto fondamentale. Ed è anche il motivo per cui la maggior parte dei controlli di governance esistenti non è adeguata. Le regole di accesso presuppongono che dietro ogni azione ci sia una persona, mentre i registri di audit presuppongono che sia possibile ricondurre quell’azione alla persona responsabile. Gli agenti smentiscono entrambe queste ipotesi.

La governance degli agenti IA colma questa lacuna. Assegna a ogni agente una propria identità, stabilisce cosa ciascuno è autorizzato a fare, monitora ciò che effettivamente fa e registra dettagli sufficienti per rispondere a eventuali domande in un secondo momento. Esamineremo come ciò si concretizza nella pratica, i rischi specifici che deve coprire e il nostro approccio in merito presso TrueFoundry.

Che cos’è la governance degli agenti di IA?

La governance degli agenti di IA è la disciplina che controlla come gli agenti autonomi effettuano l’autenticazione, a quali strumenti e dati possono accedere e come le loro azioni vengono monitorate e registrate. Considera un agente come un soggetto a sé stante, non come un’estensione della persona che lo ha implementato.

La distinzione è importante perché gli agenti compiono scelte indipendenti. Un agente di database potrebbe disporre di credenziali di lettura, ma la vera domanda è se debba interrogare una tabella contenente i record dei clienti per una determinata richiesta. La governance è ciò che risponde a questa domanda nel momento stesso in cui viene effettuata la richiesta, piuttosto che durante una revisione settimane dopo. Senza di essa, i team finiscono per fidarsi che un agente rimanga entro i limiti perché finora non è andato storto nulla.

Una buona governance deve anche essere pratica. Se i controlli rendono gli agenti lenti o difficili da implementare, i team li aggirano, e ci si ritrova con agenti non gestiti e una politica di governance che esiste solo sulla carta.

Perché il controllo degli accessi tradizionale non è sufficiente per gli agenti

Il controllo degli accessi standard assegna autorizzazioni agli utenti e registra le azioni relative agli account utente. Gli agenti rendono meno chiaro quel modello in tre modi.

L’attribuzione diventa poco chiara. Quando un agente agisce, il registro di solito mostra un account di servizio, non la persona che ha avviato la richiesta o la catena di ragionamenti che ha portato all’azione. Se qualcosa va storto, è possibile vedere che è stata eseguita una query, ma non perché o per conto di chi.

L’accesso agli strumenti si espande a dismisura. Un singolo agente può accedere a decine di strumenti e fonti di dati, ciascuno con il proprio modello di autorizzazioni. Questa superficie di esposizione cresce più rapidamente di quanto qualsiasi processo manuale di definizione delle politiche possa tenere traccia, e le lacune sono proprio il luogo in cui si verificano gli incidenti.

Il comportamento subisce variazioni. Il software tradizionale restituisce lo stesso risultato per lo stesso input. Gli agenti no. Le loro risposte variano in base alla cronologia delle conversazioni, al contesto e alle modifiche al modello sottostante, quindi un controllo che era sicuro il mese scorso può comportarsi in modo diverso oggi.

Nessuno di questi è un caso limite. Si tratta delle normali condizioni operative degli agenti, motivo per cui la governance deve essere progettata appositamente per loro, anziché essere mutuata da sistemi più datati.

I quattro pilastri di un quadro di governance degli agenti

Un quadro funzionale si basa su quattro elementi che si rafforzano a vicenda.

L’identità viene prima di tutto. Ogni agente ha bisogno di una propria identità con autorizzazioni circoscritte, separata dalle persone che lo creano o lo invocano. È questo che rende possibile tutto il resto, perché non è possibile applicare o verificare nulla se non si è in grado di distinguere gli agenti l’uno dall’altro.

L’applicazione delle politiche deve avvenire in fase di esecuzione. La differenza tra monitoraggio e governance sta nel fatto che il sistema sia in grado di bloccare un’azione non autorizzata prima che venga eseguita, non solo di segnalarla a posteriori. Un agente in sola lettura non dovrebbe essere in grado di scrivere, non solo essere segnalato per averci provato.

L’osservabilità offre una visibilità in tempo reale su ciò che stanno facendo gli agenti. È importante individuare anomalie, violazioni delle politiche e operazioni rischiose nel momento stesso in cui si verificano, in modo da poter reagire ai segnali piuttosto che ricostruire gli eventi a partire da log incompleti.

La registrazione di audit cattura la traccia decisionale. Ogni chiamata allo strumento, ogni accesso ai dati e ogni risposta dovrebbe essere registrata con attribuzione e contesto, in una forma che si possa consegnare a un revisore o a un responsabile della risposta agli incidenti. Questa è la differenza tra affermare che un agente si è comportato correttamente ed essere in grado di dimostrarlo.

I rischi legati agli agenti di IA e come ridurli

Gli agenti introducono rischi che la sicurezza delle applicazioni tradizionale non copre completamente. La gestione dei rischi legati agli agenti basati sull’IA inizia con la loro identificazione.

L’iniezione di prompt è il rischio principale. Un input dannoso nascosto nei contenuti dell’utente o in una fonte di dati esterna può indurre un agente a divulgare dati o a compiere azioni che non avrebbe mai dovuto compiere. Gli agenti che elaborano contenuti non attendibili sono i più esposti.

L’esposizione delle credenziali segue a ruota. Gli agenti che detengono chiavi API o token possono divulgarli negli output o nei log, a meno che tali valori non vengano rilevati e mascherati durante il percorso.

La fuga di dati personali (PII) avviene in modo silenzioso. I dati dei clienti che transitano attraverso un agente possono emergere in un log di conversazione, in un messaggio di errore o in una chiamata a valle, senza che nessuno abbia deciso che ciò dovesse accadere.

L’eccessiva autonomia è il rischio di concedere a un agente più di quanto gli serva. Un agente di codice con accesso in scrittura ai repository di produzione comporta un rischio che l’accesso in sola lettura eliminerebbe completamente. La soluzione sta nell’ambito di applicazione: concedere il minimo necessario a ciascun agente, e nulla di più.

La riduzione di questi rischi richiede una combinazione di controlli. Ispezionate gli input e gli output alla ricerca di credenziali, PII e contenuti proibiti prima che superino un confine. Inserite in una lista di autorizzazioni gli strumenti specifici che ogni agente può richiamare, anziché consentire l’accesso per impostazione predefinita. Impostate soglie di escalation in modo che le decisioni a rischio più elevato vengano indirizzate a un operatore umano e regolate tali soglie in base a ciò che osservate effettivamente in produzione.

Identità per singolo agente e credenziali con ambito limitato

Gli account di servizio condivisi sono la scorciatoia più comune e causano i problemi maggiori. Quando diversi agenti condividono un unico set di credenziali, si perde la capacità di distinguere quale agente abbia compiuto quale azione. Una compromissione di quell’account influisce su ogni agente che lo utilizza, non solo su quello che è stato violato. Inoltre, ogni agente eredita l’intero set di autorizzazioni dell’account condiviso invece di un ambito adeguato al proprio ruolo.

L’identità per singolo agente risolve tutti e tre i problemi. Ogni agente distribuito dispone delle proprie credenziali, che possono essere ruotate e revocate autonomamente, di permessi che riflettono il suo scopo e di una traccia di audit chiara. Questo è anche l’antidoto alla proliferazione incontrollata degli agenti, ovvero la situazione in cui i team creano agenti più velocemente di quanto chiunque riesca a tenerne traccia. Quando ogni agente ha un’identità registrata, la proliferazione diventa visibile anziché invisibile, e può essere gestita.

La gestione delle identità per gli agenti richiede astrazioni diverse rispetto alla gestione degli utenti. Gli agenti necessitano di identità persistenti che sopravvivano a una singola sessione, credenziali che possano essere aggiornate in modo indipendente e ambiti legati a ciò che l’agente fa piuttosto che a chi lo ha creato.

Conformità e preparazione all’audit

La normativa si sta adeguando ai sistemi autonomi, e standard come SOC 2, HIPAA e GDPR impongono già obblighi che le implementazioni degli agenti devono soddisfare. Il requisito pratico è un’infrastruttura in grado di produrre prove autonomamente, anziché una documentazione assemblata manualmente da qualcuno prima di un audit.

Ciò significa tracciati di audit completi, in cui ogni azione dell’agente sia registrata insieme all’attribuzione, al timestamp e al contesto. Significa registrazioni immutabili che non possono essere modificate a posteriori. Significa una conservazione dei dati conforme alle norme relative ai tipi di record e alle giurisdizioni di riferimento, nonché la possibilità di esportare i log negli strumenti di sicurezza già utilizzati dal proprio team.

Per i team soggetti a regolamentazione, il luogo in cui gli agenti vengono eseguiti è importante tanto quanto il modo in cui vengono governati. L’esecuzione degli agenti all’interno del proprio VPC, on-premise o in un ambiente air-gapped mantiene i dati sensibili all’interno dei propri confini, applicando al contempo gli stessi controlli relativi a identità, policy e registrazione.

L’approccio di TrueFoundry alla governance degli agenti

Abbiamo costruito la nostra piattaforma in modo che la governance sia parte integrante del funzionamento degli agenti, non un livello aggiunto in un secondo momento. L’Agent Gateway assegna a ciascun agente una propria identità con credenziali limitate e a rotazione, in modo che le azioni siano attribuibili e le autorizzazioni corrispondano al ruolo dell’agente piuttosto che all’accesso del suo creatore.

L’accesso agli strumenti avviene attraverso lo stesso piano di controllo. Gli agenti raggiungono strumenti e dati tramite MCP con OAuth2, RBAC e politiche sui metadati applicate a ogni chiamata agli strumenti, il che consente di autorizzare una lettura del database bloccando al contempo una scrittura. I sistemi di protezione ispezionano le richieste e le risposte alla ricerca di informazioni personali identificabili (PII) e altri contenuti proibiti sia nel percorso di input che in quello di output, e ogni chiamata viene registrata a fini di osservabilità e audit. Poiché la piattaforma opera nella vostra VPC, in ambiente on-premise o in un ambiente air-gapped con supporto SOC 2, HIPAA e GDPR, i controlli di governance sono validi ovunque vengano eseguiti i vostri agenti.

Il risultato è che identità, policy di runtime, monitoraggio e audit provengono da un unico punto anziché da quattro strumenti scollegati tra loro: è proprio questo che garantisce la coesione del framework su larga scala.

Costruire la pratica attorno alla tecnologia

I controlli funzionano solo quando l’organizzazione li sostiene. I team che considerano la governance un ostacolo troveranno il modo di aggirarla, quindi l’obiettivo è rendere il percorso regolamentato il percorso più semplice.

Un'implementazione graduale tende a funzionare: individuare gli agenti già in esecuzione, assegnare loro delle identità, attivare il monitoraggio, quindi automatizzare la documentazione di conformità. I tempi dipendono dalla complessità del vostro ambiente e dalle normative applicabili. Parallelamente, un gruppo interfunzionale che comprenda i reparti di ingegneria della piattaforma, legale, conformità e operazioni dovrebbe essere responsabile delle decisioni relative alle politiche e gestire i casi nuovi non coperti dalle politiche esistenti. La formazione completa il quadro, in modo che chi sviluppa gli agenti comprenda il modello di autorizzazioni e sappia come applicare le misure di protezione ai propri casi d’uso.

Domande frequenti

Che cos’è la governance degli agenti di IA?

La governance degli agenti di IA è l’insieme dei controlli che regolano le modalità di autenticazione degli agenti autonomi, gli strumenti e i dati a cui possono accedere e le modalità di monitoraggio e verifica delle loro azioni. Considera ogni agente come un soggetto a sé stante con autorizzazioni circoscritte, anziché consentire agli agenti di ereditare l’accesso della persona che li ha distribuiti.

In che modo la gestione dei rischi legati all’IA agentica differisce dalla normale sicurezza delle applicazioni?

Aggiunge rischi che la sicurezza standard non affronta pienamente, tra cui l’iniezione di prompt, la fuga di credenziali attraverso gli output degli agenti, l’esposizione di informazioni personali identificabili (PII) nei log delle conversazioni e un’eccessiva autonomia derivante da autorizzazioni troppo ampie. La gestione di questi aspetti richiede l’ispezione degli input e degli output in fase di esecuzione, l’inserimento in liste di autorizzazione a livello di strumento e la definizione di un ambito di autorizzazioni basato sul principio del privilegio minimo per ciascun agente.

Perché l’identità per singolo agente è importante?

Gli account di servizio condivisi rendono impossibile stabilire quale agente abbia eseguito un’azione, ampliano il raggio d’azione in caso di compromissione delle credenziali e conferiscono a ogni agente più accesso di quanto ne abbia bisogno. L’identità per singolo agente fornisce a ciascuno le proprie credenziali a rotazione, un’attribuzione chiara e un ambito che corrisponde al suo scopo.

Posso gestire la governance degli agenti nella mia VPC o in locale?

Sì. TrueFoundry funziona nella vostra VPC, in locale, in un ambiente air-gapped o su più cloud, quindi nessun dato esce dal vostro dominio. Gli stessi controlli relativi a identità, politiche e audit si applicano ovunque gli agenti siano in esecuzione: ecco perché i team soggetti a normative scelgono un modello self-hosted piuttosto che un gateway esclusivamente SaaS.

È supportato SOC 2, HIPAA e GDPR?

TrueFoundry supporta gli standard SOC 2, HIPAA e GDPR, con RBAC, SSO e registrazione di audit immutabile integrati. È proprio questa combinazione a rendere le distribuzioni degli agenti pronte per l’audit, anziché costringervi a documentarle in fretta e furia prima di una revisione.

Conclusione

La governance degli agenti IA è ciò che distingue gli agenti scalabili da quelli su cui si può solo sperare. Il quadro di riferimento non è complicato in linea di principio: assegnare un’identità a ogni agente, applicare le politiche nel momento dell’azione, monitorare le azioni degli agenti e conservare una documentazione su cui poter fare affidamento. La difficoltà sta nel riuscire a fare tutte e quattro le cose contemporaneamente, per ogni singolo agente, senza rallentare il lavoro dei team. È proprio questo il livello di controllo che ci siamo prefissati di fornire. Scopri come l’AI Gateway di TrueFoundry riunisce identità, politiche e monitoraggio in un unico piano di controllo regolamentato per i tuoi agenti.