La skill di audit di sicurezza Cloudflare trasforma la revisione del codice AI in un flusso di lavoro avversariale

Cloudflare ha rilasciato un flusso di lavoro di audit del codice AI in sei fasi, ma la skill di audit di sicurezza Cloudflare non è un altro prompt che chiede a un modello di trovare bug. Assegna agenti separati per mappare il codice, cercare vulnerabilità, mettere in discussione i risultati e verificare le prove residue.

Questa distinzione è importante perché i report di sicurezza generati dall'AI spesso contengono affermazioni plausibili senza un percorso di attacco valido. Il design di Cloudflare considera ogni vulnerabilità proposta come un'accusa che un altro agente deve tentare di confutare. Registra inoltre ciò che l'audit ha coperto, rendendo più evidenti le analisi mancanti.

La release open source racchiude idee sviluppate da Cloudflare durante la realizzazione di un harness interno per le vulnerabilità molto più ampio. La skill pubblica è pensata per un repository e una singola esecuzione di audit. Il sistema interno di Cloudflare, al contrario, conserva i risultati tra repository diversi, traccia le dipendenze e gestisce migliaia di risultati.

Questo crea la tensione centrale attorno alla release. Una skill riutilizzabile abbassa la soglia d'accesso a una revisione strutturata del codice AI, ma non può riprodurre da sola l'infrastruttura interna di Cloudflare. Gli sviluppatori ottengono un punto di partenza più solido, non un sostituto autonomo degli ingegneri della sicurezza.

Cosa cambia davvero la skill di audit di sicurezza Cloudflare

Cloudflare sta trasformando la revisione di sicurezza AI da una conversazione in un processo che produce prove, con copertura esplicita e controlli di verifica.

Il repository della skill di audit pubblico descrive un flusso di lavoro progettato per agenti di coding che supportano strumenti e sotto-agenti isolati. È rilasciato con licenza MIT e può essere installato tramite l'interfaccia a riga di comando Skills.

La skill di audit di sicurezza Cloudflare divide un audit in sei fasi. La ricognizione mappa l'architettura software, i confini di fiducia, le superfici di input e le prove disponibili. Il processo registra questa mappa in un documento architetturale e in un registro di copertura leggibile dalle macchine.

Segue la ricerca guidata dalla copertura. L'agente principale assegna cacciatori isolati ad aree definite e classi di attacco. Ogni cacciatore registra ciò che ha verificato, invece di restituire soltanto un elenco di problemi sospetti.

Questo registro è importante perché un report breve potrebbe altrimenti creare una falsa fiducia. Un agente potrebbe ispezionare il codice di autenticazione, non trovare nulla e lasciare intendere che l'intera applicazione sembri sicura. Un record di copertura può mostrare che il parsing, la configurazione di deployment, la gestione delle dipendenze o l'isolamento dei tenant hanno ricevuto poca attenzione.

La validazione dei candidati assegna ogni pista distinta a un nuovo verificatore. Questo verificatore tenta di respingere la vulnerabilità proposta controllandone presupposti, percorso nel codice sorgente, soggetto interessato e risultato di sicurezza. L'agente di ricerca non approva il proprio lavoro.

I risultati che resistono passano quindi a un output strutturato. La skill separa i record in risultati confermati, problemi che richiedono validazione e candidati respinti. Uno schema definisce i campi obbligatori, mentre i validator JavaScript inclusi controllano meccanicamente i file.

Le fasi finali verificano in modo indipendente le affermazioni sul codice sorgente e generano report indipendenti dal target. Modifiche sostanziali a un risultato attivano un ulteriore passaggio di verifica. Questo design mira a impedire a chi redige il report di rafforzare silenziosamente un'affermazione debole durante la sintesi.

Il risultato differisce da un normale audit di sicurezza del codice AI in un aspetto cruciale. Il deliverable include un resoconto delle superfici esaminate, delle idee respinte, dei fatti irrisolti e dei risultati verificati indipendentemente. Un report dall'aspetto rassicurante non è più l'unico artefatto.

Cloudflare definisce inoltre un rigoroso confine di esecuzione. Build, test, fuzzer, browser e fixture controllate dal target richiedono una sandbox del sistema operativo senza accesso alla rete esterna. Senza questi controlli, il flusso di lavoro deve conservare una pista come non verificata invece di eseguire codice non attendibile.

Questa restrizione rende la release meno comoda di un prompt di audit in una sola riga. Riflette anche un problema di sicurezza reale. Il codice in revisione può contenere istruzioni o comportamenti di build che attaccano l'ambiente di audit stesso.

Perché Cloudflare ha creato una skill prima di un harness per l'intera flotta

La skill pubblica è preziosa perché cattura il metodo di audit di Cloudflare, rivelando al tempo stesso perché una singola sessione di agente raggiunge un limite operativo.

Cloudflare afferma che il progetto è iniziato come una security skill di circa 450 righe per un singolo repository. Gli ingegneri ne hanno perfezionato i prompt finché non ha portato alla luce bug utili, quindi hanno trasferito i suoi scenari e le sue regole di validazione in un sistema più ampio.

L'azienda ha descritto quell'evoluzione nel suo articolo di engineering sul vulnerability harness. La prima versione utilizzava tre agenti di ricerca per la ricognizione, cacciatori separati per le classi di attacco, validator avversariali, risultati strutturati e verifica indipendente del codice sorgente.

Cloudflare ha identificato tre limiti durante queste prime esecuzioni. Le sessioni lunghe esaurivano il contesto del modello, le esecuzioni interrotte perdevano i progressi e le revisioni di un singolo repository non coglievano le relazioni con i servizi che lo utilizzano.

Questi fallimenti non erano semplicemente problemi di qualità del modello. Erano problemi di gestione dello stato.

Un modello può ragionare sul codice attualmente nel suo contesto, ma un audit di grandi dimensioni produce molte ipotesi parallele. Ogni ipotesi porta con sé file, confini di fiducia, presupposti, esperimenti, controargomentazioni e cambiamenti di stato. Comprimere questa cronologia in un riepilogo della conversazione può eliminare dettagli decisivi.

Cloudflare ha risposto esternalizzando lo stato. Il suo harness successivo tratta i modelli linguistici come lavoratori sostituibili e conserva informazioni durature sugli audit al di fuori delle loro finestre di contesto. Un database memorizza l'esecuzione, il repository e la fase di ogni attività.

Questa distinzione spiega perché Cloudflare ha rilasciato il punto di partenza invece di presentarlo come il sistema interno definitivo. Una skill può codificare una sequenza rigorosa in un ambiente di coding. Non può fornire automaticamente inventario della flotta, code persistenti, grafi delle dipendenze o telemetria di produzione.

Cloudflare riferisce che il passaggio dalla prima skill a un sistema che copre 128 repository ha richiesto circa sei settimane. Questo sistema interno opera su Rust, Go, C, Lua, TypeScript, Python e formati di configurazione senza orchestrazione specifica per linguaggio.

Il suo flusso di lavoro più ampio separa la scoperta dalla validazione. Il Vulnerability Discovery Harness mappa e cerca potenziali debolezze. Un diverso Vulnerability Validation System deduplica i risultati, verifica la rilevanza in produzione e gestisce la correzione.

Cloudflare afferma di utilizzare modelli diversi per queste due fasi. Questa scelta riduce la dipendenza dai ricorrenti schemi di ragionamento di un solo modello. Consente inoltre all'azienda di cambiare fornitori senza riprogettare il processo di sicurezza attorno a un modello specifico.

Questa posizione neutrale rispetto ai modelli mette sotto pressione i vendor che presentano le prestazioni nei benchmark come principale misura di un prodotto di sicurezza AI. L'argomento di Cloudflare è che orchestrazione, prove e confutazione indipendente determinano se l'output del modello diventa lavoro di engineering utile.

L'azienda non sostiene che la skill ricrei la sua pipeline di produzione. Le sue stesse indicazioni suggeriscono ai team di iniziare con ricognizione, ricerca e validazione. Il tracciamento tra repository e la deduplicazione dedicata diventano utili solo dopo che il volume degli audit crea questi problemi.

Questa sequenza offre ai team più piccoli un punto di ingresso pratico. Possono verificare se prompt e regole sulle prove funzionano sul loro codice prima di costruire attorno a essi infrastrutture costose.

Impedisce inoltre che la release pubblica diventi una demo di prodotto fuorviante. Il repository offre il metodo che ha dato origine al sistema di Cloudflare, non il sistema completo che ora opera nell'intera flotta.

Il vero avversario è la revisione del codice AI in un solo passaggio

Il vulnerability harness di Cloudflare mette in discussione l'assunto secondo cui un unico modello capace possa ispezionare un repository, identificare difetti reali e valutare in modo affidabile le proprie conclusioni.

Una revisione in un solo passaggio segue di solito uno schema familiare. Lo sviluppatore concede a un agente di coding accesso a un repository e gli chiede di trovare vulnerabilità di sicurezza. L'agente legge file selezionati, individua pattern sospetti e scrive un report rifinito.

Questo processo può produrre piste utili. Può anche nascondere tre fallimenti distinti.

Primo, il modello sceglie cosa ispezionare senza conservare un record duraturo di ciò che ha saltato. Secondo, lo stesso processo di ragionamento genera e valuta ogni affermazione. Terzo, un linguaggio persuasivo può far apparire definitive prove incomplete.

Il flusso di lavoro di Cloudflare affronta ogni fallimento separatamente. Il registro di copertura documenta la superficie di audit prevista. Cacciatori indipendenti esaminano unità circoscritte. Validator nuovi tentano di confutare i candidati invece di migliorarne la presentazione.

Questa separazione avversariale è più importante della semplice aggiunta di altri agenti. Dieci agenti che condividono gli stessi presupposti possono generare dieci versioni dello stesso falso positivo. Cloudflare assegna ruoli diversi e attribuisce ai validator l'autorità di respingere la teoria di un cacciatore.

La skill richiede inoltre un fallimento concreto di un confine. Un problema confermato necessita di un soggetto, una risorsa o un risultato di sicurezza interessati. La mancata adozione di una best practice non diventa automaticamente una vulnerabilità.

Questa distinzione filtra risultati quali comportamenti senza restrizioni disponibili solo a un amministratore già considerato affidabile. Respinge inoltre report che descrivono una difesa assente senza mostrare come un attaccante attraversi un confine reale.

Il processo interno di Cloudflare adotta requisiti di prova più rigorosi. Un risultato confermato deve includere un test riproducibile rispetto al codebase originale. Il test non può dipendere da modifiche al codice sorgente introdotte dall'agente di ricerca.

Questa regola affronta una modalità di fallimento particolarmente pericolosa. Un agente può modificare il codice durante gli esperimenti, quindi dimostrare un exploit sulla versione modificata. Senza controlli sullo stato del codice sorgente, il report risultante può attribuire all'applicazione un difetto creato dall'agente.

La validazione meccanica aggiunge un ulteriore livello. Controlli ordinari del codice verificano che file, percorsi, patch e test citati esistano o siano analizzabili correttamente. Il modello linguistico non decide se il proprio output soddisfa questi requisiti strutturali di base.

Cloudflare afferma che una singola esecuzione della skill ha rilevato circa metà delle vulnerabilità scoperte infine da esecuzioni ripetute. Si tratta di un'osservazione riportata dall'azienda, non di un tasso di rilevamento misurato in modo indipendente.

Tuttavia, il risultato supporta la scelta progettuale centrale della release. Un'esecuzione completata non dimostra una copertura completa, anche quando ogni risultato riportato è valido.

Un rigoroso audit di sicurezza del codice AI necessita quindi di due diverse affermazioni di affidabilità. Una riguarda la validità di ciascun risultato. L'altra riguarda quanto approfonditamente l'audit abbia cercato risultati.

La skill di audit di sicurezza Cloudflare espone entrambe le questioni. I suoi verdetti confermati, irrisolti e respinti descrivono l'affidabilità delle prove. Il suo registro di copertura descrive il processo di ricerca.

L'analisi statica tradizionale resta rilevante in questo modello. Gli scanner deterministici eccellono nei pattern noti, nelle regole di flusso dei dati e nei controlli ripetibili. Un agente può esplorare presupposti di fiducia specifici dell'applicazione o combinare debolezze attraverso logiche poco familiari.

L'esperienza interna di Cloudflare offre anche un avvertimento sulle preferenze presunte per gli strumenti. L'azienda afferma che i suoi cacciatori non hanno invocato un percorso Semgrep integrato durante un mese di esecuzioni. Hanno preferito leggere ed eseguire codice, richiedendo spesso ambienti o fixture mancanti.

Questa osservazione non dimostra che l'analisi statica sia priva di valore. Dimostra che installare uno strumento non garantisce che un agente lo utilizzi in modo efficace. I team devono misurare il comportamento effettivo degli strumenti all'interno del proprio flusso di lavoro.

La competizione non è quindi tra IA e scanner convenzionali. È tra output non strutturato dei modelli e un processo di audit che combina controlli deterministici, esplorazione specializzata e verifica avversariale.

Le conclusioni strutturate riducono il rumore, ma non dimostrano la sicurezza

L'aspetto più solido del rilascio è il rifiuto di trattare output plausibili del modello come prove confermate, ma questa disciplina non può misurare le vulnerabilità non scoperte.

Cloudflare riferisce che il suo harness interno per la scoperta ha generato 20.799 candidati grezzi. Circa 12.057 hanno superato la fase iniziale di validazione prima di entrare in un pool di validazione più ampio.

Dopo che le conclusioni di un altro harness si sono aggiunte al sistema, il pool centrale conteneva 13.841 record. La deduplicazione ne ha eliminati 5.442, mentre 1.154 sono stati reindirizzati perché relativi al repository sbagliato o a casi a basso rischio. Cloudflare afferma che per i team di ingegneria sono rimaste 7.245 conclusioni azionabili.

Questi numeri sono utili perché mostrano quanto filtraggio si interponga tra la generazione e la correzione. Non dovrebbero essere interpretati come un benchmark indipendente dell'accuratezza di rilevamento.

Cloudflare seleziona i propri repository, modelli, prompt, classi di attacco e definizioni. Le cifre pubblicate descrivono la sua pipeline operativa. Non dimostrano le prestazioni della skill pubblica su una base di codice non correlata.

L'azienda evita esplicitamente di dichiarare un tasso di falsi negativi. Un repository reale non dispone di un insieme completo di etichette che includa ogni vulnerabilità, quindi il richiamo non può essere calcolato direttamente. Esecuzioni ripetute che continuano a trovare bug mostrano una copertura incompleta, ma non la dimensione della lacuna residua.

Questa incertezza deve essere al centro di qualsiasi valutazione. Un report verificato può dimostrare che diverse conclusioni sono reali. Non può dimostrare che il codice sottoposto ad audit sia sicuro.

La skill pubblica cerca di comunicare questa differenza attraverso tre verdetti.

Una conclusione confermata ha una traccia completa della sorgente e un risultato osservato circoscritto. Un record da-validare conserva un'esatta questione irrisolta senza attribuire una gravità non supportata. Un record respinto documenta perché un candidato non ha superato la verifica.

Conservare i candidati respinti ha un valore pratico. Le esecuzioni future possono distinguere un percorso realmente nuovo da un'idea precedentemente confutata. I revisori possono anche verificare se il rifiuto dipendeva da fatti cambiati in seguito.

Tuttavia, l'output strutturato può creare una propria illusione di certezza. Un record JSON valido non è necessariamente una conclusione di sicurezza valida. La validazione dello schema può confermare i campi obbligatori e i valori accettati, ma non può dimostrare che un exploit attraversi un confine reale.

Cloudflare affronta tale limite tramite una nuova verifica del codice sorgente. Il verificatore esamina in modo indipendente l'affermazione sul codice, e una sostituzione sostanziale riceve un ulteriore controllo. La qualità dipende comunque dal comportamento del modello, dal contesto disponibile e dalla correttezza del modello di minaccia.

Il sandboxing presenta un'altra sfida di adozione. La skill richiede controlli del sistema operativo attorno a build ed esperimenti controllati dal target. Molti ambienti quotidiani per agenti di coding non offrono tale isolamento con limiti chiari su risorse e rete.

I team che ignorano questo requisito rischiano di eseguire dipendenze, script di build o fixture di test dannosi. I team che lo rispettano devono conservare alcune piste promettenti come irrisolte finché non è disponibile un ambiente sicuro.

Il prompt injection crea una preoccupazione correlata. File sorgente, documentazione, testo delle issue e artefatti generati possono contenere istruzioni rivolte all'agente. Il successivo workflow commerciale di Cloudflare afferma di trattare codice, log e metadati come prove anziché come istruzioni.

Lo stesso confine deve esistere nell'uso locale. Un agente di sicurezza non dovrebbe mai interpretare il contenuto di un repository come autorizzazione a esporre credenziali, ampliare l'accesso alla rete o modificare sistemi non correlati.

Il secure software framework del NIST offre un utile punto di riferimento. Considera lo sviluppo sicuro come un insieme di pratiche organizzative che includono preparazione, protezione, produzione e risposta alle vulnerabilità.

Una skill di audit basata sull'IA copre soltanto una parte di questo ciclo di vita. Può aiutare a esaminare il codice sorgente e documentare potenziali debolezze. Non garantisce progettazione sicura, governance degli accessi, provenienza delle dipendenze, controlli di distribuzione o preparazione agli incidenti.

La revisione umana resta essenziale per lo stesso motivo. Gli ingegneri comprendono il comportamento previsto, l'architettura di produzione, l'impatto sul business e i controlli compensativi che potrebbero non apparire in un repository.

Il rilascio dovrebbe quindi cambiare la forma della revisione, non eliminare i revisori. I team di sicurezza possono dedicare meno tempo a ordinare affermazioni non supportate e più tempo a testare le prove, dare priorità all'esposizione e approvare le correzioni.

Cloudflare sta collegando le conclusioni sul codice al contesto di produzione

La strategia più ampia di Cloudflare consiste nel combinare le conclusioni sul codice sorgente con telemetria di traffico e difesa, cosa che la skill autonoma non può fare da sola.

Uno scanner del codice sorgente può identificare un handler non sicuro senza sapere se viene eseguito in produzione. Potrebbe non sapere quale route raggiunga il codice, con quale frequenza i client la utilizzino o se i controlli attivi blocchino le richieste pertinenti.

Il servizio su invito Vulnerability Discovery and Remediation di Cloudflare cerca di colmare questa lacuna. L'azienda ha annunciato il servizio il 3 settembre 2026, nell'ambito di Cloudflare Managed Defense.

Secondo l'annuncio sulla context-aware remediation, il servizio collega l'analisi autorizzata del codice con Web Assets, dati del Web Application Firewall e osservabilità di Workers.

Il servizio utilizza modelli OpenAI Daybreak, incluso GPT-5.6 Cyber, per ricognizione, hunting e validazione. Cloudflare afferma che i prompt passano attraverso AI Gateway verso i server di OpenAI. L'inferenza del modello non viene eseguita all'edge di Cloudflare.

Questa implementazione illustra perché la skill open-source e il servizio commerciale svolgono ruoli diversi. La skill organizza un'indagine a livello di repository. Il servizio aggiunge informazioni su route distribuite, volume delle richieste, eventi di sicurezza e controlli esistenti.

Il contesto di produzione può cambiare la priorità senza modificare la validità tecnica. Una vulnerabilità reale su un percorso di sviluppo irraggiungibile merita un trattamento diverso rispetto allo stesso difetto su un endpoint pubblico molto utilizzato.

Cloudflare afferma che il suo processo può proporre una patch di codice e una regola WAF strettamente circoscritta quando le prove supportano entrambe. La regola edge può ridurre l'esposizione mentre gli ingegneri esaminano la modifica permanente del codice.

Il servizio non consente al modello di distribuire autonomamente la propria proposta. Le chiamate agli strumenti vengono registrate e valutate rispetto a una policy di accesso. Verifiche esterne testano patch e regole, mentre i clienti decidono se implementare le modifiche.

Questo approccio trasforma l'harness di Cloudflare per le vulnerabilità in qualcosa di più di un motore di scoperta. Diventa parte di un sistema di gestione dell'esposizione che collega prove dal codice sorgente, contesto di runtime, mitigazione e correzione.

La strategia spiega inoltre l'enfasi dell'azienda su report indipendenti dal target. Lo stesso metodo di audit può esaminare linguaggi e tipi di applicazione diversi, mentre i sistemi specifici della produzione forniscono il contesto necessario per stabilire le priorità.

La maggior parte dei team che utilizzeranno la skill pubblica non disporrà di una visibilità di rete equivalente. Potranno comunque migliorare le decisioni fornendo manifest di deployment, mappe delle route, registri di proprietà e log sanitizzati come prove controllate.

Dovrebbero mantenere chiara la provenienza. Una conclusione sul codice sorgente, un'affermazione sul deployment e un'osservazione sul traffico sono affermazioni diverse. Combinarle in un unico paragrafo non dovrebbe cancellare l'origine di ciascun fatto.

È qui che conta una gestione disciplinata della conoscenza. I team di ingegneria hanno bisogno di un record ricercabile che colleghi decisioni architetturali, prove di audit, ipotesi respinte e correzioni successive. Una base di conoscenza tecnica mantenuta può rendere questi record disponibili oltre una singola sessione dell'agente.

La skill pubblica si muove già in questa direzione attraverso artefatti persistenti. Note architetturali, record di copertura, conclusioni leggibili dalle macchine e report umani offrono ai futuri revisori qualcosa di più duraturo di una trascrizione della chat.

Tuttavia, un repository resta un quadro incompleto. Policy infrastrutturali, gestione dei segreti, configurazione delle autorizzazioni, dipendenze dei servizi e comportamento degli utenti possono determinare se una debolezza a livello di codice sorgente diventi sfruttabile.

I team che con maggiore probabilità ne trarranno beneficio tratteranno la skill come un generatore di prove all'interno di un programma di sicurezza più ampio. Quelli che con maggiore probabilità incontreranno difficoltà si aspetteranno che una scansione del repository risponda a domande sul rischio di produzione alle quali il repository non può rispondere.

Tre segnali mostreranno se il rilascio conta davvero

Il prossimo test sarà stabilire se gli sviluppatori riusciranno a riprodurre la disciplina di Cloudflare senza l'infrastruttura privata, i dati e il personale di sicurezza di Cloudflare.

Il primo segnale è la qualità degli artefatti di audit pubblici. Un'adozione utile produrrà report con confini di fiducia precisi, prove riproducibili, candidati respinti significativi e domande irrisolte espresse con onestà.

Un numero crescente di installazioni dimostrerebbe interesse, ma non efficacia. La misura migliore è se team indipendenti pubblichino audit le cui conclusioni confermate superino la revisione dei manutentori.

L'attuale design del rilascio supporta questa valutazione. I suoi schemi di copertura e delle conclusioni creano artefatti comparabili, mentre i validatori possono intercettare record malformati prima che inizi la revisione umana.

Il secondo segnale è il modo in cui il repository evolverà dopo l'uso reale. L'harness interno di Cloudflare ha imparato da esecuzioni ripetute, ambienti mancanti, copertura superficiale e conclusioni respinte. La skill pubblica affronterà una gamma più ampia di linguaggi, sistemi di build e piattaforme per agenti.

Occorre osservare le modifiche alle linee guida sulle classi di attacco, ai requisiti di sandbox, alla modellazione della copertura e alla gestione dei falsi positivi. Questi aggiornamenti riveleranno quali parti del processo di Cloudflare si trasferiscono facilmente e quali dipendono da sistemi interni.

La distinzione tra conclusioni confermate e da-validare merita particolare attenzione. Se gli utenti esterni promuovono regolarmente piste irrisolte a report sicuri, le salvaguardie del workflow esisteranno soltanto sulla carta.

Il terzo segnale è se altre piattaforme di sicurezza adotteranno una verifica altrettanto indipendente. Gli strumenti IA per il codice competono già su velocità, numero di problemi e assistenza alla correzione. Cloudflare sta spostando l'attenzione verso la tracciabilità delle prove, i tassi di rifiuto e la rendicontazione della copertura.

Questo cambiamento rafforzerebbe l'impatto più ampio della skill di audit di sicurezza Cloudflare, anche se gli sviluppatori non installeranno mai questo specifico pacchetto. Un mercato che chiede chi abbia verificato una conclusione è più sano di uno che premia il numero più alto di avvisi.

I risultati interni di Cloudflare suggeriscono perché ciò sia importante. Migliaia di candidati grezzi sono scomparsi durante validazione, deduplicazione e valutazione contestuale. Generare più candidati non era la capacità scarsa. Trasformarli in lavoro affidabile lo era.

Esistono anche segnali pratici all'interno delle singole organizzazioni. I responsabili della sicurezza dovrebbero monitorare quante conclusioni superano la revisione indipendente, quanto cresce la copertura nelle esecuzioni ripetute e quante patch superano i test di regressione.

Dovrebbero inoltre registrare il costo dell'audit e il tempo trascorso. Cloudflare afferma che le sue scansioni complete interne possono richiedere ore, con l'esecuzione più lunga che ha superato le 14 ore. La skill pubblica può consumare un tempo di modello significativo mentre hunter e verificatori esaminano aree separate.

Quella spesa può essere giustificata per repository sensibili o revisioni approfondite periodiche. Potrebbe non essere adatta a ogni pull request. Controlli più piccoli, regole deterministiche e revisioni mirate delle minacce restano più indicati per un feedback rapido.

La decisione importante non è se sostituire gli scanner esistenti con una skill per agenti. È capire dove un audit condotto da un agente e basato sulle evidenze aggiunge informazioni che i controlli attuali non rilevano.

Gli sviluppatori possono iniziare con un singolo repository delimitato e un confine di fiducia chiaramente definito. Dovrebbero esaminare il registro della copertura prima di leggere il report finale, quindi verificare ogni problema confermato confrontandolo con il codice sorgente non modificato.

Dovrebbero conservare i record irrisolti invece di forzare un verdetto. Dovrebbero eseguire i test solo all'interno di una sandbox appropriata e mantenere le decisioni di remediation sotto controllo umano.

Se questo processo produce risultati ripetibili che i manutentori accettano, Cloudflare ha introdotto un metodo di sicurezza significativo. Se gli utenti lo riducono a un altro prompt generico, le sue sei fasi aggiungeranno complessità senza generare fiducia.

La skill di audit della sicurezza di Cloudflare pone quindi una sfida concreta ai fornitori di sicurezza AI e ai team di ingegneria: smettere di misurare il successo in base al numero di debolezze che un modello riesce a descrivere. Misurare invece quali affermazioni resistono a una revisione avversariale, quali aree sono state effettivamente esaminate e quali fatti restano sconosciuti.