How to Use OpenClaw Safely: Security Best Practices for 2026

Top Security Risks

Before we get to the rules, you need to understand what can go wrong. OpenClaw is a powerful tool that connects to AI model APIs, executes code, manages files, and interacts with external services. That power comes with real security risks if you do not configure it carefully.

The three biggest risks are:

1. Exposed Gateway Token

OpenClaw's gateway is the API endpoint that accepts commands and returns responses. It is protected by a gateway token — essentially a password. If you expose this gateway over plain HTTP (no SSL), anyone who can observe your network traffic can steal the token. With the token, they have full control of your agent. They can read your conversations, execute code on your server, and access any API keys stored in your OpenClaw configuration.

This is the most critical risk because it gives an attacker complete access with minimal effort.

2. Shared API Keys

Many operators use the same API keys (OpenAI, Anthropic, Google) across multiple OpenClaw instances or share them with team members by pasting them in chat messages, storing them in unencrypted files, or committing them to Git repositories. Shared keys create two problems: you cannot audit who performed which action, and a single compromised key affects every system that uses it.

3. Unlimited Agent Permissions

Running OpenClaw with Full autonomy, no sandbox, and unrestricted file system access is like giving a stranger the keys to your house and saying "do whatever you want." If the AI model hallucinates a destructive command, or if a prompt injection attack tricks the agent into performing unintended actions, the damage is unlimited.

Rule 1: Always Use HTTPS

This is non-negotiable. Your OpenClaw gateway must be behind HTTPS with a valid SSL certificate. There are three ways to achieve this:

• Caddy reverse proxy: Caddy automatically obtains and renews Let's Encrypt certificates. It is the easiest option. A two-line Caddyfile is all you need.
• Nginx + certbot: The traditional approach. More configuration but more control.
• Tailscale: If you do not need public internet access, Tailscale provides encrypted tunnels between your devices with HTTPS certificates. Zero configuration.

If your OpenClaw instance is only accessed from your local network or a VPN, Tailscale is the simplest and most secure option. If it needs to be accessible from the public internet (for webhook callbacks from Telegram, WhatsApp, etc.), use Caddy or Nginx with Let's Encrypt.

Rule 2: Unique API Keys Per Deployment

Every OpenClaw instance should have its own set of API keys. Every team member should have their own keys. Never share keys across deployments.

For AI model providers (Anthropic, OpenAI, Google), create separate API keys for each OpenClaw instance and set appropriate spending limits on each key. This way, if one key is compromised, you can revoke it without affecting other deployments.

Store API keys in environment variables, not in configuration files. Use a .env file that is excluded from version control:

# .env file — never commit this
ANTHROPIC_API_KEY=sk-ant-...
OPENAI_API_KEY=sk-...
GATEWAY_TOKEN=your-random-token-here

If someone shares an API key with you in a chat message, consider that key compromised. Generate a new one immediately.

Rule 3: Enable Sandbox Mode

Sandbox mode isolates code execution inside a Docker container or SSH environment. Without it, your agent executes code directly on your host system with whatever permissions the OpenClaw process has.

Enable Docker sandbox at minimum. For production deployments, use SSH sandbox for even stronger isolation. See our Sandbox Mode Setup Guide for detailed instructions.

Rule 4: Start With Supervised Autonomy

Never start a new deployment on Full autonomy. Always begin with Supervised mode, where the agent must request approval before executing actions. Watch what the agent does for at least a week. Learn its patterns. Identify any unexpected behaviors.

Only move to Full autonomy for specific, well-tested workflows — and even then, use allowlists to restrict which actions can run without approval.

Rule 5: Restrict Network Access

Your OpenClaw sandbox should have the minimum network access required. If the agent does not need to make outbound HTTP requests, set the sandbox network mode to "none." If it needs access to specific APIs, use firewall rules to allow only those destinations.

On the host level, use a firewall (ufw, iptables, or cloud security groups) to restrict which ports are exposed. OpenClaw's gateway port should only be accessible through your reverse proxy, not directly from the internet.

Rule 6: Rotate Secrets Regularly

Change your gateway token, API keys, and SSH keys on a regular schedule. Monthly rotation is a good baseline for most deployments. For high-security environments, rotate weekly.

When you rotate keys:

1. Generate the new key
2. Update your OpenClaw configuration
3. Restart the OpenClaw service
4. Revoke the old key at the provider

Do not skip step 4. An old key that still works is a liability.

Rule 7: Limit File System Access

Mount only the directories your agent needs into the Docker container. Never mount your entire home directory or root file system. A minimal volume mount looks like:

volumes:
  - ./data:/data          # Agent data only
  - ./skills:/skills:ro   # Skills directory, read-only

The :ro flag makes the skills directory read-only inside the container, preventing the agent from modifying skill files.

Rule 8: Monitor and Log Everything

OpenClaw logs every action the agent takes. Enable verbose logging in production and review logs regularly. Look for:

• Unexpected code execution
• Unusual API calls
• File access patterns that do not match your workflows
• Failed authentication attempts
• High token usage spikes

Set up automated alerts for critical events. A webhook to Slack or Telegram when the agent executes code outside normal hours, for example, is a simple but effective early warning system.

Rule 9: Keep OpenClaw Updated

OpenClaw receives regular security patches. Running an outdated version means running with known vulnerabilities. Check for updates weekly and apply them promptly.

docker pull openclaw/openclaw:latest
docker-compose down && docker-compose up -d

Subscribe to the OpenClaw security mailing list or watch the GitHub repository for security advisories.

Rule 10: Plan for Compromise

Assume that at some point, something will go wrong. An API key will leak, a prompt injection will succeed, or a misconfiguration will expose something it should not. Having a plan means you can respond quickly instead of panicking.

Your incident response plan should include:

• Kill switch: A way to immediately stop the agent. docker stop openclaw works, but have it documented where anyone on your team can find it.
• Key revocation procedure: Know exactly how to revoke every API key your agent uses, and how long it takes for revocation to take effect.
• Backup strategy: Regular backups of your agent's data directory so you can restore to a known good state.
• Communication plan: If the agent handles customer data, know who to notify and how quickly if there is a breach.

The Minimal Privilege Principle

The minimal privilege principle is the single most important security concept for OpenClaw operators. It says: give your agent exactly the permissions it needs to do its job, and nothing more.

This applies at every level:

• Autonomy level: Use ReadOnly or Supervised unless Full is truly needed.
• File access: Mount only required directories, use read-only mounts where possible.
• Network access: Block all outbound traffic except what the agent needs.
• API permissions: Use API keys with the narrowest scope possible.
• Action allowlists: Explicitly list which actions the agent can perform, rather than blocking specific actions.

Every permission you grant is a potential attack vector. The fewer permissions your agent has, the less damage a compromise can cause.

Ongoing Monitoring

Security is not a one-time setup. It is an ongoing process. Schedule these monitoring tasks:

• Daily: Glance at agent logs for unusual activity.
• Weekly: Check for OpenClaw updates. Review token usage for unexpected spikes.
• Monthly: Rotate secrets. Review and prune agent permissions. Audit which skills are installed and remove any you no longer use.
• Quarterly: Full security review. Test your incident response plan. Update your documentation.

The operators who get hacked are almost always the ones who set up their agent once and never looked at it again. The ones who monitor, update, and iterate stay safe.