Come eseguire OpenClaw in sicurezza su un VPS

Che cos’è OpenClaw e perché va messo in sicurezza per primo

OpenClaw è un agente AI self-hosted. Viene eseguito sul proprio server, si collega a un modello linguistico di grandi dimensioni e può eseguire comandi shell, controllare un browser, leggere e scrivere file e agire sui messaggi inviati dalle applicazioni di chat. Questa capacità operativa è lo scopo principale dello strumento, ma costituisce anche il rischio principale. Un agente che può eseguire qualsiasi comando è sicuro solo quanto il sistema su cui viene eseguito e quanto lo sono i limiti applicati.

Due aspetti definiscono l’impostazione di questa guida. Primo, OpenClaw è progettato per essere messo in sicurezza dall’operatore. Il suo modello di sicurezza affida all’amministratore la responsabilità di definire policy restrittive per gli strumenti, sandboxing e permessi adeguati, invece di applicare impostazioni predefinite sicure. Secondo, il progetto ha già affrontato un problema di sicurezza significativo: il National Vulnerability Database elenca 199 CVE di OpenClaw pubblicate soltanto a marzo 2026, 46 delle quali nei quattro giorni compresi tra il 4 e il 7 marzo (conteggi verificati il 13 ottobre 2026). Tra le vulnerabilità di quel mese figura un’escalation dei privilegi critica, CVE-2026-32922, con una valutazione di 9.9 su 10 e corretta nella versione 2026.3.11. Nessuno dei due aspetti implica che si debba evitare OpenClaw. Significa che non va eseguito nel modo più semplice e meno sicuro. Questa guida descrive invece l’approccio prudente. Un aspetto di questo approccio consiste nel decidere in anticipo quali operazioni l’agente può eseguire senza chiedere conferma, una scelta che Claude Code rende esplicita con le modalità di autorizzazione, dove un server davanti al quale non si è fisicamente presenti richiede un’impostazione più restrittiva rispetto al laptop che si sta controllando.

Ci sono anche aspetti positivi. OpenClaw applica già una scelta sicura: il suo gateway, il singolo processo che controlla tutto, è in ascolto per impostazione predefinita sull’indirizzo di loopback, quindi non è raggiungibile da Internet a meno che non lo si esponga intenzionalmente. Gran parte del lavoro descritto di seguito consiste nel mantenerlo in questo stato e nel limitare l’impatto nel caso qualcosa vada storto.

Assegna a OpenClaw un utente dedicato senza privilegi

Non eseguire mai un agent come root. Se OpenClaw viene eseguito come root e si verifica un problema, causato da un bug, da un'istruzione errata o da una CVE come quella descritta sopra, il danno non ha limiti. Crea un utente di sistema dedicato, senza shell di login e senza sudo, quindi esegui l'agent con quell'utente:

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

Tutto ciò che appartiene a OpenClaw risiede in /opt/openclaw, di proprietà di quell'account. Questo è il passaggio più importante. È lo stesso principio descritto in eseguire i servizi con un utente senza privilegi: l'account con cui viene eseguito un agent determina il limite dei danni che può causare.

Installare OpenClaw

OpenClaw viene distribuito come pacchetto npm. Installare quindi prima Node.js se il server non lo contiene; il progetto richiede Node 24.16 o versione successiva, oppure 26.1 o versione successiva. Installare il pacchetto globalmente. In questo modo il binario openclaw viene aggiunto al PATH per tutti gli utenti. Eseguire quindi la procedura iniziale una sola volta:

sudo npm install -g openclaw@latest --allow-scripts=openclaw
sudo -u openclaw openclaw onboard

Il flag --allow-scripts=openclaw è necessario perché npm 12 blocca per impostazione predefinita gli script di installazione dei pacchetti, mentre OpenClaw deve eseguire i propri script. Con npm 11.15 o versioni precedenti, che non dispongono di questa opzione, omettere il flag. Eseguire la procedura iniziale come utente openclaw fa sì che la configurazione dell’agente venga salvata nella relativa home directory, /opt/openclaw, e non in quella di root. Il progetto offre anche un installer curl -fsSL https://openclaw.ai/install.sh | bash che esegue la stessa installazione con un solo comando. Durante la procedura iniziale, omettere il flag --install-daemon: registrerebbe il servizio di OpenClaw, mentre l’unità systemd messa in sicurezza che verrà creata di seguito è più restrittiva.

Mantieni il gateway su loopback, dietro un firewall

Il gateway è in ascolto su 127.0.0.1 per impostazione predefinita. Lascialo su quell’indirizzo. Quasi mai è necessario pubblicare questa porta su Internet. Farlo offre a chiunque la individui un punto d’accesso remoto a un processo che esegue comandi.

Configura un firewall con criterio predefinito deny davanti al server, in modo che nulla venga esposto per errore:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Qui è necessario evitare due errori. Un firewall che protegge solo IPv4 può lasciare lo stesso servizio completamente esposto su IPv6. È proprio la lacuna del firewall IPv6 in cui molte persone incorrono. Se devi raggiungere il gateway dal laptop, non aprire la porta. Usa una VPN o un tunnel SSH, così l’agent non sarà mai in ascolto su Internet aperta.

Isola i suoi secret

OpenClaw richiede una API key per il modello linguistico a cui lo colleghi. Questa chiave può generare costi e, tramite l’agente, agire per tuo conto. Trattala quindi come una password. Non inserirla nel file dell’unità e non conservarla in alcun repository. Inseriscila in un file leggibile soltanto dall’utente OpenClaw:

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

L’unità systemd carica il file con EnvironmentFile. In questo modo la chiave raggiunge il processo senza comparire nella riga di comando, nei log o nella cronologia della shell. Lo stesso criterio vale per ogni secret presente sul server: un intervento di hardening su Vaultwarden self-hosted riguarda il token amministrativo e il file di backup, non la crittografia, perché sono i permessi dei file a determinare chi può leggere un secret quando è memorizzato.

Esegui il servizio come unità systemd con misure di sicurezza avanzate

Eseguire l’agent tramite systemd consente di ottenere riavvii automatici, log ordinati tramite journalctl e, soprattutto, diverse opzioni di sandboxing a livello di kernel. Queste opzioni limitano ciò che il processo può raggiungere anche se viene compromesso. Per un agent, le più importanti sono NoNewPrivileges, che impedisce di acquisire nuovi privilegi, ProtectSystem=strict, che rende il filesystem di sola lettura tranne nei percorsi in cui autorizzi le scritture, PrivateTmp, che fornisce una directory temporanea isolata per il processo, e ProtectHome, che impedisce la lettura delle directory home.

Genera qui un’unità completa con misure di sicurezza avanzate, quindi copiala in /etc/systemd/system/openclaw.service:

L’unità avvia openclaw gateway, il processo a esecuzione continua che controlla l’agent. Se which openclaw mostra un percorso diverso sul tuo server, modifica ExecStart di conseguenza. La procedura completa per queste direttive e per daemon-reload e enable --now è disponibile in eseguire un programma come servizio systemd. Dopo aver incollato l’unità, la versione breve è:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

Metti in sicurezza anche il punto di accesso

Un server che esegue un agent è sicuro solo quanto il server che lo ospita. Altri due livelli completano la protezione. Configura SSH per usare esclusivamente l'autenticazione con chiave ed escludi l'accesso a root, come descritto in Mettere in sicurezza SSH su un VPS, in modo che l'account usato per amministrare il server non possa essere attaccato con tentativi di forza bruta. Aggiungi quindi Fail2ban per bloccare gli scanner che colpiscono ripetutamente ogni porta pubblica. Nessuno dei due interventi modifica direttamente OpenClaw, ma entrambi chiudono le vie che un attaccante userebbe per raggiungerlo.

Mantienilo aggiornato intenzionalmente

Le vulnerabilità rese pubbliche a marzo 2026 sono il motivo più chiaro possibile per mantenere il sistema aggiornato. Un bug che consente l'escalation dei privilegi in un agent è molto più grave rispetto allo stesso problema in una normale applicazione web, perché l'agent esegue già comandi. Monitora le release del progetto, applica rapidamente gli aggiornamenti di sicurezza e considera un aggiornamento di OpenClaw una normale attività di manutenzione, invece di rimandarlo.

Per capire che cosa stai realmente mettendo in sicurezza, l'architettura di un agent in stile OpenClaw descrive i vari componenti, mentre creare il tuo agent AI su un VPS illustra la struttura generale di qualsiasi agent. Se finisci per eseguire un secondo agent insieme al primo, ricorda che due sessioni di Claude Code su un singolo VPS possono passarsi il lavoro, quindi ciascuno deve avere il proprio account e i propri limiti, senza ereditare quelli del tuo account.

FAQ

È sicuro eseguire OpenClaw su un VPS pubblico?

Può esserlo, se lo configuri con misure di sicurezza adeguate. OpenClaw è progettato per offrire ampie funzionalità: esegue comandi shell e controlla un browser, quindi una configurazione superficiale è realmente pericolosa. Inoltre, il progetto ha già avuto una CVE critica (CVE-2026-32922 a marzo 2026). Il modello di sicurezza presuppone che sia l'operatore ad aggiungere i limiti necessari. Eseguilo con un utente senza privilegi, mantieni il gateway in ascolto sull'interfaccia di loopback dietro un firewall con criterio predefinito di negazione, isola le relative API key ed eseguilo come servizio systemd configurato con misure di sicurezza adeguate.

Devo esporre il gateway di OpenClaw su Internet?

No. Per impostazione predefinita, il gateway è associato all'interfaccia di loopback, e deve rimanere così. È l'unico processo che controlla l'agent, quindi un gateway esposto crea un accesso remoto a un componente progettato per eseguire comandi. Se devi raggiungerlo da remoto, usa una VPN o un tunnel SSH invece di aprire la porta.

Con quale utente deve essere eseguito OpenClaw?

Con un utente di sistema dedicato, senza shell di login e senza sudo; mai con root. Se l'agent viene compromesso, il relativo account utente limita l'entità del danno. Per questo, l'account deve essere proprietario soltanto dei propri file in una directory come /opt/openclaw e di nient'altro.

Come posso proteggere le API key di OpenClaw?

Conservale in un file leggibile soltanto dall'utente OpenClaw (modalità 600) e caricale nel servizio tramite EnvironmentFile di systemd. Mantieni la key fuori dal file unit, dalla cronologia della shell e da qualsiasi repository git. Ruotala se sospetti che sia stata divulgata.