Running OpenClaw in the Enterprise: Hardening Guide and Checklist

Running OpenClaw securely in an enterprise comes down to eight controls: one Gateway per trust boundary, sandbox mode on, named operator roles, secrets out of agent-readable files, egress through a filtering proxy and a firewall, vetted skills, exported audit logs, and a fixed patch channel. OpenClaw Enterprise, the foundation’s own control plane, is still pre-1.0. So today you build these controls yourself.

Every setting below was checked against docs.openclaw.ai on October 15, 2026. For what OpenClaw is, and whether to allow it, read the OpenClaw explainer.

What is OpenClaw Enterprise, and do you still need to harden?

“OpenClaw enterprise” means two things. One is a product. The other is a configuration job.

The product is OpenClaw Enterprise, announced September 29, 2026: an open-source control plane with multi-tenancy, hard boundaries between trusted and untrusted workloads, sandboxing with LLM-based reviews, fine-grained permissions, and audit. Its 1.0 is expected later this year. Today it is “something that organizations can use for internal pilot workloads,” piloted internally at Red Hat and OpenAI.

The configuration job is the open-source Gateway, which has a narrow trust model: one trust boundary per Gateway, meaning “a single operator or a mutually trusting team.” “Everyone who can message a tool-enabled agent shares that agent’s delegated tool authority.” Session tools also reach across the whole Gateway by default (tools.sessions.visibility is all, tools.agentToAgent.enabled is true), so an unsandboxed, tool-enabled agent can read every other agent’s transcripts.

Decision rule: count trust boundaries before you install. The number of Gateways equals the number of groups whose members may read each other’s transcripts. Say finance, engineering, and sales each want an agent (hypothetical). That is three Gateways, three OS users or VMs, and three credential sets. Hard tenant isolation on one shared platform is OpenClaw Enterprise’s job, and I would keep it to pilots until 1.0.

Step 1: Isolate the host and keep the Gateway private

Give each Gateway a dedicated VM and OS user. The trust model treats anyone who can modify ~/.openclaw as a trusted operator, so nobody else gets a login on that box.

Then decide how people reach it. The exposure runbook ranks five patterns, from loopback plus SSH tunnel up to the public internet (“rare, high-risk”), and says to avoid direct public port-forwarding. The default port is 18789.

For a company, my pick is a trusted reverse proxy with SSO, because it gives every connection a verified identity, which named roles need in Step 3. The runbook’s rules: the proxy authenticates users first, a firewall blocks direct access to the Gateway port, gateway.trustedProxies lists only the proxy’s IPs, and the proxy strips client-supplied identity headers.

Chat channels are the other front door, and the runbook calls them untrusted input. Use dmPolicy: "pairing" or a strict allowFrom list, never a "*" allowlist with broad tools. Require mentions in groups. Set session.dmScope: "per-channel-peer" so people who DM the bot do not share context. Pairing lets a sender trigger the bot; it does not make that sender a separate security boundary.

Failure mode: widening several controls at once. The runbook says to widen one at a time, re-run openclaw security audit --deep after each change, and document every warning you accept.

Step 2: Turn sandbox mode on and close the escape hatches

Sandboxing is off by default, and only tool execution moves into it; the Gateway process stays on the host. The trust model’s default for host execution is no approval prompts (security="full", ask="off"). Put together: on a default install, shell commands the model picks run on the host, as the Gateway’s user, with no prompt.

The mode setting takes off, non-main, or all. non-main skips each agent’s main session. For a team Gateway, use all. On the Docker backend, sandbox network defaults to none and network: "host" is blocked. Workspace access defaults to none, a scratch workspace that cannot see the agent’s files. Raise it to ro before rw.

Tool policy applies before the sandbox, but tools.elevated runs exec outside it on purpose. Set tools.elevated.enabled: false, and deny exec in tool policy for agents that do not need a shell.

Failure mode: one chat quietly leaving the sandbox. An administrator can opt a single chat out with sandboxMode: "off". A role-level requirement (sandbox: "required", Step 3) is immutable, even for administrators, and an unavailable backend blocks execution instead of falling back to the host. Detect drift with openclaw sandbox explain --session <key>. The docs also say the sandbox “is not a perfect security boundary,” so patch it like everything else.

The baseline I would start from, built on the runbook’s minimum safe baseline plus the settings above and below:

{
  gateway: {
    bind: "loopback", // behind an SSO proxy, use auth.mode "trusted-proxy" per the exposure runbook
    auth: { mode: "token", token: { source: "env", provider: "default", id: "OPENCLAW_GATEWAY_TOKEN" } },
  },
  session: { dmScope: "per-channel-peer" },
  agents: {
    defaults: { sandbox: { mode: "all", scope: "session", workspaceAccess: "none" } },
  },
  tools: {
    profile: "messaging",
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
    sessions: { visibility: "agent" },
    agentToAgent: { enabled: false },
  },
  proxy: { proxyUrl: "http://proxy.corp.example:3128" },
  logging: { audit: { executionIdentity: true, messages: "direct" } },
}

Step 3: Scope operators with named roles

Operator scopes gate what an authenticated client can do. operator.sessions.write lets a person start and continue their own work. operator.write adds sending messages and invoking tools. operator.admin satisfies every scope and is required for config changes, updates, and high-risk approvals.

Named roles turn scopes into policy. A role sets whether a person sees other people’s sessions (none, view, suggest, or write), which agents they can run, their maximum scopes, and whether their sessions must be sandboxed. A role change closes that person’s live connections.

With roles configured, device or bootstrap tokens without a verified identity are rejected for operator connections, so people come in through the trusted proxy or Tailscale. And shared-secret and password access keep their existing behavior, so I treat the Gateway token as an admin credential only platform owners hold.

{
  gateway: {
    roles: {
      default: "member",
      definitions: {
        member: {
          sessions: { others: "none" },
          agents: ["team-agent"],
          scopes: ["operator.sessions.read", "operator.sessions.write"],
          sandbox: "required",
        },
      },
    },
  },
}

Decision rule: the default role sees only its own sessions, runs one or two named agents, and requires a sandbox. Two named people hold operator.admin. The docs are clear that roles are “a control-plane guardrail inside one trusted Gateway operator domain, not hostile multi-tenant isolation,” which is why Step 1’s Gateway count still rules.

Step 4: Keep secrets out of files the agent can read

SecretRefs point a config field at an environment variable, file, command, or the shared secret store instead of holding the value. They are opt-in; plaintext still works. Per the secrets runtime model, “a plaintext credential left on disk in a path the agent can read is still readable via file or shell tools,” and transcripts do not mask it.

For model-provider keys behind SecretRefs, logs and errors see an opaque sentinel, and the real key is swapped in just before the request leaves. The docs’ hedge: sentinels “are not process isolation.”

The docs call a migration finished when supported credentials use SecretRefs, plaintext residue is scrubbed from openclaw.json, the auth-profile store, .env, and generated models.json files, openclaw secrets audit --check is clean, and anything left is behind OS or container isolation. Backups and copied configs stay production secrets.

Skills are a separate path. Per the skills docs, skills.entries.*.env and skills.entries.*.apiKey inject secrets into the host process for that turn, not into the sandbox, so a skill’s key sits outside your Step 2 boundary.

Decision rule (mine): every credential on a Gateway is a service account issued for that Gateway alone, with the narrowest scope the job allows. No personal OAuth tokens. If you cannot rotate it in under an hour, it does not go on the host.

Step 5: Control network egress at two layers

OpenClaw can route its runtime HTTP and WebSocket traffic through a forward proxy you operate by setting proxy.proxyUrl. It does not ship, configure, or certify that proxy.

The docs state the limit: this is “process-level coverage for JavaScript HTTP/WebSocket clients, not an OS-level network sandbox.” Raw sockets, native addons, and non-OpenClaw child processes can bypass it unless they honor proxy environment variables, and the IRC channel is never proxied. So add a second layer: a host or VPC firewall that denies all outbound traffic except to the proxy.

The proxy’s policy is the real boundary. The docs say to resolve DNS in the proxy and block by IP at connect time, reject loopback, private, link-local, and metadata destinations such as 169.254.169.254, and log destination, decision, and reason, never bodies or authorization headers. Validate with openclaw proxy validate from the service account that runs OpenClaw; it exits 1 on any failure. For the metadata address, confirm the deny in the proxy’s own log.

Decision rule: allow your model provider’s API hosts, your chat channels’ API hosts, and hosts a reviewed skill needs. Deny everything else. Keep the Docker sandbox network at none. The Gateway itself still runs on the host, so its traffic needs the proxy too. For isolation options beyond Docker, see the AI agent sandbox guide.

Step 6: Vet skills before any agent can load them

The skills docs tell you to treat third-party skills as untrusted code and read them before enabling them. The public marketplace, ClawHub, now runs security audits on every release, combining SkillSpector, Tencent’s A.I.G scanner, and its own ClawScan review, with statuses from Pass to Malicious. The docs’ caveat: “A Pass is reassuring, but it does not replace your own judgment.”

Three controls enforce your own gate. First, security.installPolicy runs a trusted local command before any skill install, across ClawHub, upload, Git, local, and update paths, and blocks the install if the command cannot return a valid decision. Second, per-agent skill allowlists: a non-empty agents.entries.*.skills list is the final set, and [] exposes none. The docs warn the allowlist “is not a host shell authorization boundary,” so an agent with exec still needs Step 2. Third, openclaw skills verify @owner/<slug> checks ClawHub’s trust record and exits non-zero on failure.

My review gate: an approved list of owner/slug@version in Git, an install policy that allows only that list, a weekly skills verify run in CI, and a human read of SKILL.md, every script, and every declared environment variable before approval. The malicious-skill history behind this rule is in OpenClaw security risks.

Step 7: Audit logging that survives an incident

OpenClaw keeps an audit ledger. Run and tool records are on by default. Execution identity (who invoked a run, under which grants) and message records are off by default. The ledger is metadata-only, returns nothing older than 30 days, and is capped at 100,000 rows. Writes are best-effort: queue saturation, storage failure, and crashes can lose evidence. The docs’ verdict: it “is not a lossless compliance archive; if you need one, use an external system fed by OpenTelemetry.”

The row cap can bite before the 30 days. 100,000 rows over 30 days is about 3,333 rows a day. Say 25 people each generate 140 ledger rows a day (hypothetical). That is 3,500 a day, so the cap is reached in about 28.6 days. At 50 people, 7,000 a day, it is about 14.3 days. The local ledger is a buffer, not your record.

Turn on logging.audit.executionIdentity and set logging.audit.messages to direct, or all if group channels are in scope. Export to your SIEM and alert on four things (my picks): spikes in blocked or failed tool actions, any change to bind, auth, DM policy, or elevated tools, any new skill install, and denied destinations at the proxy. Run openclaw security audit --deep on a schedule and diff the results. For what a full record should hold, see what to log in an AI agent audit trail.

Step 8: Pick a patch channel and a clock

Between September 15 and October 15, 2026, its GitHub releases show 8 regular stable releases (2026.9.5 through 2026.10.3) and 5 extended-stable releases. The advisory volume behind that pace is counted in the OpenClaw explainer.

Extended-stable is the enterprise option. A new line ships monthly, starting at patch .33, and receives “security and reliability fixes backported from later releases.” Each line is supported until the next one is cut, with a minimum of one month. Switch with openclaw update --channel extended-stable.

How updates apply matters too. Per the automatic updates docs, Gateway automatic updates are off by default. When enabled on stable, an update waits for active work but starts within a 15-minute hard deadline even if work remains. Extended-stable “never applies automatically.”

Decision rule (mine): production Gateways run extended-stable and take each patch through your change process within 7 days. Run one canary Gateway on stable. If an advisory names a component you use, patch within 72 hours, and rotate any credential that component could reach.

How do you prove OpenClaw is hardened? A pass/fail checklist

Run each test on every Gateway after setup, after each exposure change, and monthly. Any fail blocks company credentials until fixed.

Bottom Line

OpenClaw fits a trusted team only after you build the boundary it does not ship with: separate Gateways, sandbox on, roles, secrets out of reach, two-layer egress, gated skills, exported logs, and a patch clock.

OpenClaw Enterprise may take some of this over after 1.0. Until then, run the 18-point checklist on every Gateway this month.

FAQ

Is OpenClaw Enterprise ready for production?

Not by its own announcement. It is pre-1.0, positioned for internal pilot workloads, and free to self-host with docker-compose or Kubernetes, so a pilot costs engineering time, not a license.

Can one OpenClaw Gateway serve several teams?

Only teams that trust each other. The docs say mixed-trust users need separate Gateways, ideally under separate OS users or hosts. Named roles reduce accidental access, but the docs call them guardrails, not tenant isolation.

Does sandbox mode stop prompt injection?

No. It limits what an injected instruction can damage. The trust model says most failures are “someone messaged the bot and the bot did what they asked,” and orders the defense as identity first, scope next, model last. See prompt injection in AI agents.

Do I still need an egress proxy if the sandbox has no network?

Yes. Sandbox network settings cover tool execution only. The Gateway itself makes model and channel calls from the host.

Can we use ChatGPT or Claude subscriptions instead of API keys?

OpenClaw supports subscription sign-in, API keys, and local models. For a company Gateway, I prefer API keys or local models, because they can be issued per Gateway and rotated. The OpenClaw vs Claude Code vs ChatGPT comparison covers billing.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect