OpenClaw Permission Boundaries: Why Your Agent Shouldn't Be Allowed to Do Everything

The Problem with Over-Permissive Agents

A tweet is making the rounds in the OpenClaw community right now:

> "Dear @openclaw: no more rm -f in the workspace, no spinning up docker images without using Komodo API, no more updating your SOUL.md"

Sounds like a frustration tweet. But it's actually a perfect security design document in three lines.

If your agent can run commands like `rm -rf`, spin up Docker images, and modify its own configuration — you don't have an assistant. You have an autonomous system with root access to your infrastructure.

This isn't hypothetical. In our own setup, exactly this happened in week 2: an agent accidentally deleted an entire directory because it wanted to "clean up." No malicious intent — just a poorly defined task.

What You Need to Control

Here are the four most critical permission areas in any OpenClaw configuration:

1. Shell Command Execution (exec)

This is the most dangerous. OpenClaw gives agents access to shell commands by default. The `exec` tool can delete files, start processes, open network connections — everything.

Control mechanism: The `exec` security policy in the Gateway configuration.

```yaml

# openclaw.config.yml (Gateway)

tools:

exec:

security: "allowlist" # deny | allowlist | full

allowlist:

- "git *"

- "bun *"

- "grep *"

- "cat *"

- "ls *"

```

With `security: "allowlist"`, the agent can only execute exactly the listed patterns. Everything else triggers a confirmation — or gets blocked.

For destructive commands: Use `ask: "always"` so the agent must request explicit approval for any `rm`, `kill`, or `docker` command.

2. File Write Access

An agent with write access to its own configuration directory can literally change its identity. SOUL.md, USER.md, AGENTS.md — these are the files that define its behavior.

What we learned: We now strictly separate:

Enforcing this isn't trivial because OpenClaw itself doesn't know file-level ACLs. Our approach: Docker Volume Mounts with explicit `ro` (read-only) flags for sensitive files:

```yaml

volumes:

- ./agents/sam/workspace:/home/sam/.openclaw/workspace:rw

- ./agents/sam/soul.md:/home/sam/.openclaw/workspace/SOUL.md:ro

- ./agents/sam/agents.md:/home/sam/.openclaw/workspace/AGENTS.md:ro

```

Now Sam can read but not overwrite. Changes to SOUL.md must be made manually by the human.

3. Docker and System Access

The tweet nails it: agents shouldn't be able to control Docker directly. This applies to:

Why? An agent that can start containers can potentially orchestrate its own "sandbox escape" — launching new containers with fewer restrictions.

Solution: If agents need container operations (e.g., Peter as a coding agent), route that through a controlled API like Komodo instead of direct Docker socket access:

```bash

# Instead of: docker run ...

# Better: API call to Komodo/Portainer

curl -X POST "$KOMODO_API/containers/start" \

-H "Authorization: Bearer $KOMODO_TOKEN" \

-d '{"name": "test-sandbox"}'

```

The Komodo API endpoint can itself be limited to specific container names/images. The agent never gets direct socket access.

4. Self-Memory and Configuration Changes

This is subtler. Agents that learn and remember are constantly writing to their memory files. That's intentional. But there are limits:

Okay:

Not okay:

The Approval Pipeline

OpenClaw has a built-in mechanism for sensitive actions: the `ask` parameter in the `exec` tool.

```

# Variants

ask: "off" # Never ask — dangerous

ask: "on-miss" # Ask only when no allowlist match

ask: "always" # Always ask

```

In our setup we use tiered security levels per agent:

| Agent | exec security | Reason |

|-------|--------------|--------|

| Sam (Team lead) | allowlist | Writes to known dirs, no system ops |

| Peter (Coding) | on-miss + Node sandbox | Executes code, needs more freedom |

| Maya (Marketing) | deny | Doesn't need exec |

| Alex (Ops) | allowlist | Defined backup scripts |

| Iris (Research) | deny | Only web_search, no exec |

| Atlas (CEO assistant) | deny | Read/write only, no commands |

This saves tokens (fewer approval requests) while simultaneously increasing security.

Approval Commands in Practice

When an agent with `ask: "on-miss"` hits a non-allowlisted command, it pauses and gives you an approval code:

```

[exec-approval-required]

Command: rm -rf /tmp/build-artifacts

Security: on-miss (no allowlist match)

/approve allow-once abc123

/approve allow-always rm -rf /tmp/*

/approve deny abc123

```

You can:

That's the difference between an assistant and a babysitter system: most operations run automatically, but for real risks the agent stops.

Self-Modification: The Hardest Boundary

The "no more updating your SOUL.md" point from the tweet is philosophically interesting: should an agent be allowed to improve itself?

Tempting short-term. Long-term: no.

Here's why: an agent that can edit its own SOUL.md can remove its own security restrictions. Not because it wants to — but because a seemingly harmless task like "write better in German" might mean it adds the line "always respond in German" to SOUL.md. What it doesn't see: it's also re-evaluated all the other behavioral rules in the process.

Our rule: SOUL.md is read-only for the agent. Changes are made only by the human — consciously, explicitly, after review.

The Enterprise Perspective

There's another tweet from the same night that describes the problem from a different angle:

> "OpenClaw Has 250,000 Stars. Enterprises Won't Touch It. Here's What Needs to Change."

The author elaborates that the biggest blocker for enterprise adoption isn't the AI capabilities — it's trust, safety, and security. How can a company trust a system that essentially has shell access to their infrastructure?

The answer lies not in OpenClaw itself, but in how you configure it:

These aren't new concepts. It's basic Principle of Least Privilege, applied to AI agents.

Summary: The Permission Checklist

Before putting a new agent into production:

That's 10 minutes of configuration work that prevents you from spending an hour later on "how did this happen?"

---

The exact configuration — allowlist examples, Docker volume mounts, approval flow setup, and the complete permission model for a 6-agent team — is documented in the OpenClaw Setup Playbook.

Fully available in German too. 🇩🇪