Microsoft: non eseguire OpenClaw su normali computer da lavoro

Il 19 febbraio 2026 il Microsoft Defender Security Research Team ha pubblicato un post intitolato "Eseguire OpenClaw in sicurezza: identità, isolamento e rischio di runtime", e al suo interno ha formulato una raccomandazione che l'Orca AI Incident Archive non registra per nessun'altra voce: OpenClaw "dovrebbe essere trattato come esecuzione di codice non attendibile con credenziali persistenti" e "Non è appropriato eseguirlo su una workstation personale o aziendale standard." OpenClaw è un runtime di agenti self-hosted — l'utente lo installa sulla propria macchina, gli concede account e token e gli consente di installare skill da un registro pubblico e di agire su testo che legge da qualsiasi fonte. La tesi di Microsoft è architetturale, non un bug report: il runtime sposta il punto di esecuzione dal codice applicativo statico al contenuto fornito in fase di esecuzione, e i controlli su identità, gestione degli input e privilegi non si sono spostati di conseguenza. Il post non nomina alcun CVE, campagna o vittima e non registra alcuna compromissione. Il record completo si trova nell'Orca AI Incident Archive, dove è classificato come voce di policy fondamentale con grado di confidenza A e nessun danno reale registrato.

Quello che il post diceva, e quello che non diceva

Il post richiede circa dodici minuti di lettura e non contiene alcun apparato di divulgazione: nessun identificatore CVE, nessun intervallo di versioni interessate, nessuna build corretta, nessun indicatore di compromissione legato a un'implementazione reale. Microsoft Defender Security Research elenca Idan Hen come collaboratore. Quello che contiene invece è un modello di minaccia e una regola di implementazione, motivo per cui l'archivio lo classifica come record di policy anziché come incidente — informazioni sulla gravità, grado di confidenza A, nessun danno reale registrato, una data con precisione al giorno.

Il ragionamento è compresso in un unico paragrafo iniziale. OpenClaw «include controlli di sicurezza integrati limitati», scrive il team, perché il runtime «può acquisire testo non attendibile, scaricare ed eseguire skill (ovvero codice) da fonti esterne e compiere azioni usando le credenziali assegnategli». La conseguenza è affermata nello stesso passaggio: ciò «sposta effettivamente il confine di esecuzione dal codice statico dell'applicazione a contenuti forniti dinamicamente e capacità di terze parti, senza controlli equivalenti su identità, gestione degli input o definizione dell'ambito dei privilegi».

Seguono tre rischi, e vale la pena leggerli nelle parole stesse di Microsoft perché gran parte della copertura che ne è seguita li ha parafrasati rendendoli vaghi:

• "Le credenziali e i dati accessibili potrebbero essere esposti o esfiltrati."

• "Lo stato persistente o la 'memoria' dell'agente può essere modificato, facendogli seguire nel tempo istruzioni fornite dall'attaccante."

• "L'ambiente host può essere compromesso se l'agente viene indotto a recuperare ed eseguire codice malevolo."

Nota ciò che manca da quell'elenco. Non c'è alcuna vulnerabilità sfruttata, alcuna funzione vulnerabile, alcuna patch da distribuire. Microsoft non sta dicendo che OpenClaw ha un bug di sicurezza; sta dicendo che un programma che decide cosa fare in fase di esecuzione, in base al testo che ha recuperato, usando le credenziali che gli sono state fornite, non può essere reso sicuro tramite configurazione su una macchina che contiene anche il vero lavoro dell'operatore. La raccomandazione che ne segue è di conseguenza schietta: per la maggior parte degli ambienti, «la decisione appropriata potrebbe essere quella di non distribuirlo».

Due catene di fornitura, un unico ciclo di esecuzione

Il meccanismo descritto nel post è la convergenza di quelle che chiama le due catene di fornitura di un agente self-hosted: codice non attendibile, ovvero competenze ed estensioni, e istruzioni non attendibili, ovvero testo esterno. La maggior parte del software ha l'una o l'altra. Un gestore di pacchetti scarica codice non attendibile ma non legge Internet e non decide cosa eseguire dopo; un modello di chat legge testo non attendibile ma non può installare nulla. OpenClaw fa entrambe le cose in un unico ciclo, e il ciclo viene eseguito con l'identità dell'utente stesso.

"Installare una skill equivale sostanzialmente a installare codice con privilegi", afferma il post. Le skill vengono "spesso scoperte e installate tramite ClawHub, il registro pubblico delle skill per OpenClaw" e, nelle distribuzioni permissive, "il runtime può essere autorizzato a eseguire il flusso di installazione senza approvazione umana". La seconda catena di fornitura è gestita da Moltbook, descritto dal post come una piattaforma e un livello di identità incentrati sugli agenti, dove gli agenti pubblicano, leggono e si autenticano tramite API — e quindi, secondo la sua formulazione, "un flusso ad alto volume di contenuti influenzabili dagli attaccanti che gli agenti assimilano a intervalli programmati". La compressione è il punto: "Un singolo post malevolo può quindi raggiungere più agenti".

Il post suddivide poi il confine di fiducia in tre componenti, che è la parte più riutilizzabile dell'intero documento: identità, ovvero i token che l'agente usa per svolgere il lavoro attraverso API SaaS, repository, posta e piani di controllo cloud; esecuzione, ovvero gli strumenti che può eseguire e che modificano lo stato, inclusi file, shell, infrastruttura e messaggi; e persistenza, ovvero i modi in cui può mantenere le modifiche tra un'esecuzione e l'altra, tramite attività, configurazione e pianificazioni. Un agente che possiede tutte e tre non è un'applicazione con un prompt di autorizzazione. È un principal.

L'abilità avvelenata, in cinque fasi

Microsoft fornisce una catena di compromissione esemplificata, etichettata come scenario rappresentativo anziché come resoconto di un caso, e vale la pena percorrerla perché i suoi ultimi due passaggi sono quelli che aggirano le normali difese degli endpoint. Il post la introduce con un'affermazione sul mondo esterno — «Il reporting pubblico ha documentato la comparsa di skill malevole in registri pubblici», e in alcuni casi «il contenuto del registro è stato malware bell'e pronto confezionato come skill, anziché un sottile sosia» — ma non nomina alcuna voce di registro, campagna, attore o vittima, quindi la catena vale come argomento di plausibilità, non come ricostruzione.

• Distribuzione. Un attaccante pubblica una skill malevola su ClawHub, a volte mascherata da utilità e a volte apertamente malevola, e la promuove attraverso i canali della community; altre volte viene trovata organicamente tramite la ricerca e installata perché l'installazione è a basso attrito.

• Installazione. Uno sviluppatore o l'agente stesso avvia l'installazione perché la competenza sembra pertinente all'attività. In una distribuzione permissiva, nessun umano la approva.

• Accesso allo stato. L'attaccante punta a token, credenziali memorizzate nella cache, dati di configurazione e trascrizioni, oltre ai canali di istruzioni persistenti — file di attività, azioni pianificate, configurazione degli agenti — che guidano le esecuzioni future.

• Riuso dei privilegi. Con materiale di identità valido, l'attaccante agisce tramite API e strumenti standard, e l'attività "spesso assomiglia a un'automazione legittima, a meno che non siano in atto solidi controlli di monitoraggio e registrazione".

• Persistenza tramite configurazione. Ciò che rimane è una modifica duratura della configurazione: "nuovi consensi OAuth, esecuzioni pianificate, attività degli agenti modificate o strumenti che restano approvati in modo permanente".

Il quinto passaggio contiene la frase più incisiva del post, e quella che spiega meglio perché si tratti di un problema di policy anziché di malware: «L'obiettivo riguarda meno il dispiegamento di malware e più il mantenimento del controllo a lungo termine sul percorso di automazione». Gli strumenti di sicurezza che cercano un payload non troveranno nulla. Quello che dovrebbero intercettare è una concessione di consenso, una voce cron o uno strumento che è stato silenziosamente lasciato approvato.

La postura minima che Microsoft accetterà

Microsoft non si limita a dire al lettore «non farlo». Fornisce una soglia minima per le organizzazioni che decidono comunque di valutare il runtime, e tale soglia è più rigorosa di una sandbox. L'ambiente dovrebbe essere «una macchina virtuale dedicata o un dispositivo fisico separato che non viene usato per il lavoro quotidiano», e dovrebbe essere trattato come usa e getta. Le credenziali dovrebbero essere create esclusivamente per lo scopo dell'agente, non privilegiate e ruotate sul presupposto che siano già compromesse. Dovrebbero essere raggiungibili solo dati non sensibili. Le istruzioni salvate e lo stato dell'agente dovrebbero essere riesaminati regolarmente per individuare regole persistenti inattese, fonti considerate attendibili di recente o comportamenti che cambiano tra un'esecuzione e l'altra. E una ricostruzione dovrebbe essere un controllo atteso anziché un'emergenza: reinstallare regolarmente e ricostruire immediatamente in caso di comportamento anomalo.

Un dettaglio nel post è più utile di quanto la sua lunghezza suggerisca. Il backup di .openclaw/workspace/ cattura lo stato di lavoro dell'agente senza includere credenziali; il backup dell'intera directory .openclaw/ è più semplice da ripristinare ma cattura anche token e credenziali, e il post avverte che ciò potrebbe essere inappropriato se si sospetta che le credenziali siano compromesse. Un team che esegue il backup dell'intera directory e lo chiama disaster recovery ha archiviato proprio ciò che l'attaccante voleva.

La guida è anche una mappa del prodotto.

La seconda metà del post associa ogni controllo consigliato a un prodotto Microsoft: Microsoft Entra ID per il privilegio minimo e l'accesso condizionale sulle identità degli agenti, Microsoft Defender for Cloud Apps App Governance per l'inventario OAuth e la deriva dei consensi, Microsoft Defender for Endpoint per l'host dell'agente, Microsoft Defender XDR per la correlazione, Microsoft Purview per la prevenzione della perdita di dati sugli endpoint, Microsoft Defender for Cloud per l'egress di rete e Microsoft Sentinel dove servono conservazione più lunga o automazione. È una pratica ordinaria per un blog sulla sicurezza di un fornitore ed è anche opportuno dirlo chiaramente: il documento che raccomanda di contenere un runtime di agenti di terze parti è pubblicato da un'azienda che vende il contenimento.

Il contenuto di hunting è la parte che sopravvive a quella impostazione, perché è specifico. Il post fornisce query KQL sulle tabelle di Defender XDR — DeviceProcessEvents, CloudProcessEvents, DeviceFileEvents, DeviceNetworkEvents e OAuthAppInfo — che cercano righe di comando dei processi e nomi di file contenenti "openclaw", "moltbot" o "clawdbot", per clawhub install invocazioni con slug di skill rari, per continui cambiamenti nelle cartelle delle estensioni sugli endpoint degli sviluppatori, per nuove applicazioni OAuth con privilegi elevati, per servizi in ascolto aperti da processi agente e per runtime degli agenti che avviano cmd.exe, powershell.exe, pwsh.exe, bash, sh, curl o wget. Qualunque cosa si pensi della mappatura del prodotto, quelle query sono eseguibili da qualsiasi cliente Defender XDR il giorno della pubblicazione e non presuppongono alcuna conoscenza preliminare di quali host eseguano il runtime.

Che cosa è stabilito e che cosa non lo è

Stabilito e corroborato: Microsoft ha pubblicato il post il 19 febbraio 2026, e le citazioni sopra provengono da esso. Cybernews ha riportato l'avvertimento il 23 febbraio 2026 e TechRadar il 24 febbraio 2026, ripetendo entrambi le due frasi centrali e le indicazioni sull'isolamento anziché verificarle. Ricerche ripetute non hanno fatto emergere copertura su The Register, BleepingComputer, Wired o TechCrunch, quindi l'ondata mediatica attorno a questo post è stata piccola e derivativa; nessuna parte indipendente ha pubblicato una verifica dell'affermazione architetturale di Microsoft, e la corroborazione disponibile conferma ciò che Microsoft ha detto, non se sia corretto.

Il relay ha anche introdotto un errore che vale la pena segnalare, perché mostra quanto rapidamente un avvertimento di un fornitore su uno strumento di terze parti si trasformi in un avvertimento del fornitore su un proprio strumento. Il rapporto di Cybernews si apre descrivendo OpenClaw come «l'assistente AI di Microsoft»; non lo è. OpenClaw è un runtime self-hosted che i ricercatori di Microsoft Defender hanno esaminato, e il post stesso traccia la distinzione in termini strutturali, contrapponendo i runtime self-hosted — in cui «sei tu il responsabile del raggio d'impatto» e host, plugin e stato locale rientrano tutti nel perimetro di fiducia — agli assistenti gestiti e alle piattaforme di agenti, in cui il runtime e gli aggiornamenti sono gestiti centralmente e i controlli si concentrano sugli ambiti di identità, sulla governance dei connettori e sui confini dei dati.

Non è dimostrato: che una qualsiasi organizzazione specifica sia stata compromessa nel modo descritto dal post. Microsoft sostiene che resoconti pubblici abbiano documentato skill malevole in registri pubblici, ma il post non allega alcun nome di campagna, alcun conteggio, alcuna data e alcuna vittima, e pertanto questo elemento non comporta alcun danno reale. Né la raccomandazione è vincolante. Nessun regolatore l'ha emessa, nessun ente di standardizzazione l'ha adottata, e nulla nella documentazione mostra che un cliente, un revisore o un assicuratore la consideri un requisito. È l'opinione di un fornitore su come i propri clienti dovrebbero trattare uno strumento che non controlla — insolitamente categorica e non coercibile.

Ciò che il post cambia davvero è la forma della domanda a cui un team di sicurezza deve rispondere. Prima del 19 febbraio 2026, la decisione di eseguire OpenClaw su un portatile di lavoro poteva essere considerata una questione di configurazione e approvazione del pilot. Dopo, l'argomentazione deve essere sostenuta rispetto a un documento che afferma che è il design stesso del runtime, non le sue impostazioni, a mettere a rischio la macchina — e che non offre alcuna versione a cui aggiornare, alcuna patch da applicare e alcuna correzione nella roadmap. Il suo rimedio è un modello di distribuzione: isolare il runtime, limitare ciò che può raggiungere, monitorarlo continuamente ed essere pronti a ricostruire senza indugio.