OpenClaw Security Hardening: A Practical Checklist for Least-Privilege Agents

If you’re running OpenClaw on a VPS, home server, or inside a company network, this guide is for you.

Outcome: you’ll end up with an OpenClaw deployment where (1) agents can only run the tools/commands you intended, (2) risky actions require explicit approval, (3) the dashboard and tokens are protected, and (4) you can prove the controls work with repeatable verification steps.

This is not “security theater.” It’s a set of concrete guardrails aligned with the most common OpenClaw failure modes: overly-broad execution permissions, prompt injection leading to tool misuse, exposed dashboards/tokens, and accidental data access.

Ready for your own?

🦞 Hire an AI employee that works 24/7

Plans from less than $1/day. Dedicated cloud host, top models, and messaging on Telegram, Slack, or Discord. No API keys to manage.

Get started with Google

See plans · Cancel anytime

Threat model (keep this short, but real)

Before touching configs, pick which of these you’re defending against:

• Curious/hostile user input: someone messages your bot with prompt-injection instructions (“run this command”, “exfiltrate secrets”).
• Over-permissioned tools: your agent can run bash broadly, access the full filesystem, or call network endpoints without constraints.
• Credential leakage: tokens in logs, shell history, config files, or an exposed dashboard.
• Supply-chain risk: untrusted skills/plugins or tools you didn’t review.
• Blast radius: a single compromised agent/session can read/write everything.

Your goal is to reduce the blast radius and force a human decision at the boundaries.

Security principle #1: default-deny tool execution

In agent runners, most real damage happens when the model can execute arbitrary shell commands or call powerful tools without friction.

You want two layers:

1. Allowlist: only specific commands or tool calls are permitted.
2. Approvals: even allowed actions can require an explicit approval step (especially anything that writes, deletes, publishes, transfers money, or touches prod).

A good starting policy:

• Shell execution: deny by default; allowlist only the minimum set of subcommands.
• Filesystem writes: allow only the workspace directory; deny access to your home directory and system paths.
• Network: deny direct outbound by default; allow only specific domains needed for the job.

If you need a mental model for why this matters, treat the LLM as an operator that is:

• fast,
• sometimes wrong,
• easily socially engineered by text.

So: least privilege + explicit approvals.

Step 1 — Run OpenClaw as a non-root user (and isolate state)

Why: if OpenClaw (or an agent tool) is running as root, any “oops” becomes a full machine compromise.

What to do

• Create a dedicated OS user (e.g. openclaw) with no sudo by default.
• Ensure the OpenClaw state directory (often ~/.openclaw) is owned by that user and has restrictive permissions.
• If you use Docker, avoid --privileged, avoid mounting /var/run/docker.sock unless you really need it, and avoid mounting the host root filesystem.

How to verify

• Confirm the OpenClaw process is not root:

ps aux | grep -i openclaw | head

• Confirm state permissions are restrictive:

ls -ld ~/.openclaw
ls -l ~/.openclaw | head

You’re looking for permissions like drwx------ (owner-only) for sensitive dirs.

Common pitfalls

• Mounting your entire home directory into a container “for convenience.” This defeats isolation.
• Running as root because “it fixes file permissions.” Fix permissions properly instead.

Step 2 — Make the dashboard private (and treat tokens like root passwords)

OpenClaw deployments often include a web dashboard/control UI. Treat it as production infrastructure.

What to do

• Bind locally and access via VPN/SSH tunnel where possible.
• If you must expose it:
  • Put it behind a reverse proxy with TLS.
  • Add HTTP auth or SSO.
  • Restrict by IP allowlist.
  • Rate limit.

Also: keep the gateway/dashboard token out of:

• Git
• screenshots
• logs
• shell history

If you’re considering “I’ll just leave it open on a random port,” don’t.

Reference docs for dashboard access patterns:

• https://docs.openclaw.ai/web/dashboard

How to verify

• From an external network (or using an online port check), confirm the dashboard port is not reachable.
• If it is reachable, confirm:
  • TLS is valid
  • an auth step exists
  • unauthorized requests are blocked

Troubleshooting

• Can’t reach the dashboard remotely: use an SSH tunnel:

ssh -L 8080:127.0.0.1:YOUR_DASHBOARD_PORT user@your-server

Then open http://localhost:8080 locally.

Step 3 — Split agents by responsibility (blast-radius engineering)

The biggest practical hardening win is to stop using a single “god agent.”

Instead, create multiple agents/sessions with different capabilities:

• Chat agent (low privilege): reads messages, drafts responses, but cannot execute shell.
• Automation agent (medium privilege): can run a small allowlist (e.g., git status, npm test) and write only to a workspace directory.
• Ops agent (high privilege, rare use): can restart services, manage configs—but always requires approvals.

This design aligns with the OWASP-style idea of reducing tool access and enforcing output/format constraints in GenAI systems.

Background reading:

• https://nebius.com/blog/posts/openclaw-security
• https://www.giskard.ai/knowledge/openclaw-security-vulnerabilities-include-data-leakage-and-prompt-injection-risks

How to verify

Run a “forbidden action” test in the low-privilege agent:

• Ask it to read /etc/shadow or list your home directory.
• Ask it to run curl to an arbitrary domain.

It should fail due to policy/tool restrictions, not “because the model refused.” You want an enforced boundary.

Step 4 — Constrain shell execution with allowlists

Shell access is powerful because it becomes a universal escape hatch. Hardening means turning “arbitrary bash” into “a few safe commands.”

What to do

Build your allowlist around tasks you actually need. Example allowlist patterns:

• Read-only inspection:
  • git status
  • git diff
  • ls (scoped to workspace)
  • cat (scoped)
• Build/test:
  • npm test
  • pnpm lint
• Controlled writes:
  • a dedicated script you wrote (preferred)

Prefer wrapper scripts over allowing raw command families. For instance, instead of allowing git broadly, allow a script ./scripts/safe-git.sh that enforces:

• repository path is correct
• branch is not main
• no git push --force

How to verify

• Attempt a command outside the allowlist (e.g., rm -rf, curl, ssh).
• Confirm the tool layer blocks it.

Common pitfalls

• Allowlisting bash and thinking it’s safe because you “trust the agent.”
• Allowlisting git without blocking git push --force.
• Allowlisting python or node generally (that becomes arbitrary code execution).

Step 5 — Add approval gates for high-risk actions

Even with allowlists, you want human-in-the-loop approvals for irreversible or security-sensitive actions.

High-risk examples:

• deleting files
• rotating tokens
• pushing to production branches
• sending emails/messages to external users
• publishing content
• executing anything with elevated permissions

What to do

Adopt a simple rule:

• Approvals are required for: write/delete, external network calls, and anything touching secrets.
• Approvals are optional for: read-only actions inside a sandbox.

If your setup supports “ask modes” (prompting for approval) and “security modes” (allowlist/deny), configure them so that:

• missing allowlist entries prompt (or deny)
• unanswered prompts default to deny

A practical description of these modes (even if your exact config differs) is captured well in guides like:

• https://aimaker.substack.com/p/openclaw-security-hardening-guide

How to verify

• Trigger a risky action (e.g., “delete the file”, “push to main”).
• Confirm you get an approval prompt.
• Deny it and confirm the action does not occur.

Step 6 — Lock down filesystem scope (read and write)

If the agent can read your entire filesystem, it can leak secrets from:

• .env files
• SSH keys (~/.ssh)
• cloud credentials
• browser profiles
• password managers

What to do

• Mount/permit only the directories needed for the job (usually a workspace).
• Make secrets available only through explicit secret managers (or environment variables) and only in sessions that truly need them.
• Avoid storing secrets in plain text files inside the workspace.

How to verify

• Ask the agent to read outside the workspace.
• Confirm it cannot.

Troubleshooting

• If builds require access to cached dependencies, mount a dedicated cache directory rather than broad home access.

Step 7 — Constrain outbound network access (prompt-injection firewall)

Prompt injection frequently tries to:

• make the agent fetch remote instructions
• exfiltrate data to an attacker-controlled endpoint

So treat outbound network as a privileged capability.

What to do

• Default deny outbound network.
• If you need it, allow only:
  • known APIs/domains
  • HTTPS only
  • request size limits
  • timeouts

If you use a reverse proxy / tunneling tool to expose services, apply the same discipline there—rate limits, IP restrictions, TLS, and logging.

How to verify

• Attempt to curl an arbitrary domain (should fail).
• Attempt to access an allowed domain (should succeed).

Step 8 — Auditability: logs that help, without leaking secrets

Security controls are only useful if you can answer:

• What did the agent do?
• When did it do it?
• Under which approval?

But logs are also a leakage channel.

What to do

• Enable structured logging for tool calls and approvals.
• Redact secrets (tokens, API keys, Authorization headers) from logs.
• Keep logs private and rotate them.

How to verify

• Trigger a tool call and confirm the audit trail includes:
  • tool name
  • parameters (redacted)
  • approval decision
  • outcome

A concrete hardening checklist (copy/paste)

Use this as a final pass:

• OpenClaw runs as a non-root OS user
• State directory permissions are owner-only
• Dashboard is not publicly reachable (or is behind TLS + auth + IP allowlist)
• Separate low/medium/high privilege agents
• Shell is deny-by-default; allowlist is minimal
• High-risk actions require approvals; default is deny when uncertain
• Filesystem access is scoped to a workspace; secrets aren’t readable as files
• Outbound network is deny-by-default; allowlist only needed domains
• Tool-call logs are enabled, stored securely, and redact secrets

Troubleshooting: when hardening breaks your workflow

“My agent can’t do anything anymore”

That’s usually correct—your previous setup was too permissive.

Fix by adding capability intentionally:

1. Identify the exact command/tool call needed.
2. Decide whether it is read-only, write, or external-network.
3. Add it to the allowlist or create a wrapper script.
4. Add an approval requirement if it changes state.
5. Re-run the verification tests.

“The agent keeps asking for approvals for harmless actions”

You likely set approvals to “always” for a broad tool.

Refine approvals by:

• splitting tools (read vs write)
• wrapping actions into a single safe command
• narrowing patterns (e.g., allow git status but not git)

“We need to expose the dashboard publicly”

If you truly must, treat it like any other admin interface:

• mandatory auth (SSO preferred)
• TLS
• IP restrictions
• rate limiting
• monitoring

Do not rely on obscurity.

Where to go next

Hardening is a series, not a single post.

If you want the next most practical “security per dollar” improvement, focus on safe remote access patterns (VPN/Tailscale vs public exposure) and reverse proxy rules so you can keep OpenClaw usable without being reachable by the whole internet.

Related dashboard reference:

• https://docs.openclaw.ai/web/dashboard