Security Hardening Guide: Lock Down Your Agent

#Why Security Matters for Autonomous Agents

OpenClaw is not a passive tool — it is an autonomous agent that can read files, execute commands, send messages, and interact with external services on your behalf. This power comes with significant security responsibilities. A misconfigured or compromised OpenClaw instance can:

• Leak sensitive data — API keys, personal files, credentials stored on your machine
• Execute malicious commands — A compromised skill could run arbitrary shell commands
• Incur unexpected costs — Unauthorized API usage can run up thousands of dollars in charges
• Spread to other systems — If your agent has network access, a compromised skill could pivot to other machines

#Threat Model

Understanding what you are defending against helps you prioritize:

#Dedicated User Account

The single most impactful security measure is running OpenClaw under a dedicated, unprivileged user account. This limits the blast radius if something goes wrong.

#macOS

Create a Standard user (not Administrator) named openclaw:

1. Open System Settings > Users & Groups
2. Click Add Account
3. Set account type to Standard
4. Username: openclaw
5. Set a strong password

#Linux

#Why This Matters

A dedicated user account means:

• OpenClaw cannot access other users' home directories
• It cannot modify system files without explicit sudo grants
• File permissions restrict what the agent can read and write
• If compromised, the attacker has limited access to the system

#Bind the Gateway to Localhost

By default, the OpenClaw Gateway binds to localhost (127.0.0.1), meaning it is only accessible from the local machine. Keep it this way unless you have a specific reason to change it.

Verify your configuration in ~/.openclaw/openclaw.json:

{
  "gateway": {
    "host": "127.0.0.1",
    "port": 3420
  }
}

#If You Need Remote Access

If you need to access the dashboard remotely, do not bind to 0.0.0.0. Instead, use one of these secure alternatives:

SSH Tunnel (recommended):

ssh -L 3420:localhost:3420 openclaw@your-server

Then access http://localhost:3420 from your local machine.

Tailscale:

Tailscale creates a private network. You can safely bind to the Tailscale interface:

{
  "gateway": {
    "host": "100.x.y.z",
    "port": 3420
  }
}

Replace 100.x.y.z with your machine's Tailscale IP.

Reverse Proxy with Authentication:

If you must expose the dashboard to the internet, put it behind a reverse proxy (nginx, Caddy) with authentication:

server {
    listen 443 ssl;
    server_name openclaw.yourdomain.com;
    auth_basic "OpenClaw Dashboard";
    auth_basic_user_file /etc/nginx/.htpasswd;
    location / {
        proxy_pass http://127.0.0.1:3420;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

#Enable exec_approval for Dangerous Tools

OpenClaw's exec_approval feature requires your explicit approval before the agent executes potentially dangerous operations. This is one of the most important security settings.

#Configure exec_approval

Edit ~/.openclaw/openclaw.json:

{
  "security": {
    "exec_approval": {
      "enabled": true,
      "require_approval_for": [
        "shell_exec",
        "file_write",
        "file_delete",
        "network_request",
        "skill_install",
        "config_modify"
      ],
      "auto_approve": [
        "file_read",
        "web_search",
        "calendar_read"
      ],
      "approval_timeout": 300,
      "approval_channel": "telegram",
      "default_action": "deny"
    }
  }
}

#How It Works

When exec_approval is enabled:

1. The agent decides to perform a protected action (e.g., execute a shell command)
2. It sends you an approval request via your messaging channel
3. You review the action and respond with "approve" or "deny"
4. If you do not respond within approval_timeout seconds, the default_action applies

#Approval Categories Explained

#Enable Disk Encryption

#macOS (FileVault)

FileVault encrypts your entire startup disk, protecting your data if the Mac Mini is physically stolen.

1. Open System Settings > Privacy & Security > FileVault
2. Click Turn On FileVault
3. Choose to create a recovery key (store it somewhere safe, not on the Mac)
4. Wait for encryption to complete (can take hours, but the machine remains usable)

#Linux (LUKS)

If you did not enable disk encryption during OS installation, you can encrypt the OpenClaw data directory:

Or use LUKS to create an encrypted container for the .openclaw directory. This is more complex but provides stronger protection.

#Restrict Directory Access

Limit which directories OpenClaw can access on your system. This prevents a compromised skill from reading sensitive files outside its scope.

Edit ~/.openclaw/openclaw.json:

{
  "security": {
    "allowed_directories": [
      "/home/openclaw/.openclaw",
      "/home/openclaw/Documents",
      "/tmp/openclaw"
    ],
    "denied_directories": [
      "/etc",
      "/var",
      "/root",
      "/home/openclaw/.ssh",
      "/home/openclaw/.gnupg"
    ],
    "deny_dotfiles": true
  }
}

#Key Directories to Protect

Always deny access to these directories:

• ~/.ssh/ — SSH keys
• ~/.gnupg/ — GPG keys
• ~/.aws/ — AWS credentials
• ~/.config/gcloud/ — Google Cloud credentials
• Any directory containing .env files with secrets

The deny_dotfiles option prevents OpenClaw from reading any hidden files or directories, which is a good default since credentials are often stored in dotfiles.

#Network Monitoring and Restrictions

#Monitor Outbound Connections

Keep an eye on what your OpenClaw instance is connecting to. On macOS, Little Snitch is an excellent firewall that shows and controls all outbound connections. On Linux, use ss or netstat:

#Restrict Outbound Access

For maximum security, restrict OpenClaw to only connect to known, trusted endpoints:

{
  "security": {
    "network": {
      "allowed_hosts": [
        "api.anthropic.com",
        "api.openai.com",
        "api.telegram.org",
        "clawhub.ai",
        "registry.npmjs.org"
      ],
      "block_private_networks": true,
      "block_localhost": false
    }
  }
}

The block_private_networks option prevents skills from making requests to your local network (192.168.x.x, 10.x.x.x), which could be used to probe or attack other devices on your network.

#Keep OpenClaw Updated

Security patches are released regularly. Always keep OpenClaw up to date:

#Check for Security Advisories

There is no openclaw security advisories command. openclaw security has exactly one subcommand, described as "Security tools: audit plus optional safe fixes", so the local check is the audit below, and staying current is openclaw update. ClawHub does publish advisories, but only for itself: its moderation page says to "Do not use ClawHub advisories for vulnerabilities in third-party skills or plugins."

#Update Strategy

• Patch releases (e.g., 2.3.1 to 2.3.2): Update immediately. These usually contain security fixes.
• Minor releases (e.g., 2.3.x to 2.4.0): Update within a week. Read the changelog first.
• Major releases (e.g., 2.x to 3.0): Update carefully. Back up your configuration first and read the migration guide.

#Skill Auditing

Skills are the largest attack surface in OpenClaw. Every skill you install runs with the same permissions as the agent itself. See the Skill Security Audit Checklist for a comprehensive guide.

#Quick Skill Security Checks

List all installed skills and their sources:

Run the built-in security audit. Plain security audit "stays on the cold config/filesystem/read-only path", while --deep "adds best-effort live Gateway probes and plugin-owned security audit collectors":

There is no openclaw security review. To look at one skill before installing it, read ClawHub's own decision:

#ClawHub Security Landscape

The ClawHub marketplace has over 15,000 community-contributed skills. While the OpenClaw team reviews popular skills, the reality is:

• ~12% of skills have been flagged for suspicious behavior at some point
• Verified skills (marked with a checkmark on ClawHub) have been manually reviewed
• Unverified skills may contain malicious code
• Skill ratings and download counts can be manipulated

#API Key Security

Your LLM API keys are the most valuable secrets in your OpenClaw configuration. Protect them:

#Rotate Keys Regularly

Generate new API keys monthly and update openclaw.json. There is no openclaw config edit; openclaw config file "Prints the active config file path", so open the path it reports.

After updating, restart the gateway:

#Set Spending Limits

Configure spending limits on your LLM provider accounts:

• Anthropic: Set monthly spending limits in the Anthropic Console
• OpenAI: Set usage limits in the OpenAI API dashboard
• Google: Set budget alerts in Google Cloud Console

#Monitor for Unusual Usage

There is no top-level openclaw usage. The documented summary is on the Gateway, and it will "Fetch usage-cost summaries from session logs":

If you see unexpected spikes in API usage, your keys may have been compromised. Rotate them immediately.

#Security Checklist

Use this checklist to verify your OpenClaw installation is properly hardened:

• Running under a dedicated, unprivileged user account
• Gateway bound to localhost (127.0.0.1)
• exec_approval enabled for shell_exec, file_write, file_delete
• Disk encryption enabled (FileVault or LUKS)
• Sensitive directories (.ssh, .gnupg, .aws) are in denied_directories
• deny_dotfiles is enabled
• API keys have spending limits set on provider dashboards
• OpenClaw is on the latest version
• All installed skills have been reviewed
• Network firewall is configured (ufw on Linux, built-in firewall on macOS)
• Remote access uses SSH tunnel or Tailscale, not direct port exposure
• Regular backups of ~/.openclaw/ directory
• openclaw security audit runs clean

#Incident Response

If you suspect your OpenClaw instance has been compromised:

1. 1
   Stop the agent immediately

   Run openclaw gateway stop or systemctl --user stop openclaw. This halts all agent activity.

2. 2
   Rotate all API keys

   Go to every LLM provider dashboard and generate new API keys. Revoke the old ones.

3. 3
   Review recent activity

   Check the logs at ~/.openclaw/logs/ for suspicious commands, file access, or network requests.

4. 4
   Audit installed skills

   Run openclaw security audit and openclaw skills list --verbose. Remove any skills you do not recognize.

5. 5
   Check for persistence

   Look for unauthorized cron jobs (crontab -l), SSH authorized_keys changes, and unexpected processes.

6. 6
   Restore from backup

   If the compromise is severe, restore ~/.openclaw/ from a known-good backup.

7. 7
   Report to the community

   If a specific skill was the attack vector, report it on ClawHub and the OpenClaw GitHub issues.

#Next Steps

• Skill Security Audit Checklist — Deep dive into reviewing skills
• API Key Setup — Secure key management practices
• Cost Optimization — Spending limits protect against key theft too
• Troubleshooting — When security settings cause legitimate features to break