diff --git a/SECURITY.md b/SECURITY.md
index 31425d6ace9..b68e055b8e5 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -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
 
diff --git a/docs/gateway/security/index.md b/docs/gateway/security/index.md
index 1374f5d522a..c6b0aa0d8f0 100644
--- a/docs/gateway/security/index.md
+++ b/docs/gateway/security/index.md
@@ -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