Palo Alto Networks Unit 42 AI Defense diventa sempre attivo, ma le prove devono tenere il passo

Palo Alto Networks ha trasformato Unit 42 AI Defense in un servizio sempre attivo, sostituendo le valutazioni periodiche con test offensivi continui e multi-modello. Il lancio del 22 settembre mira a colmare il crescente divario tra attacchi alla velocità delle macchine e programmi di sicurezza ancora organizzati attorno a scansioni pianificate, revisioni manuali e remediation ritardate.

Il servizio, denominato formalmente Unit 42 Continuous Frontier AI Defense, combina modelli AI specializzati con l'esperienza umana nella sicurezza offensiva. Testa applicazioni, API, infrastrutture cloud, repository di codice e asset di rete man mano che gli ambienti dei clienti cambiano. Palo Alto Networks afferma che il sistema può anche collegare vulnerabilità distinte in percorsi di attacco, rivelando come un intruso potrebbe raggiungere sistemi di valore.

Questa promessa inserisce Palo Alto Networks in una competizione più ampia con Microsoft, CrowdStrike, Google e altri fornitori di sicurezza che stanno sviluppando difese basate su agenti. Tuttavia, la sfida decisiva non è tra fornitori. È tra la scoperta continua e un processo aziendale di remediation che spesso resta manuale, frammentato e lento.

Unit 42 AI Defense passa dalle valutazioni ai test continui

Il cambiamento importante non è un altro assistente AI. Palo Alto Networks sta trasformando i test di sicurezza offensiva in un servizio aziendale continuo.

Unit 42 ha introdotto l'offerta originale Frontier AI Defense nell'aprile 2026. Quel servizio era incentrato su un'analisi dell'esposizione in un momento specifico, seguita da un piano di sicurezza per migliorare le difese del cliente.

Il nuovo servizio di test continui estende questo approccio oltre una valutazione pianificata. Stabilisce una baseline, monitora le modifiche, esegue nuovi test, convalida i risultati e attiva ulteriori verifiche man mano che gli ambienti evolvono.

Palo Alto Networks descrive il prodotto come un servizio di sicurezza offensiva agentico. In questo contesto, agentico significa che il software può completare attività di sicurezza in più passaggi, invece di limitarsi a produrre raccomandazioni testuali.

Il servizio utilizza Claude Mythos 5 di Anthropic, GPT-5.6-Cyber di OpenAI e modelli open-weight. Un livello proprietario di orchestrazione indirizza le diverse attività verso il modello che Palo Alto Networks ritiene più adatto a ciascun compito.

Questa divisione del lavoro è importante perché i test di sicurezza comprendono diversi problemi distinti. Individuare codice sospetto, esplorare un'applicazione, valutare una configurazione e collegare vulnerabilità in un percorso di attacco richiede capacità diverse.

Unit 42 affianca quindi specialisti umani a questi modelli. I suoi consulenti esaminano i risultati, verificano se le vulnerabilità sono sfruttabili e assegnano priorità alle correzioni in base ai percorsi di attacco risultanti.

Il prodotto copre applicazioni web proprietarie e di terze parti, API, ambienti cloud, repository sorgente e asset di rete. Questa ampiezza riflette il modo in cui gli attacchi moderni attraversano i confini, anziché rimanere all'interno di un singolo strumento di sicurezza.

Un'applicazione web vulnerabile potrebbe esporre credenziali. Tali credenziali potrebbero sbloccare un servizio cloud, che potrebbe poi fornire accesso a dati sensibili o a un altro sistema di identità.

Uno scanner che segnala soltanto la prima vulnerabilità può non cogliere la conseguenza più ampia. Continuous Frontier AI Defense punta a modellare il percorso connesso, quindi a mostrare ai difensori quale collegamento merita attenzione per primo.

Il servizio può anche fornire indicazioni a livello di codice e raccomandazioni per patch virtuali. Una patch virtuale è un controllo compensativo che blocca lo sfruttamento senza modificare il software vulnerabile stesso.

Palo Alto Networks afferma che i clienti possono abbinare il servizio alla propria tecnologia separata di patch virtuali. Questa opzione è rilevante quando una correzione ufficiale del software non esiste ancora o non può essere distribuita immediatamente.

Secondo l'azienda, la disponibilità è globale tramite abbonamenti annuali. La combinazione di modelli inclusa varia in base all'abbonamento, mentre ogni configurazione utilizza il livello di orchestrazione multi-modello.

Questo lancio modifica quindi l'offerta Unit 42 in tre modi. I test diventano continui, la selezione dei modelli diventa dinamica e i risultati alimentano un ciclo ricorrente di convalida e remediation.

Il risultato è più simile a un red team permanente che a una tradizionale scansione delle vulnerabilità. Resta la domanda centrale se possa funzionare come tale su scala aziendale.

Il design multi-modello è la vera scommessa sul prodotto

Palo Alto Networks scommette che la diversità dei modelli possa individuare vulnerabilità di sicurezza che qualsiasi singolo modello frontier non riuscirebbe a rilevare.

Il ragionamento dell'azienda parte da una limitazione emersa nei propri test. Palo Alto Networks ha dichiarato ad Axios che nessun singolo modello ha individuato più del 40% delle vulnerabilità in un complesso ambiente cliente.

Le vulnerabilità individuate da Claude Mythos 5 e GPT-5.6-Cyber si sono sovrapposte meno del 10% delle volte. Queste cifre provengono dai test del fornitore e non hanno ricevuto una convalida indipendente equivalente.

Ciononostante, il divario riportato spiega l'architettura. Un servizio a modello singolo erediterebbe i punti ciechi, i modelli di rifiuto, i limiti di addestramento e i metodi preferiti di quel modello.

Un'infrastruttura multi-modello può assegnare compiti in base ai punti di forza osservati. Un modello potrebbe ispezionare il codice sorgente, mentre un altro esplora un'applicazione attiva o valuta una configurazione cloud.

I modelli open-weight aggiungono un'altra opzione. Possono essere adattati a compiti più circoscritti o distribuiti con vincoli operativi diversi rispetto ai modelli ad accesso controllato.

Il resoconto indipendente del lancio descrive un sistema che effettua ricerche continue e raccomanda correzioni. Cerca inoltre di combinare singole vulnerabilità in percorsi di attacco praticabili.

Questo secondo passaggio è essenziale. I team di sicurezza ricevono già più risultati di quanti possano gestire, e un ulteriore scanner automatizzato può aggiungere rumore senza ridurre il rischio.

La convalida dei percorsi di attacco pone una domanda più utile. Verifica se diverse vulnerabilità possano essere combinate per raggiungere un asset importante, un'identità o una funzione amministrativa.

Gli esperti umani di Unit 42 restano parte di questo processo. Il loro compito è verificare i risultati dei modelli, simulare comportamenti credibili degli avversari e distinguere percorsi di attacco plausibili da combinazioni teoriche.

Questo livello umano affronta anche un problema fondamentale dell'AI generativa. I modelli possono produrre spiegazioni convincenti ma errate, evidenze incomplete o passaggi che non possono essere riprodotti.

Un servizio utile deve quindi conservare gli artefatti. I team di sicurezza hanno bisogno dell'asset interessato, del percorso testato, del comportamento osservato, delle evidenze e della remediation proposta.

Questi record devono inoltre restare disponibili oltre la valutazione. I team necessitano di una base di conoscenza ricercabile che colleghi i risultati a responsabilità, decisioni precedenti, modifiche al codice, eccezioni e risultati dei retest.

Senza questa continuità, i test sempre attivi possono trasformarsi in un backlog in costante crescita. Più rilevamenti non producono automaticamente una sicurezza migliore.

Palo Alto Networks afferma di aver trascorso sei mesi a testare internamente l'approccio e in oltre 100 incarichi presso clienti Unit 42. Riferisce inoltre un investimento di 17 milioni di dollari nello sviluppo e nel lavoro metodologico.

Durante la distribuzione interna, l'azienda afferma che il servizio ha trovato ciò che ha definito un anno di esposizioni in tre settimane. Il confronto è notevole, ma l'annuncio non pubblica la baseline sottostante né la distribuzione della gravità.

Nelle valutazioni dei clienti, l'azienda afferma che la sua precedente Frontier AI Exposure Analysis ha rilevato esposizioni in ogni organizzazione testata. Ha classificato il 37% di tali risultati come ad alta criticità o critici.

Palo Alto Networks afferma inoltre che la maggior parte delle esposizioni proveniva da applicazioni proprietarie. Secondo quanto riferito, oltre due terzi dei risultati nelle applicazioni di terze parti non disponevano di un identificatore noto Common Vulnerabilities and Exposures.

Un CVE è un identificatore pubblico per una vulnerabilità software documentata. L'assenza di un CVE può indicare un difetto sconosciuto, un problema di configurazione o una vulnerabilità esterna ai database standard delle vulnerabilità.

Questi risultati supportano la necessità di test che vadano oltre gli scanner convenzionali. Non dimostrano quante segnalazioni fossero uniche, riproducibili o infine risolte.

L'architettura multi-modello è quindi sia l'elemento distintivo sia il primo problema di misurazione. Gli acquirenti hanno bisogno di prove che una maggiore copertura dei modelli produca meno rischi non rilevati senza moltiplicare i falsi positivi.

La sicurezza alla velocità delle macchine aumenta la pressione su ogni grande fornitore

Unit 42 AI Defense spinge i concorrenti a dimostrare che i loro agenti possono prevenire l'esposizione, non soltanto riassumere gli avvisi dopo il rilevamento.

Il lancio arriva mentre le aziende di sicurezza passano dalle interfacce chat ad agenti in grado di investigare, decidere e agire attraverso diversi sistemi. Palo Alto Networks colloca questa evoluzione nella gestione offensiva dell'esposizione.

Microsoft sta adottando un percorso correlato tramite Project Perception. L'azienda ha introdotto modelli e agenti specifici per la sicurezza, destinati a identificare, prioritizzare e correggere vulnerabilità software.

Microsoft afferma che la sua architettura combina modelli specializzati più piccoli con sistemi frontier più grandi. Il modello più piccolo gestisce l'analisi comune, mentre i modelli più grandi affrontano compiti più difficili.

Questo approccio ricorda la strategia di instradamento di Palo Alto Networks, sebbene Microsoft possa integrare i propri agenti nei prodotti per sviluppatori, identità, endpoint e cloud. La sua piattaforma di modelli per la sicurezza sottolinea inoltre governance e apprendimento continuo.

CrowdStrike si concentra sul security operations center. Il suo sistema Charlotte AI coordina agenti per indagini, threat hunting e risposta governata attraverso la piattaforma Falcon.

La proposta di SOC agentico dell'azienda parte dalla telemetria degli endpoint e dal contesto operativo. Palo Alto Networks inizia più vicino alla scoperta dell'esposizione e alla simulazione degli avversari.

Google Cloud sta inoltre integrando agenti nei flussi di lavoro di rilevamento delle minacce, indagine, sicurezza cloud e remediation. Il suo vantaggio deriva dal contesto cloud, dall'intelligence sulle minacce e dall'accesso al portafoglio di modelli di Google.

Questi prodotti si sovrappongono, ma non sono intercambiabili. Un agente per le operazioni di sicurezza indaga sull'attività, mentre un agente di test offensivi cerca attivamente vulnerabilità sfruttabili.

Le categorie probabilmente convergeranno. La scoperta porta alla remediation, la remediation richiede verifica e gli incidenti attivi spesso rivelano esposizioni che i test preventivi non hanno rilevato.

Questa convergenza aumenterà la pressione competitiva sull'accesso ai dati. Gli agenti funzionano meglio quando possono vedere codice, identità, configurazioni, relazioni di rete, ticket e comportamento in esecuzione.

Favorisce inoltre i fornitori con piattaforme aziendali consolidate. Possono collegare un risultato AI a un controllo, flusso di lavoro o punto di applicazione esistente senza creare ogni integrazione da zero.

Palo Alto Networks offre prodotti che coprono reti, sicurezza cloud, operazioni di sicurezza, identità e risposta agli incidenti. Unit 42 aggiunge competenze umane e intelligence sulle minacce a questo portafoglio.

Il servizio può quindi fungere da ponte tra consulenza e software. I consulenti convalidano i percorsi di attacco, mentre i prodotti della piattaforma possono supportare rilevamento, remediation o controlli compensativi.

Quel design crea un vantaggio commerciale, ma anche una fonte di scetticismo. Un fornitore che scopre una debolezza può raccomandare prodotti del proprio portafoglio come parte della soluzione.

I clienti avranno bisogno di una chiara separazione tra prove, priorità di remediation e raccomandazioni di prodotto. I risultati dovrebbero rimanere utili anche quando il sistema interessato appartiene a un altro fornitore.

Palo Alto Networks afferma che i suoi test includono asset di terze parti, non solo i propri prodotti. Gli acquirenti dovrebbero verificare che integrazioni, qualità delle prove e indicazioni per la remediation rimangano coerenti in ambienti eterogenei.

La pressione più ampia si estende oltre i fornitori di sicurezza. Red team interni, società di penetration testing e provider di vulnerability management devono spiegare dove l'esperienza umana crei valore oltre la scoperta automatizzata.

I tester umani continuano a portare creatività, contesto aziendale e capacità di giudizio sui comportamenti ambigui. Possono inoltre valutare processi sociali e presupposti organizzativi che un agente connesso alla rete non può osservare.

Gli agenti AI apportano ripetibilità, scala e persistenza. Possono ripetere i test dopo ogni modifica significativa senza attendere la successiva valutazione trimestrale.

Il modello vincente combinerà entrambi i punti di forza. L'automazione continua dovrebbe gestire il lavoro tecnico ricorrente, mentre gli esperti umani si concentrano su percorsi incerti, impatto aziendale e decisioni a rischio più elevato.

La scoperta continua si scontra con una remediation lenta

Il servizio ha successo solo quando i clienti riescono a correggere le esposizioni verificate quasi con la stessa rapidità con cui gli agenti le individuano.

Palo Alto Networks inquadra il prodotto attorno a una finestra difensiva che si restringe. La sua ricerca Unit 42 afferma che il percorso osservato più rapido dall'accesso iniziale all'esfiltrazione dei dati è sceso a 72 minuti.

I dati di incident response dell'azienda coprono oltre 750 indagini ad alta criticità. Riportano che la velocità degli attacchi è aumentata di quattro volte rispetto all'anno precedente.

Unit 42 afferma inoltre che l'87% degli attacchi analizzati ha attraversato almeno due superfici di attacco. Alcuni incidenti hanno coinvolto attività su fino a 10 fronti.

Secondo lo stesso rapporto, le debolezze di identità sono emerse nell'89% delle indagini. Le tecniche basate sull'identità hanno rappresentato il 65% degli accessi iniziali, mentre le vulnerabilità sfruttate hanno rappresentato il 22%.

Si tratta di statistiche generate dal fornitore e ricavate dagli incarichi di Unit 42. Descrivono un insieme sostanziale di incidenti, ma non tutte le organizzazioni né l'intero panorama delle minacce.

Anche con questa precisazione, chiariscono perché i test periodici siano sotto pressione. Una valutazione trimestrale offre una protezione limitata quando infrastruttura, codice, account e dipendenze cambiano ogni giorno.

I test continui possono ridurre l'intervallo tra la creazione di un'esposizione e la sua scoperta. Non possono ridurre autonomamente ogni processo successivo di approvazione, sviluppo, distribuzione o approvvigionamento.

Un difetto confermato in un'applicazione può comunque richiedere a un team di ingegneria di modificare il codice. Una configurazione errata del cloud può coinvolgere più responsabili con requisiti operativi in conflitto.

Un'identità esposta potrebbe richiedere la rotazione delle credenziali, la riprogettazione degli accessi e l'indagine sulle attività precedenti. Una debolezza di terze parti potrebbe non avere alcuna correzione controllabile dal cliente.

Il virtual patching può fornire protezione temporanea in alcune situazioni. Tuttavia, i controlli compensativi richiedono test, monitoraggio, responsabilità definite e un piano di remediation permanente.

Questo crea il trade-off centrale del lancio. Lo stesso sistema che migliora la scoperta può sovraccaricare team la cui capacità di remediation rimane fissa.

I responsabili della sicurezza dovrebbero quindi valutare il throughput anziché il mero numero di risultati. Le misure rilevanti includono il tempo di convalida, il tempo di assegnazione, il tempo di mitigazione e il tempo di verifica della chiusura.

Anche i tassi di riapertura contano. Una correzione che scompare durante la distribuzione successiva non rappresenta un miglioramento duraturo della sicurezza.

Un'altra misura utile è l'età dell'esposizione. La scoperta continua ha valore limitato se i risultati critici rimangono irrisolti mentre se ne accumulano di nuovi.

Le integrazioni del prodotto con i sistemi di ticketing possono aiutare a trasferire le prove nei workflow consolidati. L'integrazione non garantisce che il team corretto accetti la responsabilità o riceva un contesto sufficiente per intervenire.

Ogni ticket dovrebbe spiegare l'asset interessato, il percorso di attacco credibile, la conseguenza aziendale, le prove di convalida e il controllo raccomandato. Dovrebbe inoltre distinguere tra sfruttabilità confermata e inferenza del modello.

La definizione delle priorità deve rimanere sufficientemente stabile affinché i team possano pianificare. Se i punteggi di rischio cambiano senza prove comprensibili, sviluppatori e responsabili dell'infrastruttura diffideranno della coda.

Questo problema di fiducia è noto nel vulnerability management. I team di sicurezza spesso misurano la copertura degli scanner, mentre i team di ingegneria sperimentano il sistema attraverso falsi positivi e scadenze concorrenti.

I test sempre attivi aumentano la posta in gioco perché possono generare risultati in modo continuo. Gli acquirenti dovrebbero richiedere controlli per ambito, duplicazione, soppressione, escalation e ripetizione dei test.

Dovrebbero anche decidere dove si interrompe l'azione autonoma. Raccomandare una patch, aprire un ticket, modificare il codice e bloccare il traffico di produzione comportano rischi operativi molto diversi.

Un'implementazione matura stabilirà i permessi in base alle conseguenze. La ripetizione dei test a basso rischio può essere eseguita automaticamente, mentre le modifiche in produzione richiedono approvazione esplicita e piani di rollback.

Il risultato dovrebbe essere un ciclo chiuso. Scoprire, convalidare, assegnare, correggere, ripetere il test e conservare le prove.

Senza questo ciclo, Unit 42 AI Defense rischia di ottimizzare la parte più visibile del lavoro di sicurezza. Identificherebbe i problemi più rapidamente lasciando intatto il più difficile collo di bottiglia organizzativo.

L'affermazione sull'autonomia necessita di prove indipendenti

La maggiore incertezza non è se i modelli frontier possano trovare vulnerabilità. È se possano operare continuamente senza introdurre rischi o rumore inaccettabili.

Palo Alto Networks ha pubblicato diversi risultati interni significativi. Tuttavia, l'azienda non ha diffuso una metodologia sufficiente affinché soggetti esterni possano riprodurre le principali affermazioni sulle prestazioni.

Gli acquirenti non conoscono ancora il mix di vulnerabilità alla base del limite del 40% per un singolo modello. Mancano inoltre tassi dettagliati di precisione, recall, falsi positivi e falsi negativi.

La sovrapposizione riportata inferiore al 10% tra due modelli è particolarmente importante. Suggerisce diversità, ma una sovrapposizione ridotta può anche riflettere test incoerenti o definizioni diverse di un risultato valido.

Una valutazione indipendente dovrebbe verificare quale spiegazione prevalga. Dovrebbe inoltre testare se il sistema multi-modello individui percorsi di attacco più significativi rispetto a un team umano qualificato o a strumenti consolidati.

Il benchmarking dei sistemi di sicurezza agentici è difficile perché i test statici invecchiano rapidamente. I modelli possono assorbire dati di test pubblici, mentre gli ambienti aziendali reali includono autorizzazioni mutevoli, applicazioni personalizzate e dipendenze non documentate.

Anche il sistema di test può diventare un rischio. Un agente offensivo riceve strumenti e accessi destinati a sondare sistemi, eseguire azioni e raccogliere prove.

Tale accesso richiede confini rigorosi. L'agente dovrebbe operare secondo il principio del privilegio minimo, ricevendo solo le autorizzazioni necessarie per il compito assegnato.

Ogni azione dovrebbe essere registrata. Le operazioni ad alto rischio dovrebbero richiedere autorizzazione umana e l'ambiente dovrebbe supportare un contenimento rapido se il comportamento supera l'ambito approvato.

Il National Institute of Standards and Technology ha rilevato un ampio consenso sul fatto che gli agenti AI introducano nuove problematiche di sicurezza. Le sue conclusioni sulla sicurezza degli agenti affermano inoltre che le pratiche di cybersecurity consolidate richiedono adattamenti per i sistemi agentici.

Tali preoccupazioni si applicano direttamente ai test offensivi autonomi. Una prompt injection, uno strumento compromesso, un repository avvelenato o un obiettivo errato potrebbero reindirizzare un agente autorizzato.

Un modello potrebbe anche esporre codice sorgente sensibile o dati di configurazione a un servizio esterno. Gli acquirenti necessitano di risposte chiare su conservazione dei dati, accesso ai modelli, elaborazione regionale e politiche di addestramento.

Il design multi-modello rende queste domande più complesse. Modelli diversi possono comportare requisiti diversi di gestione dei dati, confini di distribuzione e limitazioni operative.

Palo Alto Networks afferma che esperti umani convalidano risultati e percorsi di attacco. L'annuncio pubblico fornisce meno dettagli sui controlli di approvazione, l'isolamento dei modelli, l'accesso dei clienti agli audit e le procedure di incidente per il sistema di test stesso.

Questo non significa che i controlli siano assenti. Significa che i potenziali clienti dovrebbero trattare i dettagli di governance come parte della valutazione del prodotto, non come una nota a piè di pagina dell'implementazione.

Anche l'affermazione secondo cui le esposizioni sono emerse in ogni cliente valutato merita contesto. Qualsiasi valutazione sufficientemente ampia può individuare debolezze di configurazione, componenti non supportati o problemi a bassa probabilità.

Le sole etichette di gravità non possono dimostrare l'importanza aziendale. Una debolezza tecnicamente critica può trovarsi dietro controlli solidi, mentre un difetto moderato nell'identità può consentire una catena di attacco dannosa.

I percorsi convalidati offrono un segnale migliore rispetto alla gravità isolata. Anche in questo caso, i clienti dovrebbero richiedere prove riproducibili e presupposti espliciti su accesso, capacità dell'attaccante e stato dell'ambiente.

Dovrebbero inoltre chiedere come il sistema gestisca i test distruttivi. La simulazione sicura deve stabilire la sfruttabilità senza danneggiare i dati, interrompere il servizio o violare i termini di terze parti.

Le applicazioni di terze parti presentano un altro confine. Un cliente può controllare un account o un'integrazione senza avere l'autorizzazione a eseguire test aggressivi sull'infrastruttura del provider.

La gestione dell'ambito deve quindi operare a livello di asset, azione e tempo. Un'autorizzazione ampia a testare “l'azienda” non è abbastanza precisa per un sistema autonomo.

L'interpretazione più sicura del lancio è misurata. Palo Alto Networks ha presentato un'architettura credibile e prove interne degne di nota, ma non uno standard di prestazioni stabilito in modo indipendente.

Questo divario è normale per un servizio appena lanciato. Diventa problematico solo se gli acquirenti scambiano i risultati del fornitore per esiti comprovati universalmente.

Tre segnali mostreranno se la difesa sempre attiva funziona

La prossima fase dovrebbe essere giudicata in base ai risultati della remediation, alla convalida indipendente e alle risposte della concorrenza, non al numero di modelli coinvolti.

Il primo segnale è la performance di remediation dei clienti. Palo Alto Networks dovrebbe rendere noto se i clienti chiudono più rapidamente i percorsi di attacco convalidati dopo aver adottato il servizio continuo.

Le misure utili includono il tempo mediano di convalida, il tempo di mitigazione, il tempo di chiusura e la ricorrenza dopo la ripetizione dei test. I soli conteggi di gravità non mostreranno se la sicurezza è migliorata.

Una riduzione dell'età dell'esposizione rafforzerebbe la tesi dell'azienda. Una coda crescente di risultati irrisolti suggerirebbe che la scoperta sta superando la capacità dei clienti.

Il secondo segnale è la valutazione tecnica indipendente. Ricercatori o clienti dovrebbero riprodurre il vantaggio multi-modello su applicazioni rappresentative, ambienti cloud, codebase e sistemi di identità.

Questo lavoro dovrebbe riportare falsi positivi, risultati mancati, contributi unici di ciascun modello e qualità delle prove. Dovrebbe inoltre confrontare i risultati degli agenti con tester umani e prodotti di sicurezza consolidati.

Guadagni coerenti sosterrebbero la tesi di orchestrazione di Palo Alto Networks. Grandi differenze tra ambienti mostrerebbero che gli acquirenti necessitano di aspettative di implementazione più ristrette.

Il terzo segnale è il modo in cui i concorrenti collegano la scoperta autonoma all'azione. Microsoft, CrowdStrike, Google e aziende di sicurezza specializzate stanno tutti portando gli agenti più in profondità nei workflow operativi.

Una risposta competitiva credibile combinerebbe test persistenti, remediation governata e verifica in ambienti tecnologici eterogenei. Un altro assistente conversazionale non affronterebbe lo stesso problema.

La pressione competitiva dovrebbe anche migliorare la trasparenza. Gli acquirenti hanno bisogno di evidenze comparabili sul comportamento dei modelli, sulle autorizzazioni, sulla gestione dei dati, sulla supervisione umana e sui risultati delle azioni correttive.

Palo Alto Networks ha individuato una discrepanza reale. Gli attaccanti possono automatizzare ricognizione e sfruttamento delle vulnerabilità, mentre molti difensori attendono ancora valutazioni programmate e ticket instradati manualmente.

Unit 42 Continuous Frontier AI Defense affronta questa discrepanza con test persistenti su più modelli. La sua architettura riconosce che nessun singolo modello ha una visione sufficiente e che la convalida umana resta importante.

La prova più difficile inizia dopo l'individuazione. Un'azienda deve trasformare le evidenze in modifiche con un responsabile, autorizzate, testate e durature, senza consentire a un agente offensivo di creare nuovi rischi.

I responsabili della sicurezza che valutano Palo Alto Networks Unit 42 AI Defense dovrebbero iniziare con un ambiente rappresentativo e misurare l'intero ciclo di remediation. Dovrebbero monitorare i percorsi verificati, i falsi positivi, i tempi di chiusura, le ricorrenze e lo sforzo richiesto per la revisione umana. Dovrebbero inoltre documentare ogni autorizzazione concessa agli agenti di test.

La decisione non dovrebbe dipendere dal fatto che la dimostrazione individui una vulnerabilità allarmante. Prima o poi, la maggior parte delle valutazioni su vasta scala ne rileva una. La domanda decisiva è se il servizio trasformi ripetutamente evidenze valide in sistemi più sicuri, più rapidamente dell'attuale processo dell'organizzazione.