diff --git a/SECURITY.md b/SECURITY.md index b68e055b8e5..bf6917656ca 100644 --- a/SECURITY.md +++ b/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. diff --git a/docs/gateway/security/index.md b/docs/gateway/security/index.md index c6b0aa0d8f0..69251914469 100644 --- a/docs/gateway/security/index.md +++ b/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: