OpenClaw Gateway Security Checklist: Evidence Before Exposure

OpenClaw Gateway Security Checklist: Evidence Before Exposure

An OpenClaw Gateway should not receive remote users until the operator can prove who can reach it, how identity is checked, which agents and tools are reachable, what credentials they hold and how access will be revoked. A passing installation is not enough. The launch decision needs evidence for every control and a tested rollback path.

This checklist is for the review immediately before a Gateway moves beyond local use. It complements the broader OpenClaw implementation guide for business, which covers workflow design, ownership and production operation.

The launch decision in one table

The evidence does not certify the deployment. It makes the decision reviewable and exposes missing controls before a live channel discovers them.

1. Record the trust boundary

Start with a short inventory:

• Gateway host, operating system user and state directory
• bind mode, port and every network hop to the client
• authentication mode and the owner of its secret or identity source
• enabled channels, DMs, groups and webhooks
• agents reachable from non-local senders
• tool profile, sandbox mode, exec policy and elevated access for each agent
• external credentials available to those agents
• backup location and the person allowed to restore it

OpenClaw's exposure runbook says that multiple people messaging one bot should be treated as shared delegated tool authority, not as per-user host isolation. If two companies, customers or adversarial user groups must not share authority, stop and separate the Gateway, credentials, operating system user or host.

Evidence: a dated inventory with one accountable operator and one explicit boundary.

Block launch: nobody can explain which identities share the same host authority.

2. Choose the narrowest exposure pattern

Prefer local access. Expand only when the workflow requires it.

Direct public port forwarding is a stop condition. When public access is unavoidable, the proxy should be the only network route to the Gateway.

Evidence: the selected pattern, reason, bind value and a probe from the expected client path.

Block launch: the Gateway port is directly reachable from the public internet.

3. Run the baseline and keep the findings

Run the built-in checks before changing exposure:

openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw health

The audit returns structured findings with a checkId. The deep audit adds live Gateway probes and code scans for plugins and skills. Keep the command version, timestamp, findings and disposition. Resolve critical findings. If a warning is accepted, record why it is intentional, who accepted it and when it will be reviewed again.

For a remote URL, pass credentials explicitly to the probe. Do not assume that credentials from local configuration apply to that URL.

Evidence: saved audit output and a disposition for every critical or warning finding.

Block launch: a critical finding remains unresolved, the deep probe cannot authenticate or a warning has no owner.

4. Prove identity and channel denial

Authentication is only useful when the unwanted path fails. Test both sides:

1. An authorized identity can connect.
2. An unauthorized sender or browser is denied.
3. Each DM or group reaches only the intended agent.
4. Shared conversations do not merge private context.

For messaging, prefer pairing or a strict allowFrom list over open DMs. Use stable sender IDs, require mentions in groups unless the room is tightly controlled and use peer-scoped DM sessions when multiple people can contact the bot.

Do not combine wildcard sender access with broad tools. A sender being paired means the sender can trigger the bot. It does not create a separate host security boundary.

Evidence: allowed and denied test results, channel policy and effective session scope.

Block launch: the team has tested only the happy path.

5. Inspect the effective agent authority

Sandbox, tool policy and elevated execution are different controls:

• the sandbox decides where tools run;
• tool policy decides which tools exist;
• elevated execution lets exec escape the sandbox when enabled.

Use the built-in inspector for the actual session or agent:

openclaw sandbox explain --session agent:main:main
openclaw sandbox explain --agent work

Then review the effective execution policy:

openclaw approvals get
openclaw exec-policy show

OpenClaw documents tools.exec.mode as the preferred host execution policy. Start with deny when the workflow does not need host commands. If commands are required, use the smallest allowlist or approval path that fits the job. The effective policy is the stricter result of configuration and the approvals file on the execution host.

For business actions beyond host execution, define the same boundary through an AI agent approval policy that binds each decision to an exact effect, reviewer, expiry and evidence record.

Remember that denying file tools does not make an allowed shell read-only. A shell can still change files within the permissions of its host or sandbox. Bind mounts also pierce the sandbox filesystem, and the Docker socket effectively grants host control.

Evidence: captured sandbox explanation, effective tool list, exec policy and elevated allowlist.

Block launch: an open channel reaches host exec, elevated access, control-plane tools, personal credentials or broad writable mounts without a documented need.

6. Protect secrets, state and transcripts

The security audit checks state, configuration, credentials, auth profiles, sessions and logs for unsafe permissions. Pay particular attention to:

• state or config writable by other users;
• config, credentials or auth profiles readable by other users;
• state stored in a synced consumer folder;
• shared tokens reused across Gateway and hook ingress;
• logs with sensitive-value redaction disabled;
• backups without encryption, ownership or a restoration test.

Separate business credentials from personal accounts. Give every secret a named owner and a revocation path. A backup that cannot be restored by the operator is not recovery evidence.

Evidence: permission audit, secret inventory, backup location and rotation procedure.

Block launch: credentials or transcripts are exposed beyond the intended operating system identity.

7. Verify runtime and failure recovery

The process being online does not prove that the Gateway can serve the workflow. Verify the control plane, RPC path and channels:

openclaw gateway status
openclaw status
openclaw gateway status --require-rpc
openclaw channels status --probe

Review logs during startup, an authorized request, a denied request and one expected failure. Restart the managed process and prove that the service, channel connection and intended agent recover.

Also test a dependency failure, an expired credential, a denied approval and a duplicate request. The workflow owner should know what stops, what retries and what moves to a person.

Evidence: health output, restart test, channel probe and one documented failure exercise.

Block launch: recovery depends on the person who built the system remembering an undocumented sequence.

8. Test rollback before widening access

A useful rollback returns the Gateway to a narrow state:

1. remove public forwarding, proxy routes or remote exposure;
2. bind the Gateway to loopback;
3. disable exposed channel DMs and groups;
4. deny host exec and disable elevated access;
5. rotate Gateway and affected integration credentials;
6. review recent audits, runs, tool calls and config changes;
7. rerun the deep security audit;
8. restore only the smallest access pattern the workflow needs.

Run the sequence once before launch. Record the owner, expected time, dependencies and evidence that access was actually denied after rollback.

Evidence: tested rollback record and rotation owners.

Block launch: the only response to overexposure is improvisation.

Copyable review record

Use this record for the launch review:

Gateway:
Owner:
Review date:
OpenClaw version:
Workflow:
Trust boundary:
Exposure pattern:
Allowed identities:
Reachable agents:
Reachable tools:
External credentials:
Audit findings:
Accepted warnings and owner:
Authorized connection test:
Unauthorized denial test:
Channel routing test:
Restart and recovery test:
Rollback test:
Decision: hold / conditional exposure / expose
Next review date:

The decision should remain hold when any stop condition is open. Conditional exposure means a narrow pilot with an owner, expiry date and explicit limits, not a permanent exception.

Frequently asked questions

Is a passing openclaw security audit --deep enough?

No. The audit is an important control, but the launch review also needs workflow-specific identity tests, channel routing, tool authority, credentials, recovery and rollback evidence.

Does sandboxing make an OpenClaw Gateway safe?

Sandboxing limits where selected tools run. It does not decide who can reach the agent, which tools exist, what credentials are available or whether elevated execution can escape the sandbox. Those controls must be reviewed together.

Are exec approvals a per-user permission system?

No. OpenClaw states that approvals reduce accidental execution risk but are not a per-user authorization boundary or a read-only filesystem policy. Separate trust boundaries still require architectural isolation.

Can an OpenClaw Gateway be public?

The official runbook treats public internet exposure as rare and high risk. It recommends an identity-aware proxy, TLS, rate limits, strict allowlists and sandboxed non-main sessions, with no direct public route to the Gateway.

How often should the checklist be repeated?

Repeat it after changes to exposure, proxy, channels, reachable agents, tool policy, credentials, plugins, skills or host boundaries. Also set a recurring review based on the impact of the workflow.

Official references

• OpenClaw Gateway exposure runbook
• OpenClaw security audit checks
• OpenClaw Gateway runbook
• Sandbox, tool policy and elevated access
• OpenClaw exec approvals

---

If the review reveals mixed trust boundaries, broad credentials or no tested recovery, redesign before exposure. Map a managed OpenClaw implementation for the business around the smallest workflow that can produce evidence without receiving unnecessary authority.