docs(security): clarify trusted-host deployment assumptions

SECURITY.md

@@ -47,8 +47,17 @@ When patching a GHSA via `gh api`, include `X-GitHub-Api-Version: 2022-11-28` (o
 
 - Public Internet Exposure
 - Using OpenClaw in ways that the docs recommend not to
+- Deployments where mutually untrusted/adversarial operators share one gateway host and config
 - Prompt injection attacks
 
+## Deployment Assumptions
+
+OpenClaw security guidance assumes:
+
+- The host where OpenClaw runs is within a trusted OS/admin boundary.
+- 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.
+
 ## Plugin Trust Boundary
 
 Plugins/extensions are loaded **in-process** with the Gateway and are treated as trusted code.

docs/cli/security.md

@@ -24,6 +24,7 @@ openclaw security audit --json
 ```
 
 The audit warns when multiple DM senders share the main session and recommends **secure DM mode**: `session.dmScope="per-channel-peer"` (or `per-account-channel-peer` for multi-account channels) for shared inboxes.
+This is for cooperative/shared inbox hardening. A single Gateway shared by mutually untrusted/adversarial operators is not a recommended setup; split trust boundaries with separate gateways (or separate OS users/hosts).
 It also warns when small models (`<=300B`) are used without sandboxing and with web/browser tools enabled.
 For webhook ingress, it warns when `hooks.defaultSessionKey` is unset, when request `sessionKey` overrides are enabled, and when overrides are enabled without `hooks.allowedSessionKeyPrefixes`.
 It also warns when sandbox Docker settings are configured while sandbox mode is off, when `gateway.nodes.denyCommands` uses ineffective pattern-like/unknown entries, when global `tools.profile="minimal"` is overridden by agent tool profiles, and when installed extension plugin tools may be reachable under permissive tool policy.

docs/gateway/security/index.md

@@ -30,6 +30,14 @@ OpenClaw is both a product and an experiment: you’re wiring frontier-model beh
 
 Start with the smallest access that still works, then widen it as you gain confidence.
 
+## Deployment assumption (important)
+
+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).
+
 ## Hardened baseline in 60 seconds
 
 Use this baseline first, then selectively re-enable tools per trusted agent:
@@ -66,6 +74,7 @@ If more than one person can DM your bot:
 - Set `session.dmScope: "per-channel-peer"` (or `"per-account-channel-peer"` for multi-account channels).
 - Keep `dmPolicy: "pairing"` or strict allowlists.
 - Never combine shared DMs with broad tool access.
+- This hardens cooperative/shared inboxes, but is not designed as hostile co-tenant isolation when users share host/config write access.
 
 ### What the audit checks (high level)
 
@@ -285,6 +294,8 @@ By default, OpenClaw routes **all DMs into the main session** so your assistant
 
 This prevents cross-user context leakage while keeping group chats isolated.
 
+This is a messaging-context boundary, not a host-admin boundary. If users are mutually adversarial and share the same Gateway host/config, run separate gateways per trust boundary instead.
+
 ### Secure DM mode (recommended)
 
 Treat the snippet above as **secure DM mode**: