This OpenClaw beginner security checklist addresses a concrete problem: the main session can run tools on the host. Before granting SSH access or exposing the Gateway remotely, classify ports, secrets, restart behavior, logs, backups, and messaging-channel permissions as red, yellow, or green. Red means stop. Yellow means document and constrain the risk. Green means the boundary has been checked and is acceptable for the intended use. The short answer: keep the Gateway local unless remote access is necessary, isolate tool execution where practical, and require an operator decision before any external action.
The preflight starts with the trust boundary
The evidence packet was reviewed on 2026-08-15 against the current public OpenClaw documentation. It supports configuration guidance, not a guarantee that this checklist secures every host.
| Evidence | Reviewed condition | Scope |
|---|---|---|
| OpenClaw README security model | One local-first Gateway acts as the control plane | Sessions, channels, tools, and events |
| Gateway security guide | Personal-assistant model, not a hostile multi-tenant boundary | Exposure, tool access, secrets, and workspace trust |
| Sandboxing guide | Main and non-main sessions can have different execution boundaries | Local containers and SSH/OpenShell options |
| CLI security reference | The security command can audit and fix common footguns | Findings, fixes, and explicit suppressions |
| Beginner autocomplete surface | Beginner setup queries are visible | Attention signal only, not demand or incident evidence |
Quick answer:
Red: remote exposure, host tool access, or external messaging without a reviewed boundary.
Yellow: a necessary capability exists, but its permissions, recovery path, or evidence remain incomplete.
Green: the capability is limited, observable, recoverable, and approved for the intended operator.
This classification is intentionally conservative. OpenClaw is described as a personal assistant system. That is different from a boundary designed to contain mutually hostile users.
Treat SSH access as the end of the review, not the beginning of setup.
Ports reveal the first avoidable risk
Start by listing every interface that can reach the Gateway. Do not assume “local-first” means “local-only.” A local-first control plane can still become remotely reachable through configuration, forwarding, or an SSH path.
Mark the port boundary red when you cannot explain who can connect, where the listener is bound, or what authentication protects it. Mark it yellow when remote access is necessary but the allowed source, authentication method, or revocation procedure is unclear. Mark it green only when the listener matches the intended boundary and unnecessary exposure has been removed.
Record the result as an artifact:
Gateway listener:
Expected callers:
Remote access required:
Authentication boundary:
Revocation method:
Operator approval:
Status: RED / YELLOW / GREEN
The official README directs operators to review security, Gateway exposure, sandboxing, and configuration guidance before remote exposure. That is the useful stop rule: if the exposure cannot be described plainly, do not hand over SSH access.
Secrets can cross workspace boundaries quietly
The security guide notes that workspace-local environment files can be loaded for agents and tools. That makes the workspace itself part of the secret boundary.
Inventory the kinds of secrets that may be present without copying their values into the checklist. Check environment files, shell configuration, mounted directories, tool configuration, and inherited process variables. The question is not merely whether a secret exists. It is whether the session or tool can read it.
A secret boundary is red when broad host access can expose credentials unrelated to the task. It is yellow when a required secret is available but rotation, scope, or ownership is uncertain. It becomes green when only required secrets are reachable, their permissions are narrow, and an operator knows how to revoke them.
Do not place secret values in screenshots, logs, backup notes, or audit artifacts. Record names or categories only.
A sandbox can reduce blast radius, but it does not turn an unknown workspace into a trusted one.
Restarts, logs, and backups decide whether recovery is real
Security reviews often focus on initial access and skip failure recovery. That is a mistake even when no incident has occurred.
For restarts, determine what launches automatically, which configuration returns, and whether remote or channel access becomes active again without review. Mark the boundary red if a restart restores an unreviewed exposure. Use yellow if startup behavior is unknown. Use green when the expected state is documented and can be verified after restart.
For logs, identify what is recorded, who can read it, and whether secrets or sensitive message content may appear. A missing audit trail is not automatically safer; it can make unexpected actions harder to review. A log boundary is green only when it provides useful evidence without becoming another secret store.
For backups, identify what must be recoverable and what must never be copied casually. Test whether the recovery instructions are understandable without assuming the original host remains available. The verified evidence does not establish any particular backup mechanism, retention period, or recovery result, so those choices remain host-specific.
Messaging channels need a human boundary
A connected messaging channel can turn an incoming message into tool-capable work. The important distinction is between receiving a request, preparing an action, and performing an external action.
Mark the channel red if an unknown sender can trigger host tools, autonomous messaging, payments, account changes, or remote exposure. Mark it yellow if sender approval exists but tool permissions or outbound actions remain broad. Mark it green when approved senders are defined, non-main sessions use an appropriate boundary, and consequential actions require operator review.
The available evidence does not support autonomous channel messaging or account-changing actions without an operator decision. It also does not prove that every third-party skill is safe. Review channel permissions and tool access as separate controls.
Sender approval answers who may ask; tool policy answers what the system may do.
Copy this pre-SSH review card
OPENCLAW BEGINNER SECURITY PREFLIGHT
PORTS
[ ] I know every interface that can reach the Gateway.
[ ] Remote exposure is necessary and explicitly approved.
[ ] I can revoke remote access.
SECRETS
[ ] I reviewed workspace-local environment files.
[ ] Tools can reach only the secrets they require.
[ ] Secret values are absent from logs and review artifacts.
SESSIONS AND SANDBOXING
[ ] Main-session host access is intentional.
[ ] Non-main sessions use an appropriate boundary.
[ ] I understand that sandboxing is not a perfect security boundary.
RESTARTS
[ ] I know what starts automatically.
[ ] Exposure does not return silently after restart.
[ ] I can verify the expected state after restart.
LOGS AND BACKUPS
[ ] Logs support review without unnecessarily storing secrets.
[ ] Backup scope and access are documented.
[ ] Recovery instructions do not depend on assumptions I have not checked.
MESSAGING CHANNEL
[ ] Approved senders are defined.
[ ] Incoming messages cannot silently authorize consequential actions.
[ ] External actions require operator review.
AUDIT
[ ] I ran the documented OpenClaw security command.
[ ] I reviewed each finding rather than suppressing it by default.
[ ] Every suppression records an explicit risk decision.
FINAL STATUS: RED / YELLOW / GREEN
RED ITEM OWNER:
REQUIRED CHANGE:
OPERATOR DECISION:
The limit is unknown local context
This checklist cannot discover every local secret, network route, unsafe permission, malicious third-party skill, or future advisory. OpenClaw configuration and bundled defaults can change. The correct sandbox backend depends on the host, tool requirements, and trust boundary.
The documented security command can find and fix common footguns, but suppressions can hide standing risk. An empty-looking report after broad suppression is not equivalent to a reviewed system.
My final decision is simple: do not grant SSH access or expose the Gateway while any red item remains. Yellow is acceptable only when the necessity, constraint, owner, and recovery path are written down. Recheck the current official documentation at setup time, because this card is a decision aid, not a security guarantee.
Related build logs
TL;DR: Keep OpenClaw local until ports, secrets, restarts, logs, backups, sessions, and messaging boundaries are all reviewed with no unresolved red item.
The next episode turns this preflight card into a compact post-install review artifact.
Continue with the dated source map, related beginner guides, and current limits on Builderlog
Start with the free decision tools. Inspect the scope and evidence before choosing any paid next step.
Top comments (0)