How to Secure Your Multi-Agent Setup with Sandboxes and Tool Policies

I used to worry about security when running AI agents on my local machine. It is hard to find a balance between giving an agent enough access to be useful and keeping your system safe. You might want one agent to handle your coding projects while another just manages your messages, but setting up those boundaries usually feels like a chore.

I found that the best way to handle this is to give each agent its own sandbox and a specific set of tools. This way, you can have a personal assistant with full access while keeping public-facing bots in a restricted environment.

What You’ll Need

• An active OpenClaw installation.
• Docker installed on your system for sandboxing.

Quick Start

You can set up multiple agents with different security profiles in your configuration file. Here is a 5-minute path to getting a personal assistant and a restricted family bot running.

1. Define your agents: Open your configuration file and add a list under the agents key.
2. Set the sandbox mode: Use "mode": "off" for your main agent and "mode": "all" for restricted ones.
3. Restrict tools: Use the allow and deny lists to control what the restricted agent can do.
4. Apply the config: Save the file and restart your gateway.

Here is what that configuration looks like:

{
  "agents": {
    "list": [
      {
        "id": "main",
        "default": true,
        "name": "Personal Assistant",
        "workspace": "~/.openclaw/workspace",
        "sandbox": { "mode": "off" }
      },
      {
        "id": "family",
        "name": "Family Bot",
        "workspace": "~/.openclaw/workspace-family",
        "sandbox": {
          "mode": "all",
          "scope": "agent"
        },
        "tools": {
          "allow": ["read"],
          "deny": ["exec", "write", "edit", "apply_patch", "process", "browser"]
        }
      }
    ]
  },
  "bindings": [
    {
      "agentId": "family",
      "match": {
        "provider": "whatsapp",
        "accountId": "*",
        "peer": {
          "kind": "group",
          "id": "120363424282127706@g.us"
        }
      }
    }
  ]
}

In this setup, your main agent runs on your host with full access. The family agent runs in a Docker container and can only use the read tool.

Tool Groups and Restrictions

I recommend using tool groups to save time. Instead of listing every tool, you can use shorthands like group:runtime or group:fs.

• group:runtime: Includes exec, bash, and process.
• group:fs: Includes read, write, edit, and apply_patch.
• group:messaging: Includes message.
• group:openclaw: Includes all built-in tools.

If you want a “Communication-only” agent, your config would look like this:

{
  "tools": {
    "allow": ["sessions_list", "sessions_send", "sessions_history", "session_status"],
    "deny": ["exec", "write", "edit", "apply_patch", "read", "browser"]
  }
}

Remember that each level of configuration can only further restrict tools. It cannot grant back a tool that was denied at a higher level.

Troubleshooting

Agent not sandboxed or tools still available

If your agent is not sandboxed even with mode: "all", check if a global agents.defaults.sandbox.mode is overriding it. Agent-specific configs take precedence, so ensure agents.list[].sandbox.mode is set correctly. If tools are still appearing, check the filtering order in your logs using tail -f ~/.openclaw/logs/gateway.log | grep -E "routing|sandbox|tools".

Container isolation and non-main pitfalls

If containers are not isolated per agent, ensure you have set scope: "agent" in the agent config. Also, be careful with mode: "non-main". This mode is based on the session key, not the agent ID. If you want a specific agent to never use a sandbox, you must explicitly set mode: "off".

If you have more questions, check the AI Setup Assistant.

What’s Next

• Multi-Agent Routing
• Sandbox Configuration
• Session Management
• Sandboxing Details