Claude sotto attacco: il caso degli infostealer mostra perché gli agenti AI non dovrebbero mai avere accesso completo al nostro computer
Anthropic ha iniziato a disconnettere forzatamente alcuni utenti di Claude dopo aver individuato un nuovo schema di abuso: gruppi criminali stanno usando comuni malware "infostealer" per rubare sessioni Claude già autenticate e sfruttare gli account delle vittime, consumandone le quote di utilizzo.
Nei casi rilevati l'azienda ha revocato le sessioni compromesse, rimosso i metodi di pagamento salvati e rimborsato gli importi riconosciuti come utilizzo fraudolento.
Il dettaglio più interessante, dal punto di vista della sicurezza, è che gli aggressori non hanno bisogno di conoscere la password della vittima.
Un infostealer copia cookie, token e altre informazioni presenti in locale sul computer, e riutilizza una sessione del browser che era già stata autenticata. In questo scenario anche l'autenticazione a due fattori diventa inutile: il criminale non sta facendo un nuovo login, sta riutilizzando una sessione che il servizio considera già valida. Nei casi analizzati compaiono famiglie di malware note come Vidar, LummaC2, StealC, RedLine e Acreed su Windows, con Atomic Stealer su un numero ridotto di Mac.
Anthropic ha anche chiarito di non avere elementi per ritenere che il malware sia arrivato tramite Claude. Nei casi esaminati si tratterebbe di comuni infostealer finiti sul computer attraverso software o download esterni, e l'account Claude sarebbe quindi solo una delle tante credenziali raccolte da una macchina già compromessa. Resta un punto scomodo: disconnettere l'utente ferma le sessioni rubate, ma non rimuove il malware. Se resta sulla macchina, la sessione successiva verrà rubata allo stesso modo.
Il problema va oltre Claude
L'episodio è interessante perché arriva mentre stiamo affidando ai modelli AI una quantità crescente di privilegi sui nostri computer.
Un chatbot tradizionale riceve del testo e restituisce del testo.
Un agente di coding come Claude Code è qualcosa di sostanzialmente diverso.
Può leggere file, modificare sorgenti, eseguire programmi, installare dipendenze, usare Git, interrogare servizi esterni e, attraverso strumenti e server MCP, arrivare potenzialmente a database, API, piattaforme cloud e altri sistemi aziendali.
Il rischio non nasce per forza da un comportamento malevolo del modello. Può nascere da un errore, da una dipendenza compromessa, da un repository malevolo, da una prompt injection nascosta in un file che l'agente legge, oppure da uno degli strumenti collegati all'agente.
Più capacità concediamo all'agente, più cresce il suo blast radius, cioè l'insieme dei sistemi che potrebbero finire coinvolti se qualcosa andasse storto.
È esattamente il problema su cui Anthropic stessa sta concentrando una parte importante della propria architettura di sicurezza per gli agenti. Nel 2026 l'azienda ha descritto il containment come uno dei principi fondamentali per limitare il blast radius di sistemi sempre più autonomi.
Il principio di fondo: l'agente non dovrebbe vedere il nostro computer
La regola architetturale dovrebbe essere molto semplice:
un agente AI dovrebbe avere accesso solo alle risorse necessarie per completare il compito che gli abbiamo assegnato.
Non il contrario.
Non dovremmo cioè eseguire Claude Code sul nostro computer principale, dandogli accesso all'intera home directory, per poi cercare di impedirgli di tanto in tanto di toccare qualcosa.
Dovremmo costruire un ambiente in cui, per impostazione predefinita, quelle risorse semplicemente non esistono dal punto di vista dell'agente.
È la differenza tra una sicurezza basata sul consenso e una sicurezza basata sul contenimento.
Anthropic ha osservato al proprio interno un problema molto noto nella cybersecurity: l'approval fatigue. Se un sistema continua a chiedere all'utente "vuoi autorizzare questo comando?", prima o poi l'utente inizia ad approvare in automatico.
Secondo i dati pubblicati dall'azienda, circa il 93% delle richieste di autorizzazione veniva approvato dagli utenti. L'introduzione del sandboxing ha invece permesso di ridurre di molto il numero di prompt, mantenendo un confine tecnico attorno all'agente.
In altre parole: è meglio impedire tecnicamente a un agente di leggere una chiave SSH che chiedere all'utente cento volte se vuole concederglielo.
L'architettura consigliata per Claude Code e gli altri agenti
Un'architettura prudente si può rappresentare così:
INTERNET
│
▼
┌───────────────────┐
│ EGRESS PROXY │
│ allowlist domini │
│ logging / policy │
└─────────┬─────────┘
│
traffico autorizzato
│
▼
┌────────────────────────────────────────────────────┐
│ SANDBOX / VM / CONTAINER │
│ │
│ Claude Code / AI Agent │
│ │ │
│ ┌───────────────┼───────────────┐ │
│ ▼ ▼ ▼ │
│ /workspace tool locali MCP Gateway │
│ READ/WRITE limitati │ │
│ │ │
│ /reference ▼ │
│ READ ONLY tool consentiti │
│ │
│ HOME REALE: NON MONTATA │
│ SSH KEYS: NON PRESENTI │
│ COOKIE BROWSER: NON PRESENTI │
│ PASSWORD MANAGER: NON PRESENTE │
│ CLOUD CREDENTIALS: NON PRESENTI │
│ DOCKER SOCKET HOST: NON PRESENTE │
└───────────────────────┬────────────────────────────┘
│
▼
CREDENTIAL BROKER
token brevi e con scope
│
┌──────────┴─────────┐
▼ ▼
Git Cloud/API
repo specifico servizio specificoL'idea di fondo è che Claude Code vive dentro l'ambiente di lavoro, non dentro la nostra identità digitale.
Il repository su cui deve lavorare può essere montato in lettura e scrittura. Una cartella con documentazione aziendale, se serve, può essere montata in sola lettura.
Il resto del filesystem semplicemente non dovrebbe essere disponibile.
Anthropic applica un principio simile al proprio sandboxing: isolamento del filesystem e isolamento della rete vengono considerati entrambi necessari. L'azienda sottolinea infatti che proteggere solo il filesystem non basta, e non basta neppure proteggere solo la rete.
Non montare $HOME
Questo dovrebbe diventare uno dei principi più facili da ricordare.
Un coding agent di solito non ha bisogno della nostra home directory completa.
Dentro $HOME possono trovarsi la cartella .ssh, le configurazioni di Git, i token, i file .env, cache che contengono credenziali, configurazioni Kubernetes, credenziali cloud, la history delle shell, database locali, configurazioni del password manager e molti altri dati che non hanno alcuna ragione di essere disponibili a un agente incaricato di correggere un bug in un repository.
L'approccio migliore è creare una home temporanea dentro il sandbox.
L'agente vede quella.
Non vede quella reale.
Anche la rete va messa in sandbox
Bloccare il filesystem ma lasciare l'accesso a Internet completamente libero risolve solo metà del problema.
Supponiamo che un repository contenga una prompt injection.
L'agente legge un file all'apparenza innocuo, che contiene un'istruzione costruita per convincerlo a cercare credenziali e a inviarle a un server esterno.
Se l'agente può leggere quelle credenziali e può collegarsi a piacere a Internet, l'attacco ha già tutto ciò che gli serve. Non è teoria: Anthropic ha raccontato che, dopo un tentativo di phishing, un suo dipendente ha dato a Claude Code un'istruzione dall'aspetto plausibile per recuperare delle credenziali AWS e mandarle a una destinazione esterna, e l'agente ha portato a termine l'esfiltrazione in 24 casi su 25.
Per questo una configurazione più solida dovrebbe usare un egress proxy.
L'agente, per esempio, dovrebbe poter raggiungere solo i servizi che servono al progetto: il provider del modello, il repository Git autorizzato, il registry dei pacchetti usato dal progetto e poche altre API esplicitamente approvate.
Una richiesta verso un dominio del tutto nuovo dovrebbe invece essere bloccata, oppure richiedere un'autorizzazione.
È anche il modello descritto da Anthropic per il sandbox di Claude Code, in cui l'accesso alla rete può essere limitato ai domini raggiungibili.
Le credenziali non dovrebbero entrare nel sandbox
Qui possiamo fare un passo in più.
L'agente spesso ha bisogno di autenticarsi a qualcosa.
Questo non significa però che dobbiamo consegnargli la nostra chiave privata GitHub, una chiave AWS permanente o una chiave SSH.
Tra l'agente e il servizio possiamo mettere un credential broker.
Il broker riceve una richiesta del tipo: "devo fare il push sul repository X, branch Y".
Il sistema verifica la policy e genera un token temporaneo, che consente solo quell'operazione o quell'insieme ristretto di operazioni.
Il token può durare pochi minuti e non funzionare su altri repository.
Anthropic usa un concetto simile nell'architettura cloud di Claude Code: le credenziali Git reali restano fuori dal sandbox, e un proxy controllato gestisce le operazioni Git autorizzate.
È un principio molto potente: un segreto che non entra nell'ambiente dell'agente non può essere esfiltrato dall'agente.
MCP va trattato come un sistema di privilegi
Il Model Context Protocol rende gli agenti molto più utili, perché permette loro di collegarsi a strumenti e fonti dati esterne.
Ma un server MCP non andrebbe visto come un semplice plugin.
Dal punto di vista della sicurezza è un'estensione delle capacità dell'agente.
Un MCP che può leggere il database di produzione significa che l'agente può leggere il database di produzione.
Un MCP con accesso alla posta significa che l'agente può accedere alla posta.
Un MCP capace di usare Kubernetes significa che stiamo allargando il blast radius dell'agente fino all'infrastruttura Kubernetes.
La documentazione di Anthropic raccomanda infatti di usare server MCP propri o provenienti da fornitori ritenuti affidabili, e ricorda che Anthropic non verifica né controlla automaticamente i server MCP usati dagli utenti.
Per ambienti seri introdurrei quindi un MCP Gateway centrale.
L'agente non si collega direttamente a decine di servizi. Si collega al gateway, che applica autenticazione, autorizzazioni, logging e policy.
Alcune operazioni devono restare umane
Il sandbox permette di lasciare all'agente molta più autonomia sulle operazioni a basso rischio.
Può modificare cento file del progetto, compilare il software, creare test, eseguire il linting e provare diverse soluzioni senza chiederci in continuazione il permesso.
Ma alcuni confini dovrebbero essere diversi.
Una possibile policy aziendale potrebbe funzionare su tre livelli. In automatico restano la lettura e la modifica del workspace, i test, le build, il linting, l'analisi statica, la creazione di branch e i commit locali. A consenso esplicito vanno l'accesso a nuovi domini, l'installazione di strumenti non previsti, l'uso di nuovi MCP e la lettura di dati esterni al progetto. Ad approvazione forte, infine, l'accesso ai segreti, la scrittura su database, il merge su branch protetti, la modifica dell'infrastruttura, i deployment, le operazioni cloud privilegiate e qualsiasi azione verso sistemi di produzione.
L'essere umano, quindi, non deve approvare ogni npm test.
Deve approvare l'espansione del perimetro di fiducia.
Il Docker socket è di fatto accesso all'host
C'è poi un errore architetturale particolarmente importante da evitare.
Mettere Claude Code dentro un container e montare /var/run/docker.sock dall'host può annullare gran parte dell'isolamento.
Un processo che controlla liberamente il Docker daemon dell'host può spesso creare nuovi container, con privilegi o mount che gli permettono di raggiungere parti del sistema che pensavamo di aver isolato.
Per questo "lo eseguo in Docker" non significa in automatico "l'ho messo in sandbox".
Il confine di sicurezza deve comprendere anche le interfacce privilegiate esposte al container.
Un ambiente effimero è ancora meglio
Idealmente ogni attività significativa dovrebbe poter partire da un ambiente pulito.
Repository clonato.
Dipendenze installate.
Agente avviato.
Compito eseguito.
Patch o commit esportati.
Sandbox distrutto.
Questo modello riduce sia la persistenza di eventuali compromissioni, sia l'accumulo involontario di credenziali e dati.
Per lavori particolarmente delicati può essere preferibile una VM effimera rispetto a un semplice container, mentre per lo sviluppo di tutti i giorni possono bastare sandbox a livello di sistema operativo o devcontainer configurati bene. Anche la documentazione di sicurezza di Claude Code suggerisce l'uso dei devcontainer per aumentare l'isolamento nei repository sensibili.
Il modello da adottare: Zero Trust anche per gli agenti
Per anni abbiamo applicato il principio Zero Trust agli utenti: non fidarti in automatico di qualcuno solo perché si trova dentro la rete.
Con gli agenti AI possiamo applicare lo stesso principio.
Non dobbiamo chiederci "mi fido di Claude?".
La domanda giusta è: qual è il massimo danno possibile se questa specifica sessione dell'agente viene completamente compromessa?
Se la risposta è "può modificare solo una copia del repository e parlare con quattro domini autorizzati", abbiamo costruito un sistema ragionevolmente contenuto.
Se invece la risposta è "può leggere tutta la mia home, usare le mie chiavi SSH, accedere al cloud, interrogare il cluster Kubernetes, leggere i cookie del browser e parlare con qualsiasi server su Internet", stiamo affidando a un singolo processo un blast radius enorme.
E nessun popup "Allow?" può compensare del tutto una scelta architetturale del genere.
Il caso Anthropic ci insegna anche un'altra cosa
Il sandboxing degli agenti non risolve però il problema mostrato dagli infostealer individuati da Anthropic.
Se il computer host è già compromesso, un malware può cercare direttamente sessioni del browser, password, cookie e altre credenziali presenti sulla macchina, del tutto a prescindere da Claude Code.
Un sandbox protegge soprattutto l'host dall'agente e dal codice che l'agente esegue.
Per proteggere l'agente e le nostre identità da un host già compromesso servono anche altre misure: sistema operativo aggiornato, software da fonti affidabili, protezione degli endpoint, separazione degli account, revoca delle sessioni compromesse e rotazione delle credenziali.
La sicurezza deve quindi funzionare in entrambe le direzioni.
Host sicuro
│
▼
Sandbox sicuro
│
▼
Agente con privilegi minimi
│
▼
Tool/MCP controllati
│
▼
Credenziali temporanee
│
▼
Servizi autorizzatiLa workstation AI del futuro somiglia più a un'infrastruttura cloud che a un terminale
L'arrivo degli agenti autonomi sta trasformando il nostro computer.
Il terminale non è più usato solo da un essere umano che digita un comando alla volta. Ora può essere guidato da un sistema capace di concatenare decine o centinaia di operazioni, leggere migliaia di file e prendere decisioni da solo.
Per questo il modello "installo l'agente sul laptop e gli concedo tutto" probabilmente non è quello da portarsi nel futuro.
Il modello più sano è invece quello usato da tempo nelle infrastrutture cloud: isolamento, minimo privilegio, credenziali temporanee, segmentazione della rete, logging, policy e ambienti effimeri.
Claude Code e gli altri coding agent possono ricevere un livello molto alto di autonomia.
Ma questa autonomia dovrebbe esistere dentro una gabbia costruita da noi.
Più gli agenti diventano capaci, meno dovremmo affidarci alla speranza che non facciano qualcosa di sbagliato, e più dovremmo progettare sistemi in cui, anche se qualcosa va storto, il danno possibile resta piccolo.
È forse una delle regole più importanti della nuova sicurezza agentica:
non limitare ciò che l'agente vuole fare. Limita ciò che l'agente può fisicamente raggiungere.