La sicurezza degli AI agent parte dall’identità, ma le aziende hanno bisogno di più delle credenziali

Google News ha portato all’attenzione un avvertimento del 2 settembre sugli AI agent, ma il problema va ben oltre l’ennesima checklist di sicurezza. L’articolo sostiene che le aziende debbano rispondere a tre domande prima che gli agenti si diffondano ulteriormente: dove si trovano, a cosa possono connettersi e cosa possono fare?

Questa impostazione è apparsa in un articolo ospite di GuidePoint Security firmato da Ariel Zommer, product marketer per la sicurezza in Okta. La tesi centrale è semplice. Un agente diventa un problema di identità nel momento in cui può autenticarsi, raggiungere sistemi aziendali o agire senza una costante supervisione umana.

Il tempismo conta. NIST ha pubblicato un avvertimento separato sull’identità il 27 agosto, meno di una settimana prima della pubblicazione dell’articolo di GuidePoint. Anche Microsoft, Okta e altri provider di identità stanno trasformando le identità degli agenti in oggetti di prodotto formali.

Questa convergenza cambia il dibattito aziendale. La domanda centrale non è più se un modello possa produrre una risposta accurata. È se ogni azione risultante abbia un attore visibile, un’autorità limitata, un responsabile e una connessione revocabile.

L’argomento appare familiare perché la gestione delle identità governa già dipendenti, applicazioni e carichi di lavoro tradizionali. Gli agenti complicano questo modello perché le loro azioni sono probabilistiche, le loro connessioni cambiano e una singola richiesta può attivare molte operazioni a valle.

L’identità è quindi necessaria, ma non sufficiente. Una credenziale può identificare un agente senza dimostrare che la sua azione corrente sia sicura. La vera sfida contrappone un’autonomia responsabile a un accesso comodo che le organizzazioni non riescono a tracciare pienamente.

Cosa ha effettivamente portato alla luce Google News

La notizia non riguarda la divulgazione di una nuova vulnerabilità. È un avvertimento coordinato: l’adozione degli agenti sta superando i controlli aziendali sulle identità.

L’argomento originale sull’identità è stato pubblicato da GuidePoint Security il 2 settembre 2026. È stato scritto da un dipendente di Okta e presentato come una prospettiva di partner.

Questa distinzione conta. I lettori dovrebbero considerare l’articolo un’analisi sostenuta da un fornitore, non una prova indipendente che una singola piattaforma commerciale risolva ogni problema di sicurezza degli agenti. Le sue tre domande restano utili perché descrivono lacune di controllo misurabili.

La prima domanda chiede dove esistano gli agenti di un’organizzazione. Un inventario deve includere agenti sviluppati internamente, funzionalità integrate nei prodotti SaaS, agenti ospitati nel cloud, strumenti autorizzati dai dipendenti e sistemi sperimentali.

Gli inventari tradizionali delle risorse spesso non rilevano queste categorie. Uno sviluppatore può creare un agente in un account cloud approvato senza registrarlo come applicazione aziendale separata. Un dipendente può anche autorizzare uno strumento esterno tramite OAuth.

OAuth è uno standard di autorizzazione che consente a un’applicazione di ricevere accesso limitato a un altro servizio. La sua praticità può nascondere relazioni di fiducia persistenti ai team che non hanno mai approvato l’agente sottostante.

La scoperta richiede quindi più della scansione dei repository di codice. I team di sicurezza hanno bisogno anche di inventari cloud, registrazioni delle applicazioni, concessioni OAuth, account di servizio, segnali del browser, record dell’API gateway e connessioni Model Context Protocol.

Model Context Protocol, o MCP, consente alle applicazioni AI di connettersi a strumenti e dati attraverso un’interfaccia comune. Può semplificare l’integrazione ampliando al contempo l’insieme dei sistemi raggiungibili.

La seconda domanda chiede a cosa possa connettersi ogni agente individuato. Questa mappa dovrebbe coprire applicazioni aziendali, API interne, database, sistemi di collaborazione, segreti, account di servizio e altri agenti.

Una connessione non rivela il rischio completo. I team di sicurezza devono conoscerne anche il metodo di autorizzazione, l’ambito dei permessi, la durata delle credenziali, il responsabile aziendale, la cronologia delle approvazioni e il percorso di revoca.

La terza domanda chiede cosa possa fare un agente dopo la connessione. L’accesso in lettura, la modifica di record, l’esecuzione di codice, i movimenti di denaro e l’impersonificazione degli utenti comportano conseguenze molto diverse.

Anche questi permessi possono combinarsi. Un agente che legge email e crea ticket di supporto sembra limitato quando ogni connessione viene esaminata separatamente. Diventa più rilevante quando può estrarre istruzioni e attivare azioni esterne.

Google News ha contribuito a presentare l’avvertimento a un pubblico più ampio. Tuttavia, l’evento importante è avvenuto sotto il livello di aggregazione. I fornitori di identità e gli organismi pubblici di standardizzazione stanno convergendo sugli agenti come attori aziendali di prima classe.

Questo cambiamento offre ai responsabili della sicurezza un punto di partenza più chiaro. Crea anche pressione per distinguere l’identità di un agente da quella dell’utente, dell’applicazione o dell’account di servizio che lo ha avviato.

Un token preso in prestito da un dipendente non può fornire chiaramente questa distinzione. Lo stesso vale per un’unica chiave API condivisa da diversi agenti. Entrambe le configurazioni indeboliscono l’attribuzione durante gli audit e le indagini sugli incidenti.

Il cambiamento immediato è concettuale, ma operativo. Le aziende hanno ora bisogno di record di ciclo di vita separati per gli agenti, inclusi creazione, proprietà, autorizzazione, revisione, sospensione e ritiro.

L’identità è diventata il piano di controllo dell’AI

Un agente necessita di un’identità distinta perché l’autorità senza attribuzione trasforma l’automazione ordinaria in un problema di indagine senza confini.

La gestione delle identità e degli accessi, o IAM, determina chi può accedere a una risorsa e a quali condizioni. I sistemi IAM esistenti offrono già directory, motori di policy, revisioni degli accessi, servizi di token e registri di audit.

Questi componenti offrono alle aziende una base pratica. Possono registrare un agente, associarlo a un responsabile, concedergli permessi specifici e revocare tali permessi quando l’agente cambia o viene ritirato.

NIST ha rafforzato questa posizione nella sua recente analisi sulla base dell’identità. L’agenzia ha avvertito che le prime implementazioni stanno dando priorità alle funzionalità e al valore immediato rispetto alle pratiche di identità consolidate.

NIST ha inoltre evidenziato la condivisione delle credenziali come un problema centrale. Le credenziali condivise compromettono la responsabilità perché gli investigatori non possono determinare in modo affidabile quale persona, servizio o agente abbia eseguito una transazione.

Il problema diventa più acuto quando gli agenti delegano compiti. Un utente potrebbe chiedere a un agente di preparare un briefing commerciale. Tale agente potrebbe chiamare un altro sistema per ottenere dati sugli account e un terzo servizio per la ricerca competitiva.

Ogni passaggio di consegne crea una decisione di autorizzazione. L’azienda deve preservare l’utente originario, l’agente che agisce, la risorsa richiesta e lo scopo della richiesta.

Senza questa catena, i log possono mostrare che un account di servizio ha avuto accesso a un database. Non possono spiegare quale agente abbia avviato l’azione, quale utente l’abbia richiesta o se l’azione corrispondesse a un flusso di lavoro approvato.

Un’identità di prima classe può ripristinare parte di questo contesto. Ogni agente riceve un identificatore univoco invece di prendere in prestito un account generico. Le policy possono quindi essere rivolte all’agente specifico.

Questo modello supporta il privilegio minimo, che limita un’identità all’accesso minimo necessario per il compito assegnato. Supporta inoltre la revoca senza interrompere applicazioni o dipendenti non correlati.

I token a breve durata rafforzano il modello. Un token è una credenziale firmata che rappresenta l’autorità concessa per un ambito e una durata limitati. Scadenze brevi riducono il valore delle credenziali rubate.

Le credenziali federate offrono un altro miglioramento. Consentono a un carico di lavoro affidabile di richiedere un token senza memorizzare un segreto riutilizzabile nel codice, nei file di configurazione o nella memoria di un agente.

La proprietà completa il record di base. Ogni agente in produzione necessita di una persona nominata o di un team responsabile incaricato del suo scopo, dei suoi permessi, delle sue revisioni e del suo ritiro.

Il responsabile non può essere semplicemente lo sviluppatore che ha creato il primo prototipo. La proprietà aziendale conta perché qualcuno deve decidere se l’accesso dell’agente rimanga necessario.

Anche lo stato del ciclo di vita conta. Un agente sperimentale non dovrebbe conservare permessi di produzione dopo la fine di un test. Un agente sostituito non dovrebbe restare attivo solo perché la sua chiave API continua a funzionare.

Questa struttura ricorda la governance per dipendenti e applicazioni. Tuttavia, gli agenti richiedono valutazioni più frequenti perché strumenti, istruzioni, modelli e compiti delegati possono cambiare in modo indipendente.

Le aziende dovrebbero quindi trattare la directory delle identità come un piano di controllo, non come una rubrica statica. La registrazione avvia la governance, ma l’applicazione continua delle policy la rende significativa.

Questa distinzione protegge anche la sperimentazione legittima. Gli sviluppatori possono ricevere un percorso definito per registrare un agente invece di attendere una vasta revisione della sicurezza dopo il deployment.

Un processo di registrazione utilizzabile dovrebbe acquisire scopo, responsabile, ambiente, strumenti, classi di dati, permessi e limiti operativi previsti. Dovrebbe inoltre assegnare una data di scadenza o revisione.

Se il percorso approvato è più lento della creazione di un agente non registrato, i team lo aggireranno. Il programma di identità deve quindi rendere l’onboarding sicuro più facile del deployment nascosto.

È qui che le pratiche di gestione della conoscenza possono sostenere la governance. I team hanno bisogno di record ricercabili che colleghino decisioni, responsabili, requisiti, approvazioni e modifiche successive.

Un inventario da solo risponde a dove sia stato registrato un agente. La conoscenza operativa connessa spiega perché esista e se il suo comportamento attuale corrisponda ancora a quello scopo.

Le tre domande rivelano tre fallimenti diversi

Scoperta, controllo delle connessioni e governance delle azioni sono discipline separate, e superarne una non compensa il fallimento in un’altra.

“Dove sono i miei agenti?” verifica la visibilità. I team di sicurezza non possono governare un agente che appare solo nell’account di uno sviluppatore, nel browser di un dipendente o nella configurazione di un amministratore SaaS.

Un inventario utile deve includere deployment autorizzati e non autorizzati. Deve inoltre distinguere gli agenti attivi da template, esperimenti abbandonati, istanze disabilitate e applicazioni ordinarie che utilizzano funzionalità AI.

L’inventario dovrebbe identificare l’ambiente e lo stato operativo di ogni agente. Gli agenti di sviluppo, test e produzione non dovrebbero condividere gli stessi presupposti di approvazione.

I team di sicurezza devono anche decidere cosa costituisca un agente. Un chatbot che restituisce solo testo presenta un profilo di autorità diverso da un sistema che invoca strumenti o modifica record.

La definizione dovrebbe concentrarsi sul comportamento. Se il software seleziona azioni, chiama strumenti connessi o delega lavoro con una revisione umana limitata, appartiene alla popolazione soggetta a governance.

“A cosa possono connettersi?” verifica il grafo di fiducia dell’organizzazione. Un grafo di fiducia registra le relazioni tra identità, credenziali, applicazioni, risorse e servizi delegati.

Questo grafo dovrebbe mostrare portata diretta e indiretta. Un agente potrebbe non avere accesso al database, ma possedere il permesso di chiamare un servizio che può interrogare lo stesso database.

Le connessioni tra agenti rendono la mappatura più difficile. Un agente può trasferire contesto o autorità a un altro, creando una catena che attraversa piattaforme e confini amministrativi.

Le aziende devono registrare se ogni connessione utilizzi accesso permanente o autorizzazione specifica per il compito. L’accesso permanente resta disponibile tra un compito e l’altro, aumentando l’esposizione se l’agente viene compromesso.

“Cosa possono fare?” mette alla prova il controllo in fase di esecuzione. La risposta non può essere un elenco di ambiti API copiato dalla registrazione di un’applicazione.

Un ambito può consentire la modifica dei file, ma la policy dovrebbe comunque distinguere tra l’editing ordinario e l’eliminazione di un repository. La stessa autorizzazione tecnica può coprire azioni con conseguenze aziendali diverse.

L’autorizzazione in fase di esecuzione valuta un’azione proposta nel momento in cui si verifica. Può considerare l’agente che agisce, l’utente di origine, la sensibilità della risorsa, l’operazione richiesta, la posizione e gli attuali segnali di rischio.

Alcune decisioni dovrebbero restare automatiche. Richiedere l’approvazione umana per ogni ricerca a basso rischio eliminerebbe il valore di produttività promesso dagli agenti.

Le azioni ad alto impatto meritano attriti maggiori. Le modifiche ai sistemi di produzione, i trasferimenti di denaro, la divulgazione di informazioni regolamentate e le eliminazioni irreversibili richiedono salvaguardie esplicite.

L’approvazione con supervisione umana è un’opzione. Colloca una persona in un punto decisionale definito prima che l’agente completi un’azione sensibile.

L’approvazione deve fornire un contesto significativo. Un prompt che dice “consenti azione” senza indicare la risorsa, i dati, lo scopo e l’effetto previsto diventa una casella di controllo puramente formale.

Le organizzazioni necessitano anche di una disattivazione affidabile. Un kill switch dovrebbe revocare l’accesso attivo dell’agente in tutti i sistemi connessi, invece di disabilitare soltanto la sua interfaccia visibile.

Questa capacità dipende dall’architettura delle credenziali. La revoca centralizzata funziona male quando gli agenti usano chiavi API distribuite, token memorizzati nella cache o credenziali copiate in servizi esterni.

Le tre domande formano quindi una sequenza. La scoperta stabilisce il soggetto, la mappatura delle connessioni definisce la portata potenziale e la governance delle azioni controlla l’autorità effettivamente esercitata.

Saltare la sequenza crea una falsa fiducia. Un’organizzazione può mantenere un elenco completo degli agenti lasciando al tempo stesso ogni agente elencato con autorizzazioni eccessive.

Può anche emettere token con ambiti ristretti senza rilevare gli agenti creati dai dipendenti. In alternativa, può registrare le azioni degli agenti senza conservare un contesto identitario sufficiente per attribuirle.

Il valore del framework risiede in questi confini di fallimento. Ogni domanda offre ad auditor e responsabili della sicurezza un’affermazione specifica da verificare, invece di una garanzia generale sull’“IA responsabile”.

I controlli di identità non possono decidere se un’azione è saggia

Un’identità valida risponde a chi sta agendo, ma non garantisce che l’agente abbia compreso la richiesta o scelto un’azione sicura.

Questa limitazione definisce il compromesso centrale dell’articolo. Le aziende hanno bisogno di controlli basati sull’identità, ma gli agenti restano meno prevedibili delle applicazioni tradizionali che utilizzano le stesse credenziali.

Un servizio convenzionale esegue codice scritto per un flusso di lavoro noto. Un agente può interpretare istruzioni, selezionare strumenti, generare parametri e adattare il proprio percorso in base alle informazioni ricevute.

Questa flessibilità crea valore. Significa anche che il successo dell’autenticazione non può costituire prova che la decisione successiva corrisponda all’intento dell’utente.

Il prompt injection illustra questa lacuna. Un agente può incontrare istruzioni dannose all’interno di un documento, un’email, una pagina web o un record recuperato e trattarle come parte del proprio compito.

L’aggressore non deve rubare l’identità dell’agente. Può tentare di manipolare un agente correttamente autenticato affinché utilizzi in modo improprio le proprie autorizzazioni legittime.

OWASP include l’abuso di identità e privilegi tra i suoi rischi di sicurezza agentici. La categoria copre la manipolazione delle catene di delega, dei ruoli ereditati, delle credenziali memorizzate nella cache e del contesto dell’agente.

L’uso improprio degli strumenti crea un altro problema. Un agente può chiamare uno strumento approvato con argomenti non sicuri o nella fase sbagliata di un flusso di lavoro.

I controlli di identità possono negare l’accesso a uno strumento non approvato. Non possono determinare autonomamente se ogni chiamata consentita supporti l’obiettivo effettivo dell’utente.

L’architettura di sicurezza deve quindi trattare il modello come un componente decisionale non affidabile. I controlli deterministici dovrebbero restare al di fuori del modello ovunque le conseguenze siano rilevanti.

Un controllo deterministico segue regole esplicite anziché generare una risposta probabilistica. Alcuni esempi includono controlli delle autorizzazioni, validazione degli schemi, limiti di transazione e soglie di approvazione obbligatorie.

Il motore di policy dovrebbe valutare ciò che l’agente propone, senza fare affidamento sul fatto che l’agente controlli sé stesso. L’agente non dovrebbe poter riscrivere le regole che ne controllano l’autorità.

La validazione degli input e degli output resta importante. I parametri degli strumenti dovrebbero conformarsi agli schemi previsti, ai limiti delle risorse, alle classificazioni dei dati e alle destinazioni approvate.

I controlli di rete possono ridurre ulteriormente la portata. Un agente che non ha mai bisogno di accesso alla rete internet pubblica non dovrebbe riceverlo per impostazione predefinita.

I controlli sui dati sono importanti perché l’identità non impedisce una divulgazione inappropriata a un destinatario approvato. Le policy devono considerare anche la sensibilità dei dati, lo scopo e la conservazione.

Il monitoraggio deve concentrarsi sul comportamento oltre che sugli accessi. Un’autenticazione riuscita seguita da un’enumerazione insolita, download di massa o ripetute azioni negate merita un’indagine.

È qui che l’affermazione identity-first richiede una formulazione accurata. L’identità fornisce l’ancoraggio per responsabilità, revoca e policy. Non è un sistema completo di sicurezza degli agenti.

Una piattaforma commerciale di identità può centralizzare registrazione e token. Non può garantire che ogni modello connesso resista alla manipolazione o interpreti correttamente obiettivi ambigui.

Anche la neutralità rispetto ai fornitori resta incerta. Gli agenti opereranno su Microsoft, Google Cloud, Amazon Web Services, Salesforce, ServiceNow, framework interni e prodotti SaaS specializzati.

Ogni piattaforma può rappresentare gli agenti in modo diverso. L’identità multipiattaforma richiede token interoperabili, attestazioni coerenti, emittenti affidabili e policy che resistano ai passaggi di consegne.

MCP aggiunge un altro confine. Un’azienda potrebbe governare l’agente pur dipendendo da un server esterno per esporre correttamente gli strumenti e proteggere le proprie credenziali.

Anche un livello di identità necessita di protezione contro la compromissione. Directory centralizzate e servizi di token diventano obiettivi di valore perché possono influenzare molti agenti contemporaneamente.

Le aziende dovrebbero separare i compiti amministrativi, proteggere le modifiche ad alto privilegio e monitorare le modifiche insolite alle policy. La governance degli agenti non può basarsi su un unico account console con privilegi ampi.

I log di audit meritano lo stesso scetticismo. Un grande volume di eventi non produce automaticamente prove utili.

Gli investigatori necessitano di record che colleghino la richiesta dell’utente, l’identità dell’agente, gli agenti delegati, lo strumento selezionato, la decisione di autorizzazione, la risorsa interessata e il risultato finale.

Le policy di conservazione devono preservare questa catena abbastanza a lungo per indagini e revisioni normative. Prompt e output sensibili possono richiedere minimizzazione o accesso limitato.

La conclusione corretta è più circoscritta del messaggio del fornitore. L’identità è l’inizio della sicurezza degli agenti perché il controllo necessita di un soggetto noto.

La sicurezza richiede comunque difese stratificate attorno a quel soggetto. Questi livelli includono strumenti vincolati, policy esterne, credenziali protette, controlli sui dati, monitoraggio e revisione umana.

Microsoft e Okta stanno trasformando il modello in prodotti

L’idea identity-first sta passando dal linguaggio delle conferenze a directory, flussi di token, sistemi di scoperta e controlli di revoca.

Microsoft Entra Agent ID illustra come una grande piattaforma rappresenti ora direttamente gli agenti. Microsoft descrive un’identità di agente come un service principal specializzato con un identificatore univoco.

Un service principal rappresenta un’applicazione o un carico di lavoro all’interno di un tenant di identità. La versione per agenti consente a policy e log di distinguere l’agente dal suo progetto sottostante.

Il flusso di autenticazione autonoma di Microsoft separa un’identità di agente dai segreti di produzione riutilizzabili. La documentazione raccomanda identità gestite o certificati anziché segreti client.

Gli agenti autonomi possono richiedere token applicativi per la propria identità. Gli agenti interattivi possono utilizzare flussi delegati quando agiscono per conto di un utente autenticato.

Questa differenza è essenziale. Un agente autonomo di reporting notturno non dovrebbe apparire identico a un assistente che esegue un’azione per un dipendente che ha effettuato l’accesso.

L’autorizzazione on-behalf-of preserva la relazione con l’utente durante la delega. Il token risultante può identificare l’utente come soggetto e l’agente come attore.

Questo design offre ai server di risorse più contesto per l’autorizzazione. Un sistema può chiedersi se quell’utente, agendo tramite quell’agente, sia autorizzato a eseguire l’operazione richiesta.

Microsoft documenta anche account utente speciali per agenti destinati a risorse che richiedono oggetti simili agli utenti. Tali account possono supportare caselle di posta o funzionalità collaborative senza utilizzare normali credenziali umane.

Questi account includono restrizioni. Microsoft afferma che non possono ricevere ruoli di amministratore privilegiato, creando un confine contro alcune forme di escalation.

Okta persegue lo stesso mercato da una posizione di identità neutrale rispetto alle piattaforme. Il suo lancio dell’identità degli agenti di aprile ha descritto scoperta, registrazione, connessioni gestite, governance e disattivazione.

L’azienda afferma che la sua directory può importare agenti da piattaforme esterne e registrare agenti personalizzati. Descrive anche il rilevamento di agenti ombra tramite segnali di consenso OAuth.

Okta presenta il proprio prodotto attorno alle stesse tre domande ripetute nell’articolo dell’ospite di GuidePoint. Questa sovrapposizione conferma il contesto commerciale dell’articolo.

Il messaggio del prodotto merita attenzione critica, ma le categorie di implementazione sono concrete. Le aziende necessitano di directory per gli agenti, token ristretti per le connessioni e applicazione delle policy per le azioni.

La concorrenza dovrebbe avvantaggiare gli acquirenti se le piattaforme espongono controlli interoperabili. Il modello di Microsoft può adattarsi alle organizzazioni incentrate su Entra e Microsoft Graph.

Okta pone l’accento sulla governance attraverso più cloud, applicazioni e framework per agenti. I provider cloud integreranno naturalmente i loro servizi per agenti con i sistemi di identità dei carichi di lavoro già esistenti.

Il pericolo è la frammentazione. Un’azienda potrebbe ritrovarsi con un inventario degli agenti per ogni cloud, un altro all’interno del proprio provider di identità e diversi altri nei portali di amministrazione SaaS.

Questi inventari saranno in disaccordo a meno che l’organizzazione non definisca un processo canonico di titolarità e ciclo di vita. Gli strumenti di scoperta dovrebbero alimentare tale processo invece di creare fonti di verità parallele.

La compatibilità dei token è un altro problema. OAuth può standardizzare la meccanica dell’autorizzazione, ma i fornitori possono differire per attestazioni di identità, prove di delega e controlli delle policy in fase di esecuzione.

La comunicazione agente-agente aumenta la posta in gioco. Il primo agente potrebbe portare l’autorità delegata di un utente, mentre un agente a valle opera autonomamente con autorizzazioni applicative.

La catena di autorizzazione deve mostrare dove l’autorità è cambiata. Altrimenti, una richiesta utente approvata può trasformarsi in un’ampia azione macchina senza un’escalation visibile.

I team di procurement dovrebbero testare i prodotti su flussi di lavoro reali. Un’interfaccia di directory curata conta meno della capacità della piattaforma di revocare l’accesso in ogni connettore interessato.

Dovrebbero anche verificare l’esportabilità. I dati di audit devono restare accessibili per risposta agli incidenti, conformità e migrazione, senza dipendere da un’unica vista di indagine proprietaria.

I team di sicurezza dovrebbero evitare di concedere a una nuova piattaforma per agenti un accesso illimitato solo per migliorare la visibilità. L’architettura di scoperta richiede una propria revisione del privilegio minimo.

Il mercato si sta quindi muovendo verso l’identità come infrastruttura condivisa. I vincitori non si limiteranno a registrare gli agenti.

Conserveranno l’attribuzione tra le diverse piattaforme, ridurranno le credenziali permanenti, supporteranno la revoca granulare e renderanno visibili le decisioni di policy in registri valutabili da strumenti esterni.

Cosa dovrebbero verificare le aziende prima di scalare gli agenti

La prossima fase sarà valutata in base alle prove di implementazione, non al numero di fornitori che ripetono l’espressione “identità di prima classe”.

Il primo segnale è capire se le aziende costruiscono inventari completi che includano gli agenti ombra. Una directory popolata solo attraverso l’onboarding formale non rileverà le implementazioni più rischiose.

Le organizzazioni dovrebbero confrontare i record di identità con le autorizzazioni OAuth, le risorse cloud, la telemetria del browser, l’utilizzo delle API e le configurazioni SaaS. Grandi discrepanze indebolirebbero la promessa di un approccio identity-first.

Il secondo segnale è verificare se autorizzazioni a breve durata e con ambito limitato sostituiscono i segreti statici. I numeri della migrazione contano più della capacità di una piattaforma di emettere token moderni per nuovi agenti.

I team dovrebbero individuare gli agenti esistenti che utilizzano chiavi API incorporate, account di servizio condivisi e token di refresh di lunga durata. Dovrebbero quindi misurare la rapidità con cui tali credenziali vengono eliminate.

La documentazione di Microsoft offre alle aziende un punto di riferimento tecnico. Le sue linee guida per la produzione privilegiano le credenziali federate e le identità gestite rispetto ai segreti client archiviati.

Il terzo segnale è verificare se i controlli in fase di esecuzione resistono alla delega tra piattaforme diverse. Questo determinerà se l’identità degli agenti diventerà vera infrastruttura o un’altra categoria di prodotto isolata.

Un test utile parte da una richiesta umana che attiva più agenti e strumenti. Gli addetti alle indagini dovrebbero poter ricostruire l’intera catena senza correlare manualmente log non collegati.

Il record dovrebbe identificare la persona che ha originato la richiesta, ogni agente partecipante, ciascuno scambio di token, la policy applicata e ogni risorsa interessata.

La revoca dovrebbe funzionare lungo la stessa catena. Disabilitare l’agente che avvia il processo non deve lasciare attive credenziali delegate o sessioni downstream.

Le aziende dovrebbero inoltre eseguire test avversariali. Un red team può inserire istruzioni dannose in contenuti che un agente autorizzato dovrebbe recuperare.

Il test dovrebbe mostrare se una policy esterna blocca azioni pericolose dopo che il modello ha accettato le istruzioni. L’identità da sola non produrrà quel risultato.

I responsabili aziendali hanno bisogno di un quadro decisionale per definire un’autonomia accettabile. Non tutti gli agenti richiedono lo stesso livello di revisione, perché le conseguenze variano notevolmente.

Un assistente di ricerca che legge documenti pubblici comporta rischi diversi rispetto a un agente che modifica codice di produzione. Un agente per la contabilità fornitori introduce una categoria completamente diversa.

Le revisioni degli accessi dovrebbero riflettere tali differenze. Gli agenti ad alto impatto necessitano di cicli di certificazione più brevi, limiti più rigidi, monitoraggio più solido e punti di approvazione umana definiti.

I piani di risposta agli incidenti devono includere gli agenti come attori. I team dovrebbero sapere come sospendere un’identità, invalidare i token, isolare i connettori, preservare i log e identificare i dati coinvolti.

Il piano dovrebbe coprire anche gli agenti terzi compromessi. La fiducia OAuth concessa in anticipo può rimanere pericolosa anche quando il codice interno dell’azienda non è mai stato violato.

I team di sicurezza dovrebbero chiedere ai fornitori con quale rapidità comunicano le compromissioni dei connettori e revocano gli accessi emessi. Il linguaggio contrattuale dovrebbe affrontare log, notifiche e supporto alle indagini.

Gli sviluppatori hanno bisogno di standard più chiari in fase di progettazione. Ogni nuovo agente dovrebbe dichiarare il proprio responsabile, gli strumenti, le classi di dati, il modello di autorizzazione e la massima conseguenza consentita.

Queste informazioni possono diventare parte di un record interno del workflow AI. I team di prodotto, sicurezza e ingegneria possono quindi riesaminare le modifiche rispetto allo scopo originario.

L’articolo di Google News offre un utile punto di verifica, ma la ripetizione non dovrebbe essere scambiata per una soluzione. I provider di identità hanno definito il problema più chiaramente di quanto le aziende abbiano implementato la risposta.

Le tre domande costituiscono una prima revisione pratica. La vostra organizzazione sa nominare ogni agente? Riesce a mappare ogni sistema raggiungibile? Può limitare e ricostruire ogni azione significativa?

Un “sì” richiede prove provenienti da directory, token, policy e log. Un foglio di calcolo mantenuto per un audit non dimostra il controllo in fase di esecuzione.

Iniziate con un workflow di produzione e tracciatelo dall’intenzione umana all’effetto finale. Eliminate le credenziali condivise, restringete ogni connessione e definite dove l’azione automatica deve fermarsi.

Quindi testate la revoca e la ricostruzione sotto pressione. Se una delle due fallisce, l’agente dispone di più autonomia di quanta l’organizzazione possa spiegare in sicurezza.

Google News passerà a un altro titolo. Il divario di identità rimarrà finché le aziende non sapranno collegare ogni azione di un agente a un’autorità limitata, una responsabilità chiara e una policy applicabile.