OpenClaw Security: What Actually Matters (And What Nobody Tells You)

10 mins read

Updated on Mar 4, 2026

The thing that will bite you first: prompt injection

There is no fully solved defense against prompt injection yet. That's not FUD — that's from the creator of OpenClaw himself.

What this means in practice: if your agent reads emails, Slack messages, WhatsApp, or web pages from anyone you don't fully trust, a crafted message can make your agent do things you didn't ask it to do. Someone could send a message that looks harmless but tells your agent to forward files, click buttons on logged-in websites, or send emails on your behalf.

The fix isn't a setting. It's a posture. Treat every piece of inbox content as potentially hostile. Lock down who can send messages to your agent. And if you're on a weaker model to save money — be careful. Opus and Sonnet laugh at injection attempts. Flash sometimes doesn't.

The two config changes that matter most

Most of the real protection comes from two settings working together.

Filesystem isolation. Without this, your agent's file tools can read anywhere on disk — including your API keys, gateway tokens, and system configs. Add this to your openclaw.json:

"tools": {
  "fs": { "workspaceOnly": true }
}

"tools": {
  "fs": { "workspaceOnly": true }
}

"tools": {
  "fs": { "workspaceOnly": true }
}

This locks file access to the workspace directory only. It won't stop everything (exec can still read files if exec is unrestricted — which is why the next one matters).

Exec allowlist. The exec tool is the highest-risk surface. Without restriction, a successful injection can run arbitrary shell commands. The fix is an allowlist: only the binaries you explicitly name can run.

"tools": {
  "exec": {
    "security": "allowlist"
  },
  "elevated": { "enabled": false }
}

"tools": {
  "exec": {
    "security": "allowlist"
  },
  "elevated": { "enabled": false }
}

"tools": {
  "exec": {
    "security": "allowlist"
  },
  "elevated": { "enabled": false }
}

And in ~/.openclaw/exec-approvals.json, list only what you actually need. Most people need far less than they think. If your workflows don't use curl, don't include it. curl in the allowlist is a known data exfiltration risk.

These two settings together close most of the worst attack paths. Neither alone is enough.

Start using OpenClaw in an isolated computer

Make you first hire

Get them started

Browser: the other big one

The browser tool is powerful and it's also where a lot of injection happens. A malicious page can try to embed instructions in its content that your agent then follows.

"browser": {
  "evaluateEnabled": false,
  "defaultProfile": "openclaw"
}

"browser": {
  "evaluateEnabled": false,
  "defaultProfile": "openclaw"
}

"browser": {
  "evaluateEnabled": false,
  "defaultProfile": "openclaw"
}

evaluateEnabled: false disables arbitrary JavaScript execution in page context. This is the main defense. It doesn't prevent browsing — your agent can still navigate, click, and screenshot — but it cuts off the most dangerous exfiltration path.

Use the isolated openclaw Chrome profile, not your personal browser. Never connect the agent to a browser with your saved sessions and passwords in it.

One honest gap: there's no URL allowlist in OpenClaw yet. The agent can visit any site. This is a known open problem.

Don't expose the gateway port to the internet

OpenClaw was designed to be accessed by one person, locally. The gateway port is not hardened for public internet exposure.

If you're self-hosting, put everything behind Tailscale. Your machine stays off the public internet entirely. This is the setup the creator uses and recommends. It's the simplest, most effective thing you can do for network security.

If you need remote access through a browser, Cloudflare Tunnels work well — but make sure you have proper auth in front of them, not just the tunnel URL.

Lock down the dangerous tools

Some tools can be used to persist access or run up your API bill. Add a deny list:

"tools": {
  "deny": ["gateway", "cron", "sessions_spawn"]
}

"tools": {
  "deny": ["gateway", "cron", "sessions_spawn"]
}

"tools": {
  "deny": ["gateway", "cron", "sessions_spawn"]
}

cron lets the agent schedule future tasks — useful normally, dangerous if injected. sessions_spawn can create runaway sub-agents. Deny them unless you have a specific reason not to.

File permissions on sensitive files

Quick and often forgotten:

chmod 600 ~/.openclaw/auth-profiles.json
chmod 600 ~/.openclaw/openclaw.json
chmod 600

chmod 600 ~/.openclaw/auth-profiles.json
chmod 600 ~/.openclaw/openclaw.json
chmod 600

chmod 600 ~/.openclaw/auth-profiles.json
chmod 600 ~/.openclaw/openclaw.json
chmod 600

This doesn't stop the agent's own tools from reading them — which is why the exec allowlist matters — but it prevents any other system user from accessing them.

Run the built-in security audit regularly

OpenClaw has a built-in audit. Use it. Either run the ClawdBot security check from ClawHub, or point your agent at the OpenClaw security docs page and tell it to implement and verify everything listed.

Do this once after setup, and then again any time something changes. The tool will warn you about gaps you might have missed.

What's still an open problem

Being honest here, because most guides aren't:

No browser URL allowlist. Your agent can visit any URL. If it gets redirected to a malicious page, the exec allowlist and evaluateEnabled: false help — but they're not a complete fix.
curl in the exec allowlist is a risk. If you need it, keep it. If you don't, remove it. It can be used to exfiltrate data to an external server.
sudo apt-get install * can escalate to root. If you're on a VPS and gave the agent sudo for package installs, a malicious package is a real path to full system access. Remove sudo if you don't need it.
Prompt injection has no complete solution. Better models, approval flows for destructive actions, and locked-down channels reduce the risk. They don't eliminate it.

The minimum viable config

If you want to start somewhere, start here:

{
  "tools": {
    "fs": { "workspaceOnly": true },
    "exec": {
      "security": "allowlist",
      "safeBins": ["jq", "cut", "uniq", "head", "tail", "tr", "wc", "grep", "sort"]
    },
    "elevated": { "enabled": false },
    "deny": ["gateway", "cron", "sessions_spawn"]
  },
  "browser": {
    "defaultProfile": "openclaw",
    "evaluateEnabled": false
  }
}

{
  "tools": {
    "fs": { "workspaceOnly": true },
    "exec": {
      "security": "allowlist",
      "safeBins": ["jq", "cut", "uniq", "head", "tail", "tr", "wc", "grep", "sort"]
    },
    "elevated": { "enabled": false },
    "deny": ["gateway", "cron", "sessions_spawn"]
  },
  "browser": {
    "defaultProfile": "openclaw",
    "evaluateEnabled": false
  }
}

{
  "tools": {
    "fs": { "workspaceOnly": true },
    "exec": {
      "security": "allowlist",
      "safeBins": ["jq", "cut", "uniq", "head", "tail", "tr", "wc", "grep", "sort"]
    },
    "elevated": { "enabled": false },
    "deny": ["gateway", "cron", "sessions_spawn"]
  },
  "browser": {
    "defaultProfile": "openclaw",
    "evaluateEnabled": false
  }
}

Plus Tailscale for network isolation. Plus chmod 600 on sensitive files. Plus an exec allowlist with only what you actually use.

That's it. Everything else is refinement.

If you don't want to think about any of this

That's what Clawnify is for. All of the above — filesystem isolation, exec allowlist, browser hardening, Cloudflare Tunnels with auth, device identity, systemd hardening — is configured by default on every Clawnify VPS. You get a hardened OpenClaw instance without having to read a document like this one to set it up.

If you're self-hosting and enjoying the control, this guide is for you. If you just want the agent to work securely without the setup overhead, Clawnify handles it.

Either way: security is real. The risks are manageable. And now you know what they actually are.

Riccardo

Written by