T05 · Unauthorized Access and Privilege Escalation
- Location
- SKILL.md:158
- Finding
- Shared Workspace and Memory Pool Violate Agent Isolation Boundaries<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:23-33, 43, 158-172, 196`; duplicated in `README.md:9-19, 29` **Vulnerability Type**: Excessive cross-agent data and workspace access **Risk Level**: Medium ### Vulnerable Configuration ```json "agents": { "defaults": { "workspace": "~/.openclaw/workspace", "model": { "primary": "..." } }, "list": [ { "id": "main" }, { "id": "agent_id", "name": "agent_id", "workspace": "~/.openclaw/workspace", "model": "..." } ] } ``` The documented architecture additionally states that: - All agents share the same workspace. - All agents automatically share one MemOS Cloud memory pool. - `USER.md`, containing user information, is readable by all agents. - Shared-context files are available to every agent. - The configuration checklist requires all agents to point to the same workspace path. ### Technical Analysis The design assigns the main agent and every subordinate agent the same workspace, rather than granting each agent an isolated directory with narrowly scoped shared resources. It also places every agent in a common persistent memory pool. This breaks least-privilege and tenant-isolation principles. A Telegram-facing sub-agent may process untrusted group messages and therefore has a larger prompt-injection exposure than the main agent. Once such an agent is influenced, its legitimate workspace or memory capabilities may provide access to information belonging to the user and other agents. Directory names under `workspace/agents/` do not establish a security boundary when all agents are configured with the parent `~/.openclaw/workspace` as their workspace. Without operating-system permissions, tool restrictions, or application-level access controls, a sub-agent can potentially read or modify sibling-agent files, main-agent files, and shared state. The common MemOS pool creates a similar confidentiality and integrity problem for persistent memory. The ...[truncated 1792 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Assign each agent a separate workspace, such as: ```json { "id": "agent_id", "workspace": "~/.openclaw/workspaces/agent_id" } ``` 2. Create a narrowly scoped collaboration directory instead of sharing the workspace root. 3. Make shared resources read-only by default and grant write access only to agents that require it. 4. Do not expose `USER.md`, credentials, main-agent instructions, or identity files to subordinate agents by default. 5. Use per-agent MemOS namespaces or separate memory pools with explicit access-control policies. 6. Sanitize and validate content before moving it from an agent-specific area into shared context or persistent memory. 7. Apply operating-system permissions or sandbox policies so directory conventions are backed by enforceable controls. 8. Restrict file and memory tools available to Telegram-facing agents. 9. Record and audit cross-agent reads, writes, and memory retrievals. 10. Document a trust model explaining which agents may access each shared resource and why. ]]>
