Security

OpenClaw's security model starts from the assumption that the model can make mistakes. The goal is to limit impact by constraining access control, execution scope and privilege boundaries before trusting the model to behave perfectly.

Gateway Troubleshooting Exec Approvals Pairing

Run the Security Audit First

Basic / deep / fix

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix

Risk Priorities

1. Any open DM or open group setup combined with high-privilege tools should be fixed first.

2. Any public network exposure without strong auth or with weak tokens should be corrected immediately.

3. Browser control, remote CDP and node execution are operator-level capabilities and should never be exposed casually.

4. Lock down permissions on ~/.openclaw and only load plugins or Skills you explicitly trust.

Three Core Security Surfaces

Identity

Who can send messages

DM pairing, allowlists, group allowlists and mention rules decide who can actually trigger the system.

Scope

What the bot can do

Tool profiles, sandbox isolation, exec approvals, device pairing and browser exposure together define the action boundary.

Storage

Where state and credentials live

Session logs, provider credentials, channel tokens and allowlists all live on disk, so disk access itself is part of the trust boundary.