OpenClaw·Intermediate·Last tested: 2026-03·~8 min read

Security & Governance

Production agent deployments require careful attention to access control, tool permissions, and data isolation. This page covers the key security practices for OpenClaw multi-agent systems.

Per-Agent Tool Policies

The deny list always wins over the allow list. Follow minimal privilege:

| Agent | Allowed | Denied | |-------|---------|--------| | Coordinator | All core tools + sessions_spawn | — | | Engineering | read, write, exec, process, git | sessions_spawn, gateway, cron | | Product | read, write, web_search | exec, process, git, gateway | | Risk / Analytics | read, write, web_search | exec, gateway, sessions_spawn |

Principle of Least Privilege

Each agent should only have access to the tools it needs for its specific role. When in doubt, deny a tool and add it later if needed.

Sandboxing

Agents that execute code (e.g., engineering agents) should run inside a Docker sandbox:

{
  "id": "dev-agent",
  "sandbox": { "enabled": true }
}

This isolates code execution from the host system, preventing accidental or malicious modifications to the server.

Database Access

Read-Only Only

No agent should have write access to production databases. All agents should query from reporting or data warehouse replicas, never from the core database.

For analytics agents that need database access:

Create a read-only database user with access only to reporting tables
Wrap SQL execution in a custom skill that uses the read-only connection string
Deny the exec tool to prevent agents from running arbitrary commands

Auth Profile Isolation

Each agent has its own auth-profiles.json in its agentDir:

~/.openclaw/agents/<agentId>/agent/auth-profiles.json

Warning

Never copy auth-profiles.json between agents unless you explicitly intend to share credentials. Each agent should have independent auth profiles.

Channel Security

Allowlists on all channels — Only known team members should be able to message agents
Use groupPolicy: "allowlist" and configure which channels/users each agent accepts messages from
Use requireMention: true for channels where the agent should only respond when explicitly mentioned

Workspace Security

Git-backed workspaces — Version control all workspace files in private repos
No secrets in files — Keep API keys, tokens, and connection strings in environment variables
Memory isolation — Keep workspaces fully isolated between agents

Memory Bleed

If agents share context or workspace files, you'll get unexpected crossovers in behavior. Keep workspaces fully isolated — each agent should have its own directory with its own SOUL.md, MEMORY.md, etc.

Security Checklist

[ ] Each agent has its own workspace directory
[ ] Each agent has its own agentDir (no shared auth profiles)
[ ] Code-executing agents run in Docker sandbox
[ ] Database access is read-only via custom skills
[ ] No production write access for any agent
[ ] Channel allowlists configured
[ ] Secrets stored in environment variables, not workspace files
[ ] Workspaces backed up in private Git repos
[ ] Tool deny lists configured per agent