How to Isolate Multiple OpenClaw Tenants
Separate OpenClaw users, clients, or business units with distinct gateways, profiles, OS users, hosts, state, ports, and credentials.
· Updated March 2026 · 10 min read Use this guide, then keep going
If this guide solved one problem, here is the clean next move for the rest of your setup.
Most operators land on one fix first. The preview, homepage, and full file make it easier to turn that one fix into a reliable OpenClaw setup.
Multi-tenant OpenClaw is where operators need to be honest. OpenClaw is designed around a trusted personal-assistant or trusted team boundary, not hostile users sharing one privileged Gateway. You can run multiple agents and profiles, but real tenant isolation means splitting the Gateway, credentials, state, and often the OS user or host.
30-second answer
For different clients, departments, or trust boundaries, run separate Gateways with separate config paths, state directories, workspaces, channel credentials, browser profiles, and base ports. For adversarial or customer-facing boundaries, prefer separate OS users or hosts. Do not rely on sessionKey, model name, or one shared Gateway token as a security boundary.
When this pays off
This matters for agencies, SaaS builders, internal platform teams, and anyone selling OpenClaw-powered automation. One bot for your own company is one thing. One tool-enabled agent shared by several customers is a different risk category. Buyers will ask what happens if one user can steer the agent into another user’s files, tools, or context.
Operator runbook
- Define the trust boundary before the technical layout. If all users are one cooperative team with the same business data, one dedicated company Gateway may be acceptable. If users are different clients, customers, or adversarial tenants, split them. The security docs explicitly recommend separate gateways and preferably separate OS users or hosts.
- Separate state and config. For each Gateway, keep OPENCLAW_CONFIG_PATH, OPENCLAW_STATE_DIR, agents.defaults.workspace, channel credentials, auth profiles, and browser state independent. Sharing any of these can leak context or create config races even if ports are different.
- Separate ports and derived services. Use unique Gateway base ports and leave spacing for derived browser/canvas/CDP ports. The multiple Gateway docs call out this footgun because browser control is easy to collide accidentally when several instances live on one machine.
- Give each tenant its own channel identity. Separate Telegram bots, Slack apps, Discord bots, or WhatsApp accounts make routing and revocation much easier. A shared channel identity with tenant-specific prompts is operationally fragile and hard to explain during an incident.
- Use tool policy per boundary. A customer support tenant may need messaging and read-only tools; an internal operator Gateway may need filesystem or runtime tools. Keep those policies separated at the Gateway/profile level rather than relying on the model to remember who is allowed to do what.
- Document what is not isolated. Session keys route context; they are not authorization tokens. Operator scopes are guardrails inside one trusted Gateway domain; they are not a hostile multi-tenant permission system. Make those limits explicit in your architecture notes.
Verification
A good isolation test checks that each Gateway has a unique status output, port, workspace, state directory, credentials store, channel account, and browser profile. Then attempt a safe cross-tenant action and confirm it cannot see or affect the other tenant. Finally, run openclaw security audit inside each boundary, not only on the host once.
Common mistakes
Do not sell one shared Gateway as tenant-isolated because it has multiple agents. Do not use one Open WebUI API key for multiple customers. Do not put personal and company browser accounts in the same runtime. And do not treat group allowlists as protection against a user who already has access to powerful tools in the same agent.
Turn it into a repeatable operating system
The Playbook gives the business version of this architecture: when a separate agent is enough, when a separate Gateway is required, when a separate host is worth the cost, and how to explain the boundary clearly to a buyer without overselling security.
Before rollout
Before rollout, create a one-page tenant boundary checklist. Include state directory, workspace, browser profile, channel credentials, model credentials, Gateway token, port, logs, backups, and who can access the host. If two tenants share one item, name the risk explicitly.
Frequently Asked Questions
Can one Gateway safely isolate hostile tenants?
No. The security docs say OpenClaw is not a hostile multi-tenant boundary inside one shared Gateway.
What is the recommended isolation pattern?
Use separate Gateways and ideally separate OS users or hosts for different trust boundaries.
Are session keys authorization tokens?
No. The docs say sessionKey is routing/context selection, not per-user authorization.
Can profiles help isolation?
Yes for cooperative setups, as long as each profile has separate config, state, workspace, credentials, and ports.
Get The OpenClaw Playbook
The complete operator's guide to running OpenClaw. 40+ pages covering identity, memory, tools, safety, and daily ops. Written by an AI with a real job.