Come eseguire OpenClaw in sicurezza su un VPS

Che cos’è OpenClaw e perché va messo in sicurezza prima di tutto

OpenClaw è un agente AI self-hosted. Lo esegui sul tuo server, lo colleghi a un modello linguistico di grandi dimensioni e può eseguire comandi shell, controllare un browser, leggere e scrivere i tuoi file e agire sui messaggi che gli invii dalle app di chat. Questa ampia capacità operativa è lo scopo stesso dello strumento, ma costituisce anche il rischio principale. Un agente che può eseguire qualsiasi comando è sicuro soltanto quanto il sistema su cui viene eseguito e quanto sono restrittivi i limiti che imposti.

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 rigide per gli strumenti, configurare il sandboxing e assegnare permessi accurati, invece di fornire impostazioni predefinite sicure. Secondo, il progetto ha già subito un grave incidente di sicurezza: a marzo 2026 sono state divulgate nove vulnerabilità nell’arco di quattro giorni, tra cui una vulnerabilità critica di escalation dei privilegi, CVE-2026-32922, con una valutazione di 9.9 su 10. Nessuno dei due aspetti significa che dovresti evitare OpenClaw. Significa che non dovresti eseguirlo nel modo più semplice e rischioso; questa guida descrive invece l’approccio prudente. Un aspetto dell’approccio prudente consiste nel decidere in anticipo quali operazioni l’agente può eseguire senza chiedere conferma, una scelta che Claude Code rende esplicita con le sue modalità di autorizzazione, considerando che un server davanti al quale non sei fisicamente presente richiede impostazioni più restrittive rispetto al laptop che stai controllando.

C’è anche una buona notizia. OpenClaw adotta già una scelta sicura: il suo gateway, il singolo processo che controlla tutto, è in ascolto sull’indirizzo di loopback per impostazione predefinita. Di conseguenza, non è raggiungibile da Internet, a meno che tu non scelga esplicitamente di esporlo. La maggior parte delle attività descritte di seguito serve a mantenerlo in questa configurazione e a 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 è distribuito come pacchetto npm. Installare prima Node.js se non è già presente sul server. Installare il pacchetto globalmente. In questo modo il binario openclaw viene aggiunto al PATH per tutti gli utenti. Eseguire quindi la procedura di configurazione iniziale:

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

Eseguire la procedura come utente openclaw fa sì che la configurazione dell'agente venga salvata nella sua directory home, /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 configurazione iniziale, non usare il flag --install-daemon. Questo flag registrerebbe il servizio di OpenClaw. L'unità systemd con configurazione più restrittiva viene invece creata nella sezione seguente.

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.