docs(security): clarify shared-agent trust boundaries

SECURITY.md

@@ -13,7 +13,7 @@ Report vulnerabilities directly to the repository where the issue lives:
 - **ClawHub** — [openclaw/clawhub](https://github.com/openclaw/clawhub)
 - **Trust and threat model** — [openclaw/trust](https://github.com/openclaw/trust)
 
-For issues that don't fit a specific repo, or if you're unsure, email **security@openclaw.ai** and we'll route it.
+For issues that don't fit a specific repo, or if you're unsure, email **[security@openclaw.ai](mailto:security@openclaw.ai)** and we'll route it.
 
 For full reporting instructions see our [Trust page](https://trust.openclaw.ai).
 
@@ -93,7 +93,7 @@ OpenClaw does **not** model one gateway as a multi-tenant, adversarial user boun
 - 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 (for example, reports expecting per-operator isolation for `sessions.list`, `sessions.preview`, `chat.history`, or similar control-plane reads)
-- Prompt injection attacks
+- Prompt-injection-only attacks (without a policy/auth/sandbox boundary bypass)
 - Reports that require write access to trusted local state (`~/.openclaw`, workspace files like `MEMORY.md` / `memory/*.md`)
 - Reports that depend on trusted operator-supplied configuration values to trigger availability impact (for example custom regex patterns). These may still be fixed as defense-in-depth hardening, but are not security-boundary bypasses.
 - Exposed secrets that are third-party/user-controlled credentials (not OpenClaw-owned and not granting access to OpenClaw-operated infrastructure/services) without demonstrated OpenClaw impact
@@ -108,6 +108,23 @@ OpenClaw security guidance assumes:
 - 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).
 
+## One-User Trust Model (Personal Assistant)
+
+OpenClaw's security model is "personal assistant" (one trusted operator, potentially many agents), not "shared multi-tenant bus."
+
+- If multiple people can message the same tool-enabled agent (for example a shared Slack workspace), they can all steer that agent within its granted permissions.
+- Session or memory scoping reduces context bleed, but does **not** create per-user host authorization boundaries.
+- For mixed-trust or adversarial users, isolate by OS user/host/gateway and use separate credentials per boundary.
+- A company-shared agent can be a valid setup when users are in the same trust boundary and the agent is strictly business-only.
+- For company-shared setups, use a dedicated machine/VM/container and dedicated accounts; avoid mixing personal data on that runtime.
+- If that host/browser profile is logged into personal accounts (for example Apple/Google/personal password manager), you have collapsed the boundary and increased personal-data exposure risk.
+
+## Agent and Model Assumptions
+
+- The model/agent is **not** a trusted principal. Assume prompt/content injection can manipulate behavior.
+- Security boundaries come from host/config trust, auth, tool policy, sandboxing, and exec approvals.
+- Prompt injection by itself is not a vulnerability report unless it crosses one of those boundaries.
+
 ## Workspace Memory Trust Boundary
 
 `MEMORY.md` and `memory/*.md` are plain workspace files and are treated as trusted local operator state.

docs/gateway/security/index.md

@@ -51,6 +51,34 @@ Inside one Gateway instance, authenticated operator access is a trusted control-
 - 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.
 
+## Personal assistant model (not a multi-tenant bus)
+
+OpenClaw is designed as a personal assistant security model: one trusted operator boundary, potentially many agents.
+
+- If several people can message one tool-enabled agent, each of them can steer that same permission set.
+- Per-user session/memory isolation helps privacy, but does not convert a shared agent into per-user host authorization.
+- If users may be adversarial to each other, run separate gateways (or separate OS users/hosts) per trust boundary.
+
+### Shared Slack workspace: real risk
+
+If "everyone in Slack can message the bot," the core risk is delegated tool authority:
+
+- any allowed sender can induce tool calls (`exec`, browser, network/file tools) within the agent's policy;
+- prompt/content injection from one sender can cause actions that affect shared state, devices, or outputs;
+- if one shared agent has sensitive credentials/files, any allowed sender can potentially drive exfiltration via tool usage.
+
+Use separate agents/gateways with minimal tools for team workflows; keep personal-data agents private.
+
+### Company-shared agent: acceptable pattern
+
+This is acceptable when everyone using that agent is in the same trust boundary (for example one company team) and the agent is strictly business-scoped.
+
+- run it on a dedicated machine/VM/container;
+- use a dedicated OS user + dedicated browser/profile/accounts for that runtime;
+- do not sign that runtime into personal Apple/Google accounts or personal password-manager/browser profiles.
+
+If you mix personal and company identities on the same runtime, you collapse the separation and increase personal-data exposure risk.
+
 ## Trust boundary matrix
 
 Use this as the quick model when triaging risk: