The OpenClaw Security Checklist
10 controls that separate a safe agent deployment from an expensive incident. Most failures come from over-permissioned setups, not model intelligence. This checklist covers the practical controls — things you can do today, not theoretical threat models.
Before you deploy
1. Run in containers, not bare metal
An agent running directly on your laptop or server has access to everything you do — files, credentials, network. A container (Docker, Podman) limits the blast radius if something goes wrong.
How: Use the Docker-first setup guide. Mount only the directories the agent needs. Don't bind-mount your home folder.
Why it matters: If an agent gets a malicious instruction via prompt injection, container isolation prevents it from reading your SSH keys, browser cookies, or password manager files.
2. Use separate API keys with spending limits
Never share your personal or company-wide API key with an agent. Create a dedicated key with a hard spending cap.
How: In your LLM provider dashboard, create a new key labeled "agent-prod" or similar. Set a monthly limit that matches your expected usage plus 20% buffer. Monitor weekly.
Risk if skipped: A runaway loop or prompt injection attack could burn through thousands in API credits in hours.
3. Start read-only, then graduate to write access
Give the agent read access first. Watch what it tries to do for a few days. Then selectively enable write permissions for specific tools.
How: OpenClaw's tools.exec.security setting supports allowlist mode — define exactly which binaries the agent can run. Start with read-only commands (ls, cat, curl), then add write tools as trust builds.
Why it matters: You can't un-send an email or un-delete a file. Read-only mode lets you verify the agent's judgment before giving it real power.
4. Don't connect passwords, financial systems, or admin panels
Your agent doesn't need access to your bank, your domain registrar, or your infrastructure admin panel. If it does need to interact with a sensitive system, use a scoped API token — never a full login.
How: Create service accounts with minimum permissions. Never store root/admin credentials in agent-accessible config files.
Risk if skipped: A compromised agent with admin access to your DNS could redirect your domain. With bank access, it could initiate transfers.
5. Review third-party skills before installing
Skills are code that runs with your agent's permissions. Treat them like browser extensions — read the source before installing.
How: Check the skill's SKILL.md for what tools it uses. Search for exec, web_fetch, or message calls. If a skill needs network access or shell commands, understand why before enabling it.
Why it matters: A malicious skill could exfiltrate data, send messages as you, or modify your files — all while looking like normal agent behavior.
During deployment
6. Monitor logs daily during the first two weeks
The first two weeks of deployment surface 90% of permission issues, unexpected behaviors, and integration bugs. After that, weekly review is usually enough.
How: Check openclaw status daily. Review tool call logs for unexpected patterns — especially exec, message, and web_fetch calls you didn't expect.
7. Patch regularly
Agent frameworks evolve fast. Security patches, permission model changes, and dependency updates happen frequently.
How: Check for updates weekly. Read changelogs before updating — breaking changes in permission models can inadvertently widen access.
8. Use a dedicated email and messaging account
If your agent sends emails or messages, use a dedicated account — not your personal one. This creates an audit trail and limits damage if credentials leak.
How: Create agent@yourdomain.com or a dedicated Telegram/Discord bot account. Set up forwarding so you see what the agent sends.
Ongoing operations
9. Avoid agent social networks until the threat model is clear
Agent-to-agent communication is powerful but introduces new attack surfaces: prompt injection via other agents, trust chain exploits, and data leakage through shared contexts.
How: If you enable multi-agent communication, treat every incoming agent message as untrusted input. Apply the same input validation you'd use for user messages.
10. Keep a kill switch ready
You should be able to stop your agent in under 30 seconds from any device. Practice it before you need it.
How: Know your shutdown command (openclaw gateway stop). Bookmark your provider's API key revocation page. If using cron jobs, know how to disable them (/cron list → disable). Test the kill path quarterly.
Risk if skipped: When something goes wrong at 2 AM, you don't want to be reading documentation to figure out how to stop it.
Quick-reference severity table
| Control | Severity if skipped | Effort to fix |
|---|---|---|
| 1. Containers | Critical | Medium (one-time setup) |
| 2. API key limits | High | Low (5 minutes) |
| 3. Read-only first | High | Low (config change) |
| 4. No admin access | Critical | Low (don't connect it) |
| 5. Skill review | High | Medium (per skill) |
| 6. Log monitoring | Medium | Low (daily habit) |
| 7. Patching | Medium | Low (weekly check) |
| 8. Dedicated accounts | Medium | Low (one-time setup) |
| 9. Agent networks | Medium | Low (don't enable yet) |
| 10. Kill switch | High | Low (know the command) |
The pattern behind most agent incidents
Nearly every agent security incident follows the same pattern: too many permissions + too little monitoring + no spending cap. Fix those three things and you've eliminated 80% of your risk surface.
The remaining 20% is prompt injection — which is a model-level problem, not a deployment problem. Read Prompt Injection 101 for that.
Need help locking this down? Setting up secure agent infrastructure is exactly what we do. Bridgital can audit your current setup, implement these controls, and monitor ongoing operations — so you get the productivity gains without the risk.
Agent Intel — Weekly
Practical agent security and automation insights. No hype.