Il lancio di ThreatBook RedAgents mette più pentester AI contro il modello a singolo agente
ThreatBook ha lanciato RedAgents con almeno quattro agenti AI per pentest, mettendo in discussione l'idea che un unico tester autonomo possa fornire una valutazione di sicurezza completa. Il lancio di ThreatBook RedAgents trasforma sistemi offensivi concorrenti in un pool coordinato per i test. Tuttavia, l'azienda non ha pubblicato un confronto indipendente che dimostri che l'approccio combinato individui più vulnerabilità con meno falsi positivi.
RedAgents entra in un mercato già plasmato da piattaforme di sicurezza autonome come XBOW e Horizon3.ai. Questi concorrenti vendono principalmente le prestazioni di una singola piattaforma e del relativo sistema di test. ThreatBook scommette su un approccio diverso: i team di sicurezza dovrebbero riunire vari agenti e confrontarne i risultati attraverso un'unica interfaccia.
Questa distinzione è il vero fulcro della notizia. Più agenti possono esplorare percorsi di attacco differenti, ma aumentano anche il numero di strumenti, autorizzazioni e decisioni che gli operatori devono governare. RedAgents deve dimostrare che l'aggregazione migliora la copertura senza moltiplicare il rischio operativo.
Il lancio di ThreatBook RedAgents cambia l'unità della competizione
ThreatBook non sta presentando un altro scanner autonomo. Sta posizionando la raccolta di agenti come prodotto.
ThreatBook ha annunciato RedAgents il 16 ottobre 2026. L'azienda lo descrive come una piattaforma software-as-a-service per eseguire più agenti AI di penetration testing sullo stesso obiettivo autorizzato.
Un agente AI per pentest usa modelli, strumenti di sicurezza e pianificazione iterativa per identificare e talvolta convalidare debolezze sfruttabili. RedAgents offre ai team di sicurezza un'interfaccia unificata per scegliere gli agenti, impostare un obiettivo e analizzarne l'output.
La rosa iniziale include Artex Pro, Cyber(YanJi), Yanxun e CyberStrikeAI Enterprise Edition. ThreatBook afferma che la piattaforma può eseguire questi sistemi in modo indipendente o parallelo, a seconda della valutazione.
Questa scelta è rilevante perché i singoli agenti di pentest non affrontano necessariamente un obiettivo nello stesso modo. Uno potrebbe privilegiare la logica delle applicazioni web, mentre un altro potrebbe dedicare più tempo alla ricognizione o ai percorsi delle credenziali.
Il CEO di ThreatBook, Feng Xue, ha descritto il modello a fornitore unico come una fonte di visibilità limitata. La sua tesi è che due agenti possano individuare vulnerabilità diverse, anche quando ricevono lo stesso obiettivo.
L'azienda afferma che RedAgents consolida in un'unica vista dati di test, log e vulnerabilità individuate. Questo design dovrebbe ridurre il lavoro manuale richiesto per gestire prodotti separati e riconciliare i relativi report.
Il lancio di RedAgents presenta inoltre diverse dichiarazioni sulla sicurezza attorno a questo livello di orchestrazione. ThreatBook afferma che i clienti definiscono l'ambito dei test tramite una whitelist e che gli agenti devono restare entro tali parametri autorizzati.
L'azienda sostiene inoltre che i dati di test restano nel suo ambiente anziché essere trasferiti ad agenti di terze parti. Promuove anche una conservazione zero dei dati, che consente ai clienti di richiedere la cancellazione completa dei propri dati di test.
Queste restano affermazioni del fornitore finché clienti o valutatori indipendenti non le verificheranno in condizioni realistiche. L'annuncio non spiega come RedAgents imponga i confini quando un agente genera un comando imprevisto.
Non specifica inoltre se ogni comando passi attraverso controlli deterministici delle policy. Il comunicato non fornisce dettagli su arresti di emergenza, limiti di velocità, isolamento dei privilegi o approvazione umana per azioni sensibili.
Ciononostante, il prodotto cambia la domanda competitiva. Agli acquirenti non viene più chiesto soltanto quale pentester autonomo offra le prestazioni migliori.
Viene chiesto loro se scegliere un solo sistema rappresenti l'architettura sbagliata. ThreatBook vuole che il livello di orchestrazione diventi più prezioso di ogni singolo agente ad esso connesso.
Questa proposta ricorda la scansione antimalware multi-motore, in cui diversi sistemi di rilevamento ispezionano lo stesso oggetto. ThreatBook usa esplicitamente questa idea per spiegare perché risultati sovrapposti e non sovrapposti possano migliorare la copertura.
Il pentesting pone però un problema di coordinamento più complesso. Un motore antimalware valuta un artefatto, mentre un agente di pentest può interagire con servizi live, account, database e controlli di rete.
Combinare agenti richiede quindi più della semplice raccolta dei risultati. La piattaforma deve coordinare le azioni, prevenire interferenze, normalizzare le prove e individuare risultati duplicati senza nascondere differenze significative.
Questi requisiti trasformano RedAgents da un pacchetto di prodotti a un piano di controllo operativo. La sua capacità di svolgere questo ruolo in modo affidabile determinerà se il modello di aggregazione offra un valore reale.
Perché il pentesting AI multi-agente sta arrivando ora
La tempistica riflette il passaggio da valutazioni di sicurezza programmate a una convalida continua alla velocità delle macchine.
I penetration test tradizionali dipendono spesso da specialisti umani difficili da reperire, finestre di coinvolgimento fisse e report preparati manualmente. Questa struttura offre un'istantanea dettagliata, ma l'ambiente può cambiare poco dopo la fine dei test.
Le applicazioni ricevono oggi rilasci frequenti, le risorse cloud compaiono dinamicamente e i servizi esposti cambiano senza attendere la successiva valutazione. L'intervallo tra i test può quindi diventare una finestra di rischio non gestita.
ThreatBook sostiene che gli agenti AI rendano pratici cicli di test più brevi. RedAgents è progettato per consentire ai team di sicurezza di effettuare valutazioni giornaliere, settimanali o mensili anziché trattare il pentesting come un esercizio annuale.
L'idea non è esclusiva di ThreatBook. I fornitori di test autonomi promuovono già valutazioni continue, retest e convalida dei percorsi di attacco come alternative a incarichi di consulenza isolati.
XBOW afferma che il suo sistema individua e sfrutta autonomamente vulnerabilità web, producendo al contempo prove per le debolezze che convalida. L'azienda ha riferito di aver raggiunto la prima posizione nella classifica statunitense di HackerOne nel 2025.
Secondo il resoconto pubblicato dall'azienda, il sistema ha inviato quasi 1.060 vulnerabilità nel corso di quell'attività. Revisori umani hanno controllato i report per verificarne la conformità al programma, ma XBOW afferma che non hanno partecipato alla scoperta o allo sfruttamento.
Questi dati provengono da XBOW e non dovrebbero fungere da benchmark diretto per RedAgents. Mostrano comunque perché il pentesting autonomo sia andato oltre le dimostrazioni di laboratorio.
La cronologia dei benchmark di XBOW illustra anche la difficoltà di misurare i progressi. L'azienda ha dapprima usato sfide di addestramento consolidate, poi ha creato scenari inediti e si è spostata verso obiettivi di bug bounty in produzione.
ThreatBook non ha pubblicato una valutazione comparabile dell'intera piattaforma RedAgents. Indica invece risultati associati ai singoli agenti della sua rosa.
L'azienda afferma che Cyber(YanJi) ha risolto 54 problemi mirati su 54 in un hackathon di Tencent Cloud. Sostiene inoltre che la versione open-source di Artex abbia vinto la Agent+ Offensive and Defensive Challenge di Baidu nel settembre 2026.
Secondo quanto riferito, CyberStrikeAI aveva accumulato oltre 7.800 stelle su GitHub prima che ThreatBook lo acquisisse nel settembre 2026. La popolarità può indicare l'interesse degli sviluppatori, ma non misura l'accuratezza dei test aziendali o la sicurezza dell'esecuzione.
Questi segnali a livello di agente spiegano perché l'aggregazione appaia attraente. Un acquirente può accedere a diversi approcci senza dover prevedere quale agente prevarrà per ogni applicazione, classe di vulnerabilità o ambiente infrastrutturale.
Il modello offre inoltre a ThreatBook un modo per assorbire sistemi futuri. La sua pagina prodotto afferma che la piattaforma continuerà ad aggiungere agenti commerciali, accademici e open-source.
Ciò crea un percorso di aggiornamento potenzialmente più rapido rispetto alla ricostruzione di un unico agente proprietario per ogni nuova tecnica. La piattaforma può aggiungere uno specialista quando questo offre una capacità distintiva.
Tuttavia, lo stesso design sposta la responsabilità verso la valutazione e la governance. ThreatBook deve decidere quali agenti siano idonei, quali autorizzazioni ricevano e in che modo i clienti possano confrontarne il comportamento.
Un team di sicurezza deve inoltre sapere se due agenti offrano realmente prospettive indipendenti. Più prodotti possono comunque ereditare le stesse debolezze dei modelli, dati di addestramento, strumenti o schemi di pianificazione.
La tesi multi-agente acquista valore solo quando la diversità produce una copertura utile. Eseguire agenti simili più volte può aumentare l'attività senza aumentare la comprensione.
Per questo la metrica più importante di RedAgents non è il numero di strumenti connessi. È il numero di risultati convalidati e non duplicati che tali strumenti scoprono in sicurezza, oltre una solida base di riferimento a singolo agente.
RedAgents contro il modello di pentesting a singolo agente
Il confronto centrale riguarda la copertura di un portafoglio rispetto alla coerenza di un unico sistema di test strettamente controllato.
I fornitori a piattaforma singola possono ottimizzare ogni parte della valutazione attorno a un'unica architettura. Controllano pianificazione, accesso agli strumenti, standard delle prove, regole di sicurezza, reportistica e retest.
Questa integrazione verticale può semplificare l'attribuzione delle responsabilità. Quando un test si comporta in modo anomalo o un risultato si rivela inaffidabile, il cliente ha un solo sistema e un solo fornitore da esaminare.
ThreatBook rinuncia a parte di questa semplicità per ottenere diversità. RedAgents può riunire agenti creati da team diversi, con punti di forza e percorsi tecnici differenti.
La sua piattaforma multi-agente presenta la selezione come una scelta del cliente. Un team può distribuire un agente per un'attività mirata o più agenti per una convalida incrociata più ampia.
Questo ricorda la composizione di un red team umano con specialisti di diverse superfici di attacco. Un esperto di applicazioni web, uno specialista delle identità e un tester cloud possono individuare percorsi differenti nello stesso ambiente.
Tuttavia, i membri di un team umano comunicano, risolvono conflitti e riconsiderano insieme le ipotesi. Gli agenti software hanno bisogno di un'orchestrazione esplicita per ottenere lo stesso coordinamento.
L'esecuzione parallela può anche creare interferenze. Un agente potrebbe modificare lo stato dell'applicazione, consumare un token, attivare un blocco o alterare le prove prima che un altro agente raggiunga lo stesso percorso.
I materiali di lancio non spiegano come RedAgents gestisca queste collisioni. Non chiariscono inoltre se la piattaforma serializzi le azioni pericolose o isoli ogni agente in un ambiente di test distinto.
L'aggregazione dei risultati introduce un'altra sfida. Due agenti potrebbero segnalare la stessa vulnerabilità sottostante con descrizioni, valutazioni di gravità o prove di sfruttamento differenti.
Una piattaforma utile deve riconoscere tale sovrapposizione senza fondere percorsi di attacco distinti. Deve inoltre conservare prove sufficienti affinché un tester umano possa riprodurre e dare priorità a ogni risultato.
ThreatBook afferma che RedAgents deduplica e classifica automaticamente i risultati. Non ha pubblicato dati che mostrino con quale accuratezza funzioni questo processo sull'iniziale rosa di agenti.
La riduzione dei falsi positivi è un'altra affermazione centrale. L'esecuzione di più agenti non fa automaticamente sparire un risultato errato.
Gli agenti possono ripetere la stessa falsa supposizione, soprattutto quando condividono un modello sottostante o uno strumento di sicurezza. Al contrario, un risultato corretto di uno specialista potrebbe comparire una sola volta.
Un sistema di voto potrebbe quindi respingere un risultato prezioso perché gli altri agenti non l'hanno riprodotto. L'unione di tutti i risultati potrebbe creare il problema opposto e sovraccaricare i revisori.
RedAgents necessita di un meccanismo decisionale migliore del semplice consenso. Dovrebbe distinguere tra risultati riprodotti, risultati scoperti in modo indipendente e risultati di specialisti che richiedono convalida manuale.
La piattaforma deve inoltre affrontare la concorrenza di servizi consolidati di pentesting autonomo. NodeZero di Horizon3.ai si concentra sulla scoperta autonoma dei percorsi di attacco, mentre XBOW punta su vulnerabilità web convalidate e prove in produzione.
Questi sistemi offrono un riferimento per le aspettative degli acquirenti. I clienti vorranno exploit riproducibili, asset coinvolti chiaramente identificati, indicazioni per la correzione e conferme affidabili dopo l'applicazione di una soluzione.
RedAgents può differenziarsi se più agenti individuano debolezze sostanzialmente diverse durante lo stesso incarico. Può anche prevalere se un unico piano di controllo rende quei risultati più facili da gestire rispetto a diversi contratti separati.
L'aggregatore perde il proprio vantaggio se i clienti devono analizzare manualmente risultati in conflitto. Lo perde anche se gli agenti connessi non riescono a eguagliare la profondità di una piattaforma specializzata.
I primi confronti significativi dovrebbero quindi usare target, ambiti e finestre di test identici. Dovrebbero misurare rilevamenti unici convalidati, falsi positivi, incidenti operativi e tempo di revisione umana.
Senza queste prove, RedAgents rimane un'architettura plausibile anziché un sostituto dimostrato. Il lancio definisce la direzione del prodotto, non la sua superiorità.
Il meccanismo funziona solo se l'orchestrazione aggiunge segnale
Più agenti migliorano la copertura solo quando RedAgents ne controlla le azioni e trasforma il loro output in prove difendibili.
Il primo compito della piattaforma è far rispettare l'ambito. Il penetration testing comporta azioni che sarebbero non autorizzate al di fuori di un incarico definito.
Il National Institute of Standards and Technology degli Stati Uniti definisce le regole di ingaggio come vincoli stabiliti prima dell'inizio dei test. Queste regole concedono l'autorizzazione per attività specificate senza fornire permessi illimitati.
Le linee guida NIST identificano target, sistemi soggetti a restrizioni, tecniche accettate, periodi di test e indirizzi di origine come dettagli importanti dell'incarico. Le regole di test rimangono pertinenti anche quando il lavoro viene svolto dal software.
ThreatBook afferma che RedAgents utilizza whitelist per definire l'ambito dei test. Una whitelist può limitare gli indirizzi target, ma un funzionamento sicuro richiede controlli più granulari.
I team potrebbero dover vietare tecniche di denial-of-service, azioni distruttive sui database, modifiche alle password o l'accesso ai record dei clienti in produzione. Potrebbero inoltre richiedere finestre di manutenzione e limiti alla frequenza delle richieste.
Una piattaforma multi-agente deve applicare questi vincoli in modo coerente a ogni sistema connesso. Non può presumere che ciascun agente interpreti allo stesso modo un'istruzione scritta.
L'autorizzazione dovrebbe essere applicata al di fuori del ciclo di ragionamento del modello. Controlli di rete, credenziali isolate, policy sui comandi e autorizzazioni a livello di target offrono confini più solidi dei soli prompt.
Questo è importante perché gli agenti basati su modelli linguistici possono selezionare strumenti e generare dinamicamente sequenze di azioni. La loro flessibilità li aiuta a esplorare ambienti non familiari, ma rende anche difficile prevedere ogni azione futura.
OWASP definisce una versione di questo problema come eccessiva autonomia. Si verifica quando un sistema AI riceve più funzionalità, permessi o autonomia di quanto il suo compito richieda.
OWASP raccomanda di ridurre gli strumenti disponibili, limitare i permessi, richiedere l'approvazione umana per azioni rilevanti e applicare l'autorizzazione nei sistemi downstream. Le sue linee guida sull'eccessiva autonomia avvertono anche dei rischi derivanti da agenti peer compromessi in ambienti multi-agente.
Questo avvertimento si applica direttamente a RedAgents. Un aggregatore deve trattare ogni agente connesso sia come fonte di capacità di sicurezza sia come componente che potrebbe fallire.
La registrazione centralizzata può essere utile. RedAgents afferma di registrare in un unico luogo log e risultati degli agenti partecipanti, offrendo ai revisori una traccia di audit comune.
Una traccia condivisa dovrebbe mostrare quale agente ha emesso ogni comando, quale identità ha utilizzato, quale target ha risposto e se un controllo ha modificato l'azione richiesta. Dovrebbe inoltre conservare prove per ogni rilevamento convalidato.
La mancata conservazione dei dati aggiunge un altro compromesso operativo. L'eliminazione di dati di test sensibili può ridurre l'esposizione, ma i clienti potrebbero aver bisogno di prove selezionate per correzione, audit e revisione degli incidenti.
La piattaforma dovrebbe quindi rendere precise le policy di conservazione. Gli acquirenti devono sapere cosa include la “cancellazione completa”, quando avviene l'eliminazione e se backup o log diagnostici seguono la stessa policy.
L'isolamento dei dati diventa più complesso quando agenti di terze parti entrano nella piattaforma. ThreatBook afferma che i dati di test dei clienti restano nel suo ambiente invece di raggiungere tali fornitori.
Questa affermazione richiede una spiegazione architetturale. I clienti dovrebbero capire se il codice degli agenti viene eseguito in un isolamento gestito da ThreatBook, se modelli esterni ricevono prompt e come vengono filtrati i segreti.
Il valore della piattaforma deriva in ultima analisi dalla sua pipeline di evidenze. La sola scoperta è insufficiente se i team di sicurezza non possono fidarsi dei rilevamenti, riprodurli e definirne le priorità.
Un flusso di lavoro multi-agente credibile conserverebbe le prove individuali generando al contempo una valutazione unificata. Mostrerebbe quando gli agenti concordano, quando divergono e perché la piattaforma ha selezionato la gravità finale.
RedAgents ha descritto il progetto di alto livello, ma non quel livello di implementazione. La documentazione tecnica e le valutazioni controllate dei clienti determineranno se l'orchestrazione aggiunge davvero segnale.
La questione della sicurezza fa parte del prodotto
RedAgents combina capacità offensive che devono rimanere utili ai difensori senza trasformarsi in infrastrutture di attacco incontrollate.
Ogni prodotto di pentesting autonomo affronta un problema di duplice uso. Le stesse capacità che aiutano un'azienda a convalidare le proprie difese possono aiutare un attaccante ad automatizzare ricognizione e sfruttamento.
L'elenco iniziale di ThreatBook rende questa tensione insolitamente visibile. L'azienda afferma che Artex è passato dall'open source al closed source l'8 ottobre 2026, in seguito a presunti abusi in attacchi.
L'annuncio di ThreatBook collega quella decisione a incidenti che hanno colpito organizzazioni finanziarie sudcoreane. Tuttavia, il comunicato non fornisce un rapporto completo e indipendente sugli incidenti che supporti ogni dettaglio.
L'episodio solleva comunque una questione di governance diretta. Se un agente viene associato ad abusi, come valuta RedAgents il suo codice, i modelli, le dipendenze e il comportamento operativo prima della distribuzione?
L'azienda afferma che Artex Pro aggiunge controllo, stabilità e tracciabilità rispetto all'edizione open-source. Tali descrizioni non hanno ricevuto una convalida indipendente nei materiali di lancio.
Acquisire o commercializzare uno strumento può creare responsabilità, ma non rende automaticamente sicuro lo strumento. I controlli devono essere testati contro guasti, istruzioni malevole, dipendenze compromesse e risposte inattese dei target.
La diversità degli agenti può aumentare la superficie di attacco all'interno della piattaforma di test. Ogni connettore, integrazione di strumenti, endpoint di modello, archivio di credenziali e percorso di reporting crea un'altra potenziale debolezza.
L'aggregatore deve inoltre difendersi dal prompt injection. Un target ostile potrebbe presentare contenuti progettati per indurre un agente a ignorare le restrizioni o a esporre informazioni sensibili.
La comunicazione multi-agente introduce un'altra via. Un agente compromesso potrebbe produrre contesto fuorviante che influenza le scelte di un orchestratore o di un agente peer.
OWASP raccomanda di trattare input e output degli agenti come non attendibili. I controlli deterministici dovrebbero mediare le richieste rilevanti anziché delegare ogni decisione di autorizzazione a un modello.
La whitelist e il modello di dati centralizzato di ThreatBook affrontano una parte di questo problema. Non chiariscono se i singoli comandi ricevono l'applicazione delle policy prima dell'esecuzione.
L'azienda non ha inoltre identificato audit esterni, partner di progettazione nominati o clienti in produzione per RedAgents. Test limitati possono generare tali prove, ma i primi adottanti dovrebbero richiedere confini chiari.
Gli acquirenti dovrebbero chiedere quali sistemi siano supportati, quali azioni richiedano approvazione e come siano circoscritte le credenziali. Dovrebbero anche chiedere cosa accade quando un agente esce dal flusso di lavoro assegnato.
Rollback e interruzione di emergenza meritano uguale attenzione. Un operatore di sicurezza ha bisogno di un modo affidabile per fermare tutti gli agenti attivi, revocare le credenziali e preservare le prove durante un test anomalo.
I benchmark indipendenti devono includere gli esiti di sicurezza, non solo il conteggio delle vulnerabilità. Un sistema che trova più problemi causando interruzioni o gestendo male i segreti non offre una valutazione migliore.
I test dovrebbero inoltre separare gli ambienti di formazione dai sistemi di produzione. Anche le piattaforme autonome mature riconoscono che nessuna valutazione automatizzata della sicurezza può promettere un impatto zero.
L'onere aumenta quando diversi agenti operano contemporaneamente. Maggiore attività può attivare controlli difensivi, bloccare account o influire su servizi sensibili alla frequenza.
RedAgents dovrebbe rendere la concorrenza visibile e configurabile. I clienti hanno bisogno di controllare finestre di test, frequenze di richiesta, endpoint protetti e il numero massimo di azioni simultanee.
Un rilascio prudente inizierebbe con applicazioni isolate, repliche non di produzione e asset esterni con un ambito rigorosamente delimitato. I team potrebbero poi confrontare i rilevamenti con la convalida umana prima di ampliare l'accesso.
Questo approccio non ridurrebbe il valore del prodotto. Fornirebbe ai team di sicurezza prove su quali agenti offrano buone prestazioni nel loro ambiente.
Il lancio presenta quindi capacità e rischio come un'unica questione inseparabile. RedAgents avrà successo solo se il suo piano di controllo sarà almeno tanto sofisticato quanto i sistemi offensivi che coordina.
Tre segnali mostreranno se RedAgents mantiene le promesse
La fase successiva dovrebbe essere giudicata attraverso prove comparative, controlli di sicurezza applicabili e adozione reale da parte dei clienti.
Il primo segnale è un benchmark controllato rispetto a una solida baseline a singolo agente. ThreatBook dovrebbe pubblicare test che utilizzino target, credenziali, ambiti e limiti di tempo identici.
Il risultato utile non sarebbe un conteggio totale degli avvisi. Mostrerebbe vulnerabilità uniche convalidate, rilevamenti duplicati, falsi positivi, distribuzione della gravità e tempo di verifica umana.
Quel benchmark rafforzerebbe l'argomento multi-agente se RedAgents individuasse con coerenza problemi importanti mancati da ogni singolo partecipante. Risultati simili con più lavoro operativo lo indebolirebbero.
Il secondo segnale è una documentazione dettagliata sulla sicurezza. ThreatBook dovrebbe spiegare mediazione dei comandi, isolamento degli agenti, controlli delle credenziali, gate di approvazione, comportamento di conservazione e arresto di emergenza.
I test indipendenti avrebbero più peso di un elenco di funzionalità. Gli acquirenti hanno bisogno di prove che un agente non possa uscire dal proprio ambito a causa di prompt injection, errore del modello o output di un peer compromesso.
Il terzo segnale è un'adozione ripetuta oltre le sperimentazioni limitate. Casi di studio nominativi dovrebbero mostrare con quale frequenza le organizzazioni eseguono test, quali agenti selezionano e se i rilevamenti portano a correzioni verificate.
I dati di adozione rivelerebbero inoltre se i clienti apprezzano la scelta degli agenti o se selezionano semplicemente un unico sistema predefinito. La tesi dell'aggregatore si indebolisce se la maggior parte degli utenti ignora il roster più ampio.
RedAgents entra nel mercato con una risposta coerente a un limite reale. Nessun singolo approccio di test scopre ogni vulnerabilità, e le frequenti modifiche al software rendono meno sufficiente la valutazione periodica.
Tuttavia, aggiungere agenti non garantisce una sicurezza migliore. La piattaforma deve dimostrare che la sua orchestrazione genera rilevamenti diversi e convalidati senza creare un insieme altrettanto diversificato di rischi.
I responsabili della sicurezza che valutano il lancio di ThreatBook RedAgents dovrebbero iniziare con un confronto ristretto. Dovrebbero offrire a RedAgents e a un'alternativa consolidata lo stesso target autorizzato, quindi misurare i rilevamenti confermati e il carico di lavoro degli operatori.
Dovrebbero preservare la revisione umana per le azioni rilevanti e richiedere regole di ingaggio esplicite. I risultati dovrebbero essere valutati in base a riproducibilità, valore per la correzione ed esecuzione sicura.
La domanda per il prossimo trimestre è concreta: ThreatBook riuscirà a pubblicare prove che diversi agenti governati superano un singolo pentester autonomo maturo? Sarà questo risultato, non l’ampiezza del gruppo, a stabilire se il pentesting AI multi-agente diventerà una categoria duratura.
