docs: clarify multi-instance recommendations for user isolation

This commit is contained in:
Peter Steinberger
2026-02-24 00:40:04 +00:00
parent a430e1722b
commit 400220275c
2 changed files with 9 additions and 1 deletions

View File

@@ -83,7 +83,10 @@ OpenClaw does **not** model one gateway as a multi-tenant, adversarial user boun
- Authenticated Gateway callers are treated as trusted operators for that gateway instance.
- Session identifiers (`sessionKey`, session IDs, labels) are routing controls, not per-user authorization boundaries.
- If one operator can view data from another operator on the same gateway, that is expected in this trust model.
- If you need adversarial-user isolation, split by trust boundary (separate OS users/hosts/gateways).
- OpenClaw can technically run multiple gateway instances on one machine, but recommended operations are clean separation by trust boundary.
- Recommended mode: one user per machine/host (or VPS), one gateway for that user, and one or more agents inside that gateway.
- If multiple users need OpenClaw, use one VPS (or host/OS user boundary) per user.
- For advanced setups, multiple gateways on one machine are possible, but only with strict isolation and are not the recommended default.
## Out of Scope
@@ -103,6 +106,7 @@ OpenClaw security guidance assumes:
- Anyone who can modify `~/.openclaw` state/config (including `openclaw.json`) is effectively a trusted operator.
- A single Gateway shared by mutually untrusted people is **not a recommended setup**. Use separate gateways (or at minimum separate OS users/hosts) per trust boundary.
- Authenticated Gateway callers are treated as trusted operators. Session identifiers (for example `sessionKey`) are routing controls, not per-user authorization boundaries.
- Multiple gateway instances can run on one machine, but the recommended model is clean per-user isolation (prefer one host/VPS per user).
## Workspace Memory Trust Boundary

View File

@@ -37,6 +37,9 @@ OpenClaw assumes the host and config boundary are trusted:
- If someone can modify Gateway host state/config (`~/.openclaw`, including `openclaw.json`), treat them as a trusted operator.
- Running one Gateway for multiple mutually untrusted/adversarial operators is **not a recommended setup**.
- For mixed-trust teams, split trust boundaries with separate gateways (or at minimum separate OS users/hosts).
- OpenClaw can run multiple gateway instances on one machine, but recommended operations favor clean trust-boundary separation.
- Recommended default: one user per machine/host (or VPS), one gateway for that user, and one or more agents in that gateway.
- If multiple users want OpenClaw, use one VPS/host per user.
### Practical consequence (operator trust boundary)
@@ -46,6 +49,7 @@ Inside one Gateway instance, authenticated operator access is a trusted control-
- Session identifiers (`sessionKey`, session IDs, labels) are routing selectors, not authorization tokens.
- Example: expecting per-operator isolation for methods like `sessions.list`, `sessions.preview`, or `chat.history` is outside this model.
- If you need adversarial-user isolation, run separate gateways per trust boundary.
- Multiple gateways on one machine are technically possible, but not the recommended baseline for multi-user isolation.
## Trust boundary matrix