Sondaggio CTech sulla sicurezza dell'AI: l'automazione alza l'asticella per i ricercatori umani
Il sondaggio di CTech sulla sicurezza dell'AI ha rilevato che l'automazione gestisce ormai una parte sostanziale del lavoro di ricerca, ma questo cambiamento sta aumentando le aspettative nei confronti delle persone che la supervisionano. Il sondaggio del 18 settembre ha coinvolto 30 ricercatori di sicurezza presso aziende israeliane di cybersecurity. I partecipanti hanno descritto l'AI impegnata nell'analisi dei log, nella revisione della documentazione, nelle prime scansioni del codice e nelle indagini parallele.
Questa efficienza comporta un netto ribaltamento. Una ricerca più rapida non rende meno importante un giudizio solido. Offre ad assunzioni deboli, istruzioni incomplete e permessi eccessivi più occasioni per causare danni alla velocità delle macchine.
I ricercatori di sicurezza si stanno quindi spostando dall'indagine manuale verso l'orchestrazione, la convalida e la responsabilità. Il loro avversario emergente non è semplicemente un modello AI o un attaccante automatizzato. È l'automazione priva di un giudizio umano affidabile.
Il cambiamento va oltre i team di ricerca specializzati. Le imprese stanno riempiendo i propri ambienti di agenti, account di servizio, chiavi di interfaccia di programmazione delle applicazioni e altre identità non umane. Molte possono leggere dati sensibili o compiere azioni attraverso sistemi connessi.
Nel frattempo, gli attaccanti possono utilizzare un'automazione simile per esplorare vulnerabilità e accelerarne lo sfruttamento. I difensori devono automatizzare senza fidarsi di ogni conclusione generata. Devono inoltre proteggere gli agenti che svolgono quel lavoro.
Il risultato è un nuovo standard impegnativo per la professione. I ricercatori hanno bisogno della profondità tecnica per mettere in discussione un modello, della disciplina operativa per controllare gli agenti e delle capacità comunicative per definire obiettivi precisi.
Il sondaggio CTech sulla sicurezza dell'AI mostra cosa è cambiato
L'AI ha assorbito le attività di sicurezza ripetitive, spostando il valore del ricercatore dall'output manuale verso direzione, verifica e giudizio tecnico.
Il sondaggio sui ricercatori di sicurezza ha raccolto le risposte di 30 professionisti attivi nel settore israeliano della cybersecurity. Non si è trattato di uno studio controllato sulla produttività. Ha offerto invece una visione strutturata di come i team di ricerca attivi descrivono il cambiamento del proprio lavoro.
Ogni azienda nel sondaggio ha dichiarato che l'AI aveva assunto compiti quali l'analisi dei log, la revisione della documentazione e le prime scansioni del codice. Un quarto degli intervistati ha esplicitamente descritto la tecnologia come un moltiplicatore della produttività individuale.
Yuval Barak, founding research engineer presso Astelia, ha formulato l'affermazione più forte del sondaggio sulla produttività. Ha dichiarato che gli agenti avevano portato l'output di ciascun ricercatore a circa dieci volte il livello precedente, gestendo il lavoro più oneroso.
Questa cifra riflette la valutazione di un professionista, non un parametro di riferimento del settore verificato in modo indipendente. Tuttavia, il cambiamento di flusso di lavoro sottostante è apparso con coerenza nelle risposte.
Un ricercatore doveva un tempo raccogliere log, cercare nella documentazione, confrontare percorsi del codice e organizzare potenziali risultati prima di verificare un'ipotesi. Un agente può ora eseguire simultaneamente diversi di questi passaggi.
Il ruolo umano inizia prima e termina dopo. I ricercatori devono definire la domanda, selezionare gli strumenti, limitare gli accessi, esaminare le prove e decidere se una vulnerabilità segnalata sia reale.
Roy Itzhaky, ricercatore di sicurezza nell'organizzazione del chief technology officer di Linx Security, ha descritto questo ruolo come quello di un direttore anziché di uno scavatore. L'agente esplora diversi percorsi, mentre il ricercatore li mantiene allineati e giudica i risultati.
Questa distinzione è importante perché la ricerca non si misura dal numero di piste prodotte da un sistema. Un risultato credibile deve essere riproducibile, rilevante e supportato da prove.
La scansione automatizzata può aumentare il numero di ipotesi senza migliorarne la qualità. Può inoltre nascondere l'incertezza dietro una prosa sicura di sé o artefatti tecnici convincenti.
Un modello potrebbe identificare codice sospetto e proporre un percorso di attacco plausibile. Il ricercatore deve comunque stabilire se il percorso sia raggiungibile, se i controlli esistenti lo blocchino e se lo sfruttamento produca un impatto significativo.
Lo stesso principio si applica al lavoro sulla documentazione. L'AI può riassumere indagini precedenti e far emergere risultati correlati. Non può garantire che il contesto sia aggiornato, completo o applicabile a un nuovo ambiente.
Questo cambia il modo in cui i team gestiscono la memoria istituzionale. Barak ha sostenuto che la conoscenza può diventare una proprietà del team anziché restare nelle mani dei singoli ricercatori.
Quel risultato richiede più che aggiungere un chatbot a una raccolta di documenti. I team hanno bisogno di prove organizzate, decisioni tracciabili e controlli di accesso che distinguano i risultati affidabili dalle speculazioni non concluse.
Una base di conoscenza ricercabile può sostenere questa transizione quando preserva il contesto delle fonti. Senza provenienza, un recupero più rapido può diffondere vecchie assunzioni con la stessa velocità della conoscenza valida.
L'evento è quindi più ampio di una semplice storia di produttività. L'AI sta cambiando dove i ricercatori concentrano il proprio impegno e dove i fallimenti di sicurezza possono entrare nel processo.
Il lavoro ripetitivo si sta riducendo. Cresce l'onere di specificare, supervisionare e convalidare il lavoro automatizzato.
Una ricerca più rapida mette sotto pressione i team di sicurezza
Il guadagno di produttività crea una nuova base di riferimento, costringendo i ricercatori a fornire risultati convalidati più rapidamente mentre gli attaccanti ottengono accesso a un'automazione simile.
I team di sicurezza subiscono pressioni da entrambi i lati del flusso di lavoro. Le loro organizzazioni si aspettano più output, mentre gli avversari possono usare l'AI per abbreviare la ricognizione e la sperimentazione.
Il sondaggio CTech sulla sicurezza dell'AI mostra quanto rapidamente si siano adeguate le aspettative interne. Se un agente può esaminare documentazione o scansionare codice in pochi minuti, una lunga coda manuale diventa più difficile da giustificare.
Ofri Ziv, cofondatore e vicepresidente della ricerca presso Tenzai, ha affermato che il lavoro che in precedenza rimaneva in fase di ricerca per mesi deve ora essere valutato, rafforzato e consegnato entro settimane. Questo cambiamento collega direttamente la performance della ricerca alla consegna del prodotto.
Una consegna più rapida può migliorare la difesa quando i team mantengono la convalida. Può anche incoraggiare risultati prematuri, avvisi rumorosi o controlli testati in modo inadeguato.
La pressione è particolarmente visibile nella gestione delle vulnerabilità. Le organizzazioni devono trovare debolezze sfruttabili, assegnare loro priorità, sviluppare correzioni e verificare tali correzioni in ambienti in evoluzione.
Il team Mandiant di Google ha descritto un modello operativo simile. Il suo framework di revisione agentica combina più agenti con convalida strutturata e competenza umana.
Il framework è progettato per aiutare gli esperti a esaminare il codice sorgente, individuare percorsi di sfruttamento e testare potenziali vulnerabilità. La sua struttura è importante perché l'esplorazione senza vincoli da parte dei modelli può sprecare tempo o produrre conclusioni prive di supporto.
La velocità da sola non risolve il tradizionale svantaggio dei difensori. A un attaccante basta un percorso praticabile, mentre un difensore deve ridurre l'esposizione su molte risorse, identità e applicazioni.
L'AI può aiutare i difensori a parallelizzare questo lavoro. Aiuta anche gli attaccanti ad automatizzare le ricerche, adattare tecniche pubbliche ed esaminare più frequentemente i sistemi esposti.
Google Cloud ha riferito che l'intervallo tra la divulgazione di una vulnerabilità e il suo sfruttamento attivo è sceso da settimane a giorni durante la seconda metà del 2025. Questa osservazione rafforza la necessità di una scoperta continua e di una convalida difensiva più rapida.
Non dimostra che l'AI abbia causato ogni riduzione della finestra di sfruttamento. Mostra però perché il lavoro di sicurezza periodico è sempre meno compatibile con le attuali condizioni operative.
Un penetration test svolto due volte l'anno cattura una visione temporanea di un ambiente. Nuovo codice, permessi, servizi e integrazioni possono rendere questa visione obsoleta subito dopo la consegna.
Quattro aziende del sondaggio CTech hanno dichiarato di aver creato hacker AI proprietari o ambienti interni di addestramento. Questi sistemi simulano continuamente gli attacchi e verificano come le debolezze potrebbero manifestarsi in produzione.
I partecipanti al sondaggio hanno descritto uno standard di zero falsi positivi per questi programmi. Questo standard è un'aspirazione che richiede prove, non una proprietà generale degli strumenti di sicurezza AI.
I falsi positivi comportano ancora costi reali. Consumano tempo di indagine, interrompono i team di ingegneria e possono abituare gli utenti a ignorare gli avvisi futuri.
I falsi negativi sono più pericolosi. Un agente potrebbe non rilevare una tecnica innovativa perché i suoi dati di addestramento o gli strumenti disponibili non rappresentano l'attacco.
I responsabili della sicurezza devono quindi valutare l'automazione attraverso risultati convalidati. Misure utili includono risultati riproducibili, copertura di rilevamento, tempo di correzione e tasso di conclusioni degli agenti respinte.
La risposta imposta ai ricercatori è chiara. I team devono automatizzare la scoperta ripetitiva investendo al contempo più intensamente in revisione, test e gestione delle prove.
Questa pressione probabilmente persisterà. Una volta che un'organizzazione integra l'automazione nella propria pipeline di ricerca, tornare a una produttività manuale più lenta diventa difficile.
La domanda più difficile è se i team possano scalare il giudizio allo stesso ritmo dell'output generato. Questa domanda definisce il conflitto centrale che oggi affronta la ricerca sulla sicurezza.
I ricercatori di sicurezza AI stanno diventando direttori, non scavatori
La sfida principale della professione è il giudizio umano contro l'automazione non supervisionata, non la velocità umana contro quella delle macchine.
I ricercatori di sicurezza AI non creano più valore completando personalmente ogni passaggio investigativo. Il loro valore dipende sempre più dal decidere quali passaggi debbano essere eseguiti, con quali vincoli e con quali requisiti di prova.
Questo ruolo assomiglia alla direzione tecnica. Un ricercatore può assegnare ad agenti separati la revisione del codice sorgente, la ricerca nella documentazione, l'ispezione dei log o il test di ipotesi concorrenti.
Il lavoro parallelo amplia lo spazio di ricerca. Crea però anche problemi di coordinamento che una singola indagine manuale potrebbe evitare.
Gli agenti possono ripetere la stessa assunzione errata in più rami. Possono perdere contesto rilevante, perseguire teorie attraenti ma improduttive o produrre conclusioni contrastanti.
Itzhaky ha riassunto il pericolo con un contrasto incisivo. Un pensiero superficiale un tempo consumava un pomeriggio, ma ora può mandare una flotta di agenti nella direzione sbagliata.
L'affermazione coglie il ribaltamento centrale. L'automazione riduce il costo dell'azione, ma può moltiplicare il costo di un obiettivo mal definito.
Un direttore umano deve tradurre un obiettivo investigativo in compiti delimitati. Ogni compito richiede un bersaglio, strumenti consentiti, condizioni di arresto e uno standard di prove sufficienti.
Il ricercatore deve inoltre decidere quanto gli agenti debbano rimanere indipendenti. Diversi agenti che ripetono lo stesso schema di ragionamento non forniscono una conferma significativa.
Un progetto migliore separa i ruoli. Un agente può generare ipotesi, un altro può mettere in discussione le assunzioni e uno strumento controllato può riprodurre il comportamento sospetto.
Anche quel processo richiede revisione umana. I modelli condividono schemi di addestramento e un apparente disaccordo non garantisce un ragionamento indipendente.
Ofek Haviv, ricercatore di cybersecurity presso Terra Security, ha sostenuto che i ricercatori non competono con gli agenti sul piano della velocità. Il loro valore risiede nel definire lo standard che i risultati degli agenti devono soddisfare.
Questo standard include la verità tecnica, ma anche la rilevanza organizzativa. Una debolezza teorica può avere un impatto limitato quando i controlli rendono irraggiungibile il percorso vulnerabile.
Al contrario, un piccolo errore di configurazione può creare una grave esposizione quando un agente dispone di privilegi ampi. Il contesto determina se una scoperta richieda un intervento urgente.
I ricercatori devono inoltre comprendere gli strumenti alla base delle risposte generate. Chi esamina codice sottoposto a reverse engineering deve riconoscere quando un modello inventa un comportamento o interpreta erroneamente un flusso di controllo.
Idan Revivo, responsabile della ricerca sulla sicurezza presso Island, ha messo in guardia dai nuovi arrivati capaci di usare prompt con i modelli ma che non hanno mai imparato a fare reverse engineering del software. La sua preoccupazione non è una resistenza all'automazione.
È un monito sulla capacità di verifica. Quando un modello sbaglia con sicurezza, qualcuno deve avere una profondità tecnica sufficiente per contestarlo.
Questo requisito alza l'asticella per i ricercatori junior. Il lavoro entry-level ha tradizionalmente offerto un'esposizione ripetuta a log, codice, sistemi e modalità di errore comuni.
Se gli agenti assorbono questi compiti, i nuovi ricercatori potrebbero avere meno occasioni di sviluppare l'intuito. I team devono sostituire deliberatamente quella pratica perduta con laboratori supervisionati, esercizi di riproduzione e revisione avversariale.
Il sondaggio ha rilevato che un quinto degli intervistati ha menzionato l'effetto dell'AI sulla prossima generazione di ricercatori. Roey Vilnai, direttore della ricerca cyber presso Axonius, ha affermato che l'accesso alla conoscenza ha innalzato le aspettative a tutti i livelli di esperienza.
Tamir Ishay Sharbat, direttore della ricerca sulla sicurezza presso Zenity, ha offerto una visione complementare. È entrato nella cybersecurity senza un background precedente e ora considera l'uso dell'AI un requisito per i ricercatori.
Insieme, queste prospettive evidenziano una sfida nella formazione. L'AI può ampliare l'accesso alla conoscenza rendendo al contempo più facile scambiare una competenza superficiale per vera esperienza.
I processi di assunzione dovranno valutare sia l'uso degli strumenti sia il ragionamento indipendente. Un candidato dovrebbe saper dirigere un agente, esaminarne le prove e proseguire quando il modello fallisce.
I team dovrebbero inoltre preservare esercizi manuali per le competenze essenziali. Reverse engineering, sviluppo di exploit, analisi delle identità e ragionamento sulle reti non possono sopravvivere come conoscenze puramente teoriche.
I migliori ricercatori combineranno l'esplorazione su scala macchina con uno scetticismo tecnico fondato. Sapranno quando automatizzare, quando restringere il perimetro e quando fermare il sistema.
Questa combinazione, non la sola padronanza dei prompt, sta diventando il nuovo standard della professione.
Le identità non umane ampliano la superficie di attacco
Gli agenti che svolgono attività di sicurezza diventano a loro volta identità privilegiate che le organizzazioni devono individuare, limitare, monitorare e revocare.
Undici aziende del sondaggio CTech hanno identificato gli agenti AI come un cambiamento rilevante del perimetro di sicurezza. Gli intervistati hanno raggruppato questi agenti con chiavi API, account di servizio e altre identità non umane.
Tomer Bar, vicepresidente associato della ricerca sulla sicurezza presso Semperis, ha affermato che le identità non umane superano già quelle delle persone in alcune organizzazioni clienti. Ha previsto che il rapporto potrebbe arrivare a dieci a uno nei prossimi anni.
Questa previsione è la stima di un dirigente aziendale, non una misurazione di mercato verificata in modo indipendente. Il problema di fondo delle identità è comunque concreto.
Un agente necessita dell'accesso a dati, applicazioni e strumenti per svolgere un lavoro utile. Queste connessioni gli conferiscono un'identità, un insieme di autorizzazioni oppure un accesso preso in prestito tramite un altro account.
Omer Nissim, ricercatore di sicurezza presso Sweet Security, ha evidenziato il pericolo di combinare autorizzazioni ampie con un processo decisionale imprevedibile. Ha indicato in particolare gli agenti collegati tramite server Model Context Protocol.
Model Context Protocol, o MCP, è uno standard che consente ai sistemi AI di connettersi a strumenti esterni e fonti di dati. La sua utilità dipende da come queste connessioni vengono autorizzate e vincolate.
Un agente con accesso in lettura al codice sorgente presenta un livello di rischio. Un agente che può modificare impostazioni cloud, inviare messaggi o distribuire codice ne presenta un altro.
OWASP descrive l'eccessiva autonomia come una condizione che implica funzionalità, autorizzazioni o autonomia eccessive. Output del modello inattesi o manipolati possono quindi innescare azioni dannose.
Il problema alla radice non è necessariamente un intento malevolo. Un'istruzione ambigua, una conclusione allucinata, uno strumento compromesso o un prompt iniettato possono reindirizzare un agente altrimenti legittimo.
Il principio del privilegio minimo rimane la difesa primaria. Un agente dovrebbe ricevere solo gli strumenti e le autorizzazioni richiesti per il compito attuale.
L'accesso in sola lettura è preferibile quando il lavoro non richiede modifiche. Le azioni ad alto impatto dovrebbero usare percorsi di approvazione separati e credenziali con ambito ristretto.
Le organizzazioni necessitano inoltre di identità individuali per gli agenti. Condividere una credenziale umana con un agente rende difficile l'attribuzione e può consentire al sistema di impersonare il suo operatore.
La recente guida NIST sull'identità degli agenti raccomanda di trattare gli agenti come entità distinte. Ciascuno dovrebbe disporre di identificatori, credenziali e diritti collegati all'utente o al sistema responsabile.
La guida evidenzia anche i rischi delle chiavi API statiche e dei bearer token di lunga durata. Chiunque ottenga queste credenziali può spesso usarle senza dimostrare il possesso di un'identità specifica.
Questo rende l'archiviazione e la rotazione delle credenziali parte della sicurezza dell'AI. I segreti degli agenti possono fuoriuscire tramite file di configurazione, log, archivi di memoria, output degli strumenti o record di debug.
L'approvazione umana non risolve ogni problema. Richieste di autorizzazione costanti possono creare affaticamento da consenso, inducendo gli utenti ad approvare azioni senza un esame attento.
Un design più solido assegna agli agenti confini operativi approvati. Questi confini dovrebbero definire risorse accessibili, azioni consentite, limiti temporali e condizioni di escalation.
Il monitoraggio deve catturare più della risposta finale. I team di sicurezza hanno bisogno di registrazioni delle chiamate agli strumenti, dell'uso delle identità, dei dati recuperati, delle risorse modificate e delle decisioni di approvazione.
Queste prove supportano l'indagine sugli incidenti e il controllo qualità quotidiano. Consentono ai ricercatori di ricostruire perché un agente abbia raggiunto una conclusione o compiuto un'azione.
Anche la titolarità deve rimanere visibile. Itzhaky ha osservato che gli agenti possono essere creati da dipendenti, pipeline automatizzate o altri agenti.
Senza un proprietario responsabile, un agente dimenticato può conservare autorizzazioni dopo la conclusione del suo compito originario. Questo schema ricorda gli account di servizio abbandonati, ma il comportamento autonomo rende l'esposizione più difficile da prevedere.
L'individuazione dovrebbe quindi includere inventari degli agenti, credenziali, strumenti, accessi ai dati e relazioni genitore-figlio. La revoca deve terminare sia l'agente sia ogni accesso delegato da esso creato.
È qui che la storia della produttività incontra quella della sicurezza. Un'organizzazione può distribuire agenti più rapidamente di quanto il proprio programma di gestione delle identità riesca a governarli.
Il divario risultante diventa un nuovo obiettivo di ricerca. I team di sicurezza devono investigare il comportamento degli agenti mentre usano gli agenti per investigare tutto il resto.
L'automazione non può sostituire la convalida scettica
Il sondaggio rileva un cambiamento reale nei flussi di lavoro, ma le sue affermazioni più forti su produttività e accuratezza richiedono ancora una misurazione indipendente.
Il sondaggio CTech sulla sicurezza AI offre preziose osservazioni dirette da ricercatori attivi. Il suo gruppo di 30 persone rimane concentrato nel settore israeliano della cybersecurity.
L'articolo pubblicato non fornisce un campione casuale, un questionario standardizzato o dati sulle prestazioni verificati in modo indipendente. I lettori non dovrebbero trattarne i rapporti come misure universali della forza lavoro.
La stima di un intervistato di una produttività decuplicata può segnalare un cambiamento significativo senza dimostrare un aumento di dieci volte delle scoperte convalidate. Per output si possono intendere report, ipotesi, revisioni del codice, esperimenti o vulnerabilità confermate.
Queste categorie hanno valori diversi. Dieci volte più scoperte iniziali possono creare più lavoro se la maggior parte non supera la riproduzione.
La stessa cautela si applica alle affermazioni di zero falsi positivi. Un sistema può ridurre i falsi allarmi restringendo ciò che segnala, ma questa scelta potrebbe aumentare le vulnerabilità non rilevate.
I team devono misurare entrambi i lati. La precisione descrive quante scoperte segnalate sono valide, mentre il richiamo descrive quante debolezze pertinenti il sistema effettivamente individua.
Uno strumento può sembrare accurato quando segnala soltanto problemi evidenti. Potrebbe comunque non rilevare catene di attacco sottili, software non familiari o vulnerabilità che richiedono un lungo ragionamento contestuale.
La guida sulle vulnerabilità di Google Cloud avverte che gli agenti possono trascurare silenziosamente tecniche nuove o vulnerabilità zero-day scarsamente rappresentate nei dati di addestramento.
Questa limitazione assegna all'esperienza umana un ruolo specifico. I ricercatori devono riconoscere quando la copertura di una scansione è troppo ristretta e progettare test al di fuori dei modelli familiari al modello.
L'allucinazione è un'altra preoccupazione. Un report generato può citare funzioni inesistenti, fraintendere una dipendenza o dedurre la sfruttabilità da codice incompleto.
La riproduzione dovrebbe quindi avvenire in ambienti controllati. Una pipeline credibile dovrebbe preservare input, versioni degli strumenti, prompt, stato del sistema e risultati osservabili.
Gli output degli agenti richiedono inoltre un threat modeling. Un aggressore può inserire testo che manipola un modello, specialmente quando il sistema legge siti web, repository, ticket o documenti non attendibili.
Questo attacco è chiamato indirect prompt injection. Istruzioni malevole vengono nascoste nel contenuto recuperato e tentano di reindirizzare il comportamento dell'agente.
La difesa non può basarsi interamente sul dire al modello di ignorare istruzioni dannose. I sistemi necessitano di strumenti isolati, autorizzazioni circoscritte, confini dei contenuti e approvazione esplicita per le azioni con conseguenze rilevanti.
I ricercatori devono inoltre distinguere la sicurezza del modello dalla qualità delle prove. Spiegazioni fluide possono far sembrare completa una scoperta debole.
Un solido processo di revisione pone diverse domande concrete. Il comportamento può essere riprodotto? Il percorso vulnerabile è raggiungibile? Quale privilegio richiede lo sfruttamento? Quale controllo lo blocca o lo rileva?
Il processo dovrebbe inoltre registrare le ipotesi respinte. Questi fallimenti aiutano i team a migliorare i benchmark e impediscono agli agenti successivi di ripetere lo stesso percorso improduttivo.
Un benchmark di sicurezza è una raccolta definita di attività usata per testare il comportamento di un sistema. I benchmark interni dovrebbero includere prove fuorvianti, accesso parziale, errori degli strumenti e classi di vulnerabilità non familiari.
Le prestazioni in produzione contano più dei punteggi dei benchmark. I team dovrebbero confrontare le scoperte degli agenti con incidenti successivi, revisioni manuali e test indipendenti.
I revisori umani hanno bisogno di protezione dal bias dell'automazione, ossia la tendenza a favorire una raccomandazione della macchina semplicemente perché prodotta da un sistema.
Ruotare i revisori, nascondere il punteggio di fiducia di un agente o richiedere una riproduzione indipendente può ridurre questo bias. Le scoperte ad alto impatto meritano una separazione più netta tra scoperta e approvazione.
L'argomentazione degli scettici non implica che i team debbano abbandonare l'AI. Anche la ricerca manuale non rileva vulnerabilità, segue ipotesi errate e soffre di documentazione incoerente.
La conclusione più difendibile è più circoscritta. L'AI amplia la capacità di ricerca, ma tale capacità diventa utile solo quando i team mantengono una convalida disciplinata.
La nuova asticella più alta non è la perfezione. È la capacità di spiegare ciò che l'agente ha fatto, verificare il risultato e contenere le conseguenze dell'errore.
La sicurezza continua diventa il prossimo banco di prova
La prossima fase sarà giudicata dalla convalida continua, dalla qualità della ricerca misurabile e dal controllo applicabile sulle identità degli agenti.
Il primo segnale da osservare è se la valutazione continua della sicurezza sostituirà i test periodici nei flussi di lavoro di produzione. Diversi intervistati del sondaggio hanno sostenuto che i penetration test semestrali non sono più al passo con la velocità del software e delle attività degli aggressori.
La valutazione continua significa testare asset sotto forma di codice, configurazioni, identità ed esposizioni esterne man mano che cambiano. Dovrebbe integrare revisioni umane più approfondite, anziché trasformare la sicurezza in un flusso interminabile di avvisi da scanner.
Google ha descritto una pipeline di sicurezza agentica che analizza il codice, produce prove e sviluppa correzioni. L’azienda ha dichiarato di applicare questo approccio a centinaia di milioni di righe di codice interno.
Questo sistema offre un indicatore utile perché collega l’individuazione alla riproduzione e alla correzione. La misura critica è capire se altre organizzazioni possano raggiungere una disciplina simile con dataset, team e infrastrutture più ridotti.
Un’adozione diffusa rafforzerebbe l’affermazione centrale dell’indagine. Un rumore persistente di avvisi o tassi di correzione deboli la indebolirebbero.
Il secondo segnale riguarda il modo in cui le aziende governano le identità non umane. Gli inventari degli agenti dovrebbero entrare a far parte della gestione delle identità e degli accessi, non restare un documento isolato sulle policy di IA.
Progressi utili includerebbero credenziali univoche per gli agenti, accessi di breve durata, autorizzazioni delegate, una proprietà chiaramente definita e registri completi delle azioni. Le organizzazioni dovrebbero inoltre poter sospendere un agente senza disabilitare il suo operatore umano.
Occorre monitorare standard e prodotti che collegano le azioni di un agente a uno specifico utente, compito e confine operativo approvato. Questa catena sostiene la responsabilità senza condividere credenziali personali.
Se le implementazioni continueranno a basarsi su chiavi API ampie e account di servizio generici, la produttività supererà la governance. Questo esito rafforzerebbe le preoccupazioni riguardo ad amministratori ombra e percorsi di accesso imprevedibili.
Il terzo segnale è il modo in cui cambiano assunzioni e formazione. I ricercatori junior hanno ancora bisogno di esercitarsi direttamente con codice, sistemi, sfruttamento delle vulnerabilità e prove.
I team dovrebbero pubblicare aspettative di competenza più chiare per i ruoli assistiti dall’IA. Colloqui e programmi di formazione possono verificare se i candidati individuano risultati inventati, mettono in discussione le ipotesi del modello e riproducono manualmente i risultati.
Una transizione sana creerà percorsi di apprendistato strutturati attorno alla supervisione degli agenti. I ricercatori esperti possono esporre i tirocinanti sia a esecuzioni riuscite sia ai fallimenti.
Una transizione malsana eliminerà il lavoro fondamentale senza sostituirne il valore formativo. Questo produrrebbe ricercatori capaci di usare interfacce, ma incapaci di verificare i sistemi che vi sono dietro.
Questi segnali sono importanti per gli acquirenti aziendali quanto per i professionisti della sicurezza. L’uso dell’IA da parte di un fornitore dice poco senza dettagli su autorizzazioni, prove, revisione e gestione degli errori.
Gli acquirenti dovrebbero chiedere chi approva i risultati, come gli agenti si autenticano, quali dati conservano e se i risultati possono essere riprodotti. Dovrebbero inoltre chiedere come si comporta il sistema quando uno strumento fallisce o un input contiene istruzioni malevole.
Gli sviluppatori dovrebbero aspettarsi che le revisioni di sicurezza si avvicinino a ogni modifica del codice. Potrebbero ricevere riscontri più rapidi, ma i risultati automatizzati avranno comunque bisogno di un contesto sufficiente a supportare una correzione.
I lavoratori della conoscenza dovrebbero interessarsene perché i problemi di identità degli agenti vanno oltre gli strumenti di cybersicurezza. Qualsiasi assistente connesso a email, documenti, codice o sistemi aziendali può diventare un’identità non umana con privilegi eccessivi.
L’indagine di CTech sulla sicurezza dell’IA descrive in definitiva una ridistribuzione del lavoro, non la scomparsa dei ricercatori. Le macchine svolgono più attività di raccolta ed esplorazione. Gli esseri umani assumono maggiore responsabilità per obiettivi, vincoli e verità.
Questa configurazione può migliorare la sicurezza quando le prove restano centrali. Può aumentare il rischio quando le organizzazioni confondono l’attività generata con progressi verificati.
La domanda pratica non è più se l’IA debba far parte della ricerca sulla sicurezza. È se i team riescano a rendere l’automazione responsabile prima che la sua scala superi la loro capacità di supervisionarla.
Chiedete ai vostri fornitori di sicurezza e ai team interni un risultato completo assistito da agenti, incluse le relative autorizzazioni, la traccia delle prove, la revisione umana e l’esito finale. Questo documento rivelerà più di un’ampia promessa di produttività.
