Diciamolo chiaramente: chi oggi sviluppa strumenti di sicurezza offensivi con l’IA conosce fin troppo bene quel momento. Si descrive un compito di pentesting perfettamente legittimo a un modello e si riceve un rifiuto. “I can’t help with that.” Oppure: “This request could be used for malicious purposes.” Sì grazie, lo sappiamo, è esattamente il nostro lavoro.
Le barriere di sicurezza che OpenAI, Anthropic e altri fornitori hanno integrato nei loro modelli non riescono a distinguere in modo affidabile tra un criminale che vuole costruire uno strumento d’attacco e un consulente di sicurezza che ha bisogno dello stesso identico strumento per testare l’infrastruttura di un cliente. Questa tensione non è nuova, ma nel 2026 si è notevolmente acuita e ci riguarda direttamente a Zerberos.
Il dilemma del dual-use
Gli strumenti di sicurezza offensivi sono per definizione a duplice uso. Uno scanner di exploit, un tester di credenziali, un generatore di payload: nelle mani di un pentester autorizzato rivelano vulnerabilità e nelle mani di un aggressore causano danni. Non c’è molto da girarci attorno, e lo stesso vale per il codice che li alimenta.
Modelli IA come Claude e GPT hanno accelerato enormemente lo sviluppo di questi strumenti. Analizzare codice, riconoscere pattern di vulnerabilità, suggerire logiche di exploit, generare report: per le aziende di sicurezza il guadagno in produttività è enorme. Noi di Zerberos utilizziamo Claude Code intensivamente per sviluppare e ottimizzare i nostri strumenti, ovvero ExposIQ per simulazioni d’attacco, CoreBait per scenari honeypot e PurpleHQ come piattaforma centrale per le operazioni di red team. Senza supporto IA avremmo avuto bisogno di un team decisamente più grande per gli stessi risultati.
Ma l’IA non sa chi siamo. Per il modello una richiesta di reverse shell payload ha lo stesso aspetto indipendentemente dal fatto che provenga da un pentester con un contratto firmato o da un aggressore con intenzioni malevole, e questo è il problema fondamentale.
Cosa sperimentano i ricercatori di sicurezza ogni giorno
Chris Anley, Chief Scientist di NCC Group (una delle più grandi società di consulenza in sicurezza al mondo), lo ha detto chiaramente in un articolo di TechCrunch a fine luglio: chiedere a un modello IA di provare a sfruttare un bug è un passaggio fondamentale per confermare che la vulnerabilità è reale e va corretta. Quando una barriera porta il modello a rifiutare, danneggia i difensori, non gli aggressori.
E non è un caso isolato. Numerosi ricercatori segnalano che le barriere sono incoerenti da un giorno all’altro: ciò che funzionava ieri viene bloccato oggi, ciò che passa in una formulazione viene rifiutato in un’altra. Si riformula la stessa domanda cinque volte finché non si trova una versione che il modello accetta. Non è un aumento di produttività, è una corsa a ostacoli.
Alcuni ricercatori si rivolgono ormai a modelli open source senza restrizioni o a modelli stranieri che non rispettano i requisiti di conformità occidentali. L’ironia? Le barriere bloccano i professionisti che rispettano le regole e spingono parte di loro verso alternative non controllate, mentre nel frattempo i criminali usano jailbreak per utilizzare gli stessi modelli senza alcuna restrizione.
Il caso TRIM: quando i criminali aggirano tranquillamente le barriere
Quanto siano permeabili le barriere per attori motivati lo ha dimostrato in modo piuttosto eloquente il caso TRIM. Un attore di minaccia russofono ha sviluppato sistematicamente tra marzo e giugno 2026 tecniche per aggirare le barriere di sicurezza di Claude Opus e ha documentato sei metodi di jailbreak con tanto di nomi, tra cui “Context Warming” dove si pongono domande dal suono legittimo prima di spostare gradualmente il contesto verso contenuti offensivi, e “Ghost Reset”, un metodo che secondo le sue dichiarazioni funziona nel 90 percento dei casi.
A giugno ha presentato un prodotto finito: AI Pentest Checker, una piattaforma automatizzata di scanning delle vulnerabilità basata su Claude Opus 4.8 per l’escalation di vulnerabilità critiche. Un obiettivo analizzato completamente in meno di dieci minuti, report PDF incluso.
La lezione è purtroppo evidente: le guardrail non bloccano gli aggressori, bloccano chi rispetta le regole.
Come rispondono i fornitori
Sia Anthropic che OpenAI hanno ormai riconosciuto che un approccio indifferenziato non funziona.
Anthropic gestisce il Cyber Verification Program (CVP) che si rivolge alle organizzazioni e non ai singoli. Dopo una candidatura approvata e verifica dell’identità il classificatore “High-Risk Dual Use” viene sbloccato per l’accesso API dell’organizzazione, con l’accesso legato a chiavi API specifiche e soggetto ai requisiti di governance di Anthropic. Aziende come Cymulate e ArmorCode lo hanno già ottenuto.
OpenAI persegue un approccio simile con il programma Trusted Access for Cyber (TAC) investendo però di più nella scalabilità. Ad aprile 2026 ha rilasciato GPT-5.4-Cyber, una variante del modello specificamente ottimizzata per il lavoro di sicurezza difensiva con una soglia di rifiuto più bassa per richieste legittime, e il programma TAC viene attualmente esteso a migliaia di difensori individuali verificati e centinaia di team.
Entrambi i programmi si basano sulla verifica dell’identità e sulla validazione organizzativa. L’approccio è quello giusto, ma l’implementazione ha dei limiti e noi li sentiamo nel lavoro di tutti i giorni.
La nostra esperienza dalla pratica
Noi di Zerberos, dopo un processo di verifica, abbiamo ottenuto un’esenzione che ci consente di utilizzare modelli IA per sviluppare strumenti di sicurezza offensivi senza che ogni seconda richiesta venga bloccata. Prova dell’identità, delle attività commerciali, dell’autorizzazione a condurre test di sicurezza: tutto documentato.
Funziona? Per lo più sì. Ma continuiamo a trovarci in situazioni in cui anche con accesso verificato richieste essenziali per il nostro lavoro vengono respinte. Sviluppo di exploit, generazione di payload, aggiramento di controlli di sicurezza: tutti compiti standard di un red team e tutti ambiti in cui un modello IA con il contesto giusto potrebbe dare un supporto più efficiente di qualsiasi altro strumento.
L’incoerenza è il vero problema, non l’esistenza delle barriere in sé (quelle sono comprensibili) ma la loro imprevedibilità. Quando non ci si può fidare di quali richieste andranno a buon fine e quali no, non si può integrare l’IA in modo affidabile nei flussi di lavoro. Si pianifica con uno strumento che forse aiuterà o forse no, ed è genuinamente frustrante.
Cosa deve cambiare
Il futuro non sta in meno sicurezza ma in una differenziazione migliore, e ci sono approcci che vanno nella direzione giusta:
Livelli di accesso granulari invece del binario “bloccato/consentito”. Livelli graduali legati a ruoli e contesti verificati, perché un CISO che fa controllare il proprio codice ha bisogno di libertà diverse rispetto a un pentester che sviluppa un exploit, e entrambi hanno esigenze diverse da uno studente di cybersicurezza.
Consapevolezza del contesto nella valutazione delle richieste, ovvero non solo cosa si chiede ma chi chiede e in quale quadro organizzativo. La tecnologia per questo esiste già, deve solo essere applicata in modo più coerente.
Standard di settore anziché soluzioni isolate. Oggi ogni fornitore gestisce il proprio programma, e un sistema di verifica trasversale (simile a un accreditamento) semplificherebbe il processo per tutti e impedirebbe alle aziende di sicurezza di dover ricominciare da zero con ogni fornitore.
Politiche trasparenti per i ricercatori di sicurezza con linee guida chiare e documentate su ciò che è possibile con l’accesso verificato e ciò che non lo è. La pratica attuale di tentativi ed errori con risultati che cambiano ogni giorno non è sostenibile a lungo termine.
La dimensione regolatoria
E come se tutto questo non fosse già abbastanza complicato, c’è la regolamentazione. A giugno 2026 il governo statunitense ha imposto restrizioni all’esportazione sui modelli Mythos e Fable di Anthropic dopo che un rapporto aveva mostrato che le barriere integrate potevano essere aggirate. Fable 5 è tornato all’accesso generale il 1° luglio, mentre Mythos 5 resta disponibile solo per organizzazioni statunitensi verificate.
Per le aziende di sicurezza europee come la nostra questo crea un ostacolo aggiuntivo: i modelli più potenti potrebbero diventare geopoliticamente limitati prima ancora che il settore abbia stabilito standard per l’accesso verificato. È come togliere gli strumenti migliori agli artigiani mentre si discute ancora su chi dovrebbe poterli usare.
Tra protezione e ostruzione
La tensione tra sicurezza dell’IA e pratica della cybersicurezza non scomparirà perché è strutturale. Le stesse capacità che rendono un difensore più efficace rendono anche un aggressore più pericoloso, e nessun classificatore al mondo può risolvere completamente questa ambiguità.
Ma la situazione attuale in cui le barriere bloccano i ricercatori legittimi mentre i criminali le aggirano tranquillamente è la peggiore di tutte le alternative. I fornitori hanno sviluppato gli approcci giusti con CVP e TAC, e adesso devono essere scalati, standardizzati e resi adatti alla pratica reale. In fretta.
Per le aziende che commissionano test di sicurezza questo è direttamente rilevante: chiedete al vostro fornitore come lavora con gli strumenti IA e quale accesso verificato possiede. Fa una differenza concreta se un pentester lavora con le piene capacità di un modello IA o con una versione censurata che rifiuta ogni seconda richiesta.
Utilizziamo strumenti basati sull’IA nei nostri penetration test e security assessment, con accesso verificato e governance chiara. Se volete sapere come mettiamo l’IA al servizio della sicurezza della vostra infrastruttura, ve lo mostriamo volentieri: contattateci.
Fonti: TechCrunch: AI guardrails impede offensive security researchers, Cymulate: Joining the Anthropic CVP, Help Net Security: OpenAI GPT-5.4-Cyber, Infosecurity Magazine: TRIM Jailbreak, Cato Networks: Frontier AI as Offensive Platform, Dark Reading: AI Jailbreaks for Offensive Attacks