# OpenClaw Security Best Practices: A Practical Guide OpenClaw can access files, tools, apps, and workflows, so security matters from day one. This guide covers the key practices to protect your gateway, API keys, permissions, and setup. ## Why OpenClaw Security Matters OpenClaw is not just a chatbot. It runs commands, reads and writes files, calls APIs, controls a browser, and talks to messaging channels. That power is exactly why it is useful. It is also why a careless setup can leak credentials, expose private data, or run actions you did not intend. For a broader view of what OpenClaw actually does, see [what is OpenClaw](/blog/what-is-openclaw). Security should be part of the setup from the first install. Not something you add later after something goes wrong. ## What Makes OpenClaw Risky If Misconfigured? Most OpenClaw incidents trace back to a small set of risk surfaces. Knowing them helps you focus your hardening work. - Shell command access on the host - File read and write access across the user home - API keys and credentials stored in plain files - Browser or session access with logged-in accounts - Messaging channels that any user can DM - Third-party skills with unknown code paths - Public gateway exposure on a VPS - Prompt injection from emails, web pages, or issues ## OpenClaw Threat Model: What You Are Protecting Against Before you harden anything, get clear on the real threats. Different setups face different risks. | Threat | What It Looks Like | | --- | --- | | Credential leakage | API keys or tokens read by the agent and pasted into chat, logs, or a public file | | Data exfiltration | The agent reads private files and sends them to a remote service or channel | | Prompt injection | External content tells the agent to ignore rules, send data, or run commands | | Malicious skills | A third-party skill ships hidden behavior or exfiltrates data | | Gateway abuse | A public gateway is discovered and used by an attacker | | Host compromise | A weak shell command or untrusted script gives the attacker the machine | | Destructive commands | The agent runs rm, drop table, or git push force on the wrong target | | Unauthorized channel users | Strangers DM the agent and trigger sensitive actions | ## 1. Do Not Run OpenClaw on Your Primary Machine Your main laptop or work computer is usually the worst place to run a powerful AI agent. It holds your browser sessions, SSH keys, cloud credentials, password manager, wallets, and private app data. If the agent goes wrong, all of that is in reach. Safer options keep the blast radius small. - A dedicated VPS (see [install OpenClaw on VPS](/blog/install-openclaw-on-vps)) - A spare device or old laptop on your home network - A local virtual machine isolated from your host - A Docker container with restricted volumes (see [OpenClaw on Docker](/blog/openclaw-on-docker)) - A separate Linux user account with its own home directory Keep production and personal environments separate. The goal is simple: nothing important shares the same machine as the agent. ## 2. Use a Dedicated Identity for OpenClaw OpenClaw should not use your main personal or work accounts. Create separate identities for the agent. - A dedicated email for sign-ups and OAuth - Dedicated API keys per service, scoped to least privilege - A dedicated browser profile with no saved passwords from your main work - Dedicated messaging accounts where it makes sense - Separate SSH keys and cloud credentials If anything leaks, you rotate one identity instead of resetting your whole digital life. ## 3. Secure the OpenClaw Gateway The gateway is the control point. If someone reaches it, they can drive the agent. So it should never be casually exposed. For full setup details, see the [OpenClaw configuration guide](/blog/openclaw-configuration-guide) and [gateway connect pairing](/blog/openclaw-gateway-connect-pairing). - Bind the gateway to localhost when possible - Avoid public 0.0.0.0 exposure - Enable gateway authentication with strong random tokens - Protect default ports behind a firewall Bind the gateway to localhost and set an auth token in your config: ```json // ~/.openclaw/openclaw.json (excerpt) { "gateway": { "host": "127.0.0.1", "port": 6280, "auth": { "enabled": true, "token": "REPLACE_WITH_A_LONG_RANDOM_TOKEN" } } } ``` Generate a strong token instead of typing one: ```bash openssl rand -hex 48 ``` ## 4. Harden Network and VPS Access VPS deployments need stricter network protection because public IPs are scanned constantly. A fresh VPS sees login attempts within minutes. - Default-deny inbound with UFW or nftables - Use SSH key access, not passwords - Put any web access behind a reverse proxy with authentication - Use HTTPS with a real certificate - Reach the gateway over SSH port forwarding, a VPN, or Tailscale - Block direct gateway access from the public internet Minimal UFW setup on a fresh VPS: ```bash sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp # SSH only sudo ufw enable sudo ufw status verbose ``` Reach the gateway from your laptop over SSH instead of opening the port: ```bash # On your laptop ssh -L 6280:127.0.0.1:6280 user@your-vps # Then open http://127.0.0.1:6280 locally ``` If you do not want to run all this yourself, [managed OpenClaw hosting](/blog/best-openclaw-managed-hostings) on Ampere.sh handles the gateway, networking, and TLS for you. ## 5. Protect API Keys and Secrets API keys, tokens, and credentials are usually the highest-value target in an AI agent setup. Treat secret hygiene as a top priority. - Use scoped API keys with the minimum permissions needed - Avoid hardcoding secrets in skill files, prompts, or code - Keep .env, .ssh, .aws, and .kube outside agent-readable folders - Rotate keys on a schedule and after any suspected leak - Set strict file permissions on credential files - Never paste secrets into prompts or logs - Consider a password manager workflow (see [OpenClaw on 1Password](/blog/openclaw-on-1password)) Lock down secret files so only your user can read them: ```bash chmod 700 ~/.ssh ~/.aws ~/.kube chmod 600 ~/.ssh/id_ed25519 ~/.aws/credentials chmod 600 ~/secrets/openclaw.env ``` Load API keys from a file the agent does not read directly: ```bash # ~/secrets/openclaw.env (outside agent workspace) ANTHROPIC_API_KEY="..." OPENAI_API_KEY="..." # Start OpenClaw with the env file sourced set -a; source ~/secrets/openclaw.env; set +a openclaw start ``` ## 6. Configure a Safe Codebase Path OpenClaw should only access the project folder it actually needs. Pointing it at your full home directory or system paths is convenient and risky. - Set a narrow project workspace as the agent root - Separate project code, temp files, and outputs - Keep secrets outside the codebase path - Avoid broad paths like /home/user, /Users/name, /root, or /etc - Use separate workspaces for testing and production A safe folder layout looks like this: ```text # Safe /home/openclaw/workspace/my-project/ # agent root /home/openclaw/workspace/my-project/src/ /home/openclaw/workspace/my-project/tmp/ /home/openclaw/secrets/ # NOT inside workspace /home/openclaw/.ssh/ # NOT inside workspace # Risky / # full filesystem /root # root home /home/user # personal home /etc # system config ``` ## 7. Restrict Filesystem Access Even inside the workspace, OpenClaw should have limited read and write access. Defaults that allow the agent to roam wherever it wants are how secrets leak. - Allowlist safe folders the agent can read and write - Deny sensitive directories like .ssh, .gnupg, browser profiles, password stores, and cloud configs - Separate read and write permissions where the workflow allows it - Avoid full home-directory access - Prevent access to SSH keys, cloud credentials, and private config files ## 8. Limit Shell Commands and Dangerous Tools Unrestricted shell access is one of the highest-risk permissions any AI agent can have. A single bad command can wipe data or escalate privileges. - Block destructive commands by default - Require confirmation for risky actions like deletes, force pushes, or production deploys - Disable tools the agent does not need for its current workflow - Avoid sudo, root access, Docker socket access, and unrestricted package installs - Use approval mode for any action with real-world impact A simple deny-list pattern to keep in your config or skill rules: ```text # Always block, even with approval rm -rf / dd if= mkfs :(){ :|:& };: shutdown reboot # Require human approval before running rm -rf git push --force git reset --hard psql ... drop docker system prune -a ``` ## 9. Defend Against Prompt Injection Prompt injection can come from websites, emails, support tickets, GitHub issues, chat messages, documents, or even screenshots. The attacker hides instructions inside content the agent reads. - Treat all external content as untrusted input, not as instructions - Do not let external prompts override your system rules or safety settings - Require approval before file exports, sends, or shell commands triggered by external content - Keep secrets outside files the agent can reach in the same context as untrusted text - Use least-privilege tools so a hijacked prompt cannot do much The defense is not "smarter prompts." It is fewer powers and a human in the loop for sensitive actions. ## 10. Vet OpenClaw Skills Before Installing Skills and plugins are supply-chain risk. They may ship code, request permissions, or contain hidden behavior. They run with the agent's permissions, so a malicious or sloppy skill is a real problem. - Read the skill files before installing, not after - Check the source repo and publisher, and prefer trusted authors - Avoid unknown or unreviewed skills - Review the permissions and tools the skill requests - Pin versions where possible so updates do not surprise you - Remove unused skills so they cannot be triggered later List what is installed and prune what you do not use: ```bash openclaw skills list openclaw skills remove ``` For a curated starting point, see [best OpenClaw skills](/blog/best-openclaw-skills). ## 11. Protect Soul Docs and Agent Instructions Soul Docs and long-term instruction files shape how the agent behaves. If an attacker or a runaway prompt can rewrite them, they can change the agent's identity, rules, or trust boundaries. - Restrict write access to instruction and identity files - Review changes before saving memory or behavior updates - Keep trusted instruction files separate from untrusted content - Avoid letting external prompts rewrite agent identity or rules Make core instruction files read-only by default: ```bash chmod 444 ~/.openclaw/workspace/SOUL.md chmod 444 ~/.openclaw/workspace/IDENTITY.md # Flip back to 644 only when you intentionally edit them ``` ## 12. Secure Messaging Channels and Integrations WhatsApp, Telegram, Discord, Slack, browsers, and third-party integrations can become attack surfaces if any user can DM the agent and trigger actions. - Use DM allowlists so only known users can talk to the agent - Require mentions in groups instead of replying to every message - Disable public access where it is not needed - Limit channel permissions to read-only where possible - Use dedicated accounts for the agent - Avoid connecting OpenClaw to noisy public communities Separate personal channels from production agent channels so a bad actor in one community cannot reach your real workflows. ## 13. Monitor Logs and Audit Activity You need to know what the agent is doing, especially after adding new tools, skills, channels, or remote access. - Review command history regularly - Monitor failed access attempts on the host and gateway - Check messages from unknown channel users - Audit installed skills and their last update dates - Review unusual file access patterns - Keep logs without writing secrets into them Quick audit commands to run on a schedule: ```bash openclaw status openclaw skills list openclaw logs --since 24h | grep -Ei 'error|denied|unauthorized' ``` For backups and recovery, see the [OpenClaw backup guide](/blog/openclaw-backup-guide). ## 14. Keep OpenClaw Updated Outdated OpenClaw installs, skills, and dependencies become security liabilities. Updates fix bugs, patch dependencies, and improve defaults. - Update OpenClaw regularly, not only when something breaks - Patch system and runtime dependencies - Recheck configs after updates so defaults do not slip back in - Audit skills after major releases - Restart the gateway after updates - Re-run a security pass after changing the gateway, channels, or tools Standard update flow: ```bash openclaw --version openclaw update openclaw gateway restart openclaw status ``` For long-running setups, see [run OpenClaw 24/7](/blog/run-openclaw-24-7). ## OpenClaw Security Checklist Use this checklist before running OpenClaw seriously. Tick everything before going live. - Gateway bound to localhost or private network - Gateway authentication enabled with a strong token - VPS firewall active with default-deny inbound - API keys scoped to least privilege - Secrets stored outside agent-readable folders - Safe codebase path configured (narrow project-only workspace) - Filesystem access restricted to project folders - Dangerous shell commands blocked or gated by approval - Skills reviewed, pinned, and trimmed - Soul Docs and identity files protected from runaway writes - Channel users allowlisted, especially for DMs - Logs monitored and command history reviewed - Updates applied on a regular schedule - Backups configured for config, skills, and important data ## Common OpenClaw Security Mistakes Most issues are not exotic attacks. They are small misconfigurations repeated across many setups. | Mistake | Why It Is Risky | Safer Fix | | --- | --- | --- | | Exposing the gateway publicly | Attackers can scan IPs and reach the control surface | Bind to localhost and use a private tunnel or VPN | | Using your main API keys | One compromise affects production and personal use | Use scoped, dedicated keys per project | | Using a broad codebase path | Agent may access private files outside the project | Configure a narrow project-only workspace | | Giving full filesystem access | The agent can read SSH keys, browser data, and secrets | Allowlist project folders only | | Installing random skills | Supply-chain risk from unknown publishers | Review the skill source before installing | | Running on your main laptop | Personal data and sessions are too exposed | Use a VPS, VM, container, or dedicated device | | Skipping updates | Old versions miss fixes and safer defaults | Update on a regular schedule and re-audit | | No human approval on writes | One bad prompt can send, delete, or post the wrong thing | Require approval on sensitive tool calls | ## Final Verdict: Secure OpenClaw by Reducing Blast Radius OpenClaw security is not about one magic setting. It is about isolation, least privilege, gateway protection, secret hygiene, safe codebase paths, tool limits, skill review, and regular audits. If you build the setup so that any single mistake stays small, you get most of the benefit. The agent stays useful. The damage from any one failure stays bounded. If you would rather skip the manual hardening, run [managed OpenClaw](/blog/openclaw-managed-vs-self-hosted) on Ampere.sh. You still get the power. The platform handles the gateway, isolation, and infrastructure for you. ## Frequently Asked Questions **Is OpenClaw safe to use?** OpenClaw can be safe if you configure it properly. The main risks come from exposed gateways, broad file access, unsafe skills, weak API key handling, and prompt injection. **Should the OpenClaw gateway be public?** No. Keep the OpenClaw gateway private whenever possible. Use localhost binding, strong authentication, and safer access methods like SSH tunneling, VPN, or Tailscale. **How do I protect OpenClaw API keys?** Use dedicated API keys, limit their permissions, keep them outside agent-readable folders, rotate them when needed, and never paste them into prompts, logs, or shared files. **Can OpenClaw be hacked through prompt injection?** Yes. Prompt injection can come from websites, emails, documents, chat messages, or GitHub issues. Limit agent permissions and require approval before risky actions. **Are OpenClaw skills safe to install?** Not always. Treat skills like third-party code. Review the source, check permissions, use trusted publishers, avoid unknown skills, and remove anything you do not use. **Should I run OpenClaw on my main computer?** For serious use, no. A dedicated VPS, VM, Docker container, or separate machine is safer because it limits access to your personal files, browser sessions, and credentials. **What is the best way to secure OpenClaw?** Use least privilege: keep the gateway private, isolate the runtime, scope API keys, restrict file and tool access, review skills, secure channels, and audit activity regularly.