L’ANALISI
OpenClaw Enterprise: cosa offre il control plane self-hosted per agenti
OpenClaw Enterprise rende installabile un control plane aperto per agenti persistenti: architettura, requisiti, limiti e checklist per un pilot controllato.
In breve: OpenClaw Enterprise è un control plane open source e vendor-neutral per gestire agenti con identità, autorizzazioni, audit e confini tra workload. Si può eseguire localmente o su Kubernetes, ma è ancora pre-1.0: va trattato come piattaforma da pilot, non come prodotto già maturo per la produzione.
Il delta verificato
Il 29 settembre OpenClaw Foundation ha pubblicato OpenClaw Enterprise e il relativo repository MIT. Il progetto introduce OpenClaw Control Plane per distribuire e amministrare agenti, con console, API, coda di lavoro e driver sostituibili.
Confine di deployment
OCE è realmente self-hosted: il control plane può essere avviato in locale e installato su un cluster Kubernetes esistente. Questo non rende automaticamente locale l’inferenza: il primo agente della guida usa una chiave API OpenAI, salvo configurare un provider diverso supportato.
Governance e audit
Il codice separa identità, ruoli e autorizzazioni dalle risorse degli agenti e include un package dedicato agli eventi di audit e alla sanitizzazione dei valori sensibili. Sono elementi utili da ispezionare, ma non equivalgono ancora a una certificazione o a una verifica indipendente.
Cosa si può provare oggi
Il quickstart permette di avviare il control plane e poi distribuire un primo agente. Il profilo Kubernetes locale usa k3d; il semplice profilo Compose è una preview del control plane e non può distribuire agenti, distinzione importante per evitare test incompleti.
Requisiti operativi
Servono Docker Engine o Podman, k3d, kubectl, Helm, Bash, Python 3, Go, Node.js 24 o successivo e la versione pnpm fissata dal progetto. Un pilot deve inoltre prevedere gestione credenziali, log, backup, limiti di rete e rimozione completa delle risorse.
Condizioni e limiti
OpenClaw definisce OCE adatto a pilot interni mentre lo sviluppo prosegue verso la 1.0. Le dichiarazioni su confini di sicurezza e adozione provengono dal progetto; prima di workload sensibili servono threat model, test di isolamento e verifica dei permessi effettivi.
Checklist per un pilot
- Isolare un cluster di test senza dati cliente o credenziali di produzione.
- Fissare commit, versioni di Node, Go, pnpm, Helm e immagini container.
- Inventariare ruoli, identità e permessi prima del primo deployment.
- Usare credenziali dedicate e verificare dove vengono memorizzate.
- Eseguire un agente innocuo con rete e strumenti limitati.
- Controllare audit trail, sanitizzazione dei segreti e revoca degli accessi.
- Provare separazione tra due tenant e tentativi di accesso incrociato.
- Misurare risorse, latenza, errori e comportamento dopo un riavvio.
- Documentare cleanup e rollback prima di estendere il pilot.