Le minacce interne degli agenti AI pongono l'accesso fidato al centro della sicurezza
Gli agenti AI hanno oltrepassato una soglia critica: ora possono usare credenziali fidate per leggere dati, richiamare strumenti e modificare sistemi aziendali senza una supervisione costante.
Questo cambiamento trasforma la minaccia interna degli agenti AI da una questione di sicurezza del modello a un problema di controllo degli accessi. Un agente non ha bisogno di intenti malevoli per esporre record, inviare messaggi non autorizzati o eseguire un flusso di lavoro non sicuro. Gli bastano autorizzazioni legittime, un'istruzione dannosa e sufficiente autonomia per agire.
La più recente analisi di Cybersecurity Insiders coglie questa inversione. Un tempo le aziende consideravano l'AI un software da proteggere dagli attaccanti esterni. Ora i team di sicurezza devono valutare se il software stesso possa diventare un operatore fidato ma non sicuro.
Questo non significa che ogni agente debba essere classificato come ostile. Significa che le organizzazioni non possono più considerare l'autenticazione una prova che un'azione sia sicura. Un'identità valida risponde a chi o cosa ha richiesto l'accesso. Non stabilisce se l'azione richiesta corrisponda al reale intento dell'utente.
La sfida emergente non è quindi tra esseri umani e macchine. È tra un accesso ampio e persistente e un'autorizzazione ristretta e specifica per il compito. I team di sicurezza devono decidere se gli agenti erediteranno i modelli di accesso permissivi progettati per dipendenti e applicazioni tradizionali.
La risposta determinerà se l'adozione degli agenti produrrà automazione controllata oppure una nuova categoria di incidenti interni difficili da rilevare.
La minaccia interna degli agenti AI inizia con un accesso legittimo
Il rischio determinante non è che un agente AI superi il perimetro, ma che agisca attraverso accessi che l'azienda gli ha intenzionalmente concesso.
I programmi tradizionali di gestione del rischio interno si concentrano su dipendenti, collaboratori esterni e account compromessi. Questi soggetti operano già all'interno di un confine di fiducia. Possono utilizzare impropriamente dati o sistemi senza sfruttare una vulnerabilità esposta verso l'esterno.
Gli agenti si adattano sorprendentemente bene a questo modello. Possono detenere autorizzazioni OAuth, identità di servizio, accesso alle API, permessi sui database e autorità delegata. Possono inoltre combinare tali privilegi in un flusso di lavoro articolato in più fasi.
Un agente incaricato di preparare un briefing commerciale potrebbe cercare record dei clienti, recuperare note interne e redigere un'email. Un agente di coding potrebbe leggere un repository, aprire un terminale, modificare file e inviare una pull request. Un agente di supporto potrebbe interrogare informazioni sull'account e avviare un rimborso.
Ogni singola autorizzazione può sembrare ragionevole. La capacità pericolosa emerge quando l'agente le collega in una sequenza inattesa.
Questa è una differenza fondamentale tra un agente e un'applicazione tradizionale. Il software tradizionale segue solitamente percorsi predeterminati. Un agente interpreta un obiettivo, seleziona strumenti e decide i passaggi intermedi in fase di esecuzione.
Questa flessibilità crea valore, ma indebolisce anche le assunzioni incorporate nei controlli meno recenti. Un'autorizzazione concessa per un flusso di lavoro previsto può sostenere diversi flussi di lavoro non previsti. L'agente può scoprire questi percorsi più rapidamente di un operatore umano.
La prompt injection rende il problema più acuto. La prompt injection è un attacco che inserisce istruzioni ingannevoli nei dati letti da un sistema AI. L'agente può scambiare tali istruzioni per parte del compito assegnato.
Immaginate un assistente che esamina documenti provenienti da una cartella esterna. Un documento contiene testo nascosto che ordina all'assistente di recuperare file riservati e inviarne il contenuto altrove. L'agente potrebbe obbedire perché entrambe le azioni usano strumenti approvati.
Il sistema potrebbe registrare un accesso riuscito, un token valido e chiamate API consentite. Il monitoraggio tradizionale rileva attività autorizzate. L'azienda rileva una fuga di dati.
Le linee guida sulle minacce agentiche di OWASP identificano rischi derivanti dalla pianificazione autonoma, dall'uso di strumenti, dalla memoria e dalle interazioni tra agenti. Non si tratta di comportamenti isolati del modello. Sono rischi a livello di sistema creati dalla combinazione di un modello con un'autorità operativa.
Lo stesso problema si presenta quando un agente riceve un obiettivo definito in modo inadeguato. “Risolvi tutte le richieste scadute” potrebbe portarlo a inviare messaggi, modificare record o chiudere casi che richiedevano una revisione umana. Non è necessario compromettere prima il modello.
Per questo l'intento conta quanto l'identità. Un'architettura sicura deve stabilire chi ha autorizzato il compito, quali risorse copre, quali azioni sono consentite e per quanto tempo tale autorità resta valida.
Senza questi confini, un agente autenticato diventa un insider con un ritmo operativo insolitamente rapido.
L'accesso fidato sta diventando il nuovo perimetro di sicurezza
Gli agenti AI rendono l'accesso fidato più importante della posizione in rete perché il loro lavoro legittimo attraversa già applicazioni, cloud e archivi di dati.
L'architettura zero trust aveva anticipato parte di questo cambiamento. Lo standard zero trust del NIST rifiuta la fiducia implicita basata esclusivamente sulla posizione in rete o sulla proprietà dell'asset. Centra le decisioni di sicurezza su utenti, asset, risorse e autorizzazioni esplicite.
Questo modello diventa più urgente quando il soggetto che richiede l'accesso è un sistema autonomo. Un agente può operare oltre confini che un tempo rallentavano gli insider umani. Non deve cambiare dispositivo, aprire diverse interfacce o copiare manualmente dati tra applicazioni.
Una sola istruzione può attivare una catena di chiamate agli strumenti. Tale catena potrebbe passare da una piattaforma di messaggistica allo storage cloud, poi a un database clienti e a un servizio esterno. L'agente esegue la sequenza attraverso integrazioni fidate.
Un firewall di rete rileva connessioni consentite. I sistemi di identità rilevano credenziali riconosciute. I log applicativi mostrano operazioni che l'account assegnato era autorizzato a eseguire.
Eppure il risultato complessivo può comunque violare le policy.
La sicurezza deve quindi avvicinarsi a ogni singola azione. L'autorizzazione dovrebbe considerare l'identità dell'agente, il suo proprietario, il compito corrente, la risorsa richiesta, lo strumento usato e i segnali di rischio circostanti.
Ciò richiede un'identità distinta per ogni agente distribuito. Gli account di servizio condivisi rendono più difficile l'indagine, poiché più agenti possono generare attività sotto lo stesso nome. Consentono inoltre l'accumulo di autorizzazioni quando nuovi flussi di lavoro riutilizzano lo stesso account.
Un'identità dedicata crea una traccia di responsabilità. I team di sicurezza possono collegare un agente al suo sponsor, al suo scopo, agli strumenti consentiti, all'ambiente di distribuzione e al calendario di revisione. Possono sospendere un flusso di lavoro senza disabilitare automazioni non correlate.
L'identità da sola, tuttavia, non basta. Un agente identificato in modo univoco può comunque avere privilegi eccessivi. Può anche utilizzare un'autorizzazione valida nel momento sbagliato o per l'obiettivo sbagliato.
I controlli efficaci devono ridurre sia l'ambito sia la durata delle autorizzazioni. Un agente che prepara un report trimestrale non dovrebbe mantenere un accesso permanente a ogni fonte consultata. Dovrebbe ricevere un'autorità circoscritta per il compito corrente.
Le credenziali a breve durata riducono il tempo disponibile per un uso improprio. L'accesso just-in-time concede l'autorità quando il compito inizia e la ritira in seguito. Le policy a livello di strumento limitano le operazioni che l'agente può richiamare.
Questi controlli riflettono la lezione centrale della minaccia interna degli agenti AI. La fiducia dovrebbe essere associata a un'azione specifica in condizioni specifiche, non a un agente per sempre.
Le aziende devono inoltre separare la lettura dall'azione. Un agente che riassume un calendario richiede un'autorità diversa da uno che pianifica riunioni. Un sistema che propone modifiche al codice non dovrebbe ricevere automaticamente l'autorizzazione per distribuirle.
Questa distinzione può scomparire durante un'adozione rapida. I team iniziano con un assistente in sola lettura, poi aggiungono gradualmente accesso in scrittura, controllo del browser e automazione dei flussi di lavoro. La valutazione del rischio originaria non corrisponde più al sistema distribuito.
Gli inventari degli agenti devono quindi monitorare le capacità, non soltanto le installazioni. I team di sicurezza devono sapere quali agenti possono accedere a dati sensibili, invocare strumenti esterni, comunicare pubblicamente, modificare record o autorizzare transazioni.
L'inventario deve cambiare con la stessa rapidità degli agenti.
Perché i controlli interni esistenti non rilevano il comportamento degli agenti
I controlli progettati attorno alla velocità e alle motivazioni umane faticano quando il software può eseguire centinaia di azioni legittime senza affaticamento né esitazione.
I programmi di gestione del rischio interno per gli esseri umani cercano spesso cambiamenti comportamentali riconoscibili. Un dipendente scarica volumi insoliti di dati, accede a un orario inatteso o consulta un reparto esterno al proprio ruolo abituale.
Questi segnali restano utili, ma gli agenti creano una baseline diversa. Possono operare continuamente. Possono elaborare più record di una persona. La loro attività può provenire da un'infrastruttura cloud stabile anziché dall'endpoint di un dipendente.
Un'elevata frequenza di azioni può indicare un'automazione normale anziché un comportamento malevolo. Una bassa frequenza di azioni può comunque nascondere una divulgazione accuratamente mirata. Il solo volume diventa un segnale inaffidabile.
Anche l'intento è più difficile da dedurre. Un utente umano esegue solitamente azioni attraverso una sessione interattiva. Gli investigatori possono confrontare tali azioni con responsabilità lavorative, comunicazioni e processi aziendali noti.
Un agente traduce un'istruzione ampia in decisioni intermedie. L'utente potrebbe non vedere mai tali decisioni. L'azione finale può trovarsi a diversi passaggi di distanza dalla richiesta originaria.
I log devono preservare questa catena. Gli investigatori dovrebbero poter ricostruire l'istruzione dell'utente, le decisioni del modello, il contesto recuperato, le selezioni degli strumenti, i risultati dell'autorizzazione e gli effetti finali.
Questo non significa archiviare ogni calcolo interno del modello. Significa mantenere un record verificabile delle azioni esterne rilevanti e dell'autorità che supportava ciascuna di esse.
I log applicativi standard spesso forniscono solo frammenti. Un sistema registra il token. Un altro registra la query al database. Un terzo registra un messaggio in uscita. Senza un identificatore di attività condiviso, l'organizzazione non può collegarli in un unico flusso di lavoro dell'agente.
Il problema dell'osservabilità cresce nei sistemi multi-agente. Un agente può delegare la ricerca a un altro, che chiede a un terzo sistema di eseguire uno strumento. L'autorità può viaggiare lungo la catena anche quando l'utente originario non ha mai approvato ogni partecipante.
La fiducia ricorsiva descrive questa relazione in espansione. Un'organizzazione si fida di un agente, che si fida di un altro servizio, che dipende da un'altra identità o strumento. La superficie d'attacco effettiva si estende lungo ogni collegamento.
La minaccia interna degli agenti AI può sfruttare questa catena senza produrre un evidente evento di intrusione. La risposta di uno strumento compromesso può influenzare l'agente pianificatore. Una voce di memoria avvelenata può condizionare decisioni future. Un documento esterno può reindirizzare un flusso di lavoro fidato.
Le difese esistenti sugli endpoint e sulla rete restano importanti. Possono bloccare malware, rilevare destinazioni sospette e isolare infrastrutture compromesse. Non possono stabilire in modo affidabile se un'azione aziendale autorizzata rifletta il risultato previsto dall'utente.
Questo giudizio richiede un contesto più ricco.
Le organizzazioni dovrebbero stabilire baseline comportamentali per ogni ruolo dell'agente. Un agente di reporting potrebbe normalmente leggere fonti dati approvate e scrivere in uno specifico archivio documentale. Un tentativo di inviare email o accedere a credenziali ricadrebbe al di fuori di quel profilo.
Le policy possono inoltre imporre vincoli di sequenza. La lettura di una pagina web non fidata non dovrebbe autorizzare immediatamente l'accesso a record riservati. Un cambiamento nella sensibilità dei dati dovrebbe attivare una nuova decisione di autorizzazione.
L'approvazione umana resta utile per le azioni ad alto impatto. Tuttavia, le schermate di approvazione devono presentare informazioni significative. Una richiesta vaga di “continuare” non aiuta un revisore a comprendere quali dati verranno trasferiti o quali record cambieranno.
L'approvazione dovrebbe indicare l'azione, la destinazione, le risorse interessate e la conseguenza prevista. Altrimenti, l'essere umano diventa un passaggio cerimoniale anziché un controllo di sicurezza.
Il privilegio minimo deve seguire l'attività, non l'agente
Il modello di accesso più sicuro assegna a un agente l'autorità minima necessaria per una singola attività e impone una nuova decisione quando l'attività cambia.
Il privilegio minimo è da tempo un principio di sicurezza. I sistemi agentici ne rendono l'implementazione più impegnativa, poiché i loro flussi di lavoro sono dinamici.
Un'applicazione convenzionale riceve autorizzazioni corrispondenti a un insieme stabile di funzionalità. Un agente può scegliere strumenti diversi in base alla richiesta, alle informazioni recuperate o ai risultati di un passaggio precedente.
Concedergli in anticipo ogni autorizzazione possibile semplifica lo sviluppo. Ma crea anche un accumulo di autorità inattiva. Un agente manipolato può usare capacità che l'attività corrente non ha mai richiesto.
L'autorizzazione vincolata all'attività offre un percorso migliore. Il sistema valuta l'obiettivo dichiarato e rilascia una capacità limitata per la risorsa necessaria. Tale capacità scade al termine del passaggio o della sessione.
Il modello del privilegio minimo di Microsoft raccomanda di definire identità, ambito, accesso agli strumenti e verificabilità prima di ampliare l'autonomia. Sottolinea inoltre l'importanza di identità dedicate agli agenti con proprietari responsabili.
Si consideri un agente che elabora note spese. Deve leggere i documenti inviati, confrontarli con le policy e preparare una raccomandazione. Non ha bisogno di un'autorità permanente per disporre pagamenti.
Se in seguito l'azienda consente il rimborso automatico sotto una soglia definita, tale autorizzazione di scrittura dovrebbe essere separata. Il sistema dovrebbe registrare la policy che l'ha autorizzata e richiedere un'escalation oltre il limite.
Questa scomposizione limita i danni quando qualcosa va storto. Un'istruzione malevola all'interno di una ricevuta potrebbe influenzare la raccomandazione. Non dovrebbe concedere automaticamente la capacità di reindirizzare fondi.
Lo stesso modello si applica al lavoro basato sulla conoscenza. Un agente di ricerca può cercare nei documenti approvati di un team, ma la destinazione del suo output dovrebbe rimanere vincolata. Il materiale sorgente sensibile non dovrebbe confluire in prompt pubblici, canali esterni o progetti non correlati.
Le decisioni di accesso richiedono il contesto dei dati. Un'etichetta di file, l'appartenenza a un progetto, un blocco legale, una restrizione del cliente o il livello di riservatezza possono cambiare l'appropriatezza della stessa chiamata a uno strumento.
Le organizzazioni che realizzano una base di conoscenza AI dovrebbero trattare i confini delle autorizzazioni come parte della qualità del recupero delle informazioni. Una risposta utile deve attingere a informazioni pertinenti senza oltrepassare i confini di proprietà o riservatezza.
Anche la progettazione degli strumenti conta. Strumenti generici creano modalità di errore generiche. Un connettore di database generico in grado di eseguire query arbitrarie comporta più rischi di una funzione progettata ad hoc che restituisce campi approvati.
Gli sviluppatori dovrebbero esporre l'operazione utile più circoscritta. Invece di concedere a un agente accesso completo alla casella di posta, un servizio potrebbe permettergli di recuperare messaggi corrispondenti a un identificatore di caso. Invece dell'accesso alla shell, potrebbe esporre un comando di build controllato.
Il collegamento degli strumenti associa identità specifiche di agenti a operazioni specifiche. L'agente non può invocare ogni integrazione disponibile solo perché la piattaforma sa che tali strumenti esistono.
Anche input e output necessitano di convalida esterna al modello. Un modello non dovrebbe essere l'unico responsabile di decidere se la propria azione proposta viola una policy.
Un livello di policy separato può ispezionare destinazioni, classificazioni dei dati, limiti di transazione e contesto dell'attività. Può bloccare, trasformare o sottoporre a escalation un'operazione prima dell'esecuzione.
Questa separazione affronta un comune equivoco sulla sicurezza degli agenti. Prompt migliori e modelli più potenti possono ridurre gli errori, ma non possono sostituire confini applicabili.
Un prompt è un'istruzione. Una policy di autorizzazione è un controllo.
La distinzione conta perché un agente può fraintendere un prompt, ereditare un contesto avvelenato o ricevere istruzioni in conflitto. Un motore di policy dovrebbe continuare ad applicare i limiti anche quando il modello si comporta in modo imprevedibile.
Zero Trust aiuta, ma non risolve l'intento
Zero trust può ridurre il raggio d'azione di un agente, ma non può determinare automaticamente se un'azione consentita serve il vero obiettivo dell'utente.
Questo è il compromesso centrale nel dibattito sull'accesso fidato. I fornitori di sicurezza presentano sempre più spesso identità, accesso condizionale e zero trust come risposte al rischio degli agenti. Questi controlli affrontano debolezze importanti.
Zero Trust for AI di Microsoft estende la verifica esplicita e il privilegio minimo a dati AI, modelli, carichi di lavoro, utenti e comportamento degli agenti. Microsoft descrive inoltre gli agenti manipolati, con privilegi eccessivi o disallineati come potenziali “doppi agenti”.
Questa impostazione è utile, ma le organizzazioni dovrebbero evitare di trattare zero trust come una categoria di prodotto completa. NIST descrive zero trust come un insieme di principi architetturali, non come l'acquisto di una singola tecnologia.
Un'organizzazione può distribuire controlli moderni dell'identità lasciando agli agenti autorizzazioni eccessive. Può richiedere l'autenticazione senza distinguere un'attività dell'agente da un'altra. Può raccogliere log che nessuno esamina.
I casi più difficili riguardano azioni che sono al contempo autorizzate e plausibili.
Un agente di assistenza clienti può legittimamente accedere ai dati dei clienti e inviare messaggi. Un agente di coding può legittimamente modificare file sorgente. Un agente di approvvigionamento può legittimamente contattare fornitori.
La versione dannosa o errata di ciascuna azione può apparire quasi identica a livello di identità.
L'autorizzazione contestuale riduce il divario. Il sistema può chiedersi se la destinazione sia approvata, se i campi richiesti siano necessari, se l'azione corrisponda al comportamento storico e se la classificazione dei dati consenta il trasferimento.
Tuttavia, i modelli contestuali producono falsi positivi e falsi negativi. Controlli rigidi possono interrompere flussi di lavoro utili. Controlli permissivi possono preservare la produttività consentendo al contempo combinazioni dannose.
L'organizzazione deve decidere dove termina l'autonomia. Le attività a basso impatto e reversibili possono tollerare maggiore libertà. Le attività ad alto impatto e irreversibili richiedono verifiche più solide e spesso l'approvazione umana.
La reversibilità merita particolare attenzione. Un agente che redige un messaggio crea un artefatto revisionabile. Un agente che invia il messaggio modifica il mondo esterno. Un agente che raccomanda di eliminare record è diverso da uno che esegue l'eliminazione.
L'architettura di sicurezza dovrebbe riflettere queste distinzioni.
I team dovrebbero inoltre testare gli agenti come sistemi, non soltanto come modelli. Le valutazioni dei modelli possono misurare se un agente segue le istruzioni in condizioni controllate. Il rischio in produzione dipende da strumenti, credenziali, memoria, fonti di dati e applicazioni circostanti.
Le esercitazioni red team dovrebbero introdurre documenti malevoli, obiettivi ambigui, risposte compromesse degli strumenti e combinazioni inattese di autorizzazioni. L'obiettivo è osservare se i controlli esterni contengono il fallimento.
Il framework OWASP aiuta i team a enumerare queste minacce, mentre il modello di accesso cloud del NIST spiega come le policy del livello di identità e i controlli granulari delle applicazioni supportino zero trust nei servizi distribuiti.
Nessuno dei due garantisce che un agente comprenda l'intento aziendale. Questa incertezza deve rimanere visibile nelle decisioni di distribuzione.
I responsabili della sicurezza dovrebbero quindi mettere in discussione le affermazioni secondo cui una piattaforma “protegge gli agenti” senza spiegarne l'ambito. Scopre le identità degli agenti? Governa le autorizzazioni? Ispeziona le chiamate agli strumenti? Protegge prompt e dati? Mantiene audit trail tra sistemi?
La maggior parte dei prodotti affronta solo una parte del ciclo di vita. Le imprese avranno comunque bisogno di titolarità delle policy, processi operativi, risposta agli incidenti e controlli specifici per applicazione.
La minaccia interna degli agenti AI non è una vulnerabilità unica con una sola patch. È la conseguenza dell'inserimento di decisori probabilistici all'interno di flussi di lavoro fidati.
Tre segnali mostreranno se l'accesso fidato sta migliorando
La prossima fase della sicurezza AI sarà misurata da controlli implementabili e prove derivanti dagli incidenti, non da promesse più ampie su agenti responsabili.
Il primo segnale è l'adozione di identità di agenti distinte e governate. Le organizzazioni dovrebbero poter enumerare gli agenti, identificarne i proprietari, rivederne le autorizzazioni e disabilitarli individualmente.
Il framework di identità degli agenti di Microsoft Entra mostra la direzione intrapresa dalle principali piattaforme di identità. Supporta costrutti dedicati agli agenti, registrazione delle attività, governance e accesso condizionale per attori non umani.
Altri fornitori di identità e cloud subiranno pressioni per offrire controlli comparabili in ambienti eterogenei. Le imprese raramente utilizzano una sola piattaforma di agenti o un solo sistema di identità.
I progressi diventeranno credibili quando gli amministratori potranno tracciare un'azione di un singolo agente tra le applicazioni senza fare affidamento su un account di servizio condiviso. Se le identità dedicate restano facoltative o specifiche della piattaforma, la visibilità rimarrà frammentata.
Il secondo segnale è un uso più ampio dell'autorizzazione di breve durata e circoscritta all'attività. Le piattaforme per agenti dovrebbero richiedere l'accesso per un'operazione definita anziché ereditare autorizzazioni permanenti da un utente o sviluppatore.
Questo cambiamento richiederà una migliore integrazione tra sistemi di orchestrazione e infrastruttura di identità. La piattaforma deve descrivere ciò che l'agente intende fare in una forma valutabile da un motore di policy.
Anche le interfacce di approvazione devono migliorare. Gli utenti dovrebbero vedere la risorsa, l'azione, la destinazione e l'effetto previsto prima di concedere autorizzazioni sensibili.
Se i fornitori distribuiranno questi controlli come impostazioni predefinite, la tesi dell'accesso fidato diventerà più solida. Se una configurazione sicura richiederà un'estesa ingegneria personalizzata, i team sotto pressione per le consegne continueranno a scegliere autorizzazioni ampie.
Il terzo segnale è costituito da prove pubbliche provenienti da incidenti reali e test indipendenti. I team di sicurezza devono sapere come gli agenti falliscono al di fuori delle dimostrazioni.
Le divulgazioni utili spiegheranno l'istruzione iniziale, il percorso di accesso, gli strumenti coinvolti, il controllo che ha fallito e il punto in cui il contenimento è riuscito. Riferimenti vaghi a output non sicuri non offriranno una guida architetturale sufficiente.
Le valutazioni indipendenti dovrebbero testare sistemi completi di agenti contro prompt injection, eccessiva autonomia, memoria avvelenata, esposizione di credenziali e manipolazione tra agenti. Dovrebbero inoltre misurare se i controlli preservano il lavoro utile.
La segnalazione degli incidenti chiarirà quali rischi predominano. La prompt injection riceve notevole attenzione, ma errori di configurazione, autorizzazioni eccessive, identità condivise e integrazioni non revisionate potrebbero rivelarsi altrettanto importanti.
L'esito plasmerà le priorità di spesa e progettazione. Se la maggior parte degli incidenti coinvolge credenziali rubate, la protezione delle identità avrà la precedenza. Se agenti validi usano ripetutamente in modo improprio strumenti consentiti, l'autorizzazione runtime e i controlli comportamentali diventeranno il principale terreno di scontro.
Le imprese non devono attendere standard perfetti. Possono già ora inventariare gli agenti, separare le identità, rimuovere le autorizzazioni inutilizzate, vincolare gli strumenti, registrare le catene di azioni e richiedere approvazione per le operazioni irreversibili.
Dovrebbero inoltre definire cosa accade quando un agente si comporta in modo inatteso. Sospensione rapida, revoca delle credenziali, isolamento del flusso di lavoro e conservazione delle prove devono far parte del piano di risposta agli incidenti.
La domanda pratica è semplice: la vostra organizzazione può spiegare ogni azione significativa compiuta da un agente e revocarne l’autorità senza disabilitare un intero processo aziendale?
Se la risposta è no, l’agente dispone di più fiducia di quanta l’architettura di sicurezza possa gestire in modo sicuro.
La minaccia interna rappresentata dagli agenti AI cambia l’ordine delle operazioni. Le aziende non possono prima concedere un accesso esteso e poi aggiungere il monitoraggio dopo il deployment. Identità, confini dei compiti, verificabilità e contenimento devono precedere l’autonomia.
Per gli sviluppatori e gli acquirenti enterprise, la prossima valutazione dovrebbe andare oltre la capacità di un agente di completare una demo. Bisogna chiedersi a cosa possa accedere, come scada tale autorità e se un controllo indipendente possa bloccare l’azione finale.
L’accesso affidabile è ora il campo di battaglia, perché l’accesso trasforma l’output del modello in conseguenze reali. Le organizzazioni che governeranno questa transizione coglieranno il valore dell’automazione senza considerare ogni azione autenticata intrinsecamente affidabile.
