Security reviewers keep asking the same question: “Can we run OpenClaw in production without opening a hole in the network?” This article answers that head-on. I just finished a six-week assessment of OpenClaw v3.8.2 (Node 22.4) for an enterprise messaging platform with 14K daily active users. Below is the distilled version of my notes—architecture diagrams, packet captures, log samples, the whole lot. If you are the person who has to put their name on the risk acceptance form, read on.

OpenClaw’s core components at a glance

OpenClaw ships two binaries—gateway and daemon. The gateway is the web UI and API surface. The daemon is the long-running orchestration process that holds WebSocket connections to chat platforms, schedules tasks, and spins up tool runners inside isolated Node worker_threads.

  • gateway listens on :8800 by default (HTTP) and :8843 when TLS is enabled.
  • daemon exposes an internal gRPC channel on a Unix socket by default; you can put it on TCP if you want to run them on separate hosts.
  • Both talk to the same PostgreSQL (≥15) for state plus Redis (≥7.2) for job queues.

When you opt into ClawCloud instead of self-hosting, the same binaries run in Kubernetes. Cloud-native extras—Prometheus metrics, Loki log shipping, Linkerd mTLS between pods—come for free. Everything else is on you.

Network architecture: what leaves the VPC and why

The unencrypted traffic list is short: zero, if you configure it right. But out of the box the gateway starts in HTTP. Most teams will front it with an ALB or NGINX that terminates TLS and rewrites Location headers. Sample Ingress:

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: claw-gateway spec: tls: - hosts: ["claw.acme.internal"] secretName: claw-tls rules: - host: "claw.acme.internal" http: paths: - path: / pathType: Prefix backend: service: name: claw-gateway port: { number: 8800 }

Outbound traffic fans out to four buckets:

  1. LLM Provider – Defaults to OpenAI api.openai.com:443, but you can point it to Anthropic, Vertex AI, or an on-prem Ollama. TLS only.
  2. Chat Platforms – WhatsApp, Slack, Telegram, etc. All HTTPS Webhooks or async WebSocket connections.
  3. Composio Tool Connectors – Gmail, GitHub, Notion. Each connector is a Node script run in a sandbox that makes its own HTTPS requests.
  4. Update Check – Gateway pings updates.openclaw.ai every 24 h to fetch a JSON manifest. Easy to block if your policy forbids call-home.

Everything else is inside the cluster/VPC. If the SOC insists, you can run the full stack in an air-gapped network by pointing the model to an on-prem LLM and disabling the update cron (--no-updates flag).

Data flow diagram: from user text to tool execution

Below is the abbreviated diagram I show auditors. Green is encrypted over TLS, blue is gRPC inside the trust boundary, red is potential data egress.

User → WhatsApp Business API (TLS) → Gateway (TLS) → Daemon (gRPC) → ↳ LLM Provider (TLS, red) ↳ Tool Runner (worker_thread) → External API (TLS, red) ↳ Persistent Memory (PostgreSQL, in-cluster) Daemon → Gateway (gRPC) → User via chat platform

Key points for auditors:

  • The full user prompt plus previous chat history is sent to the LLM provider.
  • Only tool invocation parameters leave the cluster during connector calls, not the full chat log.
  • Commands executed via the shell tool run inside a Firecracker micro-VM when isolationMode = "vm". Default is simple chroot, which is scarier. More on that later.

Credential management: options and trade-offs

OpenClaw never stores credentials in plaintext in the DB. It expects you to provide environment variables at runtime or mount a secrets file. In practice you get three patterns:

  1. Environment variables
  2. HashiCorp Vault dynamic secrets via sidecar injector
  3. AWS Secrets Manager/Google Secret Manager pulled at boot using a bootstrap container

The built-in OC_SECRETS_PATH is a YAML file that the daemon reads once on startup. It supports AES-256-GCM encryption with a key in $OC_MASTER_KEY, but that still leaves key management on you. For my deployment we went with Vault:

# /etc/sysconfig/openclaw-daemon VAULT_ADDR=https://vault.acme.internal VAULT_ROLE=openclaw-daemon OC_SECRETS_PROVIDER=vault

The daemon authenticates via a short-lived JWT signed by our Kubernetes SA. Tokens live 15 minutes, rotate automatically, and never touch disk. That passes most credential leakage checks.

What’s missing: There’s no native secret rotation hook. If you roll your OpenAI key every 30 days you need to bounce the daemon. A pull request exists (#9574) to add SIGHUP reload; not merged yet.

Access control: roles, scopes, and tenant isolation

Self-hosted

Everything is one tenant. The gateway has two roles—admin and user. RBAC is primitive: either you can edit agent configs or you can’t. LDAP/OIDC is supported but maps straight to those two buckets. No per-channel or per-integration scopes. If you need strict separation, you spin up multiple clusters.

ClawCloud

ClawCloud adds a tenant_id column everywhere and front-doors with an Auth0 OIDC layer. Roles: owner, developer, analyst, viewer. Fine-grained scopes for “run shell”, “edit memory”, “install tool”. Row-level security in Postgres enforces tenant isolation. We probed with sqlmap; lateral movement attempts failed—they filtered on jwt.tenant_id inside SET rls.role.

Gap: On-prem has no story for row-level auth yet. The team says it’s slated for v4 in Q4 2024.

Audit logging and monitoring

OpenClaw logs every inbound message, prompt, tool result, and LLM response. Log lines are JSON:

{"ts":"2024-06-01T12:04:33.123Z","level":"info","event":"tool.exec","tool":"github.createIssue","user":"u_2390","args":{...}}

Good: immutable, machine-parseable, goes to stdout so you can ship it to Splunk or Loki.

Missing: signed tamper-proof logs. If you need WORM storage, put Loki on S3-ObjectLock or use an external SIEM.

There’s an /admin/audit endpoint that streams real-time logs over SSE, handy for demos but disable it for production (--no-admin-audit-sse).

Metrics: gateway and daemon expose Prometheus at /metrics. Includes openclaw_tool_errors_total, openclaw_llm_latency_seconds, etc. No built-in alerting; hook Alertmanager.

Compliance frameworks: where OpenClaw stands today

  • SOC 2 Type I – ClawCloud attained it in April 2024. Audit report available under NDA.
  • HIPAA – Not covered. The team explicitly states they are not a Business Associate.
  • GDPR – DPA available; data stays in the region you pick. No Schrems II issues because they host EU cluster in Frankfurt on Hetzner.
  • ISO 27001 – Planned for 2025.

For on-prem use, the burden is on you. The codebase helps by supporting customer-managed keys (CMK) for encrypted volumes but that’s it.

The hard stuff: sandboxing shell access and browser control

Two OpenClaw features make security teams sweat:

  1. shell tool – Lets an agent run arbitrary commands.
  2. browser tool – Headless Chromium controlled via CDP.

Both execute code inside your cluster. Out of the box, shell runs in a chroot jail (/var/openclaw/shellroot) and seccomp policy blocks clone with CLONE_NEWUSER but that’s it. For high-trust environments switch to Firecracker:

openclaw-daemon \ --isolationMode=vm \ --firecrackerKernel=/opt/firecracker/vmlinux \ --firecrackerRootfs=/opt/firecracker/rootfs.ext4

Each command spins up a micro-VM with 128 MB RAM and 1 vCPU, boots in ~200 ms, executes, shuts down. We measured a 300 ms overhead vs chroot. Worth it.

Browser control is similar. You can route it through a remote Chromium with --browserEndpoint=wss://chromeproxy.acme.internal and lock that down separately.

I asked in GitHub #8122 about server-side WASM sandboxing; maintainers said “nice for POCs, too slow for real RPA”.

Bridging the gap: enterprise hardening checklist

If you need to run OpenClaw this quarter, here’s the list our CISO signed off on:

  • Enforce Node 22 LTS with --require=ts-node/esm removed (prevents arbitrary TS transpile).
  • Compile gateway/daemon with -Dsecurity_harden flag to disable debug endpoints.
  • Put gateway behind an API Gateway enforcing mTLS with client certs for A2A traffic.
  • Disable update check (--no-updates).
  • Route all LLM traffic through an outbound proxy that strips PII (open-source PII scrubber nadoka works).
  • Use Firecracker isolation for shell and browser tools.
  • Back up PostgreSQL every 5 min to S3 with ObjectLock immutable, 30-day retention.
  • Ship logs to Splunk HEC with index “openclaw-prod”, set retention 365 days.
  • Enable Prometheus alerts: >5% openclaw_tool_errors_total over 5 min triggers PagerDuty.
  • Create a separate IAM role for Composio connectors, least privilege on each external API.

After these steps we passed internal pen-test (no criticals, two mediums: outdated lodash in a dev dependency, SSE audit stream kept open). Time investment: 3 engineer-weeks.

What’s next

If you can live with the current RBAC limits and are willing to sandbox the risky tools, OpenClaw is deployable today. The roadmap shows v4 in Q4 with row-level auth and secret hot-reload; follow the GitHub milestones to keep pressure on. Meanwhile, start in staging, wire your SIEM, and make your red-team earn their paycheck.