Buone pratiche di sicurezza per OpenClaw

La documentazione di OpenClaw pubblica una baseline rafforzata: una configurazione del Gateway da copiare e incollare che mantiene un’installazione privata, abbinata e con strumenti limitati, e una baseline sicura più breve per chi vuole solo le prime tre righe. Questo articolo è quella configurazione spiegata chiave per chiave: perché c’è ogni riga e quali decisioni restano valide su un host gestito, dove l’infrastruttura è di qualcun altro.

Il Gateway: local, loopback, token

La modalità local e il bind su loopback tengono il Gateway fuori dalla rete; l’autenticazione tramite token, con un token lungo e casuale, filtra ogni client, anche quelli locali, perché la modalità di autenticazione predefinita è token anche per i bind su loopback. La documentazione indica un numero concreto per la porta, 18789, e un avvertimento concreto sull’alternativa: impostare l’autenticazione su none permette a qualsiasi processo locale di connettersi.

I canali: abbinamento e menzioni

• Policy dei messaggi diretti pairing su ogni canale: i mittenti sconosciuti attendono la tua approvazione, e l’approvazione vale per singolo canale.
• Per impostazione predefinita i gruppi richiedono una menzione, così l’agente segue la conversazione senza rispondere a ogni riga.
• Un numero separato per i canali basati sul telefono, così le conversazioni personali restano private e il numero del bot si fa carico dell’automazione.
• Ambito dei messaggi diretti per canale e per peer, così la sessione di un mittente non può riversarsi in quella di un altro.

Gli strumenti: un profilo, un elenco di divieti e nessuna via di fuga

La baseline rafforzata parte dal profilo di strumenti messaging e nega del tutto quattro gruppi: automazione, runtime, filesystem, e avvio di altre sessioni o invio di messaggi ad altre sessioni. L’accesso al filesystem è limitato allo spazio di lavoro, exec è negato e impostato su ask always, elevated è disattivato, la visibilità delle sessioni è limitata a quelle dell’agente stesso, e l’accesso tra agenti è disattivato. La documentazione dice di riattivare uno strumento quando ti serve, deliberatamente, invece di partire con tutto aperto e chiudere dopo. Una regola è integrata e non si può eliminare con la configurazione: i mittenti che non sono il proprietario non ottengono mai gli strumenti cron o gateway.

Considera questi controlli come una difesa in profondità che riduce la capacità diretta di chi fa una richiesta, non come un isolamento multiutente contro utenti ostili.

Cosa la baseline non fa

• Non ripulisce i contenuti: i controlli legati a chi fa la richiesta limitano ciò che un mittente può fare, non ciò che una pagina web o un’email possono dire al modello.
• Non isola gli utenti locali ostili: per questo, la documentazione dice di eseguire Gateway separati con utenti del sistema operativo o host separati, oppure di usare la sandbox.
• Non sceglie il livello del tuo modello, che la pagina sulla prompt injection tratta come un controllo di sicurezza a pieno titolo.

La guida alla prompt injection in OpenClaw copre il lato dei contenuti, e la guida a sandboxing, policy degli strumenti ed elevated il lato di dove girano gli strumenti; la baseline è il lato di chi può fare cosa, e i tre sono pensati per sommarsi.

Su Diali

Le righe del Gateway sono nostre: non è mai su internet, l’istanza non ha porte pubbliche e ha accesso in uscita solo al web pubblico, mai alla nostra rete interna, al server dei metadati del cloud o ad altri tenant, e il token non lascia mai il vault. Le righe dei canali e degli strumenti sono tue, nella dashboard, perché chi può scrivere all’assistente e cosa può eseguire sono questioni di policy, non di infrastruttura. La sicurezza su Diali è la pagina sul confine; OpenClaw ospitato su Diali quella sull’assistente.

• Local, loopback, token: il Gateway non è un server.
• Abbinamento, menzioni, un numero separato: i canali sono filtrati.
• Un profilo, un elenco di divieti, niente elevated: gli strumenti sono l’insieme più piccolo che fa il lavoro.