Security

Multiple OpenClaw agents on one host: which security boundaries hold?

June 25, 202611 min readUpdated September 13, 2026By OpenClawBlog Team

Published June 25, 2026 · OpenClawBlog Team · Sources checked September 13, 2026.

Running several OpenClaw agents on one machine looks like a tidy way to separate work. One agent handles a personal inbox, another works on code, and a third watches a public channel. Each has a name and, if configured correctly, its own workspace.

The dangerous assumption is that those labels create tenant isolation. OpenClaw describes multiple isolated agents in one Gateway process, each with its own workspace, state directory, and SQLite-backed session history. Its security trust model sets a narrower boundary: one Gateway is intended for one trusted operator or one mutually trusting team. Both statements can be true. Agent configuration partitions core state. It does not make the shared Gateway safe for hostile users.

The decision in one table

Situation	Minimum design	What remains shared
One operator, separate jobs	Separate agents, unique workspaces and `agentDir` paths	The Gateway, host account, plugins, and operator control plane
A trusted team sharing one business workflow	The same state separation, plus narrow session visibility and agent-to-agent rules	People who can operate the Gateway still share its trusted authority
Different trust groups on one machine	Separate Gateways and credentials, ideally separate OS users	The host administrator and underlying machine remain in scope
Mutually untrusted or adversarial users	Separate Gateway cells with separate credentials and preferably separate hosts or VPSs	Only infrastructure deliberately shared outside those cells

The last two rows are not matters of naming. OpenClaw's documentation recommends separate Gateways for adversarial-user isolation, with separate OS users or hosts where possible. Its repository security policy also says that multiple Gateways can run on one machine, but clean separation by trust boundary is the recommended operating model.

What a separate agent actually isolates

The multi-agent routing documentation treats an agent as a per-persona scope. It includes the workspace, local instruction files, authentication profiles, model registry, per-agent configuration, and the session store. The default session database is kept under the agent's agentDir.

That is useful protection against accidental mixing. A work agent can have a work repository and a business provider account while a personal agent uses a different workspace and model profile. Channel bindings then route an inbound account, peer, or channel to the intended agent.

There is an important limit. A binding chooses where a message goes; it does not authorize every action that the destination agent can perform. A session key also selects a conversation bucket. It is not an authorization token. A different name in the agent roster cannot stop a caller who already has trusted Gateway access.

State paths need deliberate review. OpenClaw warns against reusing agentDir across agents because authentication and session state can collide. It also notes that plugin-owned storage follows the plugin's configuration. Adding a second agent does not automatically split every global store. Shared skill roots can remain shared as well.

The workspace has a similar caveat. It is the agent's default working directory, not a hard filesystem sandbox. Relative paths resolve there, but absolute paths may reach other host locations unless sandboxing is enabled. A separate folder is a good organization boundary. It is not, by itself, a host security boundary.

What the shared Gateway and host still expose

The shared Gateway is the part most likely to be forgotten. OpenClaw's trust model says that session tools reach across the Gateway by default: tools.sessions.visibility defaults to all, and tools.agentToAgent.enabled defaults to true. An unsandboxed tool-enabled agent can therefore list, read, search, or message sessions belonging to other agents unless those controls are narrowed.

Sandboxing limits a caller's runtime, but it does not automatically hide every transcript from an unsandboxed agent on the same Gateway. The documented controls for persona separation are narrower session visibility such as agent or self, an explicit tools.agentToAgent.allow list, or disabling ordinary agent-to-agent messaging.

Operator roles do not solve this alone. OpenClaw describes them as control-plane guardrails inside one trusted Gateway domain. The repository's security policy makes the same point: authenticated Gateway callers are treated as trusted operators, and session identifiers are routing controls rather than per-user authorization boundaries.

Plugins widen the trust cell again. The tool and agent permissions reference says plugins run in process with the Gateway and should be treated as trusted code. A plugin is not made harmless by assigning it to a low-privilege agent. If it can read environment variables, files, or host state, that is a Gateway-level concern.

The same reasoning applies to paired nodes, browser profiles, provider credentials, and the state directory. If a personal browser account or password manager is present on a runtime exposed to a business or public agent, the host boundary has already been widened. If someone can modify ~/.openclaw or the active configuration, OpenClaw treats that person as a trusted operator.

A baseline for agents in one trusted cell

Sharing one host can be reasonable when everyone inside the Gateway already belongs to the same trust group. The baseline below is a security design, not a claim about a tested installation.

Give every agent a distinct workspace and a distinct agentDir. Record the purpose of each path. Do not reuse an agent state directory to save disk space, and inspect plugin storage separately when memory or knowledge must remain private.
Sandbox agents that handle untrusted content or need limited filesystem reach. OpenClaw's sandbox settings distinguish mode, scope, and backend. mode: all covers every session; mode: non-main leaves the main session outside the sandbox. For co-resident agents, scope: agent creates one environment per agent, while scope: session gives each session its own environment. scope: shared intentionally shares one environment and is the wrong default for isolation.
Start with workspaceAccess: none when an agent does not need the agent workspace. Use ro for read-only source access and reserve rw for a job that genuinely needs to write. The workspace access reference documents these modes and their consequences.
Review every bind mount. The sandbox and tool-policy guide explains that binds pierce the sandbox filesystem. Prefer read-only mounts, keep roots narrow, and never mount a Docker socket or credential directory casually. A tool sandbox also leaves the Gateway itself on the host.
Make tool policy match the job. For agents handling untrusted content, OpenClaw recommends denying control-plane tools such as gateway, cron, sessions_spawn, and sessions_send unless they are required. Keep cross-agent visibility narrow. If delegation is needed, restrict target agents and request sandbox: require so a child cannot silently run unsandboxed.
Remember that tool policy works by tool name. Denying write, edit, and apply_patch does not make an allowed exec call read-only. Elevated execution is an escape hatch from ordinary sandbox placement, so keep it disabled for lower-trust agents or restrict its sender allowlist tightly.
Keep plugins, browser profiles, and paired nodes out of the low-trust lane unless the workflow needs them. Pin trusted plugin sources, review their configuration, and use dedicated external accounts. A successful approval reduces accidental execution; it does not turn trusted Gateway code into hostile-user isolation.

When the shared host is the wrong boundary

Use a separate Gateway when people must not access each other's sessions, tools, credentials, or files. That is the direct rule in OpenClaw's multi-user guidance. Session ownership, sidebar filters, and presence indicators help a team coordinate. They do not protect one person's data from another trusted Gateway operator.

A separate Gateway on the same OS user is a useful operational split, but it is not a complete host boundary. This is an inference from the documentation's trust model: anyone able to change the shared user's OpenClaw state or configuration is already inside the operator trust cell. The two Gateways also share the same kernel, local administrator, and any directories or devices that are mounted into both.

For materially different trust groups, use separate OS users at minimum, with separate state directories, credentials, service definitions, and firewall rules. For adversarial users or organizations, separate hosts or VPSs are the clearer choice. A full Gateway container can add a container boundary, but an embedded tool sandbox is a different design because the Gateway and its plugins still run on the host.

The sandbox modes and scope reference is useful here because it makes the layers explicit: the backend controls where sandboxed tools execute, while the Gateway remains the control plane. It is a mistake to use a per-session Docker container as evidence that two users have separate Gateway authority.

A proposed preflight and failure drill

These are proposed operator checks, not tests performed for this article. Use synthetic messages and disposable files. Keep secrets out of the captured evidence.

openclaw agents list --bindings
openclaw sandbox explain --agent work --json
openclaw security audit

First, verify routing. Send one synthetic request through every configured channel, account, and peer. Record the matching binding, selected agent, expected workspace, and session key. A message reaching the wrong agent is a routing failure, even if both agents have similar policies.

Next, verify state separation. Confirm that every agent resolves a unique workspace and agentDir. Check memory and plugin stores separately. Do not assume that a new directory means a new database or a private knowledge index.

Then inspect the effective sandbox, rather than the intended configuration. The inspector reports mode, scope, workspace access, tool policy, and elevated gates. Test the main session as well as a channel session when using non-main; the main session is the common exception.

Run a harmless denial test for each important boundary. From agent A, attempt a session read that should be outside its visibility, a message to an unapproved agent, a child spawn to an unapproved target, and an exec operation that the policy should block. If a command reaches the host, inspect the sandbox mode, the tool policy, and the elevated gate separately. A generic tool failure does not identify the winning policy.

Repeat the checks after a Gateway restart and after a policy or plugin change. Keep the agent ID, session key, effective sandbox output, relevant logs, and configuration revision together. Mark each result as passed, unverified, or blocked. A clean configuration file proves intent; it does not prove that the running process resolved the same boundary.

Limits that remain after hardening

Prompt injection remains a risk whenever an agent reads messages, web pages, documents, or code. OpenClaw's model is explicit that the model is not a trusted principal. Identity and scope come first; model choice comes later. Stronger models can reduce mistakes, but they do not replace filesystem policy, sandboxing, approvals, or host separation.

Tool controls also have limits. A named exec permission does not describe every side effect of a shell, interpreter, package manager, or script. A plugin installed into the Gateway has the Gateway's trust level. An audit can identify configuration drift covered by its checks, but it cannot certify the intent of a third-party plugin or the safety of every external account attached to the host.

The practical rule is short. For one trusted operator, separate agents with unique state paths and per-agent sandbox policies are usually enough for workflow separation. For a trusted team with different personas, add narrow session and delegation controls. For people who must not share authority, separate the Gateway and credentials. For adversarial users, separate the OS boundary or the host as well.

If you cannot answer who can read the Gateway configuration, inspect another session, load a plugin, use a paired node, or access a provider credential, the agents are not isolated in the security sense. They are only organized.

Sources

All sources were accessed on 2026-09-13. The official documentation and repository policy did not state separate publication dates when checked.