Work through each control area before the agent touches a real system. Every item comes from the article; the blanks record what you actually deployed.
Deployment / owner:
Isolation
- [ ] The agent runs in a dedicated environment (VM, hardened container host, isolated cloud instance, or purpose-built sandbox).
- [ ] The agent does not run on an everyday laptop with access to the home directory, browser profiles, SSH keys, cloud credentials, or local application data.
- [ ] The agent has its own operating environment.
Minimum privileges
- [ ] The OpenClaw process does not run as root.
- [ ] Only the files and systems it actually needs are mounted; large portions of the host filesystem are not.
- [ ] Documents live in a dedicated working directory; writes are limited to specific locations.
- [ ] Read-only mounts are used where possible.
- [ ] Containers are non-root.
- [ ] Root filesystems are read-only.
- [ ] Unnecessary operating system capabilities are disabled.
- [ ] Process execution is restricted.
- [ ] CPU and memory are limited.
Minimum this agent needs to complete its job:
Network egress allowlist
- [ ] Outbound internet access is not unrestricted.
- [ ] Only approved destinations are reachable; everything else is blocked by default.
- [ ] A connection to an unapproved endpoint is rejected at the network layer.
| Allowlisted destination | Purpose | Approved by | Date |
|---|---|---|---|
Credentials
- [ ] No reusable credentials sit inside the agent runtime (no AWS_SECRET_KEY, GOOGLE_TOKEN, GITHUB_TOKEN, SLACK_TOKEN style environment variables).
- [ ] Credentials live behind a broker; the agent requests an action and a policy layer decides whether it is allowed.
- [ ] The credential is injected at the boundary or exchanged for a short-lived token; the agent never sees the underlying secret.
- [ ] Any credential that must exist in the environment is narrowly scoped.
- [ ] It is short-lived.
- [ ] It is read-only where possible.
- [ ] It is tied to a dedicated service account.
- [ ] It is separate from personal or administrative identities.
- [ ] No global administrator account has been given to the agent.
Dedicated service accounts
- [ ] Every external service has an identity specifically created for the agent.
- [ ] Each identity has the minimum permissions required.
- [ ] The agent account can be revoked without disabling your own identity.
| Service | Agent identity | Permissions granted | Revocation path |
|---|---|---|---|
Tool sandboxing
- [ ] Tools run inside a sandbox (WASM-based execution, isolated containers, restricted shell environments, or dedicated browser sandboxes).
- [ ] Tools do not automatically inherit access to the agent host.
- [ ] A command that manipulates a file only sees the files required for that task.
- [ ] Browser automation lives in its own sandbox.
- [ ] Third-party plugins do not inherit every privilege of the main runtime.
Plugin review
Answer for each plugin before adding it.
- [ ] Who maintains it?
- [ ] Is the source available?
- [ ] What permissions does it request?
- [ ] Does it execute inside the main process?
- [ ] Can it access secrets?
- [ ] Can it access the host filesystem?
- [ ] Can it initiate arbitrary network traffic?
- [ ] How quickly is it patched?
Human approval categories
Read automatically. Write carefully. Delete reluctantly.
- [ ] Sending external email
- [ ] Deleting files
- [ ] Deleting messages
- [ ] Changing cloud infrastructure
- [ ] Modifying identity or security settings
- [ ] Installing software
- [ ] Making purchases
- [ ] Transferring money
- [ ] Accessing sensitive records
- [ ] Publishing content publicly
Spending and resource limits
| Limit | Value set | Circuit breaker action |
|---|---|---|
| API spend | ||
| Cloud spend | ||
| Transaction size | ||
| Number of API calls | ||
| Number of spawned agents | ||
| Execution time | ||
| CPU and memory | ||
| Amount of data transferred |
Log fields
- [ ] User requests
- [ ] Agent actions
- [ ] Tool invocations
- [ ] Policy decisions
- [ ] Credential requests
- [ ] Network destinations
- [ ] Files accessed
- [ ] External messages sent
- [ ] Authentication events
- [ ] Configuration changes
Kill switch
One action should be able to do all of the following.
- [ ] Stop execution
- [ ] Disable tool access
- [ ] Revoke credentials
- [ ] Terminate network access
- [ ] Prevent new jobs
- [ ] Preserve logs
Kill switch location / who can trigger it:
Kill switch last tested / observed time to full stop:
Operate and review
- [ ] Memory and long-lived context are treated as untrusted input: writes are gated, tagged with their source, and reviewable (see the agent authority review).
- [ ] Messages between agents, and between the agent and its tools, are authenticated; a tool or sub-agent cannot be impersonated by content the agent read.
- [ ] Outbound traffic is monitored as well as allowlisted, so an unexpected destination attempt is seen, not only blocked.
- [ ] The runtime, base image, plugins, and model version have an owner and an update cadence; the last update date is recorded.
- [ ] Logs are retained for a stated period in a location the agent cannot modify.
- [ ] An incident procedure exists for the agent misbehaving: who is told, what is preserved, when the kill switch is used, how the affected systems are checked.
- [ ] Approval requests are reviewed for volume; if approvers are waving through dozens a day, the approval categories are too broad to be meaningful.
- [ ] This checklist is re-run on a stated cadence and after any change to capabilities, credentials, plugins, network rules, or model.
Deployment inventory entry (system list, service ownership map) made on:
Next review date / change triggers:
Reviewed by / date:
This checklist covers the deployment environment. It does not judge whether the agent's task and authority are appropriate; use the agent authority review for that.