SecRespond rileva che 23 modelli AI frontier non individuano intrusioni silenziose

SecRespond è arrivato su Google News con un risultato netto: nessuno dei 23 modelli frontier ha completato rilevamento e bonifica su alcun host compromesso testato. Gli agenti hanno gestito molto meglio gli avvisi visibili rispetto alle evidenze silenziose, mettendo in luce un divario tra il triage assistito dall'AI e la risposta autonoma agli incidenti.

I ricercatori di Alibaba Group hanno presentato il paper SecRespond il 29 luglio 2026. Hanno testato modelli di diverse famiglie principali tramite OpenCode, un'infrastruttura per agenti che consente ai modelli di ispezionare file e utilizzare strumenti da riga di comando.

Il test inizia dopo che un attaccante ha già avuto successo. Questo dettaglio crea il conflitto al centro dello studio. Gli agenti AI possono seguire un avviso, ma un centro operativo di sicurezza ha bisogno di investigatori che trovino anche minacce che nessuno ha segnalato.

SecRespond mette quindi in discussione una promessa comune dell'automazione. Un modello che riassume gli avvisi può ridurre il carico di lavoro degli analisti, ma ciò non lo rende un responsabile autonomo della risposta agli incidenti. Il benchmark ha individuato la differenza negli artefatti su disco, nei meccanismi di persistenza, nei passaggi di pulizia incompleti e nei piani di bonifica non verificati.

Cosa ha realmente cambiato il benchmark SecRespond

SecRespond sposta l'obiettivo della valutazione dall'interpretazione degli avvisi all'indagine su una macchina già compromessa.

Molti test di cybersicurezza iniziano prima della compromissione. Chiedono a un modello di identificare una vulnerabilità, risolvere una sfida capture-the-flag, classificare malware o ragionare su log di sicurezza selezionati. Questi compiti misurano capacità utili, ma riducono l'incertezza che definisce una violazione reale.

SecRespond inizia più tardi. Ogni agente riceve un'istantanea forense congelata del disco di un host cloud compromesso. Riceve inoltre output sintetici simili ad avvisi, scansioni delle vulnerabilità e controlli della baseline di sicurezza provenienti da un prodotto di protezione degli host.

Un'istantanea forense del disco è una copia conservata dei file e degli artefatti di un sistema in un momento specifico. Può contenere prove che gli avvisi non hanno mai menzionato, tra cui file di avvio modificati, account backdoor, log cancellati, attività pianificate o binari dannosi.

L'agente deve ispezionare quel materiale e ricostruire quanto accaduto. Produce quindi report su intrusioni, vulnerabilità, rischi della baseline e bonifica. Il compito richiede anche un file di avanzamento, creando una traccia dell'indagine invece di accettare una sola risposta finale ben rifinita.

Il benchmark comprende 10 cyber range, ossia ambienti isolati costruiti per riprodurre incidenti di sicurezza. Tali ambienti coprono quattro tipi di punto di ingresso iniziale, 21 tecniche del catalogo MITRE ATT&CK e cinque sistemi operativi.

I ricercatori hanno tradotto questi ambienti in 52 elementi di capacità e 280 checkpoint dettagliati. I checkpoint verificano se un agente abbia trovato prove concrete, le abbia attribuite correttamente, abbia raccomandato azioni appropriate e abbia coperto le verifiche necessarie.

Il rilevamento e la pianificazione della bonifica ricevono punteggi separati. Il rilevamento ha un massimo di tre punti per ogni checkpoint applicabile. La pianificazione ha un massimo di due punti, mentre i checkpoint che non si applicano a una dimensione sono esclusi da quell'aggregato.

Questa separazione è importante perché trovare un file dannoso non risponde alla domanda su cosa debbano fare i responder dopo. Una risposta sicura può richiedere l'isolamento di un host, la preservazione delle prove, la terminazione dei processi, la rimozione della persistenza, la rotazione delle credenziali, il blocco dell'infrastruttura, il ripristino dei servizi e la verifica del recupero.

Il dataset SecRespond pubblico include prompt delle attività, materiali di valutazione, checklist, output di sicurezza sintetici e archivi forensi. La sua pubblicazione rende verificabile l'affermazione centrale da parte di team esterni agli autori originali.

SecRespond definisce inoltre un confine più rigoroso per la risposta agli incidenti basata sull'AI. Un agente non riceve il pieno merito perché probabilmente ha controllato qualcosa. Il suo report deve indicare il rilevamento e citare prove che soddisfino la checklist pertinente.

Questa regola trasforma il linguaggio di sicurezza vago in prestazioni misurabili. “Indagare su attività sospette” non equivale a identificare un processo, un file, un account, un endpoint o un percorso di persistenza specifico. “Applicare patch al server” non equivale a un piano di recupero completo, sequenziato e verificato.

La copertura di Google News si è concentrata sul fallimento principale dei 23 modelli. Il cambiamento più profondo è metodologico. SecRespond chiede se un agente possa seguire piste che non gli sono mai state fornite, quindi collegare tali scoperte a un processo di pulizia difendibile.

Perché l'attenzione di Google News è importante per gli acquirenti di sicurezza AI

Il benchmark spinge fornitori e responsabili della sicurezza a distinguere l'assistenza sugli avvisi dalla risposta autonoma agli incidenti.

L'AI aiuta già i centri operativi di sicurezza a riassumere avvisi, arricchire indicatori, cercare documentazione, redigere query e preparare note dei casi. Questi flussi di lavoro restano preziosi perché gli analisti affrontano spesso prove frammentate e attività amministrative ripetitive.

Tuttavia, SecRespond misura un livello superiore di autonomia. Un responder autonomo deve decidere dove indagare, riconoscere prove mancanti, testare spiegazioni concorrenti e proseguire dopo che l'avviso più evidente è stato risolto.

Il risultato centrale del benchmark mostra perché questa distinzione è importante. Su tutti i 23 modelli valutati, nessun agente ha ottenuto rilevamento e bonifica completi neppure in un singolo cyber range.

Il miglior modello complessivo nell'esperimento riportato è stato Claude Opus 4.7. Ha raggiunto un punteggio medio, a livello di range, del 79,0 percento nei checkpoint per il rilevamento e del 65,7 percento per la pianificazione.

Il paper riporta anche una media del 72,4 percento combinando queste dimensioni per il modello leader. Questa prestazione ha comunque lasciato artefatti dannosi non trattati e bonifiche incomplete, in particolare nei range con catene di attacco più lunghe e ampie.

Tra gli altri risultati di rilievo figurano Claude Opus 4.6 con il 78,2 percento nel rilevamento e il 58,0 percento nella pianificazione. GLM-5.1 ha raggiunto il 76,3 percento e il 59,2 percento, mentre Qwen3.7 Plus ha raggiunto il 75,6 percento e il 58,8 percento.

Questi dati non dovrebbero diventare una classifica generale dei modelli sottostanti. Descrivono un'infrastruttura per agenti, una versione del benchmark, una progettazione del compito e un processo di valutazione specifici.

I risultati evidenziano invece un modello di fallimento condiviso. I modelli hanno trovato più affidabilmente prove collegate ad avvisi esistenti rispetto a prove che richiedevano una ricerca non sollecitata sul disco.

Questo schema mette sotto pressione i fornitori di sicurezza che utilizzano etichette generiche come “analista AI” o “SOC autonomo”. Gli acquirenti devono chiedere quali parti del ciclo di risposta il sistema svolga effettivamente senza una pista creata da un essere umano.

Un prodotto potrebbe riassumere con precisione un avviso endpoint, ma ignorare un secondo meccanismo di persistenza. Potrebbe raccomandare l'eliminazione di un binario dannoso senza terminare il relativo processo, rimuovere il suo loader, ruotare le credenziali esposte o verificare il ripristino del servizio.

Ogni passaggio omesso modifica l'esito operativo. Un attaccante può tornare tramite un account non trattato, un'attività pianificata, una webshell, un servizio, una voce del registro o un hook della shell. Una prima azione tecnicamente corretta può quindi creare un falso senso di contenimento.

I responsabili della sicurezza devono anche separare la qualità dell'indagine dalla qualità del report. I modelli producono spesso spiegazioni fluide, ma SecRespond valuta se tali spiegazioni contengano le prove e i dettagli di bonifica richiesti.

Questo è un problema familiare nel lavoro ad alta intensità di conoscenza. Una narrazione sicura di sé può nascondere un recupero incompleto delle informazioni. I team che costruiscono una base di conoscenza ricercabile affrontano un requisito correlato: le conclusioni devono rimanere tracciabili rispetto al materiale di origine.

Il benchmark rende concreta questa tracciabilità per la risposta agli incidenti. Un agente deve mostrare quale artefatto supporti ciascuna conclusione e quale azione affronti ciascuna condizione identificata.

La visibilità su Google News può portare questa distinzione oltre i ricercatori dei benchmark. Team di procurement, CISO, fornitori di sicurezza gestita e gruppi di audit interni dispongono ora di un esempio pubblico del perché “gestisce gli avvisi” e “gestisce gli incidenti” non siano affermazioni equivalenti.

Il vero punto cieco è l'indagine non guidata

Il comportamento più debole dei modelli emerge quando un incidente non lascia alcun avviso evidente che indichi il prossimo artefatto.

SecRespond raggruppa le prestazioni in cinque aree di capacità. Queste coprono entità di intrusione, meccanismi di persistenza, rischi della baseline, rischi di vulnerabilità e qualità complessiva dell'indagine e della risposta.

Un'entità di intrusione è un oggetto dannoso concreto, come un processo, un file, un endpoint di rete o un artefatto manomesso. I modelli hanno ottenuto i risultati migliori in questa categoria perché questi oggetti erano spesso allineati con segnali di sicurezza visibili.

Tra i modelli, il rilevamento medio ha raggiunto il 75,4 percento per le entità di intrusione. Diversi sistemi di punta hanno ottenuto risultati sostanzialmente migliori, tra cui Qwen3.7 Plus con l'88,4 percento e Claude Opus 4.6 con l'86,0 percento.

I meccanismi di persistenza hanno prodotto un risultato diverso. La persistenza si riferisce a modifiche che consentono l'accesso dell'attaccante di sopravvivere a un riavvio o a una pulizia iniziale. Esempi includono attività pianificate, servizi, hook di avvio della shell, webshell, account backdoor e sottoscrizioni Windows Management Instrumentation.

Il rilevamento medio è sceso al 58,8 percento per la persistenza. Il calo è importante perché la persistenza è esattamente ciò che i responder devono trovare prima di dichiarare pulito un host.

Il benchmark non mostra che i modelli siano privi di qualsiasi ragionamento forense. Possono collegare un avviso a un processo o file rilevante e spesso descrivono correttamente la minaccia immediata. Il fallimento arriva quando l'indagine deve espandersi oltre quel punto di partenza.

Si consideri un server web compromesso. Un avviso potrebbe identificare un processo dannoso o una connessione in uscita. Seguire quel segnale può rivelare un eseguibile, ma un'indagine completa deve chiedersi come sia entrato l'attaccante, quali credenziali siano state esposte e cosa sopravviva alla terminazione.

Il responder potrebbe inoltre dover ispezionare script di avvio, definizioni dei servizi, voci cron, account utente, cronologie dei comandi, directory delle applicazioni e log alterati. Nessun singolo avviso identifica necessariamente queste posizioni.

Questo crea un problema di ricerca con confini incerti. L'agente deve decidere quali ipotesi meritino di essere testate e per quanto tempo proseguire. Deve riconoscere che l'assenza di un artefatto non elimina altre vie di persistenza.

Gli attuali agenti basati su modelli linguistici spesso ottimizzano attorno alle prove già presenti nel contesto. Gli avvisi creano ancore ad alta salienza, così l'agente può spendere il proprio budget nello spiegare tali ancore invece di cercare prove non menzionate.

Catene di attacco più lunghe amplificano questa debolezza. Ogni tecnica aggiuntiva introduce un altro ramo, tipo di artefatto, timestamp, account o servizio che il modello deve correlare.

Il paper ha rilevato che le prestazioni diminuivano man mano che gli attacchi diventavano più lunghi e ampi. Questo risultato si adatta alla sfida operativa: la risposta agli incidenti non è una singola decisione di classificazione, ma una sequenza di giudizi collegati in condizioni di informazioni incomplete.

Un distinto benchmark di threat hunting del 2026 ha riportato un problema correlato. Cinque modelli frontier hanno cercato log di eventi Windows grezzi provenienti da 26 campagne di attacco, e il miglior modello ha trovato solo una piccola frazione degli eventi dannosi.

I due studi testano flussi di lavoro diversi, quindi i loro punteggi non sono direttamente comparabili. Tuttavia, entrambi suggeriscono che la ricerca non guidata rimanga più difficile del ragionamento su prove preselezionate.

Questo è il ribaltamento fondamentale del benchmark. Gli agenti sembrano più capaci là dove gli strumenti di sicurezza convenzionali hanno già ridotto l’incertezza. Diventano meno affidabili là dove gli investigatori umani apportano il massimo valore, mettendo in discussione ciò che l’avviso non ha rivelato.

Un team di sicurezza può comunque usare l’AI in modo produttivo entro questo perimetro. Il modello può riassumere le evidenze, proporre ipotesi, redigere query, confrontare artefatti e mantenere una cronologia dell’indagine.

Il salto rischioso consiste nel trattare queste capacità come prova che il modello abbia esaminato l’intero incidente. SecRespond mostra che una risposta ben articolata può coesistere con meccanismi di persistenza non scoperti e con una ricostruzione incompleta dell’attività dell’attaccante.

I punteggi di rilevamento nascondono un divario di remediation più ampio

Trovare più evidenze non si è tradotto in piani di bonifica altrettanto completi, rendendo la remediation il secondo grande fallimento del benchmark.

Ogni modello valutato ha ottenuto punteggi più alti nel rilevamento che nella pianificazione. Per GPT-5.5, il divario riportato ha raggiunto 34,7 punti percentuali.

I ricercatori attribuiscono questo schema al fatto che gli agenti applicano una prima correzione evidente, omettendo però le azioni rimanenti. Il comportamento ricorda l’interruzione di una checklist: una volta intervenuti sull’oggetto malevolo centrale, il modello agisce come se l’incidente fosse risolto.

La remediation reale raramente termina con una sola eliminazione o modifica della configurazione. Chi risponde all’incidente deve considerare dipendenze, preservazione delle evidenze, impatto sul business, continuità del servizio, esposizione delle credenziali e percorsi di accesso alternativi dell’attaccante.

Il punteggio di pianificazione di SecRespond valuta se un’azione sia corretta e completa. Esamina inoltre la verifica e gli effetti collaterali quando il relativo checkpoint li richiede.

La verifica non è una formalità. Un piano per rimuovere un’attività pianificata dovrebbe confermare che l’attività non esista più e che il suo payload non possa avviarsi tramite un altro meccanismo.

Un piano per bloccare l’indirizzo di un attaccante dovrebbe considerare, ove opportuno, sia il traffico in ingresso sia quello in uscita. Dovrebbe inoltre evitare di suggerire che il blocco di un indirizzo elimini malware, credenziali rubate o persistenza già presenti sull’host.

I problemi di configurazione standardizzati si sono dimostrati più semplici. Claude Opus 4.7 ha raggiunto il 74,8% nella pianificazione per i rischi di base e il 72,6% per i rischi di vulnerabilità.

Questi compiti spesso corrispondono ad azioni familiari, come il rafforzamento di una configurazione o l’aggiornamento del software interessato. L’agente può recuperare un modello di remediation riconoscibile e applicarlo al rilevamento.

La qualità dell’indagine e della risposta è rimasta molto più debole. La performance media di pianificazione in quella categoria ha raggiunto solo il 31,8%.

Questa categoria copre attività che dipendono dalla sintesi, anziché da una correzione nota. Include la ricostruzione della catena d’attacco, la qualità delle evidenze, l’onestà riguardo all’incertezza, la completezza, la verifica e la consapevolezza dell’impatto operativo.

Il miglior risultato di rilevamento in quella categoria ha raggiunto il 75,5%. Secondo il paper, quasi tutti i modelli sono rimasti sotto il 50% nella pianificazione.

Questi risultati mettono in discussione una semplice strategia di scalabilità. Fornire a un modello più avvisi non crea automaticamente un piano di risposta completo. Un maggior numero di rilevamenti visibili può invece produrre più raccomandazioni scollegate tra loro.

Un piano credibile richiede un ordine. I team possono isolare una macchina prima di modificarla, preservare le evidenze volatili prima di terminare i processi e ruotare le credenziali dopo aver determinato la portata dell’esposizione.

Devono inoltre considerare rollback e servizi. Rimuovere un componente compromesso senza comprenderne le dipendenze può interrompere la produzione o distruggere evidenze necessarie all’attribuzione.

SecRespond valuta piani scritti anziché remediation eseguite dal vivo su sistemi di produzione. Ciò limita ciò che il benchmark può dimostrare, ma mantiene visibile anche la questione della sicurezza.

Se un modello non riesce a descrivere in modo coerente una remediation completa e verificata in un ambiente controllato, le organizzazioni hanno pochi motivi per concedergli autorità illimitata su un host attivo.

Il benchmark sostiene quindi un modello operativo più ristretto. L’AI può suggerire azioni, organizzare le evidenze e mettere in evidenza i campi mancanti, mentre gli addetti umani alla risposta mantengono l’approvazione per le fasi di contenimento e ripristino.

Questa impostazione non è un rifiuto dell’automazione SOC. È una risposta alla specifica asimmetria nei dati. I sistemi erano più efficaci nell’identificare oggetti noti che nel garantire che ogni conseguenza ricevesse un trattamento sicuro.

I team di sicurezza dovrebbero riflettere questa asimmetria nei controlli di accesso. L’accesso forense in sola lettura comporta un rischio diverso rispetto al permesso di terminare processi, eliminare file, disabilitare account o modificare policy di rete.

Un agente che non rileva un artefatto nascosto produce un report incompleto. Un agente che agisce sulla base di quel report incompleto può ostacolare il ripristino, lasciando intatto il percorso alternativo dell’attaccante.

Cosa i numeri non dimostrano

SecRespond costituisce una forte evidenza di un limite condiviso, ma non è un verdetto definitivo su ogni modello o configurazione SOC di produzione.

Il paper è un preprint su arXiv, non il risultato di una peer review completata. Tra gli autori figurano ricercatori di Tongyi Lab e Alibaba Cloud, e il benchmark valuta i modelli attraverso un unico harness rappresentativo.

La scelta di OpenCode contribuisce a standardizzare l’uso degli strumenti tra i sistemi. Significa però anche che i risultati misurano una combinazione di modello e harness, non una capacità astratta del modello separata da prompting, strumenti, gestione del contesto e policy di esecuzione.

Un diverso scaffolding può modificare le prestazioni. Un agente di incident response potrebbe usare una checklist d’indagine obbligatoria, utility forensi specializzate, retrieval sulle procedure interne, più agenti cooperanti o script di validazione deterministici.

SecRespond rimane utile perché questi miglioramenti possono essere testati sugli stessi range. Tuttavia, i numeri pubblicati non dovrebbero essere trattati come limiti permanenti per ogni famiglia di modelli.

La valutazione utilizza inoltre un processo LLM-as-a-judge, nel quale modelli linguistici valutano i report generati rispetto a checklist dettagliate. Sono stati utilizzati in modo indipendente tre giudici proprietari per ridurre la dipendenza da un singolo valutatore.

Questi giudici erano Claude Opus 4.7, Gemini 3.1 Pro e GPT-5.4 Pro. Più giudici riducono i bias individuali, ma non eliminano ogni problema di calibrazione.

Un valutatore potrebbe interpretare una formulazione incompleta in modo diverso da uno specialista umano di digital forensics. Potrebbe anche premiare un linguaggio esplicito nel report senza risolvere pienamente la questione se il processo d’indagine sottostante fosse solido.

Le istruzioni di scoring cercano di controllare questo rischio. I giudici devono citare le evidenze e assegnare credito soltanto ai contenuti esplicitamente presenti nei report.

I 280 checkpoint del benchmark forniscono ulteriore struttura. Eppure ogni checklist incorpora scelte su quali artefatti, fasi di risposta e qualità meritino maggiore peso.

I 10 range sono sufficientemente diversificati da rivelare comportamenti ripetuti. Non coprono tutti i sistemi operativi, le architetture cloud, le piattaforme di identità, i prodotti endpoint o le tecniche degli attaccanti.

Anche gli ambienti sono controllati. I ricercatori hanno predisposto e compromesso gli host per il benchmark, quindi hanno bonificato credenziali e dati personali.

Questo design consente la riproducibilità ed evita l’esposizione di informazioni di produzione. Non può riprodurre pienamente il rumore, la telemetria incompleta, i vincoli organizzativi e le dipendenze aziendali di un incidente aziendale reale.

Un risultato illustra inoltre come il comportamento di sicurezza possa influire sulla copertura del benchmark. Claude Opus 4.7 ha rifiutato il compito npm-worm, quindi il paper ha omesso quel modello dalla tabella dettagliata dei checkpoint del range.

Un rifiuto può ridurre l’utilità operativa durante una legittima indagine difensiva. Può anche riflettere lo sforzo di un provider per impedire che l’assistenza dual-use degeneri in indicazioni dannose.

SecRespond non risolve questo compromesso di policy. Mostra che un’implementazione sicura necessita di definizioni dei compiti che distinguano il lavoro forense autorizzato dalle istruzioni offensive.

Gli autori del benchmark dichiarano che le evidenze rilasciate provengono da ambienti isolati e non contengono catene di exploit eseguibili. I materiali pubblici sono destinati alla ricerca difensiva.

Questa restrizione è importante nell’interpretare le affermazioni sulla risposta “nel mondo reale”. I range ricreano compromissioni end-to-end su protocolli di rete reali, ma il pacchetto rilasciato contiene evidenze forensi bonificate anziché strumenti di attacco attivi.

Non esiste inoltre uno studio sul campo indipendente che mostri come i punteggi SecRespond si traducano in tempo risparmiato dagli analisti, riduzione della gravità degli incidenti o maggiore velocità di contenimento. Questi risultati richiedono valutazioni all’interno di team operativi.

Per gli acquirenti, la lettura corretta deve quindi essere misurata. Il benchmark mette fortemente in discussione le affermazioni non supportate sulla risposta autonoma agli incidenti. Non dimostra che l’assistenza AI non abbia valore all’interno di un SOC guidato da persone.

Non stabilisce nemmeno che un determinato modello rimarrà in vantaggio nelle versioni future. La serie Claude riportata è migliorata tra le varie release, mentre i progressi nelle altre famiglie non sono stati universali.

L’unità di valutazione significativa è il sistema implementato. Include il modello, gli strumenti, i prompt, i permessi, le fonti di retrieval, i gate di revisione, il logging e le procedure di ripristino.

Tre segnali da osservare dopo il ciclo di notizie Google su SecRespond

Il prossimo test sarà verificare se i vendor migliorano la scoperta non guidata, la verifica della remediation e la valutazione di produzione riproducibile.

Il primo segnale è la riproduzione indipendente. Ricercatori e vendor di sicurezza possono eseguire il repository del benchmark pubblico con altri harness, prompt, strumenti e versioni dei modelli.

La riproduzione mostrerà se il divario nelle intrusioni silenziose persiste con modifiche allo scaffolding. Se agenti forensi specializzati continuano a non rilevare persistenza non segnalata, la tesi centrale del paper si rafforza.

Se procedure di ricerca deterministiche producono grandi miglioramenti, la lezione cambia leggermente. Il collo di bottiglia risiederebbe meno nella conoscenza del modello e più nel design dell’indagine, nel routing degli strumenti e nella copertura obbligatoria.

Ciò indebolirebbe comunque le affermazioni sugli agenti autonomi general-purpose. Fornirebbe inoltre un percorso ingegneristico più chiaro verso sistemi più sicuri.

Il secondo segnale è se i vendor pubblicheranno risultati separati per rilevamento e remediation. Un unico numero di “accuratezza della risposta agli incidenti” può nascondere il divario di pianificazione emerso da SecRespond.

Valutazioni utili dovrebbero indicare cosa il sistema ha trovato, cosa ha mancato, quale azione ha proposto e come ne ha verificato il completamento. Dovrebbero inoltre riportare rifiuti, fallimenti degli strumenti e casi che richiedono l’intervento umano.

Osservate in particolare i test sui meccanismi di persistenza. I miglioramenti sul malware collegato agli avvisi sono importanti, ma non affrontano il principale punto cieco del benchmark.

Osservate inoltre se i piani coprono l’ampiezza della bonifica. Un agente più forte dovrebbe gestire processi, file, account, esecuzione pianificata, controlli di rete, rotazione delle credenziali, ripristino dei servizi e validazione post-remediation, quando applicabile.

Il terzo segnale è costituito dalle evidenze provenienti da implementazioni SOC supervisionate. I vendor devono mostrare come i loro agenti operino con telemetria reale, procedure interne, controlli di accesso e gate di approvazione degli analisti.

L’evidenza operativa più solida non sarà unicamente un caso di studio ben confezionato. Includerà tassi di mancato rilevamento, tassi di escalation, affermazioni non supportate, frequenza delle correzioni e percentuale di raccomandazioni approvate dagli analisti senza modifiche.

Un’implementazione credibile dovrebbe preservare una traccia di audit. I revisori devono poter ricondurre le conclusioni agli artefatti e stabilire quali ricerche l’agente abbia completato prima di fermarsi.

Le organizzazioni dovrebbero inoltre testare i confini dei permessi. Indagine in sola lettura, azioni raccomandate ed esecuzione autonoma rappresentano tre diversi livelli di rischio.

SecRespond supporta l’adozione ai primi due livelli, imponendo al contempo un elevato onere della prova al terzo. I suoi risultati non giustificano l’attribuzione di ampi poteri di contenimento a un modello che non abbia dimostrato una scoperta completa.

Il titolo di Google News svanirà, ma il benchmark lascia ai team di sicurezza una domanda di procurement destinata a durare: cosa trova l'agente quando nessun avviso gli indica dove cercare?

Chiedete ai fornitori di rispondere a questa domanda con prove riproducibili. Poi chiedete come il sistema verifica ogni passaggio di bonifica e segnala l'incertezza a un operatore umano.

Le risposte riveleranno se i prodotti AI per i SOC stanno diventando strumenti investigativi o restano assistenti rapidi basati sulle rilevazioni esistenti. Per ora, SecRespond colloca tutti i 23 modelli testati dalla parte degli assistenti di questa linea.