Gli agenti AI aziendali stanno superando le fondamenta della sicurezza
Google News ha fatto emergere un duro avvertimento per le imprese: gli agenti AI agiscono già all'interno delle aziende, nonostante i controlli di sicurezza siano stati progettati per software prevedibili e utenti umani.
La questione non è più se un dipendente possa chiedere a un chatbot di riassumere un documento. Gli agenti possono recuperare record, richiamare strumenti, aggiornare sistemi, scrivere codice e avviare workflow articolati in più passaggi. Questa maggiore autorità trasforma una risposta dell'AI in una potenziale azione aziendale.
Il conflitto centrale è tra capacità e controllo. Le imprese vogliono che gli agenti completino attività utili con una supervisione limitata. I team di sicurezza devono comunque identificare ogni agente, limitarne l'accesso, tracciarne le decisioni e fermarlo quando il comportamento cambia.
Questa pressione grava contemporaneamente sui team di identità, sicurezza, conformità e piattaforma. Fornitori tra cui Microsoft, Cisco, Google, Amazon e Salesforce stanno aggiungendo funzionalità di gestione degli agenti. Tuttavia, la sola tecnologia non può risolvere responsabilità poco chiare o regole operative frammentate.
Un titolo apparso su Google News segnala quindi un cambiamento più ampio. Il perimetro della sicurezza aziendale ora include attori software che interpretano obiettivi, scelgono passaggi intermedi e interagiscono con altri attori software. Le fondamenta esistenti restano pertinenti, ma molte richiedono un adattamento significativo.
L'avvertimento di Google News riguarda le azioni, non le risposte
Un agente AI diventa un problema di sicurezza quando riceve sufficiente autorità per modificare qualcosa al di fuori del modello.
Gli assistenti di AI generativa producono principalmente contenuti che una persona può esaminare. Un agente può proseguire dalla generazione all'esecuzione. Può interrogare record dei clienti, aprire un ticket di assistenza, inviare codice, pianificare un pagamento o riconfigurare un servizio cloud.
Questa distinzione crea l'evento alla base del titolo. L'adozione aziendale è andata oltre le interfacce chat isolate, entrando in workflow collegati ai sistemi operativi. L'agente può ora attraversare confini che i team di sicurezza in precedenza gestivano tramite applicazioni separate e approvazioni umane.
Microsoft definisce gli agenti come sistemi software che accedono ai dati, prendono decisioni e compiono azioni con autorità delegata. La sua attuale baseline di governance raccomanda policy centralizzate che coprano identità, proprietà, accesso, monitoraggio, dati e standard di sviluppo.
L'autorità delegata significa che l'agente agisce usando permessi concessi da una persona, un servizio o un'organizzazione. L'agente non possiede tale autorità. Tuttavia, le sue azioni possono comunque produrre conseguenze prima che il delegante originale si accorga di un problema.
Si consideri un agente di assistenza collegato ai record dei clienti e a una piattaforma di ticketing. Leggere la cronologia di un account comporta un rischio di riservatezza. Aggiornare un diritto di accesso aggiunge un rischio di integrità. Emettere un rimborso introduce un rischio finanziario e richiede controlli di approvazione più rigorosi.
Un agente di coding presenta una variante diversa dello stesso problema. Può ispezionare repository, generare modifiche, eseguire test e inviare una pull request. Se può anche unire il codice o ottenere credenziali di deployment, una sola istruzione errata può arrivare in produzione.
Non si tratta di estensioni teoriche di un chatbot. Sono normali privilegi di automazione combinati con un processo decisionale probabilistico. Il modello può fraintendere il contesto, seguire contenuti dannosi o selezionare uno strumento inatteso mentre persegue un obiettivo valido.
Un agente opera inoltre lungo una catena più lunga rispetto alla maggior parte delle applicazioni tradizionali. Riceve un obiettivo, elabora un piano, seleziona strumenti, recupera contesto, valuta i risultati e adatta il passaggio successivo. Ogni transizione crea un ulteriore punto in cui autorizzazione o monitoraggio possono fallire.
I team di sicurezza di solito comprendono un'applicazione attraverso flussi predeterminati. Gli agenti rendono dinamici alcuni flussi. Una query al database consentita e un messaggio in uscita approvato possono diventare pericolosi quando un agente li combina senza riconoscere la divulgazione.
Ecco perché l'inquadramento di Google News è importante. Il titolo non è un'altra previsione sul futuro dell'intelligenza artificiale. Riflette un cambiamento attuale nella collocazione dell'autorità del software e nella rapidità con cui tale autorità può essere esercitata.
La prima domanda di sicurezza è quindi concreta: quali agenti possono compiere azioni oggi? Se un'organizzazione non riesce a produrre tale inventario, le sue policy si applicano solo agli agenti di cui conosce già l'esistenza.
L'adozione aziendale supera il piano di controllo
Il divario nell'adozione non riguarda semplicemente una distribuzione rapida; è la differenza tra sperimentare con gli agenti e governare ogni agente come una risorsa aziendale responsabile.
Cisco ha dichiarato nel marzo 2026 che l'85% dei principali clienti aziendali intervistati stava sperimentando con gli agenti AI. Solo il 5% aveva portato la tecnologia agentica in produzione, secondo la sua indagine aziendale.
Questi dati provengono da Cisco e dovrebbero essere letti come ricerca di un fornitore, non come un censimento universale. Illustrano comunque un importante punto di pressione. La sperimentazione crea identità, credenziali, connessioni agli strumenti e flussi di dati prima che un progetto riceva lo status formale di produzione.
Un prototipo può accedere a informazioni reali anche quando i suoi sviluppatori lo definiscono un test. I dipendenti possono collegare servizi AI per consumatori ad account aziendali. I team di business possono creare agenti di workflow senza coinvolgere la sicurezza centrale. Gli sviluppatori possono distribuire credenziali tramite framework che le operazioni di sicurezza non riescono facilmente a individuare.
Questo produce agenti ombra, ossia agenti che operano senza un inventario organizzativo completo o un'approvazione. Gli agenti ombra somigliano allo shadow IT, ma possono prendere decisioni e avviare azioni attraverso diversi servizi connessi.
Gli inventari tradizionali delle risorse possono registrare un workload cloud, un client API o un service account. Spesso non mostrano che un agente AI controlla tali componenti. Il team di sicurezza vede le credenziali senza vedere il sistema di ragionamento che le utilizza.
Anche la responsabilità può diventare poco chiara. Un responsabile di business ha richiesto il workflow, uno sviluppatore lo ha assemblato, un team di piattaforma lo ospita e un fornitore fornisce il modello. Quando l'agente si comporta in modo errato, ogni partecipante possiede soltanto uno strato.
I lettori di Google News potrebbero incontrare la sicurezza degli agenti come una nuova categoria di prodotti. Per le imprese, tuttavia, il requisito immediato è un modello operativo. Qualcuno deve autorizzare lo scopo dell'agente, approvarne l'accesso, esaminarne il comportamento e ritirarlo quando tale scopo termina.
Gli attuali controlli sull'identità degli agenti di Microsoft richiedono che ogni identità di agente abbia uno sponsor umano. Lo sponsor resta responsabile dello scopo, delle decisioni sul ciclo di vita e delle revisioni degli accessi.
Questo modello affronta una domanda fondamentale ma spesso trascurata: chi risponde di un attore non umano? Assegnare uno sponsor non rende sicuro l'agente. Stabilisce una persona che può approvare modifiche e ricevere un'escalation quando il suo accesso non corrisponde più al suo ruolo.
Il piano di controllo necessita inoltre di un registro affidabile. Ogni record dovrebbe collegare l'agente al suo proprietario, scopo, modello, strumenti, fonti di dati, credenziali, ambiente e regole di approvazione. Un elenco di abbonamenti ai modelli non può fornire questa visione.
L'individuazione deve continuare dopo la registrazione. Gli agenti possono creare processi di breve durata, delegare attività o chiamare altri agenti. Un foglio di calcolo statico diventa rapidamente incompleto quando le istanze in esecuzione differiscono dal progetto approvato.
L'approvvigionamento crea un altro divario. Una funzionalità software può aggiungere comportamento agentico tramite un aggiornamento ordinario. L'organizzazione può acquisire autonomia all'interno di una piattaforma esistente senza avviare un progetto AI separato né attivare una revisione dedicata.
La pressione sulla sicurezza si sposta quindi verso l'individuazione continua. Piattaforme di identità, gateway API, telemetria degli endpoint, log cloud e controlli sui dati devono collaborare. Nessuna singola fonte rivelerà l'intera catena.
Le aziende sottoposte alla maggiore pressione sono quelle con acquisti software decentralizzati e sistemi di identità frammentati. I loro team possono distribuire agenti più rapidamente, ma gli investigatori potrebbero faticare a ricostruire chi ha autorizzato un'azione.
Questo squilibrio spiega perché le fondamenta aziendali contano più di un punteggio isolato sulla sicurezza del modello. Un modello più sicuro non può compensare credenziali condivise, autorizzazioni eccessive, log mancanti o un workflow di produzione privo di proprietario.
L'identità deve seguire l'agente in ogni chiamata agli strumenti
Un agente nominato con accesso permanente ed eccessivo resta insicuro; l'identità deve essere associata a un'autorizzazione circoscritta e a un'attribuzione completa.
L'identità è la prima fondazione perché ogni controllo successivo necessita di un soggetto. I sistemi di sicurezza devono sapere quale agente ha richiesto l'accesso, quale persona o servizio ha delegato l'autorità e quale istanza ha eseguito l'azione.
L'utilizzo di un service account condiviso interrompe questa catena. Gli investigatori possono scoprire che un account ha interrogato un database, ma non quale agente ha avviato la richiesta. Possono inoltre non rilevare se l'azione ha seguito un'attività umana approvata.
Un'identità distinta dovrebbe persistere tra le chiamate al modello dell'agente, i componenti di pianificazione, gli strumenti e i servizi a valle. L'identità non necessita di una credenziale permanente. Necessita di una relazione tracciabile tra ogni credenziale temporanea e l'agente originario.
L'autorizzazione determina ciò che quell'identità può fare. Il privilegio minimo limita l'accesso alle risorse e alle azioni minime necessarie per uno scopo approvato. Per gli agenti, l'ambito dovrebbe riflettere anche tempo, attività e autorità dell'utente delegante.
Un agente per le spese potrebbe dover leggere la ricevuta di un dipendente e creare una sola bozza di rimborso. Non dovrebbe poter consultare il record di ogni dipendente né approvare il proprio pagamento. Il permesso dovrebbe scadere al termine dell'attività.
Questo è più rigoroso che concedere all'agente gli stessi permessi del suo sponsor umano. Un responsabile può accedere a migliaia di record per molte attività legittime. Un agente che esegue una sola attività delegata dovrebbe ricevere soltanto il sottoinsieme pertinente.
I progetti moderni ricorrono sempre più all'autorizzazione just-in-time. L'agente richiede un accesso strettamente circoscritto quando necessario e un motore di policy valuta tale richiesta. Le azioni a rischio più elevato possono richiedere che una persona approvi l'operazione esatta.
Model Context Protocol, comunemente chiamato MCP, standardizza il modo in cui le applicazioni AI si connettono a strumenti e fonti di dati. La standardizzazione può migliorare la visibilità, ma MCP non rende automaticamente sicura un'integrazione.
Il server richiede comunque autenticazione, autorizzazione, convalida degli input e logging. Il client può comunque essere manipolato da contenuti ostili. Un server MCP con privilegi ampi può trasformare una comoda integrazione in un punto concentrato di fallimento dei controlli.
Lo stesso avvertimento si applica alla comunicazione tra agenti. Un agente potrebbe delegare la ricerca a un altro e poi utilizzare il risultato per attivare un'azione. I record di sicurezza devono preservare tale catena di delega invece di trattare la richiesta finale come un evento isolato.
L'autenticazione risponde a quale identità ha effettuato una richiesta. L'autorizzazione risponde se tale richiesta era consentita. La sicurezza degli agenti deve anche valutare se la richiesta è coerente con l'obiettivo approvato e il contesto attuale.
Quest'ultimo controllo è difficile. Un agente di approvvigionamento può avere un'autorizzazione legittima per interrogare i fornitori. La stessa autorizzazione diventa sospetta se improvvisamente estrae l'intero database dei fornitori dopo aver letto un documento dannoso.
È qui che il monitoraggio comportamentale integra le policy statiche. Il sistema dovrebbe confrontare l'attività corrente con lo scopo dichiarato dell'agente, la normale sequenza di strumenti, l'ambito dei dati e i limiti delle transazioni. Deviazioni inattese meritano una revisione o una sospensione automatica.
Il framework AEGIS di Forrester sostiene che la sicurezza degli agenti debba collegare governance, identità, dati, sicurezza applicativa, operazioni di difesa dalle minacce e zero trust. Il punto centrale è che l'autonomia attraversa controlli in precedenza gestiti come discipline separate.
Zero trust significa che ogni richiesta viene valutata esplicitamente, anziché ereditare fiducia dalla posizione nella rete. Applicato agli agenti, richiede identità verificate, accessi circoscritti, controlli contestuali e osservazione continua.
Questa base migliora anche la sicurezza operativa. Un agente configurato in modo errato e un agente compromesso possono produrre azioni simili. Identità e autorizzazioni solide aiutano a contenere entrambi i casi senza richiedere al sistema di sicurezza di determinare prima l'intento.
Il titolo individuato tramite Google News chiede se le fondamenta aziendali siano pronte. L'identità offre un test pratico: l'azienda può fermare un singolo agente senza disabilitare ogni workflow che condivide le sue credenziali?
Se la risposta è no, l'organizzazione non dispone ancora di un controllo a livello di agente. Ha accesso applicativo con un livello AI aggiunto.
Il Prompt Injection Trasforma Dati Attendibili in un Percorso di Attacco
Gli agenti non si limitano a consumare testo non attendibile; possono trasformarlo in istruzioni con accesso agli strumenti aziendali.
Il prompt injection si verifica quando un contenuto influenza un modello affinché ignori o reinterpreti le istruzioni previste. L'indicazione dannosa può comparire in una pagina web, un'email, un documento, un ticket di assistenza, un commento nel codice o un record di conoscenza recuperato.
Un lettore umano può riconoscere un linguaggio sospetto e rifiutarlo. Un agente può elaborare lo stesso contenuto come contesto utile. Se l'agente può chiamare strumenti, il testo dell'attaccante può influenzare azioni che vanno oltre il modello.
Immaginate un agente che esamina documenti dei fornitori. Un documento contiene testo nascosto che indica all'agente di recuperare prezzi riservati e inviarli a un indirizzo esterno. La richiesta è dannosa anche se il file è arrivato tramite un repository approvato.
Il filtraggio degli input può intercettare istruzioni evidenti, ma non può risolvere ogni conflitto tra dati e comandi. Il linguaggio naturale svolge entrambi i ruoli. L'agente deve interpretare quale contenuto descriva il compito e quale tenti di modificarlo.
Questa ambiguità distingue la sicurezza degli agenti dalla tradizionale scansione antimalware. Un documento non deve contenere codice eseguibile. Può sfruttare il comportamento del modello nell'eseguire istruzioni usando linguaggio ordinario.
I rischi agentici di OWASP includono dirottamento degli obiettivi, uso improprio degli strumenti, abuso dell'identità, avvelenamento della memoria, comunicazione insicura tra agenti e guasti a cascata. Queste categorie collegano il comportamento del modello a conseguenze di sicurezza familiari.
Le restrizioni sugli strumenti offrono una difesa. Un agente di ricerca che legge soltanto fonti approvate non può inviare email né modificare i record dei clienti. Il suo output compromesso può comunque fuorviare una persona, ma il suo raggio d'impatto diretto resta più limitato.
La separazione dei compiti ne offre un'altra. Un componente può preparare un'azione, mentre un diverso servizio di policy la approva. L'agente non dovrebbe decidere, autorizzare ed eseguire una transazione ad alto impatto attraverso lo stesso percorso di ragionamento non verificato.
Anche la classificazione dei dati è importante. Il livello degli strumenti dovrebbe sapere se le informazioni richieste sono pubbliche, interne, riservate o regolamentate. Il piano generato dall'agente non dovrebbe prevalere su una policy che blocca la trasmissione di dati soggetti a restrizioni.
La memoria introduce un rischio meno visibile. Gli agenti possono archiviare riepiloghi, preferenze, fatti recuperati o istruzioni precedenti per attività successive. Un attaccante che avvelena quella memoria può influenzare il comportamento futuro dopo che l'input dannoso originale è scomparso.
I team devono distinguere il contesto di lavoro dalla memoria persistente. I dati temporanei relativi all'attività dovrebbero scadere. I record permanenti dovrebbero identificare la fonte, l'ora di creazione, la policy di accesso e lo stato di convalida.
Questo è rilevante per qualunque organizzazione che costruisca una base di conoscenza AI. Un recupero utile dipende da provenienza, autorizzazioni e una chiara separazione tra record autorevoli e materiale non attendibile.
Gli sviluppatori devono inoltre presumere che le protezioni falliscano. Il fatto che un modello rifiuti una richiesta pericolosa durante i test non garantisce un comportamento coerente con formulazioni, strumenti e contesti recuperati diversi.
I test pre-distribuzione dovrebbero includere attacchi in più fasi, non solo singoli prompt dannosi. Il test dovrebbe esaminare se un agente modifica il proprio piano, cerca strumenti alternativi o trasferisce istruzioni contaminate a un altro agente.
I controlli in fase di esecuzione restano necessari perché l'ambiente operativo cambia. Arrivano nuovi documenti, le autorizzazioni si ampliano, gli strumenti ricevono aggiornamenti e i modelli cambiano. Un risultato di test sicuro è una prova relativa a una configurazione in un determinato momento.
Da qui nasce il principale compromesso dell'articolo. Più contesto e più strumenti rendono gli agenti utili, ma aumentano anche il numero di percorsi dall'input non attendibile a un'azione rilevante.
Le imprese non devono eliminare ogni decisione incerta del modello. Hanno bisogno di un'architettura che impedisca alle decisioni incerte di ricevere autorità illimitata.
I Log di Audit Devono Registrare Decisioni, Delega e Conseguenze
I log tradizionali registrano eventi di sistema, ma le indagini sugli agenti richiedono l'intero percorso dalla richiesta umana alla decisione del modello e all'azione esterna.
Un registro utile dell'agente inizia dal compito che ha dato avvio al processo. Dovrebbe identificare il richiedente, l'agente, lo scopo approvato, la versione della policy, la configurazione del modello, gli strumenti, le fonti di dati e le autorizzazioni delegate.
Il registro dovrebbe poi acquisire le richieste agli strumenti e i relativi risultati. Dovrebbe mostrare quale identità ha agito, a quale risorsa ha avuto accesso, quale policy ha consentito l'operazione e se un essere umano l'ha approvata.
La registrazione del ragionamento interno presenta complicazioni legali, di privacy e tecniche. Le tracce di ragionamento del modello possono contenere informazioni sensibili e potrebbero non spiegare in modo affidabile il comportamento del modello. Le imprese dovrebbero privilegiare input osservabili, decisioni, chiamate agli strumenti e risultati.
Questa distinzione conta durante un incidente. Gli investigatori necessitano di prove sufficienti per riprodurre la sequenza. Non hanno bisogno di una narrazione non verificata che sostenga di rivelare con esattezza cosa il modello abbia “pensato”.
I log devono resistere alle alterazioni. Un agente autorizzato a modificare un sistema non dovrebbe poter cancellare l'unica prova che descrive tale modifica. I record di sicurezza richiedono controlli di accesso separati, regole di conservazione e protezione dell'integrità.
L'osservabilità necessita inoltre di correlazione tra piattaforme. Un workflow può iniziare in un'applicazione di collaborazione, invocare un modello ospitato, interrogare un database cloud, chiamare un'API esterna e aggiornare una piattaforma clienti.
Ogni servizio può produrre un log tecnicamente corretto, mentre la storia complessiva resta invisibile. Un identificatore di transazione condiviso dovrebbe collegare la richiesta originale a ogni fase delegata.
I team devono decidere cosa attiva un intervento. Un accesso non riuscito è facile da classificare. Un agente che modifica la propria sequenza di strumenti potrebbe adattarsi in modo innocuo oppure mostrare le prime prove di una manipolazione.
Le policy possono iniziare con confini ad alta affidabilità. I sistemi di sicurezza possono bloccare destinazioni non approvate, escalation di privilegi, recupero eccessivo di dati, transazioni vietate e azioni al di fuori dei periodi operativi definiti.
L'analisi comportamentale può poi identificare deviazioni più sottili. Tra gli esempi figurano combinazioni insolite di strumenti, richieste negate ripetute, enumerazione rapida dei dati, nuovi schemi di delega o accessi non correlati all'obiettivo dichiarato.
La revisione umana dovrebbe concentrarsi su questi casi ambigui. Richiedere l'approvazione per ogni azione a basso rischio annulla l'efficienza promessa dagli agenti. Consentire ogni azione elimina la responsabilità di cui le imprese hanno bisogno.
L'organizzazione necessita quindi di livelli di rischio. Leggere una pagina web pubblica è diverso dall'esportare dati dei clienti. Redigere un messaggio è diverso dall'inviarlo. Preparare una modifica al codice è diverso dal distribuirla.
Ogni livello dovrebbe specificare requisiti di autonomia, approvazione, registrazione, test e rollback. La classificazione appartiene al processo aziendale, non soltanto al modello.
Il rollback merita particolare attenzione. Alcune azioni possono essere invertite, altre no. Un file di staging eliminato può essere recuperabile. Un segreto divulgato, un pagamento completato o un messaggio pubblico possono creare conseguenze permanenti.
I piani di risposta agli incidenti devono includere il contenimento degli agenti. I team hanno bisogno di un metodo rapido per sospendere un'identità, revocare credenziali temporanee, isolare la memoria interessata, preservare i record e identificare gli agenti dipendenti.
Il settore sta iniziando a formalizzare la condivisione degli incidenti che coinvolgono gli agenti. Il framework SAFE proposto coprirebbe accessi non autorizzati, violazioni di informazioni riservate, tentativi di sondaggio persistenti e alcuni quasi incidenti.
Secondo la proposta pubblicata, le prove rilevanti possono includere prompt, tracce, chiamate agli strumenti, identità, autorizzazioni e credenziali. L'iniziativa resta una proposta, ma il suo elenco di prove illustra quanto contesto richieda un incidente che coinvolge un agente.
La segnalazione condivisa potrebbe far emergere schemi di guasto ricorrenti che le singole aziende non riescono a vedere. Potrebbe anche sollevare interrogativi difficili su riservatezza, responsabilità e misure di gravità comparabili.
Il titolo di Google News verifica in definitiva se le aziende sanno rispondere a domande forensi fondamentali. Quale agente ha agito, chi lo ha autorizzato, quali informazioni lo hanno influenzato, quale policy ha consentito l'azione e cosa è cambiato in seguito?
Se queste risposte richiedono una ricostruzione manuale tra più team, la base di sicurezza non è pronta per un'autonomia ordinaria degli agenti.
Cosa Dovrebbero Monitorare i Leader della Sicurezza
La prossima fase sarà misurata da controlli applicabili e fallimenti segnalati, non dal numero di fornitori che aggiungono l'etichetta “agente”.
Il primo segnale è l'adozione di identità distinte per gli agenti. Microsoft, Cisco e altri fornitori di piattaforme stanno introducendo funzionalità di identità incentrate sugli agenti. Le imprese dovrebbero osservare se i clienti le distribuiscono tra agenti di terze parti e personalizzati, non solo nell'ambiente di un singolo fornitore.
Un'ampia copertura delle identità rafforzerebbe l'idea che gli attuali programmi di identità possano evolvere attorno ad attori non umani. Una copertura limitata lascerebbe le organizzazioni con registri separati degli agenti e applicazione incoerente delle policy.
Il secondo segnale è costituito dalle policy in fase di esecuzione applicate ai protocolli degli strumenti. MCP e altri standard di connessione rendono più semplice creare integrazioni per gli agenti. Il progresso della sicurezza dipende dalla capacità dei gateway di autenticare costantemente gli agenti, limitare le autorizzazioni, ispezionare il contesto e registrare le azioni.
Un protocollo può essere ampiamente adottato prima che i suoi controlli di governance maturino. I team di sicurezza dovrebbero misurare azioni negate, credenziali temporanee, eccezioni alle policy e connessioni a strumenti non registrate, anziché contare i server configurati.
Il terzo segnale è una divulgazione credibile degli incidenti. Le segnalazioni pubbliche dovrebbero rivelare se i fallimenti riguardano prompt injection, autorizzazioni eccessive, delega errata, memoria avvelenata, strumenti non sicuri o assenza di approvazione umana.
I record degli incidenti aiuteranno le imprese a distinguere i comuni fallimenti operativi dalle minacce speculative. Verificheranno inoltre se i log attuali acquisiscono prove sufficienti per un'analisi significativa.
I leader della sicurezza non dovrebbero aspettare un titolo che descriva una grave perdita. Possono valutare la preparazione attraverso esercitazioni controllate già ora.
Assegnate a un agente di test un obiettivo aziendale valido e inserite istruzioni in conflitto nei contenuti recuperati. Osservate se segue il contenuto, richiede un accesso più ampio, tenta un altro strumento o si ferma per una revisione.
Poi revocate la sua identità durante il flusso di lavoro. Verificate che ogni strumento neghi le richieste successive e che gli agenti dipendenti ricevano la modifica. Una revoca efficace su una sola piattaforma genera una falsa fiducia.
Eseguite un secondo esercizio incentrato sulla titolarità. Chiedete chi approva un aumento dei permessi, chi riceve un avviso, chi può sospendere l'agente e chi decide se torna operativo.
Le risposte dovrebbero indicare ruoli nominativi, non reparti. “Sicurezza e IT” non è una procedura operativa con responsabilità definite.
Le organizzazioni dovrebbero inoltre misurare quanti agenti restano sconosciuti. Risultati delle attività di discovery, identità orfane, credenziali condivise e endpoint di strumenti non approvati rivelano le lacune di controllo più chiaramente degli annunci di deployment.
Anche i knowledge worker hanno un ruolo in questo processo. Dovrebbero sapere quando un agente agisce sotto la loro autorità e quali azioni richiedono conferma. La delega non dovrebbe nascondere la responsabilità dietro un'interfaccia automatizzata.
Gli sviluppatori hanno bisogno di modelli approvati per identità, accesso agli strumenti, segreti, log, test e memoria. Richiedere a ogni team di inventare queste basi garantisce una protezione incoerente.
Gli acquirenti aziendali dovrebbero chiedere ai fornitori come le identità degli agenti si associano agli sponsor umani, come scadono i permessi e come le azioni compaiono nei sistemi di sicurezza esistenti. Dovrebbero inoltre verificare se i log rimangono disponibili dopo la disabilitazione di un agente.
La lezione centrale di Google News non è che le imprese debbano smettere di usare gli agenti. È che l'autonomia dovrebbe seguire una maturità di controllo verificata.
Un'organizzazione pronta per gli agenti può identificare ciascuno di essi, vincolare ogni chiamata agli strumenti, preservare le catene di delega, rilevare i cambiamenti di comportamento e revocare rapidamente l'autorità. Può anche spiegare chi resta responsabile quando l'automazione fallisce.
Un'organizzazione non pronta vede soltanto un'interfaccia utile. Dietro di essa, credenziali condivise, permessi estesi, dati con livelli di fiducia misti e log frammentati creano una struttura di autorità che nessuno governa pienamente.
I prossimi uno-tre mesi dovrebbero chiarire se le piattaforme di identità, i gateway di runtime e le iniziative di disclosure stanno convergendo verso pratiche comuni. Questa convergenza renderebbe più semplice la supervisione degli agenti in ambienti aziendali eterogenei.
Fino ad allora, ogni organizzazione dovrebbe considerare l'autonomia degli agenti come un accesso da guadagnare. Si inizi con attività circoscritte, azioni reversibili, permessi di breve durata e flussi di lavoro osservabili. L'autorità va ampliata solo quando le evidenze dimostrano che i controlli funzionano.
La domanda per i lettori è immediata: se domani uno dei vostri agenti effettuasse una modifica non autorizzata, il vostro team riuscirebbe a identificarlo, fermarlo e ricostruire l'intera catena? In caso contrario, usate l'ultimo avvertimento di Google News come stimolo per censire gli agenti, assegnare responsabili identificabili e testare la revoca prima di concedere maggiore autonomia.
