Unit 42 Continuous Frontier AI Defense entra in funzione, ma nessun modello ha superato il 40% di copertura

Unit 42 Continuous Frontier AI Defense è stato lanciato il 22 settembre con un avvertimento significativo: nessun singolo modello di AI testato ha individuato oltre il 40% delle vulnerabilità.

Palo Alto Networks risponde con un servizio di sicurezza offensiva sempre attivo che combina diversi modelli di AI, software proprietario di orchestrazione e specialisti umani della sicurezza. Il servizio cerca continuamente esposizioni, verifica se gli attaccanti possono sfruttarle, mappa i percorsi d'attacco e raccomanda correzioni prioritarie.

Il dato principale rivela anche la tensione centrale del servizio. I modelli frontier possono automatizzare la ricerca sulla sicurezza su una scala che fino a poco tempo fa non era praticabile, ma ciascun modello continua a non rilevare la maggior parte dei problemi in ambienti complessi. Palo Alto Networks sostiene che la combinazione di Claude Mythos 5, GPT-5.6-Cyber, modelli open-weight, strumenti specializzati e ricercatori Unit 42 colmi una parte maggiore di questo divario.

Questo approccio mette sotto pressione i tradizionali programmi di penetration testing basati su valutazioni annuali o trimestrali. Mette inoltre alla prova gli acquirenti che avevano pianificato di scegliere un unico modello cyber leader e costruire attorno ad esso la propria automazione difensiva.

Tuttavia, il tetto del 40% deriva da una valutazione di Palo Alto Networks, non da un benchmark riprodotto in modo indipendente. L'azienda non ha fornito pubblicamente dettagli metodologici sufficienti per confrontare copertura, falsi positivi, costi o risultati di remediation tra i modelli.

Il lancio è quindi rilevante per ragioni che vanno oltre l'annuncio del prodotto. Trasforma la diversità dei modelli in una decisione di architettura della sicurezza, lasciando agli acquirenti il compito di verificare quanta protezione aggiuntiva offra il sistema combinato.

Unit 42 Continuous Frontier AI Defense trasforma i test in un servizio continuo

Il servizio sostituisce una valutazione programmata con un ciclo continuo di scoperta, convalida e remediation.

Palo Alto Networks ha introdotto il servizio globale tramite il suo annuncio di lancio del 22 settembre. Viene venduto come abbonamento annuale, con opzioni basate sui modelli utilizzati.

L'azienda lo descrive come un servizio di sicurezza offensiva agentica guidato da esperti. In questo contesto, agentico significa che il software può pianificare ed eseguire più fasi di test della sicurezza con una limitata supervisione umana.

Il servizio inizia con una valutazione di base dell'intero patrimonio tecnologico. Prosegue poi i test mentre cambiano applicazioni, identità, risorse cloud, repository di codice sorgente, API e asset di rete.

Il suo motore di test continuo cerca debolezze note e sconosciute. Un harness multi-modello assegna ogni attività al modello che Unit 42 ritiene più adatto.

Un harness è il livello software che circonda un modello. Fornisce strumenti, istruzioni, dati di destinazione, passaggi di convalida, autorizzazioni e controlli che trasformano un modello generico in un sistema operativo.

Unit 42 afferma inoltre che il servizio convalida percorsi d'attacco end-to-end. Questa distinzione è importante perché un difetto software non crea automaticamente un percorso pratico verso sistemi sensibili.

Un percorso d'attacco collega diverse condizioni, come un'applicazione esposta, controlli delle identità deboli, autorizzazioni cloud eccessive e dati raggiungibili. La convalida aiuta a determinare se tali condizioni possano produrre una compromissione significativa.

Il sistema genera quindi indicazioni per la remediation, comprese correzioni prioritarie, raccomandazioni a livello di codice e possibili patch virtuali. Una patch virtuale blocca il comportamento malevolo tramite un controllo di sicurezza quando modificare immediatamente l'applicazione interessata non è praticabile.

Secondo il comunicato stampa dell'azienda, gli abbonamenti possono utilizzare modelli Anthropic, OpenAI e open-source. Ogni configurazione impiega un harness multi-modello.

Questo progetto si basa su Unit 42 Frontier AI Defense, arrivato nell'aprile 2026. L'offerta precedente era incentrata sull'analisi puntuale delle esposizioni, un piano di sicurezza e un più ampio programma di trasformazione.

Il servizio di settembre modifica il modello operativo. Invece di produrre una sola valutazione e una roadmap, continua a testare l'ambiente dopo l'incarico iniziale.

Questo cambiamento riflette una reale debolezza delle revisioni periodiche della sicurezza. I sistemi aziendali cambiano costantemente attraverso deployment, aggiornamenti delle identità, nuove integrazioni, modifiche alla configurazione cloud e dipendenze di terze parti.

Una valutazione positiva può diventare obsoleta dopo il rilascio successivo. I test continui mirano a ridurre il tempo tra una modifica rischiosa e la sua individuazione.

Tuttavia, i test continui creano anche obblighi operativi. Un sistema sempre attivo richiede inventari degli asset stabili, credenziali controllate, confini di test, conservazione delle evidenze e regole di escalation chiare.

Senza questi controlli, la scoperta continua può trasformarsi in una generazione continua di avvisi. Il valore del servizio dipende dal fatto che i risultati convalidati raggiungano i team in grado di correggerli.

Perché il tetto del 40% di copertura conta più del lancio

Palo Alto Networks non sostiene che un singolo modello frontier risolva la scoperta delle vulnerabilità. Sostiene che il disaccordo tra modelli sia inevitabile.

Unit 42 afferma che nessun singolo modello ha individuato oltre il 40% delle vulnerabilità nelle codebase aziendali e negli ambienti live valutati. Afferma inoltre che Claude Mythos 5 e GPT-5.6-Cyber si sovrapponevano in meno del 10% delle esposizioni identificate.

Considerate insieme, queste affermazioni suggeriscono che i modelli abbiano rilevato debolezze sostanzialmente diverse. Un modello primo in classifica per numero totale di risultati potrebbe comunque non rilevare problemi individuati da un altro modello.

Questo è il ribaltamento insito nell'annuncio. Modelli cyber più capaci non concentrano necessariamente il lavoro di sicurezza attorno a un unico vincitore. Possono rendere più preziosa l'orchestrazione tra modelli differenti.

I modelli differiscono per dati di addestramento, metodi di reinforcement, salvaguardie, gestione del contesto, utilizzo degli strumenti e comportamento di ragionamento. Possono inoltre affrontare lo stesso obiettivo partendo da presupposti diversi.

Un modello potrebbe ottenere risultati migliori nella revisione del codice sorgente. Un altro potrebbe essere più efficace nell'interazione con un'applicazione live o nel collegare debolezze delle identità tra sistemi cloud.

L'harness circostante può contare quanto il modello di base. La selezione degli strumenti, la logica dei tentativi ripetuti, la memoria, la scomposizione del target e le regole di convalida influenzano ciò che il sistema può scoprire.

La precedente ricerca NOVA di Unit 42 offre un esempio più ampio di questa complementarità. NOVA è il Network and Open-Source Vulnerability Analyzer dell'azienda.

Palo Alto Networks afferma che NOVA ha analizzato 3.915 progetti open-source in due mesi e ha generato 14.090 risultati confermati relativi a vulnerabilità. L'azienda ne ha classificato il 40% come di gravità alta o critica.

Ha inoltre riferito che il 99,4% di tali risultati non era stato segnalato in precedenza. Questo dato va letto come risultato di una ricerca del fornitore, non come censimento indipendente delle vulnerabilità software.

Il progetto ha coperto ecosistemi che includono Go, JavaScript e TypeScript, PHP, C e C++, e Java. Unit 42 ha affermato che ogni modello valutato ha contribuito con risultati che gli altri modelli non avevano prodotto.

In un sottoinsieme dettagliato, il modello con il volume più elevato ha prodotto 235 risultati confermati, inclusi 185 risultati unici. Il modello con il volume più basso ha comunque prodotto 139 risultati, inclusi 93 unici.

Questi dati supportano l'idea che un ensemble possa aumentare la copertura. Non stabiliscono quanta copertura aggiuntiva riceverà ogni cliente aziendale.

Le dimensioni della codebase, il linguaggio di programmazione, l'architettura applicativa, gli strumenti disponibili e le autorizzazioni di test possono tutti modificare il risultato. Gli ambienti live introducono inoltre controlli che non esistono nei test limitati ai repository.

L'affermazione sul 40% non dovrebbe quindi essere interpretata come un limite universale per i modelli di AI. Descrive la valutazione di Unit 42 in condizioni che Palo Alto Networks non ha divulgato completamente al pubblico.

I dettagli mancanti includono l'insieme completo delle vulnerabilità, le configurazioni dei modelli, il numero di tentativi, l'accesso agli strumenti, i budget di tempo e il trattamento dei risultati duplicati.

Palo Alto Networks non ha inoltre pubblicato una matrice di confusione completa che mostri veri positivi, falsi positivi, falsi negativi e risultati contestati. Ciò rende difficile il confronto indipendente.

Ciononostante, il dato sulla copertura offre un avvertimento importante. Le aziende non dovrebbero considerare un benchmark solido di un modello come prova che un singolo modello possa vedere un'intera superficie d'attacco.

Un modello può ottenere buoni risultati in sfide controllate pur non rilevando debolezze create da una particolare catena di identità, integrazione o schema di deployment. La copertura deve essere misurata rispetto all'ambiente dell'acquirente.

La vera sfida è la copertura multi-modello contro la semplicità del modello singolo

La scelta principale non è più tra test umani e test con AI. È tra un ensemble gestito e la dipendenza da un modello e un flusso di lavoro unici.

Un sistema a modello singolo presenta vantaggi evidenti. È più facile da integrare, monitorare, governare e valutare rispetto a un servizio che instrada il lavoro tra diversi modelli proprietari e aperti.

L'acquirente può documentare un unico fornitore, una policy di accesso, una famiglia di modelli e un insieme di caratteristiche dell'output. I team di ingegneria affrontano meno elementi mobili quando diagnosticano risultati incoerenti.

Un servizio multi-modello aumenta la complessità. Ogni modello può richiedere prompt, strumenti, salvaguardie, regole di gestione dei dati e percorsi di escalation diversi.

Anche i risultati devono essere normalizzati prima che gli analisti possano confrontarli. Due modelli potrebbero descrivere la stessa vulnerabilità in modo diverso o assegnarle livelli di gravità in conflitto.

La risposta di Unit 42 è l'orchestrazione. Il suo harness proprietario è progettato per instradare il lavoro, combinare i risultati, convalidare la sfruttabilità e presentare le evidenze attraverso un unico servizio gestito.

Questo colloca il valore al di sopra del livello del modello. Se i modelli capaci diventano intercambiabili, il vantaggio durevole si sposta verso l'accesso ai target, l'instradamento delle attività, la convalida, l'integrazione della remediation e la supervisione degli esperti.

Il CEO di Palo Alto Networks Nikesh Arora ha sostenuto questa tesi in un'intervista ad Axios. Ha argomentato che più modelli abbinati all'esperienza umana rappresentano la probabile direzione del settore.

I modelli sottostanti non sono comuni chatbot pubblici. Anthropic limita le proprie capacità cyber meno ristrette a utenti verificati attraverso un programma di accesso Mythos.

OpenAI posiziona analogamente GPT-5.6-Cyber per la ricerca autorizzata sulle vulnerabilità e i test di sicurezza. Il suo programma Daybreak ampliato offre a difensori qualificati un accesso adatto a flussi di lavoro cyber avanzati.

Queste restrizioni creano un altro motivo per acquistare un servizio gestito. Molte aziende non possono ottenere, gestire o governare direttamente ogni modello soggetto a limitazioni incluso nel sistema Unit 42.

Tuttavia, l'accesso gestito introduce un rischio di concentrazione. I clienti dipendono da Palo Alto Networks per disponibilità dei modelli, decisioni di instradamento, valutazione, evidenze e priorità di remediation.

Un fornitore di modelli può modificare termini di accesso, salvaguardie, regole di conservazione o versioni dei modelli. Unit 42 deve assorbire tali cambiamenti senza indebolire la copertura né interrompere le valutazioni in corso.

I modelli open-weight offrono un'altra strada, ma comportano un proprio onere di governance. L'operatore diventa responsabile di hosting, aggiornamenti, isolamento, monitoraggio e controlli contro gli abusi.

L’ensemble crea inoltre un difficile problema di misurazione. Più modelli possono produrre più risultati senza generare una riduzione proporzionale del rischio concreto.

Dieci risultati sovrapposti a bassa gravità non hanno necessariamente più valore di una catena d’identità convalidata che raggiunge dati di produzione. Il solo volume delle scoperte è un indicatore di successo debole.

Gli acquirenti dovrebbero concentrarsi su percorsi d’attacco convalidati, risultati accettati, tempi di remediation, ricorrenze e riduzione del rischio confermata in modo indipendente. Queste misure collegano l’output dei modelli ai risultati di sicurezza.

Lo stesso principio si applica alla conoscenza interna in materia di sicurezza. Risultati, contesto del codice, registri di responsabilità e decisioni di remediation necessitano di una sede tracciabile, anziché di report dispersi.

I team di ingegneria che stanno già creando una knowledge base ingegneristica ricercabile possono applicare la stessa disciplina alle evidenze di sicurezza. L’obiettivo è preservare perché un risultato fosse rilevante e come sia stato risolto.

Il vantaggio competitivo andrà ai sistemi che trasformano le evidenze in azioni. Il solo accesso ai modelli diventerà meno persuasivo man mano che altri fornitori acquisiranno capacità simili.

Ciò che i Numeri Ancora Non Dimostrano

Il lancio presenta affermazioni convincenti sulla copertura, ma non fornisce ancora un benchmark di efficacia riproducibile.

I materiali pubblici non identificano l’intero insieme di modelli incluso nel confronto sulla copertura. Citano Claude Mythos 5 e GPT-5.6-Cyber come esempi principali, insieme a modelli open-weight.

Non spiegano nemmeno come Unit 42 abbia determinato l’insieme completo delle vulnerabilità rispetto alle quali è stata calcolata la copertura di ciascun modello.

Quel denominatore è essenziale. I ricercatori non possono sapere che un modello abbia individuato il 40% se non dispongono di un insieme di riferimento sufficientemente completo o di un insieme combinato attentamente definito.

Se il denominatore include ogni risultato unico prodotto da tutti i modelli, l’aggiunta di più modelli può aumentare il totale e ridurre la percentuale di ciascun modello individuale. Ciò dimostrerebbe comunque complementarità, ma misurerebbe una copertura relativa all’ensemble.

Un benchmark basato su vulnerabilità inserite appositamente risponderebbe a una domanda diversa. Misurerebbe se ciascun modello abbia individuato un insieme noto di difetti controllati.

Testare ambienti live dei clienti crea ulteriori complicazioni. Alcune vulnerabilità reali restano non confermate perché lo sfruttamento potrebbe interrompere la produzione o accedere a dati sensibili.

Unit 42 afferma che il suo sistema convalida la sfruttabilità nel mondo reale, ma i materiali pubblici non descrivono i confini di autorizzazione per ogni modalità di test. Tali confini possono influire in modo sostanziale sulla copertura apparente.

Anche i tassi di falsi positivi sono altrettanto importanti. Un sistema di IA può produrre molte ipotesi di vulnerabilità plausibili che consumano tempo degli analisti senza creare un rischio sfruttabile.

La convalida umana può ridurre questo problema. Tuttavia, il servizio non ha pubblicato quanti risultati grezzi gli esperti respingano, uniscano, declassino o rimandino a ulteriori test.

Anche costi e latenza restano poco chiari. Un harness multi-modello può migliorare la copertura consumando però molte più risorse di inferenza, sandbox e analisti rispetto a un flusso di lavoro con un singolo modello.

L’azienda afferma che il routing aiuta a gestire su scala il costo dell’IA di frontiera. Non ha pubblicato confronti dei costi per attività né i compromessi adottati dal suo router.

Gli acquirenti necessitano anche di chiarezza sulla gestione dei dati. I test di sicurezza possono esporre codice sorgente proprietario, dettagli architetturali, credenziali ed evidenze di debolezze sfruttabili.

Ogni fornitore di modelli può avere requisiti diversi in termini di conservazione e monitoraggio. I clienti dovrebbero stabilire quali dati lasciano il proprio ambiente, per quanto tempo restano disponibili e chi può esaminarli.

Le affermazioni del servizio sulla remediation richiedono un’analoga attenzione. Raccomandare una modifica al codice non equivale a distribuirla in sicurezza.

Le correzioni suggerite richiedono revisione, test, responsabilità, piani di rollback e verifica. Le patch virtuali possono ridurre rapidamente l’esposizione, ma possono anche creare una falsa sensazione di sicurezza se il difetto sottostante permane.

Palo Alto Networks afferma che il servizio può far emergere una baseline dell’intero ambiente e continuare i test man mano che l’ambiente cambia. Gli acquirenti dovrebbero chiedere come rilevi tali cambiamenti e determini cosa ritestare.

Un commit di repository, un aggiornamento delle policy cloud, una nuova route API o un cambiamento d’identità possono influire su parti diverse di un percorso d’attacco. Un retest efficiente dipende dalla comprensione di queste dipendenze.

La domanda scettica fondamentale è quindi misurabile: l’ensemble riduce l’esposizione convalidata più rapidamente rispetto agli attuali programmi di penetration testing e gestione delle vulnerabilità?

La risposta richiede evidenze a livello di cliente. Confronti utili includerebbero risultati accettati per ora di test, percorsi d’attacco critici eliminati, tempo mediano di remediation e tassi di ricorrenza.

Un retest indipendente dovrebbe anche confermare che le correzioni segnalate chiudano il percorso originale. Altrimenti, il sistema rischia di misurare il lavoro generato anziché il rischio ridotto.

Nessuna di queste lacune rende il servizio inefficace. Esse definiscono la differenza tra una strategia tecnica plausibile e un valore operativo dimostrato in modo indipendente.

I Test Continui con IA Sottopongono i Team di Sicurezza a Nuove Pressioni

Il servizio sposta il collo di bottiglia dall’individuazione delle vulnerabilità alla decisione su quali risultati meritino un’azione immediata.

I team di sicurezza gestiscono già avvisi degli scanner, risultati dell’analisi del codice, segnalazioni di bug, risultati dei penetration test, configurazioni cloud errate e avvisi sulle identità. Un ulteriore sistema di scoperta ad alto volume può aggravare questo carico.

L’enfasi di Unit 42 sulla convalida degli exploit è concepita per affrontare questo problema. Un risultato collegato a un percorso d’attacco praticabile merita più attenzione di una debolezza teorica isolata.

Questa prioritizzazione diventa critica quando gli agenti operano in modo continuo. Un report mensile consente ai team di elaborare un pacchetto delimitato, mentre un sistema sempre attivo può generare lavoro dopo ogni cambiamento significativo.

La pressione si estende oltre il centro operativo di sicurezza. Proprietari delle applicazioni, team cloud, amministratori delle identità e responsabili dell’ingegneria devono partecipare alla remediation.

Una raccomandazione a livello di codice richiede uno sviluppatore che comprenda il servizio interessato. Un risultato relativo alle identità può richiedere modifiche che interrompono flussi di lavoro consolidati o sistemi automatizzati.

L’esposizione cloud può coinvolgere più team e account. Una correzione di rete può influire su disponibilità, monitoraggio e traffico dei clienti.

Ciò rende i dati di responsabilità parte del controllo di sicurezza. Il servizio deve collegare ogni esposizione convalidata alla persona o al team in grado di risolverla.

Le organizzazioni necessitano inoltre di obiettivi di risposta basati su sfruttabilità, portata e impatto aziendale. Le sole etichette di gravità raramente catturano queste relazioni.

Un difetto critico in una libreria potrebbe non avere alcun percorso raggiungibile in un ambiente. Una debolezza moderata nell’identità potrebbe fornire accesso diretto a sistemi di produzione sensibili.

I test continui cambiano anche le domande di approvvigionamento. Gli acquirenti dovrebbero valutare il processo operativo che circonda i modelli, non soltanto i nomi dei modelli stampati nell’annuncio.

Dovrebbero chiedere se Unit 42 fornisca evidenze per ogni fase dell’attacco, registri ogni azione degli strumenti, separi la scoperta dallo sfruttamento e supporti condizioni di arresto definite dal cliente.

Le credenziali dovrebbero adottare il privilegio minimo necessario per i test. L’accesso alla produzione dovrebbe essere isolato, temporaneo, monitorato e revocabile.

Le azioni distruttive richiedono controlli espliciti. Un agente che convalida una debolezza del database non dovrebbe ricevere il permesso di modificare o rimuovere informazioni di produzione.

I clienti dovrebbero inoltre richiedere log completi. Un risultato utile dovrebbe mostrare l’asset interessato, il percorso testato, l’evidenza osservata, la versione del modello e dell’harness e il revisore umano.

Questi registri supportano remediation, audit, risposta agli incidenti e retest successivi. Aiutano inoltre a identificare regressioni del modello dopo un aggiornamento.

I fornitori tradizionali di penetration testing subiscono pressioni da questo modello operativo. Gli incarichi annuali offrono competenze approfondite, ma i loro risultati iniziano a invecchiare non appena il target cambia.

Gli scanner automatizzati affrontano una sfida diversa. Offrono visibilità continua, ma molti faticano a convalidare catene di exploit complesse tra livelli di codice, cloud, identità e rete.

Unit 42 sta posizionando il proprio servizio tra queste categorie. Combina automazione continua, supervisione di esperti e convalida dei percorsi d’attacco.

La questione irrisolta è se questa combinazione possa scalare economicamente senza ridurre la qualità della revisione umana. L’attenzione degli esperti resta limitata anche quando l’inferenza dei modelli si espande.

Se i modelli generano risultati più velocemente di quanto i clienti possano correggerli, il servizio deve contribuire a ridurre la coda. In caso contrario, la scoperta continua può esporre più frequentemente gli stessi vincoli organizzativi.

Tre Segnali Mostreranno se la Strategia Multi-Modello Funziona

Il prossimo test non è un altro annuncio di modello. È la prova che una copertura combinata produce una riduzione del rischio più rapida e verificata in modo indipendente.

Il primo segnale è una metodologia di valutazione dettagliata. Palo Alto Networks dovrebbe divulgare come abbia calcolato il limite di copertura del 40% e il dato di sovrapposizione inferiore al 10%.

Una metodologia utile identificherebbe le versioni dei modelli, i tipi di target, le autorizzazioni degli strumenti, i limiti di tentativi, i budget di tempo, i criteri di convalida e il denominatore.

Dovrebbe inoltre riportare falsi positivi e risultati contestati. Senza questi dettagli, gli osservatori esterni non possono determinare se il vantaggio dell’ensemble derivi dalla diversità dei modelli, dal design dell’harness, da maggiore capacità di calcolo o dall’intervento umano.

Pubblicare queste informazioni rafforzerebbe l’argomento centrale. Se la differenza persiste in condizioni riproducibili, i sistemi difensivi a modello singolo affronteranno un chiaro svantaggio architetturale.

Se test indipendenti mostrano differenze minori, i clienti potrebbero preferire flussi di lavoro più semplici con un modello e strumenti specializzati. Il risultato indebolirebbe la tesi a favore di un grande ensemble gestito.

Il secondo segnale è l’evidenza dei clienti collegata alla remediation. I case study dovrebbero riportare percorsi d’attacco convalidati e chiusi, tempi di risoluzione, ricorrenza e confronto con precedenti metodi di test.

Individuare in alcune settimane esposizioni equivalenti a un anno di lavoro sembra impressionante, ma il volume da solo non dimostra valore. Il risultato importante è se i team abbiano eliminato prima un rischio concreto.

Le evidenze dovrebbero distinguere le vulnerabilità appena scoperte dai risultati già rilevati dagli scanner. Dovrebbero inoltre separare le correzioni generate dal modello dalle modifiche revisionate e distribuite dai clienti.

Un retest indipendente renderebbe questi risultati più credibili. Un team separato dovrebbe confermare che il percorso d’attacco originale non funzioni più e che la correzione non abbia creato un’altra esposizione.

Il terzo segnale è il modo in cui concorrenti e fornitori di modelli reagiscono. Altri fornitori di sicurezza possono costruire i propri router, collaborare con programmi di modelli ad accesso controllato o offrire livelli di convalida indipendenti dal modello.

Anthropic e OpenAI possono anche ampliare l’accesso diretto per difensori verificati. Un accesso più ampio ridurrebbe uno dei vantaggi dell’acquisto di capacità tramite un fornitore gestito.

Allo stesso tempo, nuove versioni dei modelli possono aumentare la diversità. Un modello con addestramento o comportamento nell’uso degli strumenti realmente diversi potrebbe contribuire con risultati che i sistemi attuali non individuano.

Osservate se Unit 42 aggiunge modelli perché migliorano la copertura misurata o perché rafforzano un elenco di marketing. Il servizio dovrebbe poter rimuovere modelli che aggiungono poco valore unico.

Gli acquirenti dovrebbero richiedere dati sul contributo di ogni modello nell’ensemble. Un report utile mostrerebbe risultati unici convalidati, sovrapposizione, costo, latenza e prestazioni per categoria di attività.

Dovrebbero inoltre chiedere come il routing cambi nel tempo. Un harness che apprende quale modello gestisca meglio un determinato linguaggio o tipo di target può migliorare l’efficienza.

Tuttavia, il routing dinamico complica la riproducibilità. Ritestare lo stesso ambiente con una diversa combinazione di modelli può produrre risultati ed evidenze differenti.

I record con versioni possono controllare questo problema. Ogni risultato dovrebbe conservare il modello, l’harness, gli strumenti, le policy e lo stato del target rilevante utilizzati durante i test.

Unit 42 Continuous Frontier AI Defense arriva in un momento in cui i modelli cyber stanno diventando più capaci e più soggetti a restrizioni. Questa combinazione crea una domanda di intermediari affidabili.

Palo Alto Networks ha offerto una risposta coerente: utilizzare più modelli, circondarli di strumenti controllati, convalidare i risultati e mantenere gli esperti nel ciclo.

L’affermazione di una copertura del 40% rende questa strategia plausibile, ma non conclusiva. Le aziende dovrebbero trattarla come un’ipotesi da verificare rispetto alle proprie applicazioni, identità e ambienti cloud.

I responsabili della sicurezza che valutano il servizio dovrebbero iniziare con un progetto pilota circoscritto. Prima dell’avvio dei test, occorre definire asset, autorizzazioni, controlli di sicurezza, risultati esistenti e metriche di remediation.

Successivamente, confrontate i risultati accettati, i percorsi di attacco verificati, il carico di lavoro degli analisti e i tempi di chiusura con il programma attuale. Chiedete quale modello abbia contribuito in modo unico a ciascun risultato importante.

Questo processo trasforma l’affermazione centrale di Unit 42 in qualcosa che un’organizzazione può verificare. Se l’ensemble individua percorsi significativi che gli strumenti esistenti non rilevano, l’architettura giustifica la sua complessità.

Se invece si limita ad ampliare la coda degli avvisi, il numero di modelli non avrà importanza. La domanda è se i test continui con più modelli aiutino i difensori a chiudere le esposizioni prima che gli attaccanti possano sfruttarle.