Alibaba avrebbe vietato Claude Code per timori sulla sicurezza

Alibaba vieta Claude Code: considera la notizia un segnale per gli acquisti, non un verdetto

Una grande organizzazione di sviluppo non ha bisogno della prova di una backdoor per sospendere l'uso di un agente AI per la programmazione. Basta una domanda irrisolta nel punto sbagliato: «Questo strumento può leggere codice sorgente che non possiamo divulgare per motivi legali o contrattuali?»

È questa la prospettiva pratica che adotterei per il presunto divieto di usare Claude Code sul lavoro imposto da Alibaba. La preoccupazione riportata è seria, ma la conclusione per chi sviluppa non è «Claude Code ha una backdoor confermata». I fatti pubblicamente disponibili non lo dimostrano. La conclusione utile è più circoscritta e operativa: gli agenti AI per la programmazione sono ormai abbastanza vicini a codice sorgente, sistemi di build, segreti, log e flussi di distribuzione da dover seguire lo stesso percorso di acquisto e revisione della sicurezza previsto per piattaforme CI/CD, strumenti di ricerca nel codice, strumenti di osservabilità e portatili degli sviluppatori.

In altre parole: separa l'accusa dal piano di controllo.

Il timore di una backdoor, presunto o riportato, va trattato come un'affermazione non verificata finché non emergono prove tecniche concrete. Ma le categorie di rischio legate a Claude Code sono molto reali e meritano un'attenta valutazione: a quale codice può accedere l'agente, quali comandi può eseguire, quale telemetria lascia la macchina, quale modello elabora il prompt, quali regole di conservazione si applicano e come l'organizzazione fa rispettare le proprie policy su migliaia di postazioni di sviluppo.

È questo l'aspetto che dovrebbe interessare ai responsabili dello sviluppo.

Che cosa significa davvero vietare Claude Code sul lavoro

Quando un'azienda vieta o sospende uno strumento per sviluppatori, spesso le persone lo interpretano come una condanna tecnica. In pratica, i divieti rappresentano frequentemente uno stato del processo di acquisto.

Un «divieto» può significare diverse cose:

Quindi, se secondo quanto riportato Alibaba vieta Claude Code, questo non dimostra automaticamente l'esistenza di un problema tecnico nascosto. Può indicare che i revisori interni non erano soddisfatti delle garanzie disponibili, oppure che il flusso di lavoro predefinito dello strumento era in conflitto con la policy di sicurezza interna.

Questa distinzione conta. Gli sviluppatori dovrebbero evitare di trasformare ogni blocco degli acquisti in un complotto. Ma dovrebbero anche evitare di liquidarlo come burocrazia. Gli strumenti per sviluppatori che agiscono come agenti creano una superficie di esposizione ai rischi di sicurezza più ampia rispetto ai plugin di completamento automatico. Claude Code può esaminare un repository, proporre diff, eseguire comandi se autorizzato e aiutare a orientarsi in un sistema. È proprio questo a renderlo utile, ed è proprio per questo che merita una vera revisione.

La domanda centrale sulla sicurezza: che cosa può vedere l'agente?

Il primo controllo da valutare è l'accesso al codice. Claude Code opera all'interno di un ambiente di sviluppo locale e ragiona sui file e sul contesto a sua disposizione. È una capacità potente, perché gli permette di comprendere un progetto reale anziché frammenti isolati. Significa anche che i team devono considerare il repository come un insieme di dati.

In pratica, i casi rischiosi non riguardano solo i file che contengono segreti evidenti. Includono:

• Algoritmi proprietari
• Dettagli di implementazione specifici dei clienti
• Infrastruttura come codice
• Schemi delle API interne
• Controlli di sicurezza e logica di rilevamento
• Fixture di test contenenti dati copiati dalla produzione
• Note sugli incidenti, analisi post mortem o file locali di appunti
• File di ambiente inseriti accidentalmente in un commit del repository

Un'insidia comune: i team si concentrano sul fatto che i file .env siano ignorati, ma dimenticano che test e documentazione spesso contengono informazioni sufficienti a ricostruire flussi di lavoro sensibili. Un agente che esamina tests/integration/payments/ può vedere credenziali fittizie, endpoint dei partner, regole del ciclo di vita degli account e comportamenti in caso di guasto. Anche quando non è presente alcun segreto, il repository può comunque essere riservato.

Una semplice policy interna può partire dalla classificazione dei repository:

{
  "repo": "payments-core",
  "classification": "restricted",
  "ai_tools": {
    "claude_code": "requires_security_exception",
    "allowed_models": [],
    "external_context_upload": false
  },
  "data_notes": [
    "Contains payment processor workflows",
    "Includes customer contract-specific behavior",
    "No production secrets permitted"
  ]
}

La policy migliore è banale ed esplicita. Gli sviluppatori non dovrebbero dover dedurre se un repository è sicuro per l'uso con un agente.

Permessi dell'agente: la differenza tra leggere e agire

Claude Code non è solo una finestra di chat. È progettato per lavorare nel terminale, esaminare file, modificare codice e partecipare ai flussi di sviluppo. A seconda della configurazione e dell'approvazione dell'utente, un agente può passare dal «suggerire» all'«agire».

Questo confine dei permessi è il secondo aspetto che i team di sicurezza dovrebbero esaminare.

Uno schema tipico e sicuro è:

# Start Claude Code inside a specific repo, not from a broad home directory
cd ~/work/approved-service
claude

Poi limita l'ambito della directory di lavoro. Non avviare strumenti agentici da ~/work, ~/, o dalla radice di un monorepo, a meno che l'intero albero non sia approvato per quell'uso.

Per i repository a rischio più elevato, i team spesso richiedono regole come:

• L'agente può leggere i file sorgente nel repository corrente
• L'agente non può accedere alle directory superiori
• L'agente non può leggere .env, materiale crittografico o archivi locali di credenziali
• L'agente può proporre patch ma non eseguire comandi di distribuzione
• L'agente richiede un'approvazione esplicita prima di installare pacchetti o eseguire comandi shell
• L'agente non può chiamare servizi interni di produzione da una macchina di sviluppo

Le modalità esatte dipendono dal tuo ambiente, ma il modello di sicurezza deve essere concreto. «Gli sviluppatori staranno attenti» non è un controllo.

Un approccio utile consiste nel combinare la policy dello strumento con i limiti imposti dal sistema operativo e dalla shell. Per esempio, esegui il lavoro sensibile in un container di sviluppo pulito con un mount del filesystem dall'ambito limitato:

docker run --rm -it \
  -v "$PWD:/workspace" \
  -w /workspace \
  --network=none \
  node:22-bookworm bash

Questo esempio disabilita completamente l'accesso alla rete. Non è pratico per ogni flusso di lavoro, ma dimostra il punto: non affidarti soltanto allo strumento AI per definire il confine. Usa le stesse primitive di isolamento di cui ti fidi già per build e test.

Telemetria, log e ciò che lascia la macchina

L'area successiva da esaminare è la telemetria. Per qualsiasi agente AI per la programmazione, poni due domande distinte:

1. Quali prompt e informazioni di contesto del progetto vengono inviati a un fornitore di modelli?
2. Quale telemetria operativa viene raccolta dallo strumento stesso?

Sono aspetti correlati, ma non identici. La richiesta al modello può includere contesto selezionato dal codice, nomi di file, diff, output del terminale e istruzioni dell'utente. La telemetria dello strumento può includere metadati d'uso, errori, dati sulle prestazioni, eventi relativi alle funzionalità o log diagnostici.

La struttura minima di una richiesta per un compito di programmazione potrebbe essere concettualmente questa:

{
  "model": "claude-sonnet-4-6",
  "messages": [
    {
      "role": "user",
      "content": "Refactor the auth middleware to return typed errors."
    }
  ],
  "context": {
    "files": [
      {
        "path": "src/auth/middleware.ts",
        "content": "..."
      },
      {
        "path": "src/auth/errors.ts",
        "content": "..."
      }
    ],
    "terminal_output": "npm test failed in auth.middleware.spec.ts"
  }
}

I dettagli effettivi dell'implementazione variano, ma è su questa struttura che i revisori della sicurezza dovrebbero ragionare. La risorsa sensibile è spesso il contesto, non la breve istruzione dell'utente.

Una valutazione pratica dovrebbe chiedere:

• Gli sviluppatori possono vedere quali file sono inclusi nel contesto?
• È possibile escludere i percorsi sensibili?
• I prompt o le risposte vengono conservati?
• I prompt vengono utilizzati per l'addestramento?
• Come vengono gestiti il monitoraggio degli abusi e la registrazione degli eventi di sicurezza?
• Le impostazioni aziendali o dell'API possono modificare le modalità di conservazione?
• Quali log vengono archiviati localmente?
• Quali log vengono inviati a sistemi remoti?

La risposta corretta può variare tra abbonamenti personali, piani per team, piani aziendali, accesso diretto all'API e rivenditori terzi. Non dare per scontato che funzionino tutti allo stesso modo.

Instradamento dei modelli e confini del fornitore

L'instradamento dei modelli è un altro tema poco discusso. Nell'attuale gamma Claude, i team possono scegliere tra Opus 4.8, Sonnet 4.6, Haiku 4.5 e Fable 5 con una finestra di contesto di 1M, a seconda dell'interfaccia del prodotto e della disponibilità. Per i flussi di lavoro di sviluppo, i modelli della classe Sonnet offrono spesso il giusto equilibrio tra ragionamento, latenza e costi; Opus è utile per sessioni più complesse di progettazione architetturale o debugging; Haiku può essere utile per attività rapide e circoscritte; i modelli con contesto esteso cambiano i criteri di valutazione per repository di grandi dimensioni e documenti di progettazione corposi.

Ma chi si occupa degli acquisti ha bisogno di una domanda più precisa di «qual è il modello migliore?».

Deve sapere dove vengono inviati i prompt.

Una checklist per l'instradamento dei modelli dovrebbe includere:

• Quali ID dei modelli sono consentiti?
• Quale confine geografico o contrattuale si applica?
• Lo strumento può instradare le richieste verso modelli di fallback?
• Gli utenti possono cambiare il modello selezionato?
• Sono consentiti modelli beta o in anteprima?
• L'endpoint API è diretto, passa attraverso un proxy o viene intermediato da un altro fornitore?
• Prima della chiamata al modello vengono eseguite operazioni di registrazione dei log, caching o trasformazione dei prompt?

Per i team che utilizzano direttamente l'API Claude, centralizzare l'accesso tramite un gateway interno può essere utile:

from anthropic import Anthropic

client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1200,
    messages=[
        {
            "role": "user",
            "content": "Review this patch for unsafe database migrations:\n\n..."
        }
    ],
)

print(message.content[0].text)

Questo schema di accesso diretto all'API è più facile da valutare rispetto a una proliferazione di strumenti desktop non gestiti, ma comporta un onere specifico: occorre implementare autonomamente autenticazione, registrazione dei log, classificazione dei dati, limitazione della frequenza delle richieste e applicazione delle policy. Alcune organizzazioni utilizzano un proxy interno che rifiuta i modelli non consentiti o blocca i repository soggetti a restrizioni.

Una policy indicativa potrebbe essere così:

{
  "allowed_models": [
    "claude-sonnet-4-6",
    "claude-haiku-4-5"
  ],
  "blocked_models": [
    "preview-*"
  ],
  "repo_rules": {
    "public": ["claude-sonnet-4-6", "claude-haiku-4-5"],
    "internal": ["claude-sonnet-4-6"],
    "restricted": []
  }
}

Non è particolarmente entusiasmante, ma è il tipo di controllo che rende concreta una valutazione della sicurezza.

La conservazione dei dati è una questione contrattuale, non di impressioni

Un errore comune è discutere della sicurezza degli strumenti di IA come se fosse soltanto una questione tecnica. La conservazione dei dati riguarda anche il contratto e la configurazione dell'account.

Per Claude Code e i relativi flussi di lavoro Claude, i team di sviluppo dovrebbero verificare le condizioni applicabili al proprio specifico tipo di account e alla modalità di distribuzione adottata. Non riprendere una risposta riferita a un diverso livello di prodotto e non presumere che un'impostazione per utenti privati si applichi a un'integrazione aziendale.

Nelle riunioni di valutazione, preferisco suddividere le domande sulla conservazione in quattro categorie:

La categoria degli artefatti locali è facile da trascurare. Anche se la policy del fornitore è accettabile, una trascrizione locale contenente codice proprietario può comunque rappresentare un problema se finisce in una cartella sincronizzata, in un backup non crittografato o in un pacchetto di dati per l'assistenza.

In pratica, consiglio ai team di documentare una semplice regola di gestione: le trascrizioni delle sessioni di programmazione con l'IA sono artefatti di sviluppo e assumono il livello di sensibilità del file più sensibile incluso nella sessione.

Controlli delle policy interne che funzionano davvero

Le migliori policy per gli strumenti di IA sono abbastanza brevi da essere ricordate dagli sviluppatori e abbastanza specifiche da poter essere applicate dal team di sicurezza.

Una policy praticabile per Claude Code in un'organizzazione di sviluppo di medie dimensioni potrebbe includere:

• Usare solo tipi di account approvati
• Non usare lo strumento nei repository soggetti a restrizioni senza una deroga
• Non inserire nei prompt segreti, credenziali, dati di produzione o dati dei clienti
• Avviare lo strumento solo dalla directory radice del repository previsto
• Richiedere l'approvazione per i comandi shell che modificano file, installano pacchetti, effettuano chiamate di rete o interagiscono con sistemi di distribuzione
• Usare solo i modelli presenti nell'elenco approvato
• Archiviare le trascrizioni in base alla classificazione del repository
• Segnalare comportamenti imprevisti dello strumento tramite il canale di segnalazione del team di sicurezza

Questa policy dovrebbe essere affiancata da controlli tecnici. Alcuni esempi:

# Block accidental secret exposure before commits
git secrets --scan
gitleaks detect --source .

E un file di esclusione a livello di progetto per il contesto dell'IA, se la catena di strumenti lo supporta:

.env
.env.*
*.pem
*.key
secrets/
credentials/
customer_exports/
prod_dumps/
incident_notes/

I file di esclusione non bastano da soli. Sono misure di protezione, non un programma di governance dei dati. Tuttavia, riducono il numero di errori comuni che si trasformano in incidenti di sicurezza.

Per i team che adottano Claude Code come standard, manterrei anche, sotto controllo di versione, un AI_USAGE.md vicino alla directory radice del repository:

# AI Tool Policy

Classification: internal

Allowed:
- Use Claude Code for tests, refactors, local debugging, and documentation.
- Include source files from this repository.

Not allowed:
- Do not paste customer data.
- Do not include `.env` files, credentials, or production logs.
- Do not ask the agent to run deployment commands.

Approved models:
- claude-sonnet-4-6
- claude-haiku-4-5

Gli sviluppatori hanno bisogno di policy disponibili dove lavorano, non soltanto in una wiki sulla conformità.

L'accusa di una backdoor va tenuta separata

Il timore relativo a una backdoor riportato nelle notizie è l'aspetto della vicenda Alibaba che attira maggiormente l'attenzione, ma è anche quello più facile da gestire male.

Una backdoor è un'affermazione tecnica specifica. Implica un accesso nascosto intenzionale, un comportamento non autorizzato o un canale di controllo occulto. Servono quindi prove: comportamenti riproducibili, tracce di rete, analisi dei binari, log, revisione del codice sorgente o un rapporto credibile su un incidente, con dettagli sufficienti per valutarlo. In loro assenza, resta un'accusa o una segnalazione, non un riscontro confermato.

I team di sicurezza dovrebbero comunque reagire razionalmente. Un'azienda può sospendere l'uso di uno strumento mentre indaga su un'accusa, soprattutto se lo strumento ha ampio accesso al codice sorgente. Non è panico: è normale gestione del rischio.

L'approccio corretto è:

• Non affermare che Claude Code abbia una backdoor confermata, a meno che le prove non lo dimostrino.
• Non liquidare il timore soltanto perché non è confermato.
• Valutare lo strumento sulla base di controlli verificabili.
• Decidere se una restrizione temporanea sia giustificata nel proprio ambiente.
• Rivalutare la decisione man mano che emergono fatti più solidi, risposte dei fornitori e risultati dei test interni.

Questa è una posizione intermedia matura.

Cosa succede davvero quando i team saltano la valutazione

All'inizio, il problema raramente appare drammatico. Sembra una semplice comodità.

Un team usa un agente su un repository del frontend rivolto al pubblico. Un altro lo usa su un servizio con contratti API interni. Qualcuno incolla una traccia dello stack proveniente dalla produzione. Qualcun altro gli chiede di riassumere un documento locale su un incidente. Uno sviluppatore senior lo avvia dalla directory radice di un monorepo perché vuole un contesto che comprenda più servizi. Nessuno sta cercando di divulgare dati; il flusso di lavoro semplicemente non ha confini.

Poi l'ufficio acquisti chiede quali repository siano stati utilizzati con quali strumenti, e nessuno sa rispondere.

Questo è il vero rischio dietro il presunto divieto di Alibaba: non che ogni agente di programmazione basato sull'IA sia segretamente malevolo, ma che le organizzazioni adottino strumenti di sviluppo agentici più rapidamente di quanto riescano a monitorarli e governarli.

Claude Code è prezioso proprio perché opera dove lavorano gli sviluppatori. Può accelerare la scrittura dei test, l'esplorazione della base di codice, la pianificazione delle migrazioni e i refactoring tediosi. Ma la stessa vicinanza che lo rende utile impone di trattarlo come parte dell'insieme di strumenti e processi di sviluppo da sottoporre a controllo.

Indicazioni pratiche

Considera il presunto divieto di Alibaba come un motivo per rafforzare il tuo processo di valutazione, non come prova di una backdoor confermata in Claude Code.

Prima di approvare Claude Code o qualsiasi strumento analogo di programmazione agentica, valuta:

• Accesso al codice: quali repository, file e artefatti locali può vedere lo strumento
• Permessi dell'agente: se può eseguire comandi, modificare file, installare pacchetti o accedere alle reti
• Telemetria: quali prompt, risposte, metadati e dati diagnostici vengono raccolti
• Instradamento dei modelli: quali modelli Claude sono consentiti e se esiste un instradamento di fallback
• Conservazione dei dati: come vengono archiviati contenuti dei prompt, output, metadati e log locali
• Controlli delle policy: come vengono applicate la classificazione dei repository e le indicazioni per gli sviluppatori

Per la maggior parte dei team, l'obiettivo non dovrebbe essere un sì o un no indiscriminato. È preferibile puntare a un'adozione controllata: account approvati, modelli approvati, classificazioni chiare dei repository, isolamento locale dove necessario e regole scritte che gli sviluppatori possano seguire senza interrompere il lavoro.

La presunta presenza di una backdoor rientra nella categoria «indagare e verificare». Le pratiche di sicurezza correlate rientrano nella categoria «agire subito».