Il leak del sorgente di Claude Code ha generato una serie di reazioni fra cui l’analisi delle vulnerabilità esposte, la documentazione degli attacchi immediati, le raccomandazioni operative. Tutto corretto, tutto necessario, tutto insufficiente. Perché il problema che il leak porta a galla non è tecnico nel senso classico del termine, è strutturale e riguarda una caratteristica del codice generato da AI che finora abbiamo discusso in teoria, mai misurato in pratica.

Partiamo da un presupposto: Claude Code era già scritto in parte da un LLM prima che qualcuno ne vedesse il sorgente. Come nel gatto di Schrödinger, finché il sorgente era chiuso, il codice era simultaneamente sicuro e compromettibile, auditabile e opaco, affidabile e replicabile. Il leak ha aperto la scatola ma, a differenza dell'esperimento mentale, questo gesto non ha collassato la sovrapposizione in un unico stato. Ha rivelato che entrambi gli stati erano già veri, e lo erano da prima che qualcuno guardasse. Qui poteremmo immaginare un dibattito diviso in tre posizioni. La prima è rassicurante: adesso che il problema è visibile, possiamo gestirlo. È la lettura preferita dei vendor di cybersecurity, e non è sbagliata, ma è incompleta. La seconda è più scomoda: sapere non cambia nulla, perché resta il problema che il codice generato da LLM continuerà a essere prodotto con le stesse caratteristiche, il leak o no. La terza è quella preoccupante: il leak ha peggiorato la situazione non perché abbia rivelato qualcosa di nuovo, ma perché ha abbassato la soglia di ingresso per chi voleva sfruttarlo. Prima serviva competenza per immaginare i pattern, ora basta guardare. C'è poi una quarta considerazione trasversale alle precedenti: il vero problema non è questo leak specifico, ma il fatto che la condizione di Schrödinger rischia di essere valida per ogni tool AI in produzione che genera parti di sé stesso con un LLM. Claude Code è stato il primo a essere svelato, non sarà l'ultimo.

Come hanno sottolineato un po’ tutti all’indomani del leak di Claude Code, il cuore del problema è la prevedibilità, o meglio, la riproducibilità statistica del codice generato da modelli linguistici. Il software tradizionale può essere analizzato, testato, reverse‑ingegnerizzato. Non può essere rigenerato perché ogni sviluppatore produce scelte architetturali che dipendono da contesto, esperienza, vincoli specifici di progetto. Il codice prodotto da un modello linguistico introduce invece una forma di riproducibilità statistica che nel software tradizionale non esiste: chi conosce il modello, i suoi pattern, le sue tendenze stilistiche, può approssimare l'output anche senza averlo mai visto.

Non è rigenerazione identica. È qualcosa di più sottile e più pericoloso perché comporta la possibilità di costruire varianti credibili, di anticipare patch, di replicare bug sistemici su larga scala. Il gatto era già in quello stato, solo che noi non lo sapevamo. La conferma empirica è arrivata quasi subito, con la ricerca di Zscaler che ha documentato la comparsa di repository fake che distribuivano Vidar e GhostSocks, costruite sfruttando la simmetria tra codice originale e codice replicato. Il leak è stato un acceleratore, non la causa.

Il dibattito che non si può rimandare

Eppure questa tesi, per quanto solida nelle sue premesse, non è ancora dimostrata in via definitiva. E il dibattito che ne consegue è tutt'altro che accademico. Uno studio arXiv del dicembre 2025 intitolato significativamente AI-Generated Code Is Not Reproducible (Yet) ha analizzato 300 progetti generati da Claude Code, OpenAI Codex e Gemini, rilevando che il codice generato da LLM sarebbe meno riproducibile di quanto appaia, anche per chi lo ha prodotto. Questo complica non poco la tesi della prevedibilità statistica, ponendo a chi volesse replicare o anticipare output specifici davanti alle stesse incognite. Veracode, in un altro studio, conclude che il problema della sicurezza è sistemico e indipendente dalla dimensione del modello. Le due tesi non si escludono, anzi, confermano la sensazione che stiamo cercando di misurare un rischio che non sappiamo ancora definire.

I tassi di successo per linguaggio mostrano l’impatto della complessità dell’ecosistema. Fonte: arXiv

Potremmo andare avanti elencando decine di studi che espongono tutto e il contrario di tutto, ma non cambierebbe il fatto che in questo momento dubbi e perplessità abbondano, le certezze mancano. Il leak di Claude Code è il primo caso in cui questa incertezza diventa operativa, il che favorisce più gli attaccanti che i difensori. E qui si aprono vari scenari. Sul piano operativo, l’asimmetria nasce dal fatto che chi attacca non ha bisogno di certezze per agire, gli basta una probabilità ragionevole. Chi difende, invece, deve capire esattamente che cosa sta difendendo.

Sul piano regolatorio non ci sono ancora normative che tocchino la composizione del codice, né standard a cui appellarsi. Sul piano culturale, il vaso di Pandora è aperto e la domanda non è come richiuderlo, ma se il settore ha la maturità per affrontare ciò che ne è uscito prima del prossimo leak. Perché ci saranno altri leak, non necessariamente più gravi, sicuramente più attesi, ma il calcolo delle probabilità è favorevole.

Utente con permessi limitati

In assenza di riferimenti normativi, la cornice concettuale più strutturata disponibile oggi viene paradossalmente dall'industria stessa. Non è nemmeno figlia del leak: a dicembre 2025 CyberArk aveva lanciato Secure AI Agents Solution estendendo agli agent AI autonomi gli stessi principi di accesso just-in-time, privilegio minimo e monitoraggio continuo delle sessioni applicati alle identità umane e macchina. RSA, nell'analisi pubblicata a margine del leak su Claude Mythos e Capybara, è arrivata alla stessa conclusione in modo indipendente. Il messaggio convergente è che gli agent AI non sono strumenti passivi: sono identità non umane con accesso privilegiato, attori che prendono decisioni, accedono a risorse, manipolano dati, interagiscono con altri sistemi. E in quanto tali vanno governati con controlli stringenti, privilegi minimi e approccio Zero Trust.

Se accettiamo questa definizione, il leak di Claude Code cambia natura perché non è più la pubblicazione del codice sorgente di un software, è la divulgazione della mappa completa del comportamento di un'entità che agisce per conto di chi la usa. Il leak fa capire come decide, cosa considera legittimo, dove si ferma e dove no, quali condizioni la spingono ad agire in un modo piuttosto che in un altro. È come pubblicare il profilo psicologico di un amministratore di sistema con accesso illimitato. Chi lo legge impara come manipolarlo senza che se ne accorga.

Questo è il salto concettuale che dovrebbero fare le analisi sul leak di Claude Code: la questione non è la vulnerabilità nel codice, i repository fake, i pattern prevedibili. È che il leak ha reso pubblica la logica decisionale di un agente che in molte aziende opera già con accesso a file, processi, dipendenze, pipeline di sviluppo. Un attaccante che conosce questa logica può ora costruire un contesto che spinge l'agent a comportarsi in modo malevolo, ma nel pieno rispetto di tutte le regole che l'agent stesso si è dato. Senza forzare nulla, senza lasciare tracce riconoscibili.

Una governance con un piano mancante

Tuttavia, questa prospettiva apre una contraddizione che l'approccio identitario da solo non risolve. Zero Trust applicato alle identità non umane presuppone che il comportamento dell'agent sia verificabile. Ma se il codice che governa quel comportamento è in parte generato in modo opaco, la governance dell'identità si applica a un'entità il cui funzionamento interno nessuno può davvero certificare, nel senso che sapere chi è un agent e cosa può fare non equivale a sapere come decide.

La questione si amplifica ulteriormente nelle architetture multi-agent, che sono la direzione in cui si muove l'intero settore. Negli ambienti reali Claude Code non opera isolato, interagisce con altri modelli, condivide contesto, passa istruzioni. Se un nodo della catena è compromesso o manipolato, il problema si propaga agli altri agent con cui condivide memoria e tool, attraverso percorsi che le difese progettate per applicazioni tradizionali non sono attrezzate a rilevare. Il sorgente esposto fa sì che un attaccante conosca il modo in cui ciascun nodo della catena prende decisioni.

C'è poi una dimensione che le analisi tecniche tendono a trascurare: la delega implicita. Quando un'azienda adotta Claude Code, delega a quel tool una serie di decisioni operative, come le dipendenze da accettare, i file da modificare, le configurazioni da applicare. Questa delega non viene mai esplicitata contrattualmente, verificata o revocata. Un attaccante che conosce queste condizioni può costruire le condizioni per spingere l'agent verso decisioni favorevoli all'attacco, senza intervenire sul codice e senza generare segnali anomali. È una banale (ma efficace) manipolazione del contesto operativo dell'agent.

La domanda che nessuno dei framework attuali affronta in modo diretto è di chi sia la responsabilità di rendere verificabile il comportamento degli agent AI. CISA, Google SAIF e Cloud Security Alliance convergono su principi corretti: giudizio umano nella catena di controllo, privilegi minimi, fiducia guadagnata sul campo. Ma presuppongono tutti che il codice su cui quegli agent girano sia auditabile e dichiarato. In pratica, abbiamo costruito una governance sull'identità degli agent senza chiederci chi certifica ciò che quegli agent eseguono. È un'architettura di controllo con un piano mancante. E il piano mancante è esattamente quello su cui si muoveranno i prossimi attacchi.