Agent Team Builder

• Outcome: Review
• Latest audit: Sep 11, 2026 · 5:44 AM UTC
• Version: 0.1.0

Overview

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.

A.I.G

Vulnerability Patterns

• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: references/openclaw-team-example.json5:165
• Finding: Overprivileged Host Filesystem, Command Execution, and Network Access<![CDATA[ ## Vulnerability Details **File Location**: `references/openclaw-team-example.json5:165-184` and `references/openclaw-team-example.json5:340-355` **Vulnerability Type**: Excessive host-level permissions and insufficient sandboxing **Risk Level**: High ### Vulnerable Code ```json5 "tools": { "allow": [ "read", "write", "edit", "exec", "memory_search", "memory_get", "sessions_list", "sessions_history", "sessions_send", "sessions_spawn", "session_status", "browser", "web_search", "web_fetch" ], "sessions": { "visibility": "all" // Orchestrator needs to see all sessions for coordination } } ``` ```json5 // File system restrictions "fs": { "workspaceOnly": false // Set to true if you want strict workspace-only file access // Set to false if agents need to read team-shared/ via symlinks }, // Exec security "exec": { "security": "allow", "ask": "auto" // "deny" = no exec at all // "allow" + "ask": "always" = ask before every exec // "allow" + "ask": "auto" = ask for risky commands } ``` ### Technical Analysis The example configuration gives the planner simultaneous access to filesystem read and write operations, command execution, cross-agent session tools, and network-capable browser and web tools. The planner is not configured with a sandbox, while the global filesystem policy explicitly permits access outside the workspace. This exceeds the minimum privileges required for ordinary team coordination. A coordinating agent generally needs task delegation and narrowly scoped access to team status data, but it does not inherently require unrestricted host filesystem access or command execution. The project documentation correctly notes that workspaces are not sandboxed by default and that absolute paths can reach other host locations. Nevertheless, the supplied copyable configuration retains the unsafe defaults. Prompt injection received through Discord, Telegram, web content, or shared projec ...[truncated 1448 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Change the global filesystem policy to workspace-only access: ```json5 "fs": { "workspaceOnly": true } ``` 2. Apply an agent-scoped sandbox to every agent, including the planner: ```json5 "sandbox": { "mode": "all", "scope": "agent", "workspaceAccess": "rw" } ``` 3. Remove `exec`, `process`, `write`, and `edit` from the planner unless a documented workflow specifically requires them. 4. If command execution is required, use `"ask": "always"` and a narrowly defined command allowlist. 5. Grant browser and web tools only to agents that need external research. 6. Expose shared memory through a narrowly scoped, sandbox-mounted directory instead of disabling workspace restrictions globally. 7. Require explicit user confirmation before accessing host paths, modifying files, executing commands, or transmitting file contents. 8. Separate the coordination role from any role that performs host-level execution. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: references/openclaw-team-example.json5:58
• Finding: Cross-Agent Session Disclosure with Outbound Delivery Allowed by Default<![CDATA[ ## Vulnerability Details **File Location**: `references/openclaw-team-example.json5:58-67` and `references/openclaw-team-example.json5:165-184` **Vulnerability Type**: Unrestricted cross-agent session visibility and permissive message delivery **Risk Level**: High ### Vulnerable Code ```json5 // Policy for sessions_send delivery "sendPolicy": { "rules": [ // Example: deny agent-to-agent sends into Discord groups // (forces visible @mention collaboration instead) // { // "match": { "channel": "discord", "chatType": "group" }, // "action": "deny" // } ], "default": "allow" } ``` ```json5 "tools": { "allow": [ "read", "write", "edit", "exec", "memory_search", "memory_get", "sessions_list", "sessions_history", "sessions_send", "sessions_spawn", "session_status", "browser", "web_search", "web_fetch" ], "sessions": { "visibility": "all" // Orchestrator needs to see all sessions for coordination } } ``` ### Technical Analysis The planner can enumerate sessions, inspect session histories belonging to all agents, and send messages into sessions. At the same time, the global send policy allows delivery by default. The only example restricting delivery into Discord groups is commented out and therefore provides no enforcement. Session histories can contain private conversations, source code, project information, personal data, or credentials inadvertently supplied by users. Combining cross-agent history access with permissive outbound delivery creates a direct path across agent and channel isolation boundaries. The `dmScope` setting isolates conversations by channel and peer, but this protection is weakened when an orchestrator has global history visibility and can relay content into other sessions. Agent coordination does not generally require unrestricted access to complete private histories. ### Attack Path 1. The planner receives a malicious prompt through an enabled chann ...[truncated 991 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Change the send policy to deny by default: ```json5 "sendPolicy": { "rules": [ { "match": { "channel": "discord", "chatType": "group" }, "action": "deny" } ], "default": "deny" } ``` 2. Add narrow allow rules only for named agents, approved session types, and expected private destinations. 3. Use `"visibility": "tree"` or `"visibility": "agent"` instead of `"all"` during normal operation. 4. Enable global cross-agent visibility only temporarily and after explicit user approval. 5. Remove `sessions_history` from agents that only need task dispatch. 6. Prevent session-history content from being sent to external channels without confirmation and data-loss-prevention checks. 7. Enforce a policy that blocks delivery from private sessions into group chats. 8. Prefer `sessions_spawn` with minimal task context over exposing complete historical sessions. 9. Audit all calls to `sessions_history` and `sessions_send`, including source and destination session identifiers. ]]>

T02 · Agent Memory Poisoning

Warning

• Location: references/team-shared-memory.md:124
• Finding: Persistent Shared Memory Poisoning Through Unrestricted Multi-Agent Writes<![CDATA[ ## Vulnerability Details **File Location**: `references/team-shared-memory.md:124-145` and `references/team-shared-memory.md:166-181` **Vulnerability Type**: Persistent shared-context poisoning and insufficient writer isolation **Risk Level**: Medium ### Vulnerable Code ```bash # 3. Symlink into each agent's workspace for agent in "${AGENTS[@]}"; do 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 echo "⚠ Workspace not found: $WORKSPACE (create agent first)" fi done ``` ```markdown ## Team Shared Memory Protocol ### Reading Team Context - Before starting any significant task, read `team-shared/TEAM-STATUS.md` to understand current priorities and blockers - Use `memory_get` to read `team-shared/TEAM-KNOWLEDGE.md` when you need team-level preferences or standing decisions - Check `team-shared/TEAM-DIRECTORY.md` for other agents' IDs and session keys ### Writing Team Context - After completing a significant task, update `team-shared/TEAM-STATUS.md` with the outcome - When a team-level decision is made, append to `team-shared/TEAM-DECISIONS.md` with date, context, and rationale - Format: `## YYYY-MM-DD: [Decision Title]\n[Context]\n[Decision]\n[Rationale]` - NEVER write private user information to team-shared files ``` ### Technical Analysis The setup links every agent workspace to one persistent shared directory. Every agent is instructed to consume shared status, knowledge, decisions, and directory data and is also instructed to write updates to that same location. No technical control restricts which agents may modify authoritative files. There is no schema validation, signature verification, immutable provenance, trusted-writer separation, or approval process. The instruction not to write private information is advi ...[truncated 2175 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Make shared knowledge and decision files read-only for specialist agents. 2. Designate one trusted curator, preferably a minimally privileged memory service or approval-controlled orchestrator, as the sole writer. 3. Store agent submissions in a separate untrusted inbox rather than directly modifying authoritative context. 4. Validate proposed updates against strict schemas and reject executable instructions, tool directives, credential material, and unexpected file references. 5. Require user approval before promoting submitted content into authoritative shared memory. 6. Record immutable provenance for every update, including agent ID, source session, timestamp, and content hash. 7. Do not store raw session keys, credentials, API integration details, or private user data in shared files. 8. Treat shared-memory content as untrusted data in agent instructions and explicitly prohibit following operational directives found in it. 9. Use file permissions or separate mounts to enforce read-only and write-only roles at the operating-system level. 10. Replace files atomically and maintain version history so poisoned updates can be detected and rolled back. 11. Before running `rm -f`, verify the existing path type and require confirmation when it is not the expected symlink. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence

Findings (12)

Context-Inappropriate Capability

High

• Confidence: 98% confidence
• Finding: 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 Parameter Abuse

High

• Category: Tool Misuse

Content

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

• Confidence: 85% confidence
• Finding: 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).

Credential Access

High

• Category: Privilege Escalation

Content

## 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

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Vague Triggers

Medium

• Confidence: 88% confidence
• Finding: 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

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.

• Confidence: 60% confidence
• Finding: 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

### The Design

Create a shared directory symlinked into every agent's workspace:

```
~/.openclaw/team-shared/           ← Single source of truth

• Confidence: 93% confidence
• Finding: 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.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

- `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.

• Confidence: 60% confidence
• Finding: 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

"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."
        }
      },

• Confidence: 60% confidence
• Finding: 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.

Context-Inappropriate Capability

Medium

• Confidence: 94% confidence
• Finding: 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.

Context-Inappropriate Capability

Medium

• Confidence: 95% confidence
• Finding: 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.

Natural-Language Policy Violations

Medium

• Confidence: 95% confidence
• Finding: 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.

Static analysis

No suspicious patterns detected.