Secure OpenClaw before it reaches your files, browser, shell, and keys.
OpenClaw is useful because it can act across local tools. That same capability makes exposed gateways, broad credentials, and unrestricted tool calls the security boundary to harden first.
Start with a constrained runtime
Control baseline
The highest-value OpenClaw security controls.
Armorer focuses on the runtime boundary: what the agent can reach, what it can change, what credentials it can use, and which actions require review.
Keep OpenClaw local by default
Bind local gateways and control surfaces to loopback unless there is a reviewed reason to expose them.
Scope tools and credentials
Treat filesystem, browser, shell, MCP, and SaaS credentials as separate risk surfaces with narrow grants.
Monitor runtime behavior
Watch command execution, file access, prompt flow, and tool calls for sensitive data movement.
Practical checklist
Before running OpenClaw against real work.
Use this as the operator checklist before connecting OpenClaw to sensitive repos, browsers, APIs, or production-adjacent systems.
Run OpenClaw from a dedicated workspace with limited secrets and no broad environment dump.
Use token-based access for any local control plane or gateway surface.
Disable or narrow risky tools before connecting OpenClaw to real repositories, browsers, or SaaS accounts.
Put shell, filesystem, network, and browser actions behind a reviewed policy layer.
Review threat-intel findings before exposing an OpenClaw instance beyond localhost.
Use Armorer Guard to scan prompts, tool calls, and runtime actions before they become system changes.
OpenClaw agent profile
Install details, risk notes, and compatible skills.
Gateway security baseline
The threat-intel control record for OpenClaw gateway hardening.
Armorer Guard
Scan prompts, outputs, and tool calls before they become actions.
Armorer Guard walkthrough
How Guard wraps OpenClaw with runtime security checks.