Dentro il leak Claude Code: dettagli tecnici sorprendenti

Una semplice svista commessa dai tecnici di Anthropic nella fase di pubblicazione del pacchetto npm di Claude Code ha trasformato uno strumento proprietario in uno dei casi più discussi degli ultimi anni. Il codice sorgente di Claude Code, assistente AI per la programmazione rilasciato nel 2025, è finito pubblicamente accessibile attraverso il registry npm. L’incidente non è stato causato da un attacco informatico, ma da un errore umano durante le operazioni: una situazione che evidenzia un aspetto spesso trascurato della sicurezza delle applicazioni, ovvero la gestione dei file e dei componenti generati automaticamente durante il processo di compilazione e distribuzione del software, che se non controllati correttamente possono esporre dati riservati e funzionalità interne.

Claude Code rappresenta uno dei primi esempi concreti di agenti AI per lo sviluppo software, capaci di orchestrare task complessi, interagire con strumenti esterni e mantenere stato persistente tra sessioni. La diffusione di strumenti simili ha accelerato in modo evidente: già nel 2025 oltre metà degli sviluppatori dichiarava un utilizzo quotidiano di assistenti AI nella scrittura del codice.

Architettura interna di Claude Code: agenti, orchestrazione e memoria persistente

L’accesso al codice di Claude Code ha offerto uno sguardo raro su come sono costruiti gli strumenti AI di nuova generazione. Claude Code non si limita a generare codice: implementa un’architettura a più livelli basata su agenti cooperanti, con una componente centrale che gestisce la decomposizione dei task e la loro esecuzione.

Tra gli elementi più rilevanti emerge un sistema di multi-agent orchestration, in cui un agente principale suddivide un obiettivo in sotto-attività assegnate a worker specializzati. La comunicazione avviene tramite bus di messaggi e memoria condivisa, mentre un scheduler interno gestisce le dipendenze tra task utilizzando logiche simili a grafi aciclici.

Il codice rivela anche la presenza di una persistent memory che consente all’agente di mantenere informazioni tra sessioni senza dipendere da storage esterno. Una scelta che suggerisce un livello di autonomia più elevato rispetto ai classici assistenti stateless.

Altri componenti degni di nota includono strumenti per l’integrazione con ambienti reali: controllo del browser tramite Playwright, esecuzione di comandi Bash e supporto per webhook, ovvero la capacità di ricevere notifiche automatiche da altri sistemi tramite chiamate HTTP in tempo reale. Non si tratta di prototipi: molte di queste funzionalità risultano complete ma disattivate tramite flag interni.

Un sistema di sicurezza anti-distillazione

Tra gli elementi più sorprendenti scoperti da Alex Kim, emerge un flag denominato ANTI_DISTILLATION_CC. Quando attivo, il client CLI invia un parametro specifico alle API (anti_distillation: ['fake_tools']) che induce il server a iniettare informazioni fittizie nei prompt. L’obiettivo è chiaro: contaminare eventuali dataset raccolti da chi intercetta il traffico, rendendo meno efficace l’addestramento dei modelli concorrenti.

Accanto a questa tecnica compare un secondo approccio più sofisticato: la sintesi lato server delle risposte intermedie. Il sistema memorizza temporaneamente il testo generato, lo comprime in un riassunto e lo restituisce firmato. In caso di successive interazioni, il contenuto originale può essere ricostruito tramite firma crittografica. Chi registra il traffico ottiene solo versioni ridotte, prive della catena di ragionamento completa.

Entrambe le soluzioni mostrano però limiti evidenti. Il codice indica chiaramente che l’attivazione dipende da flag di runtime e condizioni specifiche; un semplice proxy MITM (man-in-the-middle) in grado di modificare le richieste HTTP può rimuovere il parametro incriminato. Inoltre, l’uso di provider API terzi o SDK alternativi esclude completamente questi controlli. La protezione reale sembra quindi più legale che tecnica.

Modalità undercover: identità mascherata dell’assistente

Una porzione del codice, identificata come undercover mode, impone all’assistente di evitare qualsiasi riferimento interno quando opera su repository esterni.

Il modello non deve citare nomi in codice, strumenti aziendali e nemmeno il nome Claude Code. La funzione non prevede disattivazione nelle build interne; nelle versioni distribuite, viene eliminata dal bundle finale.

Il risultato è un comportamento deliberatamente mimetico: contributi generati dall’AI nei progetti open source non contengono indicatori espliciti della loro origine. La scelta solleva interrogativi sulla tracciabilità del codice prodotto automaticamente, soprattutto in ambienti collaborativi dove l’attribuzione ha implicazioni legali e di sicurezza.

Analisi del linguaggio: regex al posto dei modelli

Un dettaglio curioso riguarda il rilevamento della frustrazione dell’utente. Invece di delegare l’analisi del sentiment a un modello linguistico, il codice utilizza una singola espressione regolare (regex) per intercettare parole chiave offensive o segnali di irritazione. Dal punto di vista ingegneristico, la scelta riduce latenza e costi: una regex opera in tempo costante e non richiede chiamate API.

Il compromesso è evidente: precisione inferiore rispetto a un modello semantico, ma prestazioni nettamente migliori. In uno strumento CLI che gestisce migliaia di richieste, il risparmio computazionale diventa rilevante.

Attestazione del client: controllo crittografico delle richieste

Un altro componente significativo è il sistema di client attestation. Le richieste HTTP contengono un segnaposto automaticamente sostituito durante l’esecuzione del programma (a runtime) sviluppato in Zig, con un hash, cioè un valore univoco generato tramite un algoritmo crittografico. Il server utilizza questo valore per verificare che la richiesta sia stata inviata da un file binario originale e non da un client alterato o manomesso.

Il meccanismo ricorda un DRM applicato alle API: impedisce a strumenti non ufficiali di sfruttare le stesse credenziali o di aggirare i modelli di pricing.

Tuttavia, anche qui emergono margini di elusione. La presenza di flag di compilazione e kill switch remoti suggerisce che il sistema non sia rigidamente imposto; inoltre, l’uso di runtime alternativi potrebbe neutralizzare la sostituzione dell’hash.

Efficienza operativa: errori e costi nascosti

Il codice rivela anche problematiche interne legate all’efficienza. Un commento documenta oltre 250.000 chiamate API giornaliere sprecate a causa di errori ripetuti nella funzione di autocombinazione dei prompt. La soluzione adottata è semplice ma efficace: interrompere il processo dopo tre fallimenti consecutivi (presenza del parametro MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3).

La presenza di log così dettagliati indica un monitoraggio costante dei costi operativi. Nei sistemi basati su token, ogni inefficienza si traduce direttamente in spesa.

KAIROS: indizi su un agente autonomo persistente

Tra le parti più interessanti del codice compaiono riferimenti a KAIROS, una modalità non ancora pubblica che sembra orientata a un agente sempre attivo.

Le funzionalità suggeriscono un’evoluzione significativa: esecuzione in background, integrazione con webhook GitHub, aggiornamenti periodici tramite cron e persino una forma di “memoria” persistente con processi di distillazione notturna.

Si intravede un passaggio da assistente reattivo a entità autonoma capace di operare senza input continuo. L’implementazione appare ancora incompleta, ma la direzione verso cui sta guardando Anthropic è chiara.

Rendering e sicurezza: soluzioni prese dai motori di gioco

Il terminale CLI (command-line interface) di Claude Code utilizza tecniche insolite per questo tipo di software.

L’impiego di strutture come Int32Array per rappresentare caratteri e stili, insieme a un sistema di patch ottimizzate, riduce drasticamente il numero di operazioni durante lo streaming dei token. Il risultato è una maggiore fluidità nella visualizzazione, fondamentale quando il testo arriva carattere per carattere.

Dal punto di vista della sicurezza, il modulo Bash include più di 20 controlli mirati, tra cui la protezione contro exploit associati a Zsh (un’altra shell Unix simile a Bash) e contro tecniche di manipolazione dell’input che sfruttano caratteri invisibili o variabili di ambiente per alterare il comportamento dei comandi.

Si tratta di un grado di accuratezza e profondità difficilmente riscontrabile in strumenti simili.

Feature nascoste e flag di attivazione

Il codice contiene decine di feature flag, utilizzati per attivare o disattivare funzionalità già implementate ma non ancora rilasciate. L’approccio consente di distribuire codice completo mantenendo il controllo sulle feature visibili agli utenti: un po’ come fa Microsoft con Windows 11.

Tra le funzionalità individuate compaiono agenti sempre attivi in background, schedulazione tramite cron, modalità vocale e sistemi di automazione.

Alcune implementazioni suggeriscono scenari di utilizzo avanzati: agenti in grado di sospendere l’esecuzione e riprenderla autonomamente, oppure coordinare più istanze con ruoli differenziati.

Interessante anche la presenza di meccanismi di controllo interno, come modalità progettate per evitare la divulgazione accidentale di informazioni sensibili nei contenuti generati. Una misura che, ironicamente, non ha impedito la diffusione dell’intero codice sorgente.

Implicazioni per la sicurezza e la supply chain

L’incidente evidenzia un punto critico: gli strumenti di sicurezza tradizionali non intercettano errori legati alla configurazione della distribuzione. Scanner statici e sistemi di rilevamento segreti operano sul codice, non sugli artefatti finali resi pubblici.

Nel caso di Claude Code, la vulnerabilità nasce da una catena di distribuzione mal configurata: build, packaging e pubblicazione. Una sequenza che sfugge facilmente ai controlli se non si introducono verifiche specifiche. Il problema assume un peso maggiore in ambienti dominati dal cosiddetto sviluppo assistito da AI, dove il codice viene prodotto rapidamente e spesso con minore revisione manuale.

Il leak non ha esposto dati degli utenti né i pesi dei modelli, ma ha reso visibili logiche interne, strumenti proprietari e roadmap di sviluppo. Per un concorrente, queste informazioni rappresentano un vantaggio concreto: riducono i tempi di progettazione e forniscono pattern architetturali già validati.

Il caso Claude Code mostra con chiarezza una realtà tecnica cruciale: la superficie di attacco non coincide più solo con il codice applicativo, ma include l’intero ciclo di distribuzione. Errori minimi, come una riga mancante in un file di configurazione, possono avere effetti sproporzionati quando il software coinvolge sistemi complessi e diffusi su larga scala.