T05 · Unauthorized Access and Privilege Escalation
- Location
references/openclaw-team-example.json5:165- Finding
Overprivileged Host Filesystem, Command Execution, and Network Access
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is not clearly malicious, but it provides copyable OpenClaw team setup guidance with broad file, command, session-history, network, and persistent shared-memory access that should be reviewed carefully.
Install only if you are comfortable reviewing and narrowing the generated OpenClaw configuration. Before using the examples, prefer workspaceOnly:true, sandbox every agent including the planner, deny outbound sessions_send by default, avoid all-session history visibility unless temporarily needed, keep secrets and session keys out of shared files, and treat shared memory as untrusted coordination data rather than authoritative instructions.
references/openclaw-team-example.json5:165Overprivileged Host Filesystem, Command Execution, and Network Access
references/openclaw-team-example.json5:58Cross-Agent Session Disclosure with Outbound Delivery Allowed by Default
references/team-shared-memory.md:124Persistent Shared Memory Poisoning Through Unrestricted Multi-Agent Writes
The configuration sets fs.workspaceOnly to false, which permits file access beyond agent workspaces and explicitly contemplates shared access via symlinks. This weakens containment and can expose host files or unrelated project data if an agent with read/write or exec capability is compromised or behaves unsafely.
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
WORKSPACE="$HOME/.openclaw/workspace-$agent"
if [ -d "$WORKSPACE" ]; then
# Remove existing symlink if present
rm -f "$WORKSPACE/team-shared"
ln -s "$SHARED_DIR" "$WORKSPACE/team-shared"
echo "✓ Linked team-shared → $WORKSPACE/team-shared"
else
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
## 2026-03-05: Use JWT for API Authentication
**Context**: Need auth for the API gateway
**Decision**: JWT with RS256, 15-min access tokens, 7-day refresh tokens
**Rationale**: Stateless, works well with microservices, industry standard
**Owner**: coder implements, reviewer validates
The skill says to use it whenever the user mentions broad concepts like building an AI team or says things like "set up my agents," without giving exclusion conditions or negative examples. Those phrases are broad enough to catch ordinary agent-help requests that may not specifically be about OpenClaw multi-agent team building.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
to workspace files, routing bindings, channel configuration, and collaboration rules.
Use this skill whenever the user mentions building an AI team, multi-agent setup,
multi-agent collaboration, agent roles, OpenClaw team configuration, or wants to
create multiple agents that work together. Also trigger when the user says things like
"set up my agents", "create an agent team", "configure multi-agent", "I want multiple
AI assistants working together", or references team coordination, agent routing,
agent-to-agent communication, or workspace isolation in OpenClaw.
The shared-memory design explicitly creates persistent cross-agent state through symlinked directories, increasing the risk that one agent can read, overwrite, or misuse information created by another. Because the pattern is durable and shared across sessions, mistakes or malicious prompt outcomes can propagate and persist beyond a single conversation.
Create a shared directory symlinked into every agent's workspace:
~/.openclaw/team-shared/ ← Single source of truth
The skill recommends a shared symlinked directory writable by multiple agents, which weakens workspace isolation and creates an easy path for cross-agent data exposure or contamination. Even though it later says not to write private information there, the design normalizes persistent shared state before establishing strong privacy boundaries, access controls, or least-privilege guidance.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
- `TEAM-DIRECTORY.md` — Put this content in AGENTS.md instead
- `GROUP_MEMORY.md` — Not a standard file; MEMORY.md already has group/private scoping
If you create custom .md files in the workspace, the agent CAN read them with
`memory_get` or file tools, but they are NOT automatically loaded into the session
context the way AGENTS.md, SOUL.md, USER.md, and IDENTITY.md are.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
"enabled": true,
"softThresholdTokens": 4000,
"systemPrompt": "Session nearing compaction. Store durable memories now.",
"prompt": "Write any lasting notes to memory/YYYY-MM-DD.md; reply with NO_REPLY if nothing to store."
}
},
The example grants the planner and coder broad capabilities including exec, process spawning, browser/web access, and multi-session coordination. For a team-building/configuration skill this exceeds least-privilege defaults and increases the blast radius if an agent is prompt-injected, misrouted, or tricked into executing hostile instructions.
The document explicitly tells every agent to consult TEAM-DIRECTORY.md for other agents' IDs and session keys, which unnecessarily centralizes sensitive coordination secrets in a shared location readable by all participants. In a team-building skill, broad distribution of session keys expands the blast radius of any compromised or misconfigured agent and can enable impersonation, unauthorized inter-agent actions, or lateral movement across agent sessions.
The natural-language example under User Preferences specifies 'Language: Chinese (primary), English (technical terms OK)', which imposes a language preference on agent behavior. Because the document does not frame this as user-selected opt-in or a region-specific requirement, it conflicts with the policy against forcing a specific language or locale.
No suspicious patterns detected.