Minacce OpenClaw: valutazione dei rischi e come gestire la “shadow AI”

Tutti hanno probabilmente sentito parlare di OpenClaw, precedentemente noto come “Clawdbot” o “Moltbot”, l’assistente IA open source che può essere distribuito in una macchina in locale. Si collega alle famose piattaforme di chat come WhatsApp, Telegram, Signal, Discord e Slack, che gli consente di accettare comandi dal proprietario e spostarsi in città sul file system locale. Ha accesso al calendario, all’e-mail e al browser del proprietario e può persino eseguire comandi del sistema operativo tramite la shell.

Dal punto di vista della sicurezza, quella descrizione da sola dovrebbe essere sufficiente per dare una scossa. Ma quando le persone iniziano a provare a utilizzarlo per il lavoro in un ambiente aziendale, l’ansia si trasforma rapidamente nella convinzione di un caos imminente. Alcuni esperti hanno già soprannominato OpenClaw la più grande minaccia interna del 2026. I problemi con OpenClaw coprono l’intero spettro dei rischi evidenziati nella recente OWASP Top 10 for Agentic Applications.

OpenClaw consente di collegare qualsiasi LLM locale o basato su cloud e l’utilizzo di un’ampia gamma di integrazioni con servizi aggiuntivi. Il fulcro è un gateway che accetta comandi tramite app di chat o un’interfaccia utente Web per instradarli agli agenti di intelligenza artificiale appropriati. La prima iterazione, soprannominata Clawdbot, è stata rilasciata a novembre 2025; a gennaio 2026 era diventato virale e portava con sé un mucchio di grattacapi relativi alla sicurezza. In una sola settimana sono state rivelate diverse vulnerabilità critiche, competenze dannose sono emerse nella directory delle competenze e sono stati divulgati segreti da Moltbook (essenzialmente “Reddit for bots”). Per finire, Anthropic ha richiesto il marchio per rinominare il progetto per evitare di violare “Claude”, e il nome dell’account X del progetto è stato violato per sventare criptovalute.

Problemi noti di OpenClaw

Sebbene lo sviluppatore del progetto sembri riconoscere l’importanza della sicurezza, poiché si tratta di un progetto per hobbisti, non ci sono risorse dedicate per la gestione delle vulnerabilità o altri elementi essenziali per la sicurezza del prodotto.

Vulnerabilità di OpenClaw

Tra le vulnerabilità note di OpenClaw, la più pericolosa è la CVE-2026-25253 (CVSS 8.8). Il suo sfruttamento porta a una totale compromissione del gateway, consentendo a un utente malintenzionato di eseguire comandi arbitrari. È molto facile peggiorare le cose: se l’agente visita il sito di un utente malintenzionato o l’utente fa clic su un collegamento dannoso, il token Authenticator primario viene divulgato. Con tale token a disposizione, l’utente malintenzionato ha il controllo amministrativo completo sul gateway. Questa vulnerabilità è stata corretta nella versione 2026.1.29.

Sono state inoltre rilevate due pericolose vulnerabilità di inserimento dei comandi (CVE-2026-24763 e CVE-2026-25157).

Impostazioni predefinite e funzionalità non sicure

Numerose impostazioni predefinite e peculiarità dell’implementazione rendono un attacco al gateway una passeggiata:

• l’autenticazione è disabilitata per impostazione predefinita, quindi il gateway è accessibile da Internet.
• Il server accetta le connessioni WebSocket senza verificarne l’origine.
• Le connessioni di Localhost sono implicitamente attendibili, il che rappresenta un’emergenza in attesa di verificarsi se l’host esegue un proxy inverso.
• Diversi strumenti, inclusi alcuni pericolosi, sono accessibili in modalità Ospite.
• I parametri di configurazione critici perdono di vista la rete locale tramite messaggi broadcast mDNS.

Segreti in chiaro

La configurazione di OpenClaw, la “memoria” e i registri della chat archiviano chiavi API, password e altre credenziali per LLM e servizi di integrazione come testo normale. Si tratta di una minaccia critica, nella misura in cui le versioni degli infostealer RedLine e Lumma sono già state individuate con percorsi file OpenClaw aggiunti ai relativi elenchi di oggetti da rubare. Inoltre, l’infostealer Vidar è stato sorpreso a rubare segreti da OpenClaw.

Abilità dannose

La funzionalità di OpenClaw può essere estesa con le “competenze” disponibili nell’archivio ClawHub. Poiché chiunque può caricare una competenza, non ci è voluto molto prima che gli autori delle minacce iniziassero a “raggruppare” l’infostealer AMOS macOS nei propri caricamenti. In breve tempo il numero di competenze dannose ha raggiunto le centinaia. Ciò ha spinto gli sviluppatori a stringere rapidamente un accordo con VirusTotal per garantire che tutte le competenze caricate non vengano solo confrontate con i database di malware, ma anche sottoposte all’analisi del codice e del contenuto tramite LLM. Detto questo, gli autori sono molto chiari: non è una pallottola d’argento.

Problemi strutturali nell’agente di intelligenza artificiale di OpenClaw

Le vulnerabilità possono essere corrette e le impostazioni rafforzate, ma alcuni dei problemi di OpenClaw sono fondamentali per la progettazione. Il prodotto combina diverse funzionalità critiche che, se raccolte insieme, sono decisamente pericolose:

• OpenClaw dispone di un accesso privilegiato ai dati sensibili nel computer host e agli account personali del proprietario.
• L’assistente è particolarmente aperto ai dati non attendibili: l’agente riceve i messaggi tramite app di chat ed e-mail, naviga autonomamente nelle pagine Web e così via.
• Soffre dell’incapacità intrinseca dei LLM di separare in modo affidabile i comandi dai dati, rendendo possibile la prontezza di inserimento.
• L’agente salva le informazioni chiave e gli artefatti delle proprie attività per informare le azioni future. Ciò significa che una singola injection riuscita può avvelenare la memoria dell’agente, influenzandone il comportamento a lungo termine.
• OpenClaw ha il potere di dialogare con il mondo esterno: inviando e-mail, effettuando chiamate API e utilizzando altri metodi per esfiltrare i dati interni.

Vale la pena notare che sebbene OpenClaw sia un esempio particolarmente estremo, questo elenco di “Cinque terrificanti” è in realtà caratteristico di quasi tutti gli agenti di IA multiuso.

Rischi OpenClaw per le organizzazioni

Se un dipendente installa un agente come questo in un dispositivo aziendale e lo aggancia anche a una suite di servizi di base (si pensi a Slack e SharePoint), la combinazione di esecuzione autonoma dei comandi, ampio accesso al file system e autorizzazioni OAuth eccessive crea terreno fertile per un profondo compromesso di rete. In effetti, l’abitudine del bot di accumulare token e segreti non criptati in un unico posto è un disastro in attesa di verificarsi, anche se l’agente di intelligenza artificiale stesso non viene mai compromesso.

Inoltre, queste configurazioni violano i requisiti normativi in più paesi e settori, causando potenziali sanzioni ed errori di revisione. Gli attuali requisiti normativi, come quelli della legge UE sull’IA o del NIST AI Risk Management Framework, impongono esplicitamente un rigoroso controllo degli accessi per gli agenti di IA. L’approccio alla configurazione di OpenClaw non è chiaramente all’altezza di tali standard.

Ma il vero problema è che, anche se ai dipendenti è vietato installare questo software sui computer del lavoro, OpenClaw può comunque finire nei propri dispositivi personali. Questo crea anche rischi specifici per l’intera organizzazione:

• I dispositivi personali archiviano spesso l’accesso a sistemi aziendali come le configurazioni VPN aziendali o i token del browser per l’e-mail e gli strumenti interni. Questi possono essere hackerati per prendere piede nell’infrastruttura aziendale.
• Controllare l’agente tramite le app di chat significa che non è solo il dipendente a diventare un bersaglio per il social engineering, ma anche il relativo agente di intelligenza artificiale, vedendo diventare realtà le acquisizioni di account IA o la rappresentazione dell’utente nelle chat con i colleghi (tra le altre truffe). Anche se il lavoro viene discusso solo occasionalmente nelle chat personali, le informazioni in esse contenute sono pronte per la raccolta.
• Se un agente IA in un dispositivo personale è connesso a qualsiasi servizio aziendale (e-mail, messaggistica, archiviazione file), gli utenti malintenzionati possono manipolare l’agente per sottrarre dati e questa attività sarebbe estremamente difficile per i sistemi di monitoraggio aziendali da individuare.

Come rilevare i rootkit

A seconda delle capacità di monitoraggio e risposta del team SOC, questo può tenere traccia dei tentativi di connessione al gateway OpenClaw nei dispositivi personali o nel cloud. Inoltre, una specifica combinazione di avvisi può indicare la presenza di OpenClaw in un dispositivo aziendale:

• Cercare le directory ~/.openclaw/, ~/clawd/ o ~/.clawdbot nei computer host.
• Scansione della rete con strumenti interni, o pubblici come Shodan, per identificare le impronte digitali HTML dei pannelli di controllo di Clawdbot.
• Monitorare il traffico WebSocket sulle porte 3000 e 18789.
• Tenere d’occhio i messaggi broadcast mDNS sulla porta 5353 (in particolare openclaw-gw.tcp).
• Verificare la presenza di tentativi di autenticazione insoliti nei servizi aziendali, ad esempio nuove registrazioni di App ID, eventi OAuth Consent o stringhe User-Agent tipici di Node.js e altri user agent non standard.
• Cercare i modelli di accesso tipici della raccolta automatizzata dei dati: lettura di enormi blocchi di dati (estrazione di tutti i file o di tutte le e-mail) o scansione delle directory a intervalli fissi durante le ore di riposo.

Controllo della shadow AI

Un set di pratiche di igiene della sicurezza può ridurre efficacemente la footprint sia della shadow IT che della shadow IA, rendendo molto più difficile la distribuzione di OpenClaw in un’organizzazione:

• Utilizzare la lista consentiti a livello di host per garantire che vengano installate solo le applicazioni approvate e le integrazioni cloud. Per i prodotti che supportano l’estendibilità (ad esempio, estensioni Chrome, plug-in di VS Code o competenze di OpenClaw), implementare un elenco chiuso dei componenti aggiuntivi selezionati.
• Condurre una valutazione della sicurezza completa di qualsiasi prodotto o servizio, inclusi gli agenti di intelligenza artificiale, prima di consentire loro di collegarsi alle risorse aziendali.
• Trattare gli agenti IA rispettando gli stessi rigorosi requisiti di sicurezza applicati ai server rivolti al pubblico che elaborano dati aziendali sensibili.
• Implementare il principio del privilegio minimo per tutti gli utenti e le altre identità.
• Non concedere privilegi di amministratore senza un’esigenza aziendale critica. Richiedere a tutti gli utenti con autorizzazioni elevate di utilizzarle solo durante l’esecuzione di attività specifiche anziché utilizzare continuamente account privilegiati.
• Configurare i servizi aziendali in modo che alle integrazioni tecniche (ad esempio le app che richiedono l’accesso OAuth) vengano concesse solo autorizzazioni minime.
• Controllare periodicamente le integrazioni, i token OAuth e le autorizzazioni concesse alle app di terze parti. Esaminare la necessità di questi requisiti con i proprietari di attività commerciali, revocare in modo proattivo le autorizzazioni eccessive ed eliminare le integrazioni obsolete.

Distribuzione sicura dell’agentic AI

Se un’organizzazione consente agli agenti di IA a titolo sperimentale, ad esempio per test di sviluppo o pilota di efficienza, o se casi d’uso di IA specifici hanno ottenuto il via libera per il personale generico, dovrebbero essere implementate solide misure di monitoraggio, registrazione e controllo dell’accesso:

• Distribuire gli agenti in una subnet isolata con regole rigorose in ingresso e in uscita, limitando la comunicazione solo agli host attendibili richiesti per l’attività.
• Utilizzare token di accesso di breve durata con un ambito di privilegi strettamente limitato. Non consegnare mai token agente che concedono l’accesso a server o servizi principali dell’azienda. Idealmente, creare account di servizio dedicati per ogni singolo test.
• Isolare l’agente utilizzando strumenti e set di dati pericolosi non attinenti al suo lavoro specifico. Per le distribuzioni sperimentali, è consigliabile testare l’agente utilizzando dati puramente sintetici che imitino la struttura dei dati di produzione reali.
• Configurare la registrazione dettagliata delle azioni dell’agente. Dovrebbero essere inclusi i registri eventi, i parametri della riga di comando e gli elementi della catena di pensieri associati a ogni comando eseguito.
• Configurare SIEM per contrassegnare l’attività anomala dell’agente. In questo caso sono applicabili le stesse tecniche e regole utilizzate per rilevare gli attacchi LotL, sebbene siano necessari ulteriori sforzi per definire l’aspetto delle normali attività per un agente specifico.
• Se vengono utilizzati server MCP e competenze aggiuntive dell’agente, eseguirne la scansione con gli strumenti di protezione emergenti per queste attività, ad esempio skill-scanner, mcp-scanner o mcp-scan. In particolare per i test di OpenClaw, diverse aziende hanno già rilasciato strumenti open source per controllare la sicurezza delle proprie configurazioni.

Politiche aziendali e formazione dei dipendenti

Un divieto assoluto di tutti gli strumenti di IA è un percorso semplice ma raramente produttivo. I dipendenti di solito trovano soluzioni alternative: scacciare il problema nell’ombra, dove è ancora più difficile da controllare. È invece meglio trovare un equilibrio sensato tra produttività e sicurezza.

Attuare criteri trasparenti sull’utilizzo degli agentic AI. Definire quali categorie di dati possono essere elaborate dai servizi di IA esterni e quali sono rigorosamente vietate. I dipendenti devono capire perché qualcosa è vietato. Un “sì, ma con vincoli” è sempre meglio di un “no” generale.

Allenati con esempi reali. Gli avvisi astratti sui “rischi di dispersione” tendono a essere inutili. È meglio dimostrare come un agente con accesso all’e-mail può inoltrare messaggi riservati solo perché richiesto da un’e-mail in entrata casuale. Quando la minaccia sembra reale, cresce anche la motivazione a seguire le regole. Idealmente, i dipendenti dovrebbero completare un breve corso intensivo sulla sicurezza dell'IA.

Offri alternative sicure. Se i dipendenti hanno bisogno di un assistente IA, fornisci uno strumento approvato con gestione centralizzata, registrazione e controllo degli accessi OAuth.