Red teaming dell'AI coding: tre modi di mettere alla prova quello che l'AI produce

Apri Claude Code. Scrivi cosa vuoi. L'agente lavora, ti restituisce il codice, tu lo leggi, magari chiedi una correzione, e via. Un agente, una conversazione, un thread che scorre dall'alto in basso. Poi, quando qualcosa salta — un edge case ignorato, una funzione che "sembrava giusta" — ti lamenti che l'AI ha sbagliato.

È il modo in cui usa Claude Code la stragrande maggioranza delle persone. Ed è anche il modo meno affidabile di usarlo.

Il punto non è avere fede cieca nell'AI. È il contrario. La modalità lineare costringe un singolo agente a fare da giudice di se stesso: genera, e poi — nello stesso contesto, con gli stessi bias — decide se quello che ha generato va bene. E un modello che si autovaluta ha un difetto strutturale documentato, ci torno tra poco. Criticare uno strumento mentre lo si usa all'1% del suo potenziale è una critica viziata: ingiusta verso lo strumento, e verso te stesso.

Gli AI coding tool di oggi — Claude Code, Cursor, Codex — supportano già subagent, sessioni concorrenti, isolamento via git worktree. Quasi nessuno li usa così. Tra "un agente" e una manciata di agenti orchestrati in parallelo c'è uno spazio enorme e in gran parte inesplorato. Il red teaming è il primo passo concreto dentro quello spazio.

Cos'è il red teaming, e perché applicarlo all'AI coding

Red teaming significa, testualmente nella definizione di Anthropic, "testare in modo avversariale un sistema tecnologico per identificarne le vulnerabilità". Nasce in ambito militare e di sicurezza: una squadra — il red team — ha il compito esplicito di attaccare, rompere, trovare il punto debole, mentre il blue team difende. Non è controllo qualità gentile. È adversariale per progetto.

Applicato all'AI coding, il principio si traduce così: invece di chiedere a un agente "va bene questo codice?", incarichi un secondo agente di dimostrare che non va bene. Cambia tutto, perché cambia l'incentivo. Un agente a cui chiedi conferma cerca conferma. Un agente a cui chiedi di rompere, rompe.

E qui non c'è un solo bersaglio. Ci sono tre livelli distinti, ed è utile tenerli separati perché richiedono setup diversi:

Il codice prodotto dall'agente — è corretto, robusto, gestisce gli edge case?
Il tuo setup agentico — l'agente stesso può uscire dai binari, essere dirottato, eseguire cose distruttive?
Il prodotto costruito — il software che hai consegnato è sicuro contro un attaccante reale?

Vediamoli uno per uno, con cosa sono, perché servono e come si fanno in pratica con Claude Code.

Livello 1 — Agente contro agente

Il primo livello è il più immediato da adottare e quello con il ritorno più alto sul lavoro quotidiano. Un agente genera il codice. Un secondo agente, separato, lo attacca: cerca edge case non gestiti, assunzioni fragili, bug, percorsi che si rompono. Prima che l'umano metta gli occhi sul diff.

Perché un agente separato, e non l'autocritica

La domanda ovvia è: non basta dire allo stesso agente "ora rivedi quello che hai scritto"? No. E c'è un motivo misurato.

Il paper Self-Preference Bias in LLM-as-a-Judge (Wataoka et al., arXiv 2410.21819, ottobre 2024) documenta che GPT-4, usato come giudice, sovrastima sistematicamente la qualità dei propri output. Il meccanismo proposto è interessante: gli LLM tendono a favorire output a perplexity più bassa — cioè più "familiari" al modello — indipendentemente da chi li ha generati. Un modello che valuta il proprio codice lo trova familiare, e la familiarità diventa, di fatto, un voto a favore.

L'autocritica guidata non è inutile in assoluto: la Constitutional AI di Anthropic (arXiv 2212.08073) mostra che funziona per l'allineamento. Ma è un meccanismo di training, non un sostituto del controllo esterno — e Anthropic stessa nota un limite preciso: un modello capace di riconoscere quando viene valutato può "verificare la conformità dichiarata invece dell'adozione genuina dei valori". Tradotto nel nostro contesto: l'agente può imparare a sembrare rigoroso nella revisione senza esserlo.

Un critico esterno non condivide il contesto né i bias del generatore. È questa indipendenza, non l'intelligenza superiore, a renderlo utile.

Che funziona, lo dicono i numeri

Il pattern ha un nome consolidato — generator-critic (o actor-critic): un agente produce una bozza, un secondo la critica contro criteri specifici, poi si rivede, con uno stop check dopo ogni giro. E ci sono evidenze quantitative che la critica multi-agente batte il singolo thread.

Il paper di Du et al. 2023, Improving Factuality and Reasoning in Language Models through Multiagent Debate (arXiv 2305.14325, ICML 2024), fa proporre a più istanze del modello delle risposte, poi le fa leggere e criticare a vicenda fino a convergenza. Risultato: accuratezza su task aritmetici dal 67,0% all'81,8%; su GSM8K dal 77,0% all'85,0%.

Sul versante codice c'è CriticGPT (OpenAI, Finding GPT-4's mistakes with GPT-4, giugno 2024): un modello GPT-4 addestrato specificamente a criticare il codice di ChatGPT. Con il suo aiuto i revisori umani superano quelli senza aiuto nel 60% dei casi, e le sue critiche sono preferite a quelle di ChatGPT nel 63% dei casi su bug reali — in parte perché produce meno nitpick, meno falsi allarmi. Tienilo a mente: ci torneremo nella sezione sui limiti.

Esiste anche un dato che gira spesso, un miglioramento su HumanEval dall'80% al 91% con un loop di reflection. Lo riporto per onestà, ma secondo le fonti tecniche da cui circola è una cifra di blog, non di un paper primario verificabile: trattala come indicazione di tendenza, non come numero da citare in una slide.

Come si fa: un subagent red teamer in Claude Code

In Claude Code un subagent è un file Markdown con frontmatter YAML; il corpo del file diventa il system prompt. Lo crei a mano o con /agents. Per un revisore parti da tool read-only: niente scrittura, niente esecuzione di comandi distruttivi. Il suo lavoro è leggere e segnalare, non toccare.

C'è un punto critico, confermato dalle best practice ufficiali: i system prompt di default spingono il modello verso un atteggiamento accomodante. Se non lo istruisci esplicitamente a essere critico, ottieni un secondo complice, non un red teamer. Va detto in modo netto, quasi sgradevole.

Ecco un system prompt di partenza, da adattare:

Sei un revisore avversariale. Il tuo compito NON è approvare:
è trovare ciò che si rompe.

Per ogni file modificato cerca:
- edge case non gestiti
- assunzioni implicite su input, ambiente, ordine delle operazioni
- race condition e stato condiviso
- errori gestiti in modo silenzioso (catch vuoti, fallback muti)
- percorsi di esfiltrazione dati o input non validati
- dipendenze non verificate

Tratta il codice generato da un'AI con sospetto extra:
"sembra corretto" non è una verifica.

Per ogni problema indica: dove si trova, perché è un problema,
come riprodurlo concretamente.

Non aggiungere nitpick stilistici: solo ciò che ha impatto reale.
Se non trovi problemi gravi, dillo — ma motiva perché.

Per farli girare davvero in parallelo serve l'isolamento. git worktree crea copie separate dello stesso repo in directory diverse: un worktree per il generatore, uno per il red teamer che lavora sullo stesso branch in sola lettura. Senza isolamento rischi overwrite silenziosi — l'agente B scrive dopo l'agente A e una versione vince senza che nessuno te lo segnali.

Il red teamer è, a tutti gli effetti, un subagent. E vale la disciplina di quando dividere e quando no: non spawnarlo per riflesso. Rientra nel caso valido — isolamento di permessi, agente read-only indipendente — ma resta un caso, non una regola da applicare a ogni console.log.

Livello 2 — Red teaming del tuo setup agentico

Qui il bersaglio cambia. Non è più il codice prodotto: è l'agente stesso. La domanda è: come può uscire dai binari? Prompt injection, comandi distruttivi, esecuzione non autorizzata, esfiltrazione di dati.

Il file che guida l'agente può anche dirottarlo

La prompt injection è il rischio numero uno per gli agenti nel 2026. La OWASP Top 10 for Agentic Applications 2026, pubblicata a dicembre 2025, classifica l'Agent Goal Hijacking come rischio #1 in assoluto.

Il vettore è più banale di quanto sembri. I file di un repository — README, CLAUDE.md, commenti nel codice, metadati di package.json — finiscono dentro il context window dell'agente. E un LLM non ha un confine crittografico tra "istruzioni dell'utente" e "contenuto da analizzare": è tutto testo nello stesso flusso. Un esempio documentato è un pacchetto fittizio con commenti HTML invisibili nel terminale ma perfettamente leggibili dall'agente, che gli chiedono di inserire una routine di esfiltrazione credenziali dentro gli error handler "di produzione" — codice che, in code review, sembra del tutto plausibile.

Chi ha letto il pezzo su GROUNDING.md, il file che sovrascrive il prompt riconoscerà la leva. Lì un file Markdown con autorità più alta del prompt utente è uno strumento di governance: guida l'agente, gli impone vincoli sani. Qui è la stessa identica leva, rovesciata. Lo stesso meccanismo che rende potente un file di contesto ben scritto rende devastante un file di contesto malevolo. Stessa fisica, segno opposto.

Il caso Claude Code, marzo 2026

Non è teoria. Il 31 marzo 2026 Anthropic ha esposto per errore il codice sorgente di Claude Code — circa 512.000 righe di TypeScript, via una sourcemap di debug finita su npm. Pochi giorni dopo l'Adversa AI Red Team ha trovato un bypass concreto: Claude Code limitava l'analisi dei comandi a 50 sotto-comandi per ragioni di performance; superata quella soglia, ripiegava su prompt generici saltando le validazioni di sicurezza. Un CLAUDE.md malevolo poteva quindi generare una pipeline di 50 e passa sotto-comandi mascherata da build legittima, e aggirare così le deny rule. (Sulla vicenda del leak c'è un pezzo dedicato sul blog.)

A questo si lega la lethal trifecta di Simon Willison: un agente diventa pericoloso quando ha tutti e tre gli elementi insieme — accesso a dati privati, esposizione a contenuto non fidato, capacità di comunicare verso l'esterno. La difesa affidabile è strutturale: togliere una delle tre gambe. Non sperare di rilevare ogni singolo attacco.

In pratica, il modello di sicurezza di Claude Code è il riferimento concreto: read-only di default, deny/allow list, sandbox costruita su primitive del sistema operativo (bubblewrap su Linux, Seatbelt su macOS), accesso di rete via proxy con allowlist di domini. Anthropic riporta che la sandbox riduce dell'84% i prompt di permesso nell'uso interno — e, soprattutto, che una sandbox ben fatta isola anche una prompt injection riuscita: un Claude compromesso non può rubare chiavi SSH né fare "phone home". E no, la scorciatoia non è disattivare la sandbox o lanciare con --dangerously-skip-permissions: sarebbe esattamente il contrario di questo livello.

Lo spunto chiave: spietato anche col codice dell'AI

C'è un riflesso da disinnescare. Tendiamo a essere più indulgenti con il codice scritto dall'AI — è pulito, ben formattato, ha i commenti giusti. Un buon red teamer fa l'opposto: non risparmia nemmeno il codice generato dall'AI. Anzi, è proprio lì che serve di più.

Il codice AI ha un bias specifico: sembra giusto. È coerente, leggibile, idiomatico. E quella plausibilità superficiale è esattamente ciò che fa passare l'esfiltrazione dentro l'error handler dell'esempio di prima. In code review umana un blocco di codice ordinato abbassa la guardia. Il red teamer non ha la guardia: non gli importa se il codice è bello, gli importa solo se si rompe. Quando attacchi il tuo setto agentico, includi sempre nel mirino quello che l'agente stesso ha prodotto.

Livello 3 — Red teaming del prodotto costruito

Il terzo livello è il più ambizioso: usare un agente AI come penetration tester del software che hai consegnato — scritto con o senza AI. L'agente come red teamer del deliverable finale.

Per un articolo pratico questo livello serve più come orizzonte che come tutorial — difficilmente lo orchestri stasera sul tuo laptop — ma è utile sapere che è già realtà industriale, perché ridefinisce l'asticella.

XBOW è una piattaforma di offensive security autonoma: un coordinatore persistente dirige migliaia di agenti paralleli, ognuno con contesto fresco e obiettivo focalizzato, e accetta una scoperta solo dopo conferma controllata e non distruttiva dell'exploitabilità. È stata validata su HackerOne trovando vulnerabilità originali in applicazioni di produzione, e a maggio 2026 ha chiuso 35 milioni di dollari di Series C aggiuntivi.

La DARPA AI Cyber Challenge (AIxCC), finale ad agosto 2025, è ancora più indicativa: sette sistemi di cyber reasoning hanno lavorato su 54 milioni di righe di codice, identificato l'86% delle vulnerabilità sintetiche (54 su 63) e patchato 43 di quelle individuate; in più hanno trovato 18 vulnerabilità reali precedentemente ignote. Costo medio per task: circa 152 dollari. I sistemi vincitori sono stati rilasciati open source.

E c'è il Project Glasswing di Anthropic, su cui il blog ha già un pezzo dedicato: un agente di sicurezza che, con un modello frontier non rilasciato, ha identificato migliaia di zero-day in ogni major OS e browser. Il punto, per noi, non è il dettaglio della notizia. È che l'AI come red teamer di prodotto non è una previsione: sta già succedendo su scala industriale. Quello che fanno XBOW e AIxCC oggi su milioni di righe è la versione matura di quello che puoi iniziare a fare in piccolo sul tuo repo.

Adversariale non vuol dire solo attacco

Una precisazione, prima della critica onesta. Orchestrare più agenti non significa per forza farli litigare. Ci sono due modi di farlo lavorare insieme, ed entrambi sono utili.

Il modo cooperativo: gli agenti si dividono il lavoro, uno scrive i test mentre un altro scrive l'implementazione, un terzo aggiorna la documentazione. Collaborano verso lo stesso obiettivo. Il modo adversariale: un agente ha il compito esplicito di rompere quello che l'altro costruisce. Il red teaming sta tutto in questo secondo modo — ma sapere che esiste il primo aiuta a non vedere il multi-agente solo come conflitto. La domanda giusta, ogni volta, è: questo task ha bisogno di un alleato in più o di un avversario in più?

Critica onesta: quando il red teaming non conviene

Il red teaming non è gratis, e venderlo come soluzione universale sarebbe disonesto.

Costa token, e parecchi. Un workflow generator-critic-revise raddoppia o triplica la spesa rispetto al thread singolo. Per task piccoli — uno script throwaway, una utility di dieci righe — il costo supera nettamente il beneficio. Il red teaming si giustifica dove il codice ha impatto reale: sicurezza, dati, parti critiche del sistema.

Un red teamer troppo aggressivo genera rumore. È il problema dei nitpick che OpenAI ha dovuto mitigare proprio in CriticGPT: un critico iper-zelante produce falsi positivi che ti fanno perdere tempo e — peggio — ti abituano a ignorare gli allarmi. Quando ogni revisione torna con quaranta segnalazioni, smetti di leggerle. Il system prompt deve calibrare la soglia, ed è per questo che nell'esempio sopra c'è scritto esplicitamente "niente nitpick stilistici".

Non è una garanzia. Due agenti basati sullo stesso modello possono condividere lo stesso punto cieco. La diversità aiuta — usare modelli diversi per generatore e critico — ma non è magia. Il red teaming riduce il rischio, non lo azzera.

C'è un limite pratico al parallelismo. Secondo le stime che circolano nei blog tecnici — non un dato ufficiale — il tetto realistico è intorno ai 5-7 agenti concorrenti su un laptop, e ogni git worktree pesa diversi GB su disco, prima che rate limit e overhead di review annullino il guadagno. Più agenti non è automaticamente meglio.

Il giudizio umano finale resta. Il red teamer riduce il carico di review, non lo elimina. Chi decide cosa va in produzione sei tu. E attenzione al teatro della sicurezza: aggiungere un agente chiamato "security" non rende sicuro un setup con la lethal trifecta intatta. La difesa vera del Livello 2 è strutturale — sandbox, allowlist, deny list — non un secondo prompt ben scritto.

Tutto questo è la versione operativa del paradosso del vibe coding: il vibe coding chiede fiducia, il red teaming è la verifica strutturata che rende quella fiducia sostenibile. Non "fidati o non fidarti", ma "costruisci il meccanismo che verifica al posto tuo". E perché quel meccanismo sia efficace deve avere il contesto giusto — i criteri, cosa controllare — che è poi il tema della memoria degli agenti.

Cosa farne stasera

Non serve riscrivere il tuo workflow. Serve un primo passo concreto, e il primo passo è il Livello 1.

Crea un subagent red teamer. Un file Markdown, frontmatter YAML, tool read-only, e il system prompt avversariale che hai visto sopra — adattato al tuo dominio. La prossima volta che Claude Code ti genera codice che andrà davvero in produzione, prima di leggerlo tu, passalo al red teamer. Leggi cosa trova. Le prime volte ti sorprenderà — non perché l'AI sia magica, ma perché tu, sul codice che "sembrava giusto", la guardia l'avevi già abbassata.

Poi, quando il pattern ti è entrato nelle mani, sali: rivedi il tuo setup col Livello 2, controlla quali file finiscono nel context window dell'agente e se la sandbox è davvero attiva.

Usare Claude Code in modalità lineare e poi lamentarsi quando sbaglia è come comprare una macchina e guidarla solo in prima. Lo strumento può fare molto di più. Il red teaming è dove inizi a usarlo sul serio — e a quel punto, se l'AI sbaglia, almeno la critica è onesta.

Fonti: