The OpenClaw workflow security checklist we use before turning on tools

An OpenClaw workflow is safe enough to enable when its trigger is trusted, its tools are limited to the job, its secrets stay outside prompts, and its irreversible actions have explicit guards. Start with authority, not with clever prompt wording.

This checklist is for the moment a useful demo asks for email, browser, shell, messaging, or production access. That is where the workflow stops being a text generator and starts becoming an operator. Treat the permission change accordingly.

1. Define the trust boundary

• Who can send instructions to this agent?
• Can untrusted people place text into the context through email, documents, web pages, tickets, or group chat?
• Does the Gateway serve one trusted operator boundary, or are mutually untrusted users sharing it?
• Which accounts and machines can the workflow reach?

Official OpenClaw guidance assumes one trusted operator boundary per Gateway. If mutually untrusted users need access, separate the Gateways and preferably the OS users or hosts. A session key routes context. It is not a tenant security boundary.

2. Inventory the blast radius

Write down the worst credible action for each tool. If an inbox summarizer also holds a production deployment token, the workflow has inherited a risk it does not need. Remove the token instead of asking the prompt to be careful around it.

3. Keep secrets out of the conversation

Do not paste API keys into SOUL.md, HEARTBEAT.md, task prompts, template examples, or chat. Supply credentials through host configuration or a secret-management path supported by the integration. Scope each credential to the smallest useful account and permission set.

• Use separate credentials for separate environments.
• Prefer read-only scopes when the workflow only reads.
• Rotate credentials after accidental prompt or log exposure.
• Keep state, auth, and config files readable only by the intended OS user.
• Never publish a template with live identifiers or copied production output.

4. Treat fetched content as untrusted

An email, web page, attachment, issue, or document can contain text that looks like instructions. The workflow should know which text is operator intent and which text is material to inspect. That distinction belongs in the architecture as well as the prompt.

A useful pattern is read, extract, decide, act. The reader gets only the tools needed to collect and structure data. A later step applies a narrow policy. High-impact actions require either a deterministic rule or explicit operator approval. Do not browse an arbitrary page and make a privileged change in the same unconstrained turn.

5. Put hard gates around irreversible actions

1. Resolve the exact target with a read-only check.
2. Show or record the proposed mutation.
3. Confirm that the workflow has authority for this class of action.
4. Use a stable idempotency or deduplication key.
5. Execute once and save the provider's result identifier.
6. Verify the resulting state independently.

Deleting a file, sending a customer message, merging code, and charging a card are different actions, but they share the same shape. Ambiguity before execution should block the run. Ambiguity after execution should trigger reconciliation, not a blind retry.

6. Audit the actual configuration

openclaw security audit
openclaw security audit --deep
openclaw security audit --json

Run the audit after meaningful configuration changes and before exposing new network surfaces. Review findings about inbound policy, tool reach, browser control, file permissions, plugins, sandbox drift, and model hygiene. Do not treat an automated fix as a substitute for understanding the trust boundary.

7. Test the ugly paths

• A sender includes 'ignore previous instructions' in the content being summarized.
• The external API succeeds but the agent times out before closeout.
• The same event is delivered twice.
• A credential loses a required scope.
• The Gateway restarts during the run.
• The target file, customer, repository, or environment is ambiguous.
• The model proposes an action outside the workflow's stated purpose.

A workflow is not ready because the happy path worked once. It is ready when the unhappy paths stop safely, leave evidence, and tell the operator what to do next.

A simple go/no-go scorecard

If any answer is wrong, keep the workflow read-only while you fix it. Read-only agents can still be extremely useful. Authority should expand because the controls earned it, not because the demo looked impressive.