I guardrail di Anthropic, Google e OpenAI stanno rallentando la ricerca offensiva in cybersecurity

I controlli di sicurezza di Anthropic, Google e OpenAI affrontano ora una prova difficile: secondo i ricercatori, guardrail più rigidi stanno ostacolando il lavoro autorizzato di cybersecurity offensiva. Le restrizioni prendono di mira l'hacking malevolo, ma gli stessi controlli possono bloccare la convalida delle vulnerabilità, il reverse engineering e lo sviluppo di exploit.

Il conflitto è diventato più difficile da ignorare dopo che diversi ricercatori di sicurezza offensiva hanno descritto rifiuti ripetuti e risultati incoerenti. Il loro lavoro consiste nell'individuare falle sconosciute prima che vengano sfruttate dai criminali, spesso sviluppando proof of concept controllati.

Il problema non è semplicemente che le aziende di IA rifiutano richieste pericolose. I ricercatori affermano che i sistemi faticano a distinguere un test autorizzato da un attacco reale. Questa ambiguità genera ritardi, limita la riproducibilità e spinge il lavoro sensibile verso modelli open ospitati localmente.

OpenAI e Anthropic hanno introdotto programmi di verifica pensati per ridurre questo attrito. Anche Google limita gli utilizzi dell'IA generativa che coinvolgono malware, interruzioni delle infrastrutture e aggiramento dei filtri di sicurezza. Nel complesso, queste politiche mostrano come le principali aziende statunitensi di IA stiano tracciando confini attorno alle capacità cyber a duplice uso.

La controversia centrale è più netta di una normale lamentela sui rifiuti dei modelli. La sicurezza offensiva e quella difensiva richiedono spesso gli stessi passaggi tecnici. Un modello non può sempre identificare l'autorizzazione dell'operatore a partire dal codice, dal comando o dalla vulnerabilità inseriti nel contesto.

Questo lascia ai laboratori di frontiera la scelta tra due errori costosi. Un modello permissivo può aiutare un attaccante a muoversi più rapidamente. Un modello eccessivamente cauto può impedire a un difensore di comprendere e correggere la stessa debolezza.

I ricercatori affermano che il lavoro cyber legittimo viene bloccato

Il cambiamento immediato è che i guardrail cyber ora interrompono flussi di lavoro pratici di ricerca, non solo richieste palesemente malevole.

Un'inchiesta sulla cybersecurity del 23 luglio ha documentato le lamentele di ricercatori che individuano vulnerabilità e sviluppano exploit. Diversi hanno dichiarato che i modelli di frontiera rifiutavano richieste legittime o fornivano risposte incoerenti durante attività autorizzate.

Per sicurezza offensiva si intende il test dei sistemi dalla prospettiva di un attaccante, con il permesso del proprietario. Include penetration test, convalida degli exploit, red teaming e alcune forme di reverse engineering.

Queste attività possono mettere in luce debolezze che una revisione convenzionale del codice non rileva. Un percorso di codice sospetto diventa concreto solo dopo che un ricercatore ha stabilito se possa essere raggiunto e sfruttato.

Chris Anley, chief scientist di NCC Group, ha dichiarato a TechCrunch che chiedere a un modello di sfruttare un bug può confermare se meriti una correzione. Un rifiuto in quella fase non elimina soltanto una comodità. Può interrompere il processo di raccolta delle prove che aiuta un'azienda a dare priorità a una correzione.

Anley ha paragonato la tecnologia a un martello, che può fungere sia da strumento sia da arma. Il suo punto più ampio riguarda la sovrapposizione tecnica. Le istruzioni utili per lo sfruttamento possono anche essere essenziali per dimostrare che il codice vulnerabile crea un rischio reale.

Questa sovrapposizione diventa particolarmente importante con gli zero-day, ossia vulnerabilità sconosciute al fornitore interessato al momento della scoperta. I ricercatori devono spesso tracciare l'esecuzione, manipolare la memoria o costruire input insoliti prima di comprendere una falla.

Questi passaggi assomigliano al comportamento di un attaccante perché i ricercatori stanno riproducendo l'attacco. Un classificatore vede termini, codice e comandi sospetti. Potrebbe non vedere il contratto o l'autorizzazione di laboratorio che rendono il lavoro legittimo.

Un ricercatore presso un produttore di componenti per smartphone ha dichiarato a TechCrunch che gli strumenti di Anthropic erano diventati appena utili per l'individuazione di vulnerabilità al di fuori del suo programma di verifica. Il ricercatore ha affermato che il sistema si fermava non appena rilevava attività legate alla sicurezza.

Chris Thompson, CEO di RemoteThreat, ha descritto un'altra modalità di fallimento. Ha affermato che i guardrail si comportavano in modo diverso tra le sessioni, anche all'interno di programmi verificati che offrivano restrizioni più blande.

Questa incoerenza è importante perché la ricerca sulle vulnerabilità dipende da esperimenti ripetibili. Un ricercatore deve stabilire se un risultato dipenda dal bersaglio, dal metodo di test o dall'intervento variabile del modello.

Quando l'applicazione delle policy cambia senza una spiegazione chiara, il modello aggiunge un'altra variabile non controllata. Il tempo si sposta dall'analisi della vulnerabilità alla riformulazione dei prompt e alla diagnosi dei rifiuti.

Le restrizioni non incidono allo stesso modo su tutti i professionisti. Giuseppe Cali, che individua zero-day e sviluppa exploit, ha dichiarato a TechCrunch che i guardrail non avevano ostacolato il suo lavoro.

Cali usa l'IA per il reverse engineering iniziale e per costruire strumenti di supporto. Mantiene sotto il proprio controllo l'effettiva individuazione delle vulnerabilità e la weaponization, anche perché apprezza quel lavoro.

La sua esperienza pone un limite importante alle critiche. I modelli di frontiera possono restare utili quando i ricercatori affidano loro compiti di supporto a minor rischio. Il conflitto si intensifica quando un flusso di lavoro si avvicina alla sfruttabilità, al comportamento del payload o ai test operativi.

Il dibattito attuale riguarda quindi l'accesso a capacità specifiche, non il fatto che l'IA abbia o meno valore nella sicurezza. I modelli possono riassumere il codice, spiegare funzioni, proporre test o assistere nella documentazione senza oltrepassare le barriere di policy più difficili.

I problemi emergono quando un ricercatore chiede al modello di collegare questi passaggi. È spesso in quel collegamento che una possibile falla diventa una scoperta di sicurezza verificata.

Perché le policy di Anthropic e Google non possono separare nettamente attacco e difesa

Le policy di Anthropic, Google e di altri laboratori di frontiera affrontano un problema di classificazione che i soli prompt non possono risolvere in modo affidabile.

Anthropic afferma che le sue protezioni in tempo reale bloccano gli utilizzi proibiti e le attività a duplice uso ad alto rischio. La categoria degli utilizzi proibiti include condotte con scarso valore difensivo legittimo, come lo sviluppo di ransomware o l'esfiltrazione di dati su larga scala.

La categoria a duplice uso ad alto rischio è più complicata. Anthropic include esplicitamente lo sfruttamento delle vulnerabilità e lo sviluppo di strumenti di sicurezza offensiva, entrambi potenzialmente utili per finalità difensive legittime.

Queste richieste vengono bloccate per impostazione predefinita sui modelli Claude interessati. Gli utenti verificati possono richiedere modifiche tramite il Cyber Verification Program, o CVP, di Anthropic.

Anthropic afferma che i professionisti approvati possono comunque incontrare blocchi. L'azienda riconosce che può rifiutare erroneamente candidati idonei e che gli utenti approvati possono subire restrizioni durante attività legittime.

Questo riconoscimento riflette la sfida tecnica centrale. Un modello può ricevere istruzioni identiche per lo sviluppo di un exploit da un penetration tester e da un criminale. La differenza visibile è spesso l'autorizzazione, non l'operazione richiesta.

La policy sugli utilizzi proibiti di Google vieta allo stesso modo i contenuti di IA generativa che facilitano malware, abusi delle infrastrutture o l'elusione dei filtri di sicurezza. Consente eccezioni quando i benefici educativi, scientifici o pubblici superano il danno.

Il linguaggio sulle eccezioni riconosce il contesto, ma applicarlo su vasta scala resta difficile. Un utente può sostenere di possedere un bersaglio senza dimostrarlo. Un ricercatore legittimo può anche lavorare su un prodotto senza controllarne l'infrastruttura.

OpenAI descrive le capacità cyber come intrinsecamente a duplice uso. Afferma che i flussi di lavoro difensivi e offensivi si basano in larga parte sulle stesse conoscenze e su molte delle stesse tecniche.

L'azienda ha segnalato un forte aumento delle prestazioni cyber nel 2025. Secondo il suo piano di resilienza cyber, i risultati dei suoi modelli nei capture-the-flag sono passati dal 27% di agosto al 76% di novembre.

Le sfide capture-the-flag sono esercizi di sicurezza controllati con bersagli intenzionalmente vulnerabili. Testano competenze quali ricognizione, reverse engineering, sfruttamento e escalation dei privilegi.

OpenAI utilizza soglie di capacità più elevate per anticipare modelli in grado di sviluppare exploit zero-day remoti o assistere intrusioni complesse. Questa traiettoria spiega perché l'azienda non tratterà ogni richiesta cyber come ordinaria programmazione.

Google DeepMind ha adottato un approccio basato sul rischio simile a livello di sviluppo dei modelli. Il suo framework di sicurezza include la cybersecurity tra i domini che richiedono valutazioni delle capacità e mitigazioni crescenti.

Queste policy rispondono a una preoccupazione reale. Un modello capace può comprimere conoscenze specialistiche, automatizzare attività ripetitive e coordinare strumenti. La stessa efficienza disponibile per un difensore può ridurre lo sforzo necessario per gli abusi.

Tuttavia, il filtraggio aggressivo dei prompt è una risposta grossolana a un problema di identità e autorizzazione. Il solo contenuto tecnico fornisce prove deboli dello scopo dell'utente.

Anche una formulazione semplice può trarre in inganno. Un prompt benigno può contenere termini come shellcode, exploit, persistenza o estrazione di credenziali perché questi concetti compaiono in valutazioni legittime.

Una richiesta malevola può usare un linguaggio ripulito. Un attaccante potrebbe descrivere il furto di credenziali come recupero dell'account o mascherare lo sfruttamento come test di compatibilità.

I classificatori devono valutare codice, intento, bersaglio, cronologia dell'account e attività circostante. Anche allora, formulano giudizi probabilistici anziché verificare l'autorizzazione legale.

I falsi positivi diventano particolarmente probabili durante la ricerca esplorativa. I ricercatori non sanno sempre in cosa si trasformerà un percorso di codice sospetto. Potrebbero dover testare diverse ipotesi offensive prima di identificare la vulnerabilità effettiva.

Questa incertezza entra in conflitto con sistemi che si aspettano uno scopo difensivo chiaramente definito fin dall'inizio. Il processo di ricerca spesso produce quella spiegazione soltanto dopo l'avvio di un lavoro tecnico dall'aspetto pericoloso.

L'accesso verificato aiuta, ma non elimina l'attrito

I programmi di verifica migliorano l'accesso per i difensori noti, ma non possono garantire flussi di lavoro di ricerca senza restrizioni o prevedibili.

Il CVP di Anthropic è un programma basato su candidatura per attività cyber legittime ad alto rischio. L'azienda afferma di puntare a fornire una decisione di revisione entro due giorni lavorativi.

L'approvazione è collegata a una specifica organizzazione. I ricercatori possono comunque ricevere blocchi se usano un altro workspace o incontrano un'attività che resta proibita.

La disponibilità varia anche in base alla piattaforma. Anthropic dichiara che il CVP non è attualmente disponibile tramite Amazon Bedrock o Google Vertex AI. Nemmeno le applicazioni di terze parti che usano Claude possono partecipare.

Queste distinzioni creano complessità operativa. Un team di sicurezza può ricevere un trattamento diverso a seconda del proprio cloud provider, della configurazione del workspace o dell'integrazione software.

Il programma richiede inoltre la conservazione dei dati. Anthropic consiglia alle organizzazioni che utilizzano la zero data retention di creare un workspace separato in cui la conservazione sia abilitata.

Questa condizione solleva una seconda questione oltre ai guardrail. La ricerca offensiva coinvolge spesso codice sorgente riservato, vulnerabilità non corrette, firmware proprietario e informazioni che potrebbero consentire una compromissione.

Inviare questi materiali a un modello ospitato può creare un'esposizione inaccettabile, anche quando esistono protezioni contrattuali. Alcuni ricercatori evitano quindi i servizi di frontiera prima che un fornitore abbia corretto la falla.

Paolo Stagno, chief technology officer di Crowdfense, ha dichiarato a TechCrunch che il suo team usa modelli di frontiera per il reverse engineering. Evita di usarli per individuare vulnerabilità o creare exploit.

Stagno ha citato il timore di divulgare informazioni sensibili sulle vulnerabilità o che i dati vengano assorbiti in futuri addestramenti. Per il lavoro sugli exploit, il suo team utilizza modelli open gestiti localmente, che non richiedono l'invio del materiale a un provider.

Il sistema di accesso cyber fidato di OpenAI utilizza diversi livelli di capacità. L'accesso standard supporta comuni attività difensive, mentre l'accesso verificato riduce alcune restrizioni per il lavoro autorizzato.

Un accesso più specializzato copre i test offensivi, inclusi sviluppo di exploit, penetration testing, reverse engineering e red teaming. L'approvazione per un livello di accesso non concede automaticamente tutti i modelli specializzati in ambito cyber.

OpenAI afferma inoltre che il programma non elimina tutte le protezioni o i rifiuti. L'accesso resta limitato agli utenti approvati, ai flussi di lavoro interni e ai sistemi che l'organizzazione possiede o è autorizzata a testare.

Queste condizioni sono difendibili. Un provider non può interpretare in sicurezza la verifica come un'autorizzazione generalizzata ad attaccare qualsiasi bersaglio.

Tuttavia, mostrano anche perché la verifica non risolve pienamente il problema della ricerca. L'autorizzazione è granulare. Può applicarsi a un sistema, un periodo, un metodo di test o un incarico per un cliente.

Un'approvazione generale a livello di account non può cogliere ogni cambiamento di ambito. Una revisione continua dei documenti introdurrebbe ulteriori ritardi ed esporrebbe più informazioni sui clienti.

OpenAI aveva precedentemente dichiarato che il suo programma fidato aveva raggiunto migliaia di difensori verificati e centinaia di team impegnati nella protezione di software critico. Questa scala mostra la domanda, ma non misura i falsi positivi né i flussi di lavoro abbandonati.

Gli indicatori di performance mancanti sono quelli pratici. I ricercatori devono sapere con quale frequenza le richieste approvate vengono bloccate, quanto durano i ricorsi e se le decisioni restano stabili tra gli aggiornamenti dei modelli.

Hanno anche bisogno di spiegazioni utili. Un generico messaggio di sicurezza non rivela se l'elemento scatenante sia stato il bersaglio, il comportamento del codice, l'output richiesto o l'attività accumulata dell'account.

Senza queste informazioni, gli utenti sperimentano con la formulazione dei prompt. Questo comportamento può sembrare un tentativo di aggiramento anche quando il ricercatore vuole soltanto un risultato legittimo.

Un'applicazione migliore delle regole dovrebbe concentrarsi sull'intero ambiente operativo. I provider possono combinare la verifica dell'identità con esecuzione isolata, allowlist di bersagli, limiti di frequenza, log di audit e accesso di rete controllato.

Questo modello ricorda un cyber range, un ambiente isolato per esercitazioni di sicurezza. Offre prove di autorizzazione più solide rispetto alla sola classificazione dei prompt.

Attribuisce inoltre maggiore responsabilità all'infrastruttura. I provider devono confermare che un bersaglio apparentemente isolato non possa diventare un ponte verso un sistema esterno.

Questo approccio non coprirà tutti i ricercatori. Specialisti indipendenti e piccole società di consulenza potrebbero non disporre della documentazione organizzativa richiesta dai programmi rivolti alle imprese.

La ricerca sulla sicurezza ha tratto a lungo beneficio da figure esterne che indagano sui prodotti senza un rapporto formale con il fornitore. Limitare l'accesso avanzato a grandi istituzioni facilmente verificabili potrebbe restringere quella comunità.

Il risultato sarebbe un sistema a due livelli. Le grandi aziende ricevono modelli specializzati e supporto, mentre i ricercatori indipendenti si affidano a strumenti consumer, modelli open locali o metodi manuali.

Le protezioni stanno spingendo il lavoro sensibile verso i modelli open

Quando i modelli di frontiera ospitati diventano imprevedibili o inadatti al lavoro riservato, i ricercatori hanno un motivo per eseguire modelli open localmente.

Diversi ricercatori hanno dichiarato a TechCrunch di ricorrere a modelli scaricabili quando i servizi di frontiera americani rifiutano attività offensive. Thompson ha indicato in particolare modelli open cinesi come GLM.

L'implementazione locale cambia la struttura di controllo. I ricercatori possono scegliere la versione del modello, conservare i prompt, disabilitare la connettività esterna e mantenere il codice vulnerabile sul proprio hardware.

Possono anche riprodurre un esperimento dopo che un fornitore aggiorna il suo servizio ospitato. Un checkpoint di modello fisso si comporta in modo più coerente rispetto a un servizio le cui protezioni possono cambiare senza preavviso.

Questo non significa che ogni modello open eguagli la qualità di ragionamento di un modello ospitato leader. I ricercatori devono confrontare capacità, gestione del contesto, requisiti hardware e integrazione degli strumenti.

I modelli open trasferiscono inoltre maggiore responsabilità per la sicurezza all'operatore. Un agente mal isolato può eseguire comandi non sicuri, esporre segreti o raggiungere sistemi di produzione.

Tuttavia, il controllo locale risponde contemporaneamente a due lamentele. Elimina i rifiuti a livello del provider e riduce la necessità di inviare dati non pubblicati sulle vulnerabilità a un servizio esterno.

Questa combinazione conta più della leadership nei benchmark. Un modello leggermente più debole può essere più utile se resta disponibile durante un flusso di lavoro sensibile e ripetibile.

Il cambiamento crea anche una tensione strategica per le aziende americane di IA. Protezioni rigorose possono ridurre gli abusi sulle loro piattaforme, reindirizzando al contempo esperti legittimi verso sistemi al di fuori della loro governance.

Quei ricercatori forniscono quindi feedback, integrazioni e conoscenze sui flussi di lavoro a un altro ecosistema di modelli. Il loro utilizzo può migliorare gli strumenti che ruotano attorno a modelli con minori restrizioni.

Questo non dimostra che le protezioni rendano internet meno sicuro. Gli aggressori possono usare modelli open indipendentemente da ciò che scelgono i difensori verificati.

Tuttavia, la migrazione dei difensori può indebolire l'argomento secondo cui le restrizioni dei servizi ospitati preservano un vantaggio per gli utenti responsabili. Il vantaggio conta solo se tali utenti possono completare un lavoro significativo.

OpenAI inquadra la propria strategia intorno all'offerta di strumenti migliori per i difensori, limitando al contempo il potenziamento delle attività malevole. Anthropic offre analogamente protezioni adattate per professionisti verificati.

Entrambi gli obiettivi dipendono da un accesso calibrato. Un controllo che blocca quasi tutti i comportamenti dall'aspetto pericoloso può ridurre gli abusi, ma può anche eliminare la capacità promessa ai difensori.

La pressione alla migrazione va oltre i rifiuti espliciti. I modelli ospitati possono diventare poco attraenti quando requisiti di conservazione, esclusioni della piattaforma o ricorsi poco chiari complicano incarichi riservati.

Una società di consulenza può servire più clienti con confini di autorizzazione separati. Non può mescolare con leggerezza il loro codice sorgente e i loro risultati in un unico spazio di lavoro conservato.

Un ricercatore indipendente può analizzare un prodotto ampiamente distribuito prima di contattarne il produttore. Quella persona non può sempre fornire un contratto con un cliente che dimostri l'autorizzazione.

I programmi bug bounty creano un'altra area grigia. Invitano ai test secondo regole pubblicate, ma un provider di modelli potrebbe non essere in grado di verificare se ogni azione richiesta resti nell'ambito consentito.

Queste situazioni evidenziano i limiti della verifica a livello aziendale. La fiducia si lega a una persona o a un'organizzazione, mentre l'autorizzazione si lega a un'operazione specifica.

I modelli gestiti localmente evitano questo divario di verifica. Eliminano anche il provider che potrebbe rilevare abusi su larga scala, sospendere l'accesso o indagare su schemi sospetti.

Il compromesso quindi si sposta anziché scomparire. I servizi ospitati offrono supervisione, ma possono creare attriti e problemi di riservatezza. I modelli locali offrono controllo, ma riducono l'applicazione centralizzata delle regole.

I laboratori americani di frontiera non possono invertire la disponibilità dei modelli open attraverso rifiuti più rigidi. L'opzione più realistica è rendere l'accesso ospitato responsabile migliore dell'alternativa locale.

Ciò significa politiche prevedibili, ricorsi più rapidi, controlli della privacy significativi e ambienti progettati per lo sfruttamento controllato. La sola capacità grezza del modello non manterrà i ricercatori di sicurezza su una piattaforma.

Le critiche dei ricercatori hanno limiti importanti

I ricercatori offensivi individuano reali fallimenti nei flussi di lavoro, ma i loro interessi non determinano quanto ampiamente debbano essere rilasciate capacità di IA pericolose.

Alcune aziende di sicurezza offensiva scoprono, acquisiscono o vendono vulnerabilità a clienti governativi. Il loro lavoro non porta sempre a una divulgazione e a correzioni immediate.

Mark Dowd, un ricercatore di spicco citato da TechCrunch, ha venduto zero-day a governi occidentali. Ha riconosciuto che questo background può influenzare la sua visione delle restrizioni aziendali.

I governi attribuiscono valore alle vulnerabilità non divulgate perché le agenzie di intelligence possono utilizzarle mentre i bersagli restano esposti. Quel mercato complica qualsiasi semplice equivalenza tra ricerca offensiva e difesa pubblica.

Un provider di modelli deve considerare più del fatto che il cliente sembri rispettabile. Deve anche valutare se l'assistenza possa ampliare sorveglianza, intrusione o accumulo di exploit.

L'autorizzazione legale non coincide con il beneficio pubblico. Un'operazione approvata dal governo può restare controversa o creare un rischio sistemico se una vulnerabilità colpisce software ampiamente usato.

I ricercatori differiscono anche su quanto centrale debba diventare l'IA. Il flusso di lavoro di Cali suggerisce che un'assistenza utile possa fermarsi prima della scoperta automatizzata di bug o della loro trasformazione in armi.

Questo approccio preserva il giudizio umano nelle fasi più rischiose. Riduce inoltre la probabilità che un modello trasformi un'idea incompleta in un metodo di attacco riutilizzabile.

Nel frattempo, l'argomento sul rischio dei provider non è ipotetico. OpenAI afferma che le prestazioni cyber dei modelli sono aumentate rapidamente, e tutti e tre i laboratori trattano le capacità cyber avanzate come un serio ambito di sicurezza.

Man mano che i modelli acquisiscono maggiore agentività prolungata, una singola risposta diventa meno importante di una sequenza di azioni. Un agente può ispezionare codice, generare test, eseguire comandi, valutare fallimenti e rivedere il proprio piano.

Questa capacità cambia la posta in gioco. Un rifiuto che un tempo bloccava una breve richiesta di malware potrebbe dover governare migliaia di azioni coordinate.

Rende inoltre essenziali i test isolati. Un agente che opera con strumenti può oltrepassare confini che un assistente solo testuale non può raggiungere.

I ricercatori meritano un accesso prevedibile, ma i provider hanno bisogno di prove che l'ambiente circostante contenga gli eventuali fallimenti. La sola verifica non può fornire tali prove.

Non esiste inoltre una misurazione pubblica e standardizzata della qualità delle protezioni per il lavoro cyber legittimo. Gli aneddoti rivelano modalità di fallimento, ma non stabiliscono tassi complessivi di falsi positivi.

Le interviste di TechCrunch riguardano organizzazioni e flussi di lavoro diversi. Offrono segnali d'allarme credibili, non un'indagine rappresentativa del settore della sicurezza.

Anche i provider pubblicano dati limitati sulle esperienze degli utenti approvati. I numeri delle adesioni mostrano la portata, ma dicono poco sul completamento delle attività o sull'utilità dei modelli.

Questo vuoto di prove incoraggia entrambe le parti a sovrastimare la propria posizione. I ricercatori possono interpretare un rifiuto come prova che la politica di sicurezza sia arbitraria. I provider possono trattare la disponibilità del programma come prova che l'accesso legittimo funzioni.

Una valutazione migliore testerebbe flussi di lavoro autorizzati realistici su più modelli. Dovrebbe misurare successo delle attività, rifiuti inappropriati, conformità non sicura, coerenza, tempi di ricorso e requisiti di gestione dei dati.

Il benchmark dovrebbe includere casi ambigui. Prompt difensivi facili e richieste di ransomware palesi non mettono alla prova il confine contestato.

Gli scenari potrebbero includere la convalida di exploit in un cyber range, il reverse engineering di malware, l'analisi di un bersaglio di un programma bug bounty e lo sviluppo di una proof of concept sicura.

I valutatori indipendenti avrebbero anche bisogno di accesso ai livelli di modello a più alto rischio. Altrimenti misurerebbero le restrizioni pubbliche senza esaminare se la verifica risolva effettivamente il problema.

I risultati non dovrebbero divulgare dettagli operativi che consentano abusi. La rendicontazione aggregata può comunque mostrare se i controlli distinguono più accuratamente il lavoro legittimo nel tempo.

Finché tali prove non esistono, conclusioni forti restano premature. Le protezioni creano chiaramente attrito per alcuni ricercatori, ma rimuoverle creerebbe un rischio diverso e potenzialmente maggiore.

L'obiettivo pratico non è un accesso senza restrizioni. È un accesso responsabile che rimanga utile in condizioni realistiche di test offensivi.

Cosa devono dimostrare ora Anthropic, Google e OpenAI

La prossima fase dovrebbe essere valutata in base all'affidabilità dei flussi di lavoro, all'esecuzione controllata e alla capacità di mantenere i ricercatori responsabili su piattaforme governate.

Il primo segnale è una performance misurabile all'interno dei programmi di verifica. Anthropic e OpenAI dovrebbero comunicare le tempistiche di approvazione, gli esiti dei ricorsi e i tassi di falsi positivi per le richieste legittime a duplice uso.

Questi numeri necessitano di contesto, inclusi modello, livello di accesso e categoria di attività. Un'unica percentuale riferita all'intero programma potrebbe nascondere gravi problemi nella convalida degli exploit.

Anthropic afferma già di puntare a decidere sulle domande CVP entro due giorni lavorativi. La domanda più importante è cosa accade dopo l'approvazione.

Se i ricercatori verificati incontrano ancora frequenti blocchi inspiegabili, la verifica ha spostato il confine senza risolvere il problema del flusso di lavoro. Una riduzione dei falsi positivi rafforzerebbe la tesi a favore di misure di protezione calibrate.

Il secondo segnale è la diffusione di ambienti di ricerca controllati. I laboratori di frontiera possono offrire spazi di lavoro isolati con strumenti sottoposti ad audit, rete limitata e chiare autorizzazioni sugli obiettivi.

Tali ambienti consentirebbero ai modelli di svolgere attività dall'aspetto pericoloso senza concedere accesso aperto a infrastrutture esterne. Renderebbero inoltre la revisione degli incidenti più concreta delle speculazioni a livello di prompt.

Il successo richiederebbe supporto su piattaforme cloud e strumenti di terze parti. Le attuali lacune nella disponibilità del CVP di Anthropic mostrano come l'accesso possa interrompersi quando il modello raggiunge gli utenti tramite intermediari.

I controlli sulla privacy conteranno quanto quelli sull'esecuzione. I team di sicurezza necessitano di opzioni credibili per gestire codice proprietario e vulnerabilità non divulgate senza creare ulteriore esposizione.

Se le aziende abbinano i cyber range a solide opzioni di conservazione dei dati, più ricercatori potranno giustificare l'uso di modelli ospitati. Se la conservazione rimane obbligatoria, il lavoro sensibile continuerà a spostarsi in locale.

Il terzo segnale è il comportamento dei ricercatori. I fornitori dovrebbero osservare se team offensivi rispettati utilizzano modelli di frontiera specializzati per la convalida degli exploit, non solo per la sintesi del codice.

Una continua migrazione verso GLM e altri modelli scaricabili indebolirebbe l'affermazione secondo cui l'accesso verificato offre ai difensori un vantaggio pratico. Un'adozione stabile suggerirebbe che le misure di protezione stanno diventando utilizzabili.

Google rientra in questo confronto, anche se i recenti resoconti dei ricercatori si sono concentrati soprattutto su Anthropic e OpenAI. Le sue politiche e il suo framework di frontiera riflettono lo stesso compromesso di fondo.

L'abbinamento delle parole chiave anthropic google coglie inoltre una realtà di mercato più ampia. I team di sicurezza confrontano governance, distribuzione, privacy e accesso tra fornitori, non soltanto i punteggi grezzi dei benchmark.

Nessuna azienda può risolvere la classificazione del duplice uso con un messaggio di rifiuto migliore. I miglioramenti decisivi combineranno identità, ambiente, autorizzazione, monitoraggio e un percorso trasparente per correggere gli errori.

Sviluppatori e acquirenti aziendali dovrebbero porre domande dirette prima di adottare un modello AI per il lavoro di sicurezza. Quali attività attivano misure di protezione rafforzate? Gli utenti approvati possono presentare ricorso durante un incarico attivo?

Dovrebbero inoltre esaminare conservazione dei dati, elaborazione regionale, disponibilità della piattaforma, verificabilità tramite audit e stabilità delle versioni del modello. Questi dettagli determinano se un prodotto può supportare un programma di sicurezza reale.

I ricercatori offensivi dovrebbero documentare i falsi positivi senza pubblicare materiale che favorisca danni. Evidenze comparabili renderanno più difficile per i fornitori liquidare i fallimenti come usi impropri isolati.

Nel frattempo, le aziende di AI dovrebbero trattare i rifiuti di richieste legittime come difetti di sicurezza. Un sistema che blocca indiscriminatamente i difensori non raggiunge l'equilibrio previsto.

Il prossimo test è semplice. Anthropic, Google e OpenAI possono mantenere una supervisione significativa offrendo al contempo ai ricercatori autorizzati un accesso affidabile alle capacità che gli aggressori già cercano?

Se i programmi verificati diventeranno coerenti e riservati, i modelli di frontiera governati potranno trattenere gli esperti responsabili. In caso contrario, questi esperti continueranno a orientarsi verso alternative locali con meno restrizioni e minore supervisione da parte dei fornitori.