docs(security): clarify workspace memory trust boundary

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.