From b13fc7eccdc74324c269927e83147abfdda12149 Mon Sep 17 00:00:00 2001 From: Peter Steinberger Date: Sun, 22 Feb 2026 11:22:24 +0100 Subject: [PATCH] docs(security): clarify workspace memory trust boundary --- SECURITY.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/SECURITY.md b/SECURITY.md index ae6885bc23e..1a26e7541c0 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -49,6 +49,7 @@ When patching a GHSA via `gh api`, include `X-GitHub-Api-Version: 2022-11-28` (o - 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 +- Reports that require write access to trusted local state (`~/.openclaw`, workspace files like `MEMORY.md` / `memory/*.md`) ## Deployment Assumptions @@ -59,6 +60,15 @@ OpenClaw security guidance assumes: - 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. +## Workspace Memory Trust Boundary + +`MEMORY.md` and `memory/*.md` are plain workspace files and are treated as trusted local operator state. + +- If someone can edit workspace memory files, they already crossed the trusted operator boundary. +- Memory search indexing/recall over those files is expected behavior, not a sandbox/security boundary. +- Example report pattern considered out of scope: "attacker writes malicious content into `memory/*.md`, then `memory_search` returns it." +- If you need isolation between mutually untrusted users, split by OS user or host and run separate gateways. + ## Plugin Trust Boundary Plugins/extensions are loaded **in-process** with the Gateway and are treated as trusted code.