OpenClaw, perché le aziende lo vietano mentre OpenAI assume il suo creatore

Negli ultimi giorni OpenClaw è passato da curiosità da community a oggetto di discussione nei team di sicurezza enterprise, con una conseguenza pratica: in varie imprese è comparso nei blocchi delle soluzioni EDR, nelle denylist dei proxy o nelle policy interne che vietano agenti autonomi non approvati sui client aziendali. È ancora fresca, tuttavia, la notizia dell’assunzione dello sviluppatore di OpenClaw, Peter Steinberger, che passa attivamente nella fila di OpenAI.

Come si concilia questa notizia con la decisione di molte realtà aziendali che reputano OpenClaw una minaccia?

Prima di tutto: OpenAI non ha “acquisito” OpenClaw

Diverse testate parlano di “acquisto” ma la sostanza è che Steinberger entra in OpenAI, mentre OpenClaw resta un progetto open source, la cui governance è spostata verso una fondazione, che ne proseguirà lo sviluppo e il supporto.

In ambito enterprise ciò che conta è la catena di fiducia (chi decide roadmap, distribuzione, firme dei rilasci, policy di telemetria, processo di disclosure). Anche se il codice rimane aperto, il “centro di gravità” percepito cambia. Ma non è per questo che in tanti hanno deciso per il ban di OpenClaw.

OpenClaw non è un “chatbot”: è un agente con canali, strumenti e capacità d’azione

OpenClaw è descritto come un assistente AI che “fa davvero le cose”: inbox, email, calendario, check-in voli, e così via, interfacciandosi con l’utente tramite i canali di messaggistica e le app che usa abitualmente. WhatsApp e Telegram compresi.

Dal repository ufficiale emergono riferimenti ai componenti tipici di una piattaforma agentica: gateway, sessioni, routing multi-agente, integrazioni con canali (Slack, Discord, Telegram, WhatsApp, ecc.), e soprattutto un set di tools che possono includere esecuzione comandi, accesso file, automazioni e connettori.

Per un team di sicurezza, questo significa che OpenClaw non è “solo software”: è un operatore che interagisce con account e servizi. E un operatore automatizzato ha un profilo di rischio simile a quello di:

• RPA (Robotic Process Automation) con privilegi estesi.
• Bot con accesso a Slack/Discord e ad altri canali.
• Client che gestisce credenziali e token.
• Esecutore di azioni (API e/o automazioni locali).

L’incidente che ha fatto scattare l’allarme: prompt injection porta a installazione non autorizzata

Il fattore che ha accelerato i divieti è anche reputazionale, ma nasce da un fatto tecnico concreto: un attacco di prompt injection su un workflow basato su Claude (tramite Cline) ha permesso a un attaccante di far installare OpenClaw su macchine degli utenti.

Cline è un agente AI per il coding che usa Claude per decidere azioni da eseguire sul sistema. Inserendo istruzioni malevole nel contesto, l’agente è stato indotto a eseguire comandi non previsti, nello specifico l’installazione automatica del software OpenClaw sui computer degli utenti.

La prompt injection in un chatbot “solo testo” è fastidiosa; in un agente dotato di abilità operative come OpenClaw è un potenziale attacco RCE (remote code execution) indiretto: l’input controllato dall’attaccante può far scattare una catena di attività che:

• legge file locali o repository;
• usa token di sessione;
• invia richieste verso servizi interni;
• automatizza azioni su account con privilegi.

I punti tecnici che spingono al ban in azienda

OpenClaw, per fare ciò che promette, deve autenticarsi: email, calendari, chat, servizi vari. In azienda è indispensabili chiedersi dove sono conservati token/refresh token, come sono cifrati a riposo, come si gestiscono rotazione e revoca, se esista isolamento per workspace/utente, se le “skills” possano leggere segreti.

Uno strumento come OpenClaw mette in evidenza molteplici criticità su credenziali e accesso ai servizi connessi: per un’impresa, finché non esistono controlli formali e implementazioni verificabili, la scelta più economica è vietare. In questo senso, Cloudflare ha proposto un’infrastruttura che permette di isolare OpenClaw e usarlo in modo sicuro.

L’integrazione con Slack, Discord, Telegram, WhatsApp e servizi simili introduce un rischio tipico: l’arrivo di comandi e contenuti dall’esterno, provenienti da ambienti in cui anche un attaccante può intervenire o inviare payload, cioè dati o istruzioni costruiti appositamente per sfruttare eventuali vulnerabilità.

Nel repository di OpenClaw si fa riferimento in modo esplicito a policy sui messaggi diretti (DM), a comandi per individuare configurazioni potenzialmente rischiose (come openclaw doctor, uno strumento di diagnostica che analizza le impostazioni) e alla necessità di un consenso esplicito (opt-in) per consentire la ricezione di DM pubblici in ingresso.

È un aspetto fondamentale: indica che il progetto stesso è consapevole che configurazioni pensate per essere più comode o automatiche possono, se non gestite con attenzione, trasformarsi in un punto debole dal punto di vista della sicurezza.

Le skills e le estensioni

Il valore di un agente cresce con plugin/skills. Ma ogni skill è potenzialmente:

• Codice eseguito localmente o in un runtime con accesso a segreti.
• Un connettore che parla con API aziendali.
• Un punto in cui entra codice di terze parti.

In azienda tutto ciò entra in conflitto con molteplici policy, linee guida e buone pratiche: se uno strumento come OpenClaw permette di “installare skill al volo”, molti reparti IT tendono a bloccarlo a priori. Non per rigidità, ma perché diventa impossibile gestirlo in modo sicuro.

Egress e data leakage: l’agente “vede” tanto e parla tanto

Un agente AI che gestisce posta e documenti è un concentratore di dati. Anche se non provvisto di alcuna “telemetria malevola”, il rischio è concreto.

Vi è la possibilità di invii involontari (es. allegati, snippet, riassunti) verso modelli cloud, errori di routing tra spazi di lavoro (profilo lavorativo vs profilo personale), fuoriuscita di dati attraverso log, trace e debug.

Per questo alcune aziende scelgono il blocco totale, altre consentono solo modalità “local-first”.

Le principali vulnerabilità scoperte in OpenClaw

Vale la pena ricordare come nelle ultime settimane siano stati identificati diversi bug critici in OpenClaw, molti dei quali con impatto di tipo RCE (Remote Code Execution) o compromissione completa dell’host.

• CVE-2026-25253 — RCE via token exfiltration. Permette a un attaccante remoto di ottenere accesso al gateway e eseguire codice arbitrario. Il vettore è il furto del token di autenticazione tramite WebSocket.
• CVE-2026-25157 — command injection su macOS/SSH. Input non sanitizzati permettevano esecuzione di comandi arbitrari.
• CVE-2026-24763 — command injection nella sandbox Docker. Un uso non sicuro della variabile PATH nella costruzione dei comandi consentiva la manipolazione del comando eseguito nel container.
• CVE-2025-6514 — RCE (versioni precedenti conosciute come Clawdbot). Vulnerabilità critica che portava all’esecuzione di comandi arbitrari da remoto.

Lo sviluppatore ha risolto la maggior parte delle vulnerabilità in modo piuttosto rapido. Il vero punto, tuttavia, è che OpenClaw introduce rischi strutturali che non si risolvono con una patch.

Perché l’architettura agentica di OpenClaw è il vero problema

Un sistema come OpenClaw non si limita a rispondere a prompt, ma – come osservato in precedenza – opera come un vero e proprio operatore automatico con privilegi: legge email, scrive file, utilizza API, interagisce con chat e servizi e può eseguire comandi.

Se viene compromesso, il danno non resta confinato al software, ma si estende all’identità digitale dell’utente, trasformandosi in un accesso diretto a dati, servizi e flussi operativi.

A questo si aggiunge il problema degli attacchi logici, come la prompt injection, che non sfruttano bug ma il comportamento dell’AI: messaggi costruiti ad arte possono indurre l’agente a inviare file riservati, esfiltrare informazioni o modificare istruzioni operative. Sono scenari già stati dimostrati e non sono coperti da CVE, quindi non possono essere “patchati” in senso tradizionale.

Il rischio aumenta ulteriormente perché OpenClaw gestisce credenziali di altissimo valore — API key, token OAuth, accessi a servizi come Gmail, Slack o Telegram — e sono già stati osservati casi di malware in grado di sottrarre le configurazioni dell’agente, ottenendo di fatto l’accesso a tutti gli account collegati.

Il modello a plugin (skills) introduce poi un’ulteriore superficie d’attacco: codice non verificato, possibili backdoor e accesso diretto ai segreti dell’utente.

Il punto più critico, tuttavia, è che l’agente può essere manipolato anche senza exploit: basta un’email o un contenuto costruito ad hoc per indurlo a compiere azioni malevole con i privilegi dell’utente, trasformando un semplice input in una catena operativa completa senza che venga sfruttata alcuna vulnerabilità software.

È per questo che molte aziende stanno vietando OpenClaw: perché combina accesso a dati sensibili, capacità di eseguire azioni, esposizione a input non fidati e decision making autonomo, dando origine a una nuova categoria di rischio che si può definire insider threat automatizzato. Non è più l’hacker esterno a entrare nel sistema, ma è l’agente AI stesso, manipolato, ad agire come vettore di compromissione.

La skill per OpenClaw più scaricata in assoluto conteneva malware

OpenClaw dispone di un marketplace o archivio di skills (ClawHub) che gli utenti possono usare per installare plugin e arricchire l’agente AI di nuove abilità. Il concetto è potente: installi una skill e l’agente ottiene nuove integrazioni, nuovi tool, nuove automazioni.

Il problema è ClawHub è usato come canale di distribuzione malware: skills camuffate da strumenti utili (trading crypto, riassunti YouTube, tracker wallet, ecc.) con documentazione curata e rassicurante.

In risposta, OpenClaw ha introdotto misure minime di difesa, come la richiesta di un account GitHub vecchio di almeno una settimana per pubblicare nuove skills. È un freno leggero, utile solo contro l’attaccante pigro: non è una vera verifica d’identità, né un processo di review, né una firma crittografica della supply chain.

Come confermano le analisi inviate su VirusTotal, ci sono ad oggi centinaia di skills per OpenClaw che integrano comportamenti palesemente malevoli.

Le campagne che portano all’installazione di malware veri e propri hanno condotto sui sistemi degli utenti infostealer e reverse shell per attivare il controllo remoto dei sistemi. La conseguenza pratica è immediata: sottrazione di materiali ad altissimo valore operativo. Si pensi a credenziali salvate nei browser, chiavi SSH, sessioni, wallet, file .env con API key.

È esattamente il tipo di bottino che trasforma un “tool interessante” in un rischio inaccettabile su endpoint aziendali.

Il caso simbolo: “What Would Elon Do?” e la manipolazione della popolarità

Citiamo un episodio emblematico perché combina due cose: malizia tecnica e abuso del meccanismo reputazionale.

Cisco (nel suo blog sulla sicurezza degli agenti AI) descrive il caso di una skill OpenClaw arrivata in alto nel ranking (“What Would Elon Do?”) che conteneva 9 vulnerabilità, 2 critiche, comportamento da malware (esfiltrazione silente dei dati) e uso di prompt injection per aggirare linee guida/sicurezze. Cisco evidenzia anche il punto “socio-tecnico”: la popolarità può essere fabbricata e l’hype aiuta gli attaccanti a spingere download e fiducia.

Conclusioni: perché OpenAI punta sul creatore di OpenClaw e cosa significa per la sicurezza

Il fatto che OpenAI abbia deciso di integrare nel proprio team il principale sviluppatore di OpenClaw non è una contraddizione rispetto ai rischi emersi, ma un segnale preciso della strada che l’intero settore sta imboccando. Le piattaforme di intelligenza artificiale stanno evolvendo da strumenti passivi a sistemi agentici capaci di agire nel mondo reale: leggere dati, prendere decisioni, interagire con servizi e automatizzare processi.

In questo contesto, figure che hanno già progettato architetture di agenti operativi rappresentano un asset fondamentale, perché possiedono competenze difficili da trovare e fondamentali per costruire le prossime generazioni di assistenti autonomi. Assumere lo sviluppatore di OpenClaw significa quindi acquisire know-how su orchestrazione di agenti, integrazione multi-canale, gestione dei tool e, soprattutto, su come trasformare un modello linguistico in un “sistema operativo” capace di eseguire azioni concrete.

Allo stesso tempo, però, il caso OpenClaw dimostra quanto questa evoluzione sia delicata. Le criticità emerse non sono semplicemente bug da correggere, ma limiti strutturali di una tecnologia che mette insieme autonomia decisionale, accesso ai dati e capacità operative. Proprio per questo, è plausibile che OpenAI abbia interesse a portare queste competenze “in casa” anche per rafforzare i controlli, definire standard di sicurezza più rigorosi e costruire architetture agentiche con modelli di trust, sandboxing e gestione dei permessi più maturi di quelli visti finora nei progetti community-driven.

In questo quadro, le scelte delle aziende che vietano OpenClaw diventano perfettamente coerenti. Non si tratta di una reazione ideologica verso OpenAI, ma della presa d’atto che un agente autonomo con accesso a canali, credenziali e strumenti modifica radicalmente il threat model aziendale.