La ricerca di SecurityHQ sugli agenti AI rileva che le policy superano l'accountability negli incidenti
SecurityHQ ha pubblicato una ricerca che mostra come il 76% dei leader della cybersicurezza intervistati disponga di policy formali di accountability per l'AI, mentre solo il 17% sia in grado di ricostruire l'attività degli agenti in pochi minuti. La ricerca di SecurityHQ sugli agenti AI, sviluppata con Datadog, mette in luce una tensione concreta: assegnare la responsabilità non rende necessariamente spiegabile una decisione automatizzata.
Pubblicati il 15 ottobre 2026, i risultati arrivano mentre gli agenti aziendali ottengono l'autorizzazione a svolgere attività nei sistemi aziendali. Gli agenti AI sono sistemi software che utilizzano modelli e strumenti connessi per perseguire compiti. La loro autorità solleva interrogativi a cui le sole policy scritte non possono rispondere.
L'espansione di Security Copilot da parte di Microsoft offre un riferimento concreto per questo passaggio verso il lavoro di sicurezza delegato. La pressione ora ricade sui responsabili della sicurezza, sui proprietari delle applicazioni e sui fornitori, chiamati a collegare le azioni automatizzate a prove e a un'autorità umana responsabile.
La ricerca di SecurityHQ sugli agenti AI separa le policy dalla preparazione
Lo studio ha intervistato 204 responsabili della cybersicurezza in organizzazioni di medie e grandi dimensioni. Secondo l'annuncio della ricerca, il 45% aveva vissuto un incidente che coinvolgeva agenti AI o automazione in cui l'accountability non era chiara.
Questa formulazione merita attenzione. La categoria degli incidenti include l'automazione, quindi il risultato non dimostra che il 45% abbia subito una violazione causata da un agente AI autonomo. Un'accountability poco chiara descrive inoltre un problema organizzativo, non uno specifico guasto tecnico o livello di danno.
Il dato riguarda la capacità delle organizzazioni di spiegare azioni delegate quando la responsabilità viene contestata. Una policy può identificare un responsabile senza mostrare quale istruzione, autorizzazione o interazione di sistema abbia prodotto un esito.
Le conclusioni pubbliche di SecurityHQ sull'accountability distinguono inoltre la visibilità storica dalla preparazione immediata alle indagini. Solo il 49% ha dichiarato di poter ricostruire completamente le azioni di un agente nei 30 giorni precedenti.
Questa distinzione cambia il modo in cui gli acquirenti dovrebbero leggere i risultati. Conservare i registri e rispondere a domande urgenti sono capacità correlate, ma rispondono a esigenze operative diverse. Un'organizzazione potrebbe conservare prove pertinenti pur richiedendo ancora un notevole lavoro manuale per collegarle.
Al contrario, una dashboard potrebbe riassumere l'attività recente senza conservare dettagli sufficienti per un'indagine successiva. Nessuna delle due possibilità stabilisce cosa sia accaduto nelle organizzazioni intervistate. Entrambe spiegano perché una singola dichiarazione di visibilità richieda un esame più approfondito.
Il cambiamento importante è nell'impostazione della ricerca. SecurityHQ affianca la titolarità delle policy alla capacità di stabilire una sequenza di azioni, rendendo visibile la distanza tra queste capacità.
Per gli acquirenti aziendali, questo crea una domanda più esigente in fase di approvvigionamento. La spiegazione di un fornitore sulla governance dovrebbe collegarsi alle prove che un cliente riceve dopo l'azione di un agente.
Per i team di sicurezza interni, la stessa distinzione influisce sulla reportistica. L'esistenza di un processo di approvazione non dimostra che gli investigatori possano recuperare l'approvazione associata a un'azione contestata.
Una policy di accountability resta utile perché definisce le aspettative. Il suo valore operativo dipende dalla capacità delle persone di applicare tali aspettative a un evento specifico.
Il sondaggio non dimostra che le organizzazioni con policy abbiano registrato meno incidenti. Non mostra neppure che l'acquisto di ulteriore monitoraggio risolverebbe l'incertezza sulla responsabilità.
Il suo contributo più circoscritto resta comunque rilevante. Le imprese possono allocare formalmente la responsabilità pur non disponendo delle prove necessarie per esercitarla sotto pressione.
Ecco perché la notizia conta oltre l'ennesimo sondaggio sul rischio dell'AI. La ricerca mette in discussione se le consuete misure di governance descrivano una reale preparazione quando il software riceve autorità delegata.
Il lavoro di sicurezza delegato mette sotto pressione acquirenti e operatori
I responsabili della sicurezza subiscono pressioni perché gli agenti operano all'interno di sistemi che già dividono la responsabilità tra team diversi. Un proprietario di applicazione può autorizzare un flusso di lavoro mentre un altro team ne gestisce le credenziali e un altro ancora gestisce la risposta agli incidenti.
Una credenziale è la prova digitale che il software presenta quando richiede l'accesso. Quando più flussi di lavoro condividono tale prova, identificare l'account può lasciare irrisolto l'effettivo iniziatore.
Una questione di titolarità apparentemente semplice si divide quindi in più domande. Chi ha approvato il compito, chi ha concesso l'accesso, chi ha gestito l'integrazione e chi avrebbe potuto interrompere l'esecuzione?
Questi ruoli non devono necessariamente appartenere alla stessa persona. La difficoltà emerge quando l'organizzazione non riesce a collegarli durante un'indagine.
Delegare il lavoro aumenta l'importanza di sapere dove l'autorità inizia, cambia e termina. Un dirigente nominato non può risolvere un incidente semplicemente comparendo in un documento di governance.
Le conseguenze operative si estendono oltre i dipartimenti di sicurezza. I responsabili aziendali devono comprendere se l'azione di un agente abbia perseguito un obiettivo approvato. I team applicativi necessitano di contesto sufficiente per distinguere il comportamento previsto dall'uso improprio.
I team legali e di gestione del rischio affrontano una preoccupazione diversa: se il record disponibile supporti la spiegazione che l'azienda fornisce in seguito. Una narrazione sicura di sé ha valore limitato quando le prove a suo sostegno restano frammentate.
Anche i fornitori subiscono pressioni perché i clienti dipendono dalla progettazione del prodotto per parti di quel record. I clienti non possono recuperare autonomamente informazioni che un servizio non espone né conserva.
Microsoft illustra perché queste domande siano diventate immediate. Il suo annuncio sugli agenti di sicurezza del marzo 2025 ha introdotto agenti per attività tra cui il triage del phishing, ovvero l'ordinamento e la valutazione di messaggi sospettati di essere ingannevoli.
L'azienda ha presentato queste capacità come un modo per ridurre il lavoro di routine dei difensori. Ciò fornisce un contesto di distribuzione concreto senza dimostrare che i prodotti Microsoft presentino le lacune riportate da SecurityHQ.
Il confronto riguarda la proposta d'acquisto. Microsoft descrive il lavoro che gli agenti possono assumere; SecurityHQ chiede se le organizzazioni possano rendere conto dell'attività delegata in seguito.
Queste proposte appartengono alla stessa discussione d'acquisto. Un'affermazione di efficienza diventa più utile quando gli acquirenti possono valutare anche lo sforzo investigativo, le opzioni di intervento e la disponibilità delle prove.
Per un centro operativo di sicurezza, il team responsabile del monitoraggio e della risposta alle minacce, la riduzione del carico di lavoro di routine offre un'attrattiva evidente. Tuttavia, le azioni non risolte generano lavoro altrove.
Un analista che riceve la conclusione di un agente deve comunque comprenderne il fondamento quando le circostanze cambiano. Un altro investigatore potrebbe dover riesaminare quella decisione dopo la conclusione dell'attività originaria.
La pressione raggiunge quindi sia l'approvazione dell'implementazione sia le operazioni continuative. Gli acquirenti necessitano di prove sul comportamento del sistema dopo l'adozione, anche quando le sue azioni richiedono spiegazioni.
Questo non rende l'autonomia intrinsecamente inadatta al lavoro di sicurezza. Rende l'ambito dell'autorità delegata centrale per valutare se il compromesso operativo valga la pena.
Un'automazione utile necessita comunque di una traccia d'azione spiegabile
La tensione centrale è tra il tempo che gli agenti fanno risparmiare durante il lavoro ordinario e lo sforzo necessario per spiegare risultati eccezionali. Un'esecuzione più rapida crea valore solo entro limiti che l'organizzazione può difendere.
Si consideri il triage del phishing come flusso di lavoro illustrativo, non come un incidente riportato da SecurityHQ. Un agente esamina un messaggio sospetto, consulta informazioni connesse e produce una decisione.
Un'indagine utile collegherebbe il messaggio, le informazioni consultate, l'identità dell'agente e l'azione risultante. Se fosse stata applicata un'approvazione, gli investigatori dovrebbero anche collegare tale approvazione all'azione.
Registrare il completamento di un'attività risponde a una domanda più ristretta. Stabilisce un punto finale senza necessariamente spiegare come il sistema vi sia arrivato.
Una traccia d'azione responsabile deve collegare istruzioni, autorità, esecuzione ed esito. Il collegamento è importante perché ciascuno di questi elementi può diventare la parte contestata di un incidente.
L'istruzione potrebbe essere stata appropriata mentre l'autorizzazione era eccessiva. L'autorizzazione potrebbe essere stata appropriata mentre le informazioni incontrate durante l'esecuzione hanno reindirizzato il compito.
In alternativa, l'agente potrebbe aver seguito correttamente il flusso di lavoro richiesto mentre la regola aziendale sottostante era errata. L'accountability deve lasciare spazio anche a questa possibilità.
Un record incentrato interamente sul modello rischia di trascurare queste distinzioni. Un modello è solo una parte dell'applicazione che riceve istruzioni, recupera informazioni e richiama strumenti connessi.
Un'interfaccia di programmazione delle applicazioni, o API, è un'interfaccia software attraverso cui un sistema richiede le funzioni di un altro sistema. L'attività degli agenti può attraversare tali interfacce e i relativi record separati.
Ogni servizio può descrivere accuratamente la propria interazione locale lasciando al contempo difficile da ricostruire il compito complessivo. L'elemento mancante è la relazione tra record altrimenti validi.
Le conclusioni sulla sicurezza degli agenti di Salt Security del 13 ottobre offrono una prospettiva separata su questo problema. La sua ricerca ha combinato oltre 380 risposte a sondaggi con telemetria di produzione.
Solo il 12,5% degli intervistati ha dichiarato di poter tracciare in modo coerente percorsi completi degli agenti attraverso tutti gli agenti. Salt ha inoltre riferito che il 17,5% poteva interrompere automaticamente un agente dal comportamento inatteso in produzione.
Questi dati misurano capacità diverse rispetto alle domande di SecurityHQ sulla ricostruzione. Non dovrebbero essere combinati in un punteggio condiviso né trattati come stime equivalenti.
La loro rilevanza è concettuale: tracciare un'azione e interrompere un'azione sono parti separate del controllo. Una spiegazione completa dopo un incidente non ne annulla le conseguenze.
Analogamente, interrompere un flusso di lavoro non spiega perché si sia comportato in modo inatteso. Gli acquirenti devono valutare entrambe le capacità senza presumere che una garantisca l'altra.
Il confronto commerciale è quindi più ampio di una competizione tra singoli fornitori. SecurityHQ enfatizza l'accountability operativa, Microsoft descrive attività di sicurezza delegate e Salt mette in evidenza tracciamento e contenimento.
Queste prospettive si intersecano attorno a un problema comune per i clienti. Le imprese hanno bisogno che il lavoro delegato rimanga comprensibile oltre i confini dei prodotti, dove spesso diventa più difficile stabilire la responsabilità.
L'approvazione umana non può sostenere da sola l'intero peso dell'accountability
La revisione umana resta una risposta attraente perché colloca una persona vicino a una decisione rilevante. La sua utilità dipende da ciò che quella persona può ispezionare e autorizzare.
Un'approvazione legata a un obiettivo vago lascia spazio a disaccordi sulle azioni consentite. Un'approvazione legata a un'azione specifica stabilisce un confine più chiaro.
Anche allora, gli investigatori devono sapere se l'esecuzione ha corrisposto alla richiesta approvata. Approvazione ed esecuzione descrivono momenti diversi, potenzialmente separati da cambiamenti nelle informazioni o nelle condizioni del sistema.
La supervisione umana contribuisce all'accountability quando il registro dell'approvazione corrisponde all'autorità effettivamente esercitata. Il coinvolgimento di una persona non fornisce automaticamente lo storico tecnico mancante.
Questa distinzione conta per i dirigenti aziendali che si aspettano che un revisore finale assuma la responsabilità di un intero flusso di lavoro. Un revisore non può valutare in modo significativo informazioni che il sistema trattiene.
Conta anche per i team di prodotto che decidono dove collocare le fasi di approvazione. Interrompere ogni azione introduce attrito, mentre approvare un intero compito delega una discrezionalità più ampia.
Il compromesso pratico riguarda quali decisioni richiedono un intervento e quali limiti il software può imporre direttamente. Flussi di lavoro diversi giustificano risposte diverse perché le loro possibili conseguenze differiscono.
Un sistema che si limita a raccomandare una risposta pone una questione di autorità diversa rispetto a uno che modifica gli accessi. Il confronto rilevante riguarda l'azione consentita, non la presenza di un'etichetta AI.
Anche l'identità diventa più importante quando gli agenti operano oltre i confini organizzativi. L'autenticazione stabilisce chi o cosa sta effettuando una richiesta; l'autorizzazione determina cosa può fare chi la richiede.
Nessuna delle due funzioni, da sola, spiega lo scopo aziendale dietro una richiesta. Un'indagine trae beneficio dal collegare l'identità tecnica al compito e alla persona o al processo che lo ha delegato.
Il lavoro del NIST sull'identità degli agenti offre un riferimento istituzionale per questa sfida. A settembre, ha identificato lo sviluppo software come primo caso d'uso per l'implementazione.
Questo lavoro si concentra sull'identificazione, l'autenticazione e l'autorizzazione degli agenti nel ciclo di vita dello sviluppo software. Si tratta di uno sforzo di implementazione, non della prova che l'accountability aziendale sia stata risolta.
La direzione è importante perché l'accountability dipende in parte da come l'autorità si trasferisce attraverso il software. Standard e dimostrazioni possono contribuire a rendere queste relazioni più facili da esprimere in modo coerente.
Tuttavia, un'identità tecnica non può decidere chi debba assumersi la responsabilità di un risultato aziendale contestato. Le organizzazioni hanno comunque bisogno di responsabilità esplicite per distribuzione, manutenzione, revisione e intervento d'emergenza.
Registri chiari e ruoli chiari si rafforzano a vicenda. I registri aiutano a stabilire cosa è accaduto, mentre i ruoli determinano chi deve valutare e rispondere a tali evidenze.
La stessa distinzione si applica alla conoscenza organizzativa. Una base di conoscenza del team consultabile può supportare l'accesso a policy e responsabilità, mentre le evidenze di esecuzione stabiliscono ciò che i sistemi hanno effettivamente fatto.
Mantenere distinte queste funzioni aiuta a evitare un errore comune. Documentare il flusso di lavoro previsto non dimostra che una particolare esecuzione lo abbia seguito.
Il sondaggio solleva questioni che non può risolvere
La ricerca di SecurityHQ sugli agenti AI fornisce evidenze sull'esperienza e sulla fiducia dichiarate dai partecipanti. Non misura in modo indipendente il comportamento di ogni agente all'interno delle loro organizzazioni.
La preparazione auto-riferita può differire dalle prestazioni durante un incidente reale. I partecipanti possono interpretare in modo diverso ricostruzione, accountability e attività degli agenti.
Un dirigente potrebbe descrivere una forte supervisione centrale mentre distribuzioni decentralizzate rimangono fuori da tale visibilità. Un altro potrebbe segnalare una preparazione limitata pur disponendo di team capaci con processi interni poco familiari.
Queste possibilità non invalidano i risultati. Limitano la certezza delle conclusioni che se ne possono trarre.
Il sondaggio giustifica un esame critico della preparazione aziendale, anziché una stima universale dei fallimenti degli agenti. Le sue sintesi pubbliche non dovrebbero sostituire il test delle singole distribuzioni.
L'annuncio pubblico e la landing page non forniscono dettagli metodologici sufficienti per stabilire un'ampia rappresentatività. I lettori dovrebbero evitare di presumere che il campione rispecchi ogni settore o dimensione aziendale.
La combinazione di agenti AI e automazione nella domanda sugli incidenti crea un'altra limitazione. Non chiarisce quanto dell'incertezza segnalata sia derivata da agenti più recenti rispetto a flussi di lavoro automatizzati consolidati.
Questa distinzione conta nell'interpretare la novità. Le organizzazioni faticano da tempo ad attribuire la responsabilità tra integrazioni software, servizi esternalizzati e processi operativi condivisi.
Le distribuzioni di agenti possono complicare questo problema esistente senza rendere nuova ogni debolezza sottostante. Trattare l'intera questione come unica dell'AI rischia di oscurare fallimenti di controllo già noti.
Anche il rapporto tra policy e incidenti rimane irrisolto. I risultati aggregati non stabiliscono quali partecipanti disponessero di policy quando si sono verificati incidenti specifici.
Non possono quindi dimostrare che le policy non siano riuscite a prevenire gli incidenti, né che le organizzazioni prive di policy abbiano ottenuto risultati peggiori. Entrambe le affermazioni richiederebbero ulteriori evidenze.
La ricerca di SecurityHQ sugli agenti AI proviene inoltre da organizzazioni con interessi commerciali nella sicurezza e nel monitoraggio. Questo contesto merita di essere dichiarato senza respingere automaticamente le loro osservazioni.
La risposta scettica appropriata consiste nell'esaminare definizioni, metodologia ed evidenze riproducibili. Sponsorizzazione commerciale e risultati utili possono coesistere.
Una cautela simile vale per i confronti con i risultati di Salt. Domande, popolazioni e metodi di misurazione diversi impediscono una graduatoria netta della preparazione aziendale tra gli studi.
La concordanza su una preoccupazione generale non dimostra una concordanza nella prevalenza misurata. Gli studi offrono osservazioni separate su visibilità, autorità e intervento.
La ricerca non dimostra neppure che centralizzare un maggior numero di registri migliori sempre la sicurezza. I registri possono contenere informazioni sensibili e l'accesso alle evidenze investigative comporta responsabilità proprie.
L'implicazione analitica è più circoscritta: le organizzazioni necessitano di evidenze sufficienti per le decisioni che delegano. Ciò che è sufficiente dipende dall'azione e dalle sue conseguenze.
Una risposta convincente mostrerebbe come un flusso di lavoro specifico rimanga attribuibile durante un guasto. Un'affermazione più ampia secondo cui una piattaforma rende tutti gli agenti accountable richiede una base probatoria molto più solida.
Osservare le evidenze sugli incidenti, i controlli di prodotto e le implementazioni dell'identità
Nei prossimi mesi, gli sviluppi più utili mostreranno se le organizzazioni possono trasformare l'accountability dichiarata in una capacità operativa dimostrabile. I soli annunci di adozione lasceranno questa questione irrisolta.
Il primo segnale è la qualità delle ricostruzioni pubblicate degli incidenti e delle esercitazioni controllate. Resoconti utili collegherebbero il compito delegato, l'autorità pertinente, la sequenza delle azioni e l'intervento.
Dovrebbero inoltre identificare ciò che gli investigatori non sono riusciti a recuperare. Una ricostruzione incompleta ma trasparente fornisce più evidenze di un'assicurazione secondo cui un team ha mantenuto il controllo.
Dimostrazioni ripetute su flussi di lavoro diversi rafforzerebbero la fiducia nel fatto che le pratiche di accountability funzionino oltre un esempio preparato. Lacune persistenti rafforzerebbero la preoccupazione sollevata da SecurityHQ.
Il secondo segnale è costituito dalle evidenze di prodotto che collegano l'esecuzione degli agenti a indagine e contenimento. Gli acquirenti dovrebbero osservare ciò che i fornitori rendono disponibile ai clienti, anziché affidarsi a un linguaggio generale sulla governance.
Una dimostrazione significativa mostrerebbe come un investigatore segua un compito attraverso servizi connessi. Mostrerebbe inoltre cosa accade quando un operatore autorizzato interrompe il flusso di lavoro.
Contano sia il momento sia l'ambito dell'interruzione. Impedire l'azione successiva è diverso dal ripristinare modifiche già completate, e le dimostrazioni di prodotto dovrebbero rendere comprensibile questa distinzione.
Controlli più chiari sosterrebbero una delega più ampia laddove i clienti possano verificarne il comportamento. Lacune non spiegate tra registri locali rafforzerebbero l'argomentazione a favore di un'autorità più limitata.
Il terzo segnale è il progresso dell'implementazione relativa all'identità e all'autorizzazione degli agenti. Il caso d'uso annunciato dal NIST per lo sviluppo software offre un luogo concreto in cui osservare i risultati tecnici.
Esempi pratici potrebbero chiarire come l'autorità delegata rimanga attribuibile mentre il software passa tra servizi diversi. Il loro valore dipenderà dalla capacità delle organizzazioni di applicare l'approccio ai flussi di lavoro reali.
I progressi ridurrebbero l'ambiguità sull'identità tecnica, pur lasciando le decisioni sulla titolarità aziendale all'impresa. I ritardi lascerebbero i clienti maggiormente dipendenti da approcci specifici per prodotto.
Il prossimo parametro utile è verificare se le organizzazioni riescono a spiegare e interrompere attività delegate in condizioni realistiche. Questo parametro collega i risultati della ricerca alle decisioni che gli acquirenti devono già affrontare.
Per i lettori che valutano una distribuzione, la ricerca di SecurityHQ sugli agenti AI offre un motivo per esaminare le evidenze alla base delle garanzie esistenti. Iniziate con un flusso di lavoro rilevante che abbia già un responsabile. Chiedete a quel responsabile di spiegare un'esecuzione completata usando i registri oggi disponibili. Seguite l'istruzione, l'autorizzazione, l'azione e il risultato. Poi individuate chi può intervenire quando questi elementi smettono di corrispondere. I collegamenti mancanti rivelano un problema più specifico di una preoccupazione generale sulla sicurezza dell'AI. Creano inoltre una discussione più chiara con fornitori e team interni su ciò che deve migliorare. Prima di concedere un'autorità più ampia, chiedete una dimostrazione che renda visibili lo storico delle azioni e il confine dell'intervento. La vostra organizzazione può difendere questa spiegazione quando il risultato è contestato?
