OpenClaw Security Best Practices

When you give an AI agent access to your shell, your files, and your cloud APIs, security isn't just a feature—it's the foundation. Here is the definitive guide to hardening your OpenClaw infrastructure against common threats.

As a lead operator for Mira, I've spent thousands of hours refining the security posture of our agent fleet. We operate on the principle of Least Privilege Automation. Every permission granted to an agent must be justified, monitored, and restricted to the narrowest possible scope.

1. Host-Level Hardening

OpenClaw typically runs as a background daemon (the Gateway) on a host machine—whether that's your laptop, a Mac mini in a closet, or a VPS. The security of the agent starts with the security of the host.

Firewall Configuration

On macOS, the Application Firewall should be enabled and configured to block all unauthorized incoming connections. OpenClaw communication happens over encrypted channels, but the local ports should not be exposed to the network.

# Enable the macOS Application Firewall
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on

# Block all incoming connections by default
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setblockall on

SSH Hardening

If you access your OpenClaw host via SSH, password authentication is a non-starter. Use key-based authentication only and disable root login.

Edit /etc/ssh/sshd_config.d/100-openclaw.conf (or equivalent):

PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3
LoginGraceTime 20
AllowUsers your-username

2. API Key & Secrets Management

OpenClaw stores its configuration, including provider API keys, in ~/.openclaw/openclaw.json. This file is the "crown jewels" of your deployment.

File Permissions

Ensure that your configuration files are only readable by the user running the OpenClaw process.

chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/openclaw.json

Using 1Password for Secrets

For production environments, avoid hardcoding secrets in openclaw.json. Use the 1Password CLI (op) to inject secrets into the environment at runtime.

# Run the gateway with secrets injected from 1Password
op run --env-file=.env.secrets -- openclaw gateway start

For more on this, check our guide on integrating 1Password with OpenClaw.

3. Safe Tool Execution

Tools are the primary way agents interact with the world. Improperly configured tools can lead to Remote Code Execution (RCE) or data exfiltration.

The Approval Loop

Never disable the approval loop for high-risk tools like exec, write, or gateway. OpenClaw's approval system ensures a human is always in the loop for destructive or system-level changes.

When you see an approval request, read the command. Don't just /approve; verify that the piped output or chained operators aren't doing something unexpected.

Restricted Workspaces

Agents should operate within a dedicated workspace directory. OpenClaw enforces this by resolving relative paths against the workspace root.

# Example workspace structure
/Users/jkw/.openclaw/agents/mira-wren/workspace/

Avoid giving agents access to your entire home directory. Use the attachAs parameter in sessions_spawn to mount only the specific directories needed for a sub-agent's task.

4. Agent Privacy Firewalls

In a fleet configuration, not all agents are created equal. Use the "Privacy Firewall" pattern to isolate agents that handle public data from those that handle private data.

• Internal Agents: Have access to calendars, emails, and personal documents. Use strict authentication and 2FA for access.
• External/Partner Agents: No access to private data. These agents should run in isolated sandboxes with restricted toolsets.

We document these boundaries in AGENTS.md to ensure every operator (human or AI) knows the limits of each agent's authority.

5. Audit & Monitoring

Security is a continuous process. You must monitor what your agents are doing and audit their logs regularly.

Session History Logging

OpenClaw logs every message, tool call, and tool result. Use the sessions_history tool to review past interactions, especially when debugging a failed task or investigating suspicious behavior.

Automated Health Checks

Set up a cron job to run periodic security audits on your host. Our healthcheck skill can be scheduled to run every 24 hours to verify firewall status, SSH configuration, and file permissions.

# Add a daily security health check
openclaw cron add --name "daily-security-audit" \
  --schedule "cron: 0 0 * * *" \
  --payload '{"kind": "agentTurn", "message": "Run a full security health check and report any issues."}'

FAQ

Is it safe to give an agent shell access?

Yes, provided you use OpenClaw's approval loop and restrict the agent to a non-privileged user and a specific workspace. Never run OpenClaw as root.

How do I prevent an agent from deleting my files?

Use the edit tool instead of write for modifications, and always review rm or find -delete commands in the approval loop.

What should I do if an API key is leaked?

Immediately revoke the key in the provider's dashboard, update openclaw.json with a new key, and restart the gateway.

Can I limit which tools a sub-agent can use?

Yes. When using sessions_spawn, use the toolsAllow parameter to pass a whitelist of allowed tool IDs to the sub-agent.

Does OpenClaw support 2FA?

OpenClaw respects the 2FA settings of the underlying providers (like GitHub or Google). For the OpenClaw Gateway itself, we recommend running it behind a VPN or Tailscale with 2FA enabled.

Conclusion

Hardening your OpenClaw deployment is an investment in the longevity of your automation. By following these best practices, you can build with confidence, knowing that your agents are operating within a secure and well-monitored framework.

Ready to dive deeper? Learn how to build custom MCP servers that integrate securely with your internal APIs.