Security Best Practices

⏱️ 30 min

OpenClaw security does not begin with an impossible promise to block every prompt injection. First constrain who can trigger the agent and what the agent can do after it is triggered. The official security guide uses the same priority: lock down open DMs and groups, then review tools, network exposure, filesystem permissions, plugins and models.

Confirm the trust model

OpenClaw targets a personal-assistant trust model: one trusted operator boundary per Gateway. It is not a hostile multi-tenant isolation layer for unrelated users sharing one privileged agent.

If two users or organizations do not trust each other, split Gateways and credentials. Higher-risk deployments should also use separate OS users or hosts.

Risk factors multiply

External input × Available tools × Data scope × Automatic execution
                                           ↓
                                       Blast radius

A public room alone may not create an incident. A public room combined with shell, file and network write access gives misleading or malicious content real execution power.

Four layers to review

Layer	Review	Safe baseline
Entry	DMs, groups, pairing and allowlists	Deny unknown senders; require explicit group triggers
Gateway	Bind address, authentication and remote access	Prefer loopback; never expose an unauthenticated Gateway publicly
Tools	Shell, filesystem, browser, network and cron	Minimum privilege; ask before high-impact actions
Data	Config, credentials, logs and workspace	Restrict readable scope; never place secrets in skills or chat

Run the official security audit

After security-related configuration changes or before exposing a network surface:

openclaw security audit

Probe the running Gateway when needed:

openclaw security audit --deep

--fix applies deliberately narrow remediations. It cannot decide which permissions the business needs, so inspect the scope first:

openclaw security audit --fix

Permission matrix

Do not write “administrators may use every tool.” Record actions at a reviewable level:

Action	Default	Allow condition	Rollback
Read named workspace	Allow	Workspace paths only	Stop and record the accessed path
Modify a file	Ask	Show target and change summary	Restore from version history
Execute shell	Deny	Approve the exact command	Terminate process and preserve logs
Send an external message	Ask	Show recipient and final body	Stop later sends and notify operator
Create cron work	Ask	Record cadence, input and owner	Disable task and record last run

What pairing and allowlists do not solve

Pairing and allowlists control who can directly request work. They do not sanitize web pages, attachments, forwarded messages or tool results included in a trusted user's context.

Tool policy, workspace scope and automatic-execution rules are still required.

Review skills and plugins

Answer five questions before installation:

Can you verify the source and maintainer?
Which files, environment variables or credentials can it read?
Which domains or external services can it contact?
Does it execute scripts or install dependencies?
After removal, how are credentials and scheduled work revoked?

If you cannot inspect the script, do not install it into a Gateway holding production credentials.

Practice: complete the security baseline

Gateway exposure is limited to the required network scope;
DM and group entry points use pairing or allowlists;
filesystem access is restricted to the named workspace;
shell, browser writes, messaging and cron default to deny or ask;
credentials do not appear in skills, prompts or log examples;
openclaw security audit has been run and recorded;
stop, rollback and operator-notification procedures are written.

Done means you can take any external input and identify the maximum data and action scope it can reach.