Multi-Agent Sandbox

• Outcome: Review
• Latest audit: Sep 11, 2026 · 9:47 AM UTC
• Version: 1.0.0

Overview

This skill is a disclosed setup guide, but it asks users to create persistent host network bridges and broad agent permissions that weaken the sandbox boundary it claims to provide.

Review this carefully before installing. It is not clearly malicious, but it makes host-level and persistent networking changes, grants broad agent/session capabilities, uses a remote installer script, enables broad Discord intents, and documents root SSH with host-key checking disabled. Use a dedicated host or test environment, restrict Docker networking to the intended container, avoid bridging the gateway unless strictly required, use a non-root VPS account, pin and verify installers, keep SSH host-key verification enabled, and document how to disable and remove the services.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (5)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:268
• Finding: Unpinned Remote Installation Script Is Executed Directly by a Shell<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 268-272 **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: Critical ### Vulnerable Code ```bash curl -fsSL https://tailscale.com/install.sh | sh sudo tailscale up --ssh ``` ### Technical Analysis The instructions download a mutable script from an external URL and pass the response directly to `sh`. There is no version pinning, cryptographic checksum verification, signature validation, or opportunity to inspect the downloaded content before execution. Although the domain is consistent with the named Tailscale product, the effective code executed by this command can change after the Skill has been reviewed. A compromise of the upstream website, its distribution infrastructure, DNS resolution, TLS termination, or the installation script itself could result in arbitrary commands being returned and immediately executed. The initial shell runs with the invoking user's permissions. Installation scripts may request or invoke privilege elevation to configure package repositories, install packages, and register system services. The subsequent `sudo tailscale up --ssh` command explicitly performs a privileged system configuration change. ### Attack Path 1. An attacker compromises the upstream script, its hosting infrastructure, or another component of the delivery chain. 2. The user follows the Skill and executes the documented `curl | sh` command. 3. The attacker's modified response is sent directly to `sh`. 4. The payload executes with the invoking user's permissions and may attempt to obtain elevated privileges during installation. 5. The payload can modify user files, steal accessible secrets, install additional software, or establish persistence. If elevation succeeds, the compromise can extend to the host system. ### Impact Assessment Successful exploitation permits arbitrary command execution with the permissions of the user running the installation command. ...[truncated 218 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Replace `curl | sh` with installation through Tailscale's documented signed package repository. - Pin an explicitly reviewed package or installer version where the distribution mechanism supports it. - If a script must be used, download it to a local file first rather than piping it into a shell. - Verify a cryptographic signature or a checksum obtained through a separately trusted channel. - Present the script for operator inspection before execution. - Execute installation with the minimum necessary privileges and document all privileged changes. - Avoid granting administrative privileges to an installer whose exact content has not been verified. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:157
• Finding: Persistent Network Bridges Expose Host and VPS Services to Docker Workloads<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 157-199 **Vulnerability Type**: Persistent service registration and excessive network access **Risk Level**: High ### Vulnerable Code ```ini # /etc/systemd/system/socat-bridge-docker0-gateway.service [Unit] Description=Socat bridge: docker0 → Gateway After=network.target docker.service [Service] Type=simple ExecStart=/usr/bin/socat TCP-LISTEN:18789,bind=172.17.0.1,reuseaddr,fork TCP:127.0.0.1:18789 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target ``` ```ini # /etc/systemd/system/socat-bridge-docker0-vps-ssh.service [Unit] Description=Socat bridge: docker0:2222 → VPS Tailscale SSH After=network.target docker.service tailscaled.service Wants=tailscaled.service [Service] Type=simple ExecStart=/usr/bin/socat TCP-LISTEN:2222,bind=172.17.0.1,reuseaddr,fork TCP:100.y.y.y:22 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target ``` ```bash sudo systemctl daemon-reload sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway" sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh" ``` ### Technical Analysis The Skill creates root-managed systemd services that expose two sensitive endpoints through the Docker bridge: - The local gateway at `127.0.0.1:18789` - The VPS SSH service at the Tailscale address on port 22 Binding listeners to `172.17.0.1` instead of `0.0.0.0` reduces exposure to external interfaces, but it does not limit access to the intended sandbox container. Other workloads connected to the default Docker bridge may also be able to reach these ports. The gateway bridge is particularly inconsistent with the claimed isolation model. The sandbox configuration denies direct use of the `gateway` tool, but this bridge creates a network route to the gateway service. The actual security boundary therefore depends ...[truncated 2045 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Avoid exposing the local gateway to sandbox containers unless it is indispensable to a documented feature. - If gateway access is necessary, use a narrowly scoped authenticated API rather than a transparent TCP bridge. - Place the intended sandbox in a dedicated Docker network instead of relying on the shared default `docker0` bridge. - Restrict firewall access to the intended container address or subnet and prevent unrelated containers from joining that network. - Require strong application-layer authentication and authorization on both forwarded services. - Use mutual TLS or another authenticated proxy where practical. - Run the bridge under a dedicated unprivileged system account where supported. - Harden the systemd units with controls such as `NoNewPrivileges=true`, `PrivateTmp=true`, `ProtectSystem=strict`, `ProtectHome=true`, and a restrictive capability set. - Prefer explicit operator-controlled service startup over automatic boot persistence when continuous availability is not required. - Document an uninstall procedure that stops and disables the services, removes their unit files, reloads systemd, and removes the firewall rules. - Replace VPS root access with a restricted, non-root account limited to the required workspace and operations. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:293
• Finding: SSH Server Identity Verification Is Disabled for a Root Connection<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 293 **Vulnerability Type**: Insecure SSH configuration **Risk Level**: High ### Vulnerable Code ```bash ssh -o StrictHostKeyChecking=no root@172.17.0.1 -p 2222 ``` ### Technical Analysis `StrictHostKeyChecking=no` allows SSH to accept a previously unknown server key without requiring operator verification. This weakens SSH's protection against connecting to an impersonated endpoint. The address in this command is a local `socat` listener rather than the VPS itself. SSH still authenticates the server through the key presented over the forwarded connection. If the bridge destination, routing, DNS-independent network path, or local listener is redirected, disabling strict verification makes it easier for a sandbox to connect to an unintended server without detecting the substitution. The use of the `root` account unnecessarily increases the consequences of successful authentication. The documented task only requires collaboration through a shared workspace and does not establish a need for unrestricted VPS administration. ### Attack Path 1. An attacker gains the ability to replace or redirect the local bridge, manipulate the bridge destination, or impersonate the VPS endpoint. 2. The sandbox executes the documented SSH command. 3. SSH receives an unrecognized host key but does not require confirmation because strict checking is disabled. 4. The sandbox establishes a connection to the attacker's SSH server or otherwise treats the substituted endpoint as trusted. 5. The attacker may observe commands and transferred data or exploit any authentication material presented by the client. 6. If the legitimate root account is independently compromised or authorization is overly broad, the same workflow provides full VPS administrative access. ### Impact Assessment Endpoint impersonation can compromise the confidentiality and integrity of commands, files, and collaboration data sent through SSH. ...[truncated 173 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove `StrictHostKeyChecking=no`. - Pre-provision the VPS host key in a dedicated `known_hosts` file. - Use `StrictHostKeyChecking=yes` and specify the controlled file with `UserKnownHostsFile`. - Verify the host-key fingerprint through a separate trusted channel before deployment. - Ensure the host-key entry reflects the key presented through the forwarded endpoint. - Replace `root` with a dedicated non-root collaboration account. - Restrict that account to the required workspace using filesystem permissions, SSH authorization controls, and narrowly scoped `sudo` rules only if elevation is unavoidable. - Prefer short-lived credentials and restrict Tailscale SSH policy to the exact user, source device, destination, and account required. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:52
• Finding: Sandbox Agent Is Granted Excessive Session and Agent-Orchestration Capabilities<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 52-75 **Vulnerability Type**: Excessive agent permissions and session visibility **Risk Level**: Medium ### Vulnerable Code ```json "sessionToolsVisibility": "all", ``` ```json "alsoAllow": ["message", "sessions_send", "sessions_list", "sessions_history"], ``` ```json "allow": [ "exec", "process", "read", "write", "edit", "apply_patch", "image", "web_search", "web_fetch", "sessions_list", "sessions_history", "sessions_send", "sessions_spawn", "subagents", "session_status", "message", "browser" ], ``` ### Technical Analysis The sandbox receives visibility into all session tools together with permission to list sessions, inspect session history, send messages, spawn sessions, invoke subagents, browse the web, and execute commands. These permissions exceed the minimum needed for the declared hub-and-spoke collaboration model. In particular, `sessions_history` may expose conversation content available within the configured visibility scope, while `sessions_send`, `sessions_spawn`, and `subagents` allow the sandbox to influence or initiate other agent workflows. Per-agent `agentToAgent.allow` restrictions provide some protection, but broad session visibility and orchestration capabilities increase the consequences of prompt injection or compromise. This also conflicts with the stated objective of isolating sandbox agents from main-agent private data. ### Attack Path 1. An attacker sends adversarial content to the sandbox through Discord, shared files, browser content, or another accepted input. 2. The sandbox follows the malicious instruction or is otherwise compromised. 3. It invokes `sessions_list` to enumerate accessible sessions. 4. It invokes `sessions_history` to retrieve any conversation content permitted by the broad visibility configuration. 5. It uses `sessions_send`, `sessions_spawn`, `subagents`, or `message` to influence trusted agents or create additional activity. ...[truncated 684 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Change `sessionToolsVisibility` from `all` to the narrowest supported visibility scope. - Remove `sessions_history` and `sessions_list` unless the sandbox has a documented need to inspect existing sessions. - Remove `sessions_spawn` and `subagents` unless autonomous agent creation is an explicit requirement. - Permit `sessions_send` only to the specific main agent required by the hub-and-spoke design. - Expose a constrained collaboration API that accepts narrowly defined messages instead of general session-management tools. - Apply per-agent and per-session authorization checks to every session operation. - Prevent sandbox-accessible histories from containing secrets, private user data, or credentials. - Log and rate-limit session enumeration, history access, message sending, and agent spawning. - Test the final policy with a hostile sandbox prompt to confirm that unrelated sessions and agents remain inaccessible. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:209
• Finding: Discord Bot Is Instructed to Enable Unnecessary Privileged Gateway Intents<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 209 **Vulnerability Type**: Excessive third-party service permissions **Risk Level**: Medium ### Vulnerable Code ```text Enable all 3 Privileged Gateway Intents (MESSAGE CONTENT, SERVER MEMBERS, PRESENCE) ``` ### Technical Analysis The Skill instructs operators to enable all three Discord privileged gateway intents. `MESSAGE CONTENT` may be necessary for processing message text and mention-gated interactions, but the documented workflow does not establish a need to retrieve the full server member list or user presence information. Enabling `SERVER MEMBERS` and `PRESENCE` broadens the categories of data available to the bot and increases the consequences of bot-token compromise. This violates least-privilege principles because the Skill's declared functionality is message-based collaboration rather than member synchronization or presence monitoring. ### Attack Path 1. The operator follows the Skill and grants all privileged intents to the Discord bot. 2. The bot token is later exposed through configuration leakage, logs, malware, an agent interaction, or another compromise. 3. The attacker uses the token to operate a Discord gateway connection subject to Discord's authorization controls. 4. The compromised bot gains access to privileged member or presence events that were not necessary for the collaboration workflow. 5. The attacker collects guild metadata and user-activity information or uses it to support social engineering and targeting. ### Impact Assessment The affected scope is the Discord guilds to which the bot has been invited and the permissions and intents Discord grants to that bot. The unnecessary intents can expose member metadata and presence information beyond what is required to process mention-gated messages. This finding does not by itself grant host access, but it increases privacy exposure and the impact of credential compromise. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Enable only the gateway intents required by tested functionality. - Retain `MESSAGE CONTENT` only if the bot cannot implement the documented behavior without it. - Disable `SERVER MEMBERS` unless the bot performs a documented member-management or member-lookup function. - Disable `PRESENCE` unless presence monitoring is an explicit requirement. - Minimize the bot's guild permissions in addition to its gateway intents. - Restrict the bot to the required guilds and channels. - Store bot tokens in a dedicated secret manager or protected environment configuration. - Rotate the token immediately if it is exposed and audit Discord activity following any suspected compromise. ]]>

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (16)

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

bash ca-certificates curl git jq \
    openssh-client \
    python3 ripgrep \
  && rm -rf /var/lib/apt/lists/*
```

Rebuild and force-recreate containers:

• Confidence: 90% 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).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

bash ca-certificates curl git jq \
    openssh-client \
    python3 ripgrep \
  && rm -rf /var/lib/apt/lists/*
```

Rebuild and force-recreate containers:

• Confidence: 90% 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).

Chaining Abuse

High

• Category: Tool Misuse

Content

bash ca-certificates curl git jq \
    openssh-client \
    python3 ripgrep \
  && rm -rf /var/lib/apt/lists/*
```

Rebuild and force-recreate containers:

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

```bash
docker build -f Dockerfile.sandbox -t openclaw-sandbox:bookworm-slim .
docker ps --format "{{.ID}} {{.Image}}" | grep sandbox | awk '{print $1}' | xargs -r docker rm -f
```

## Step 4 — Socat Bridges

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

External Script Fetching

High

• Category: Supply Chain

Content

Install on all machines:

```bash
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --ssh
```

• Confidence: 98% confidence
• Finding: Piping a remote script directly into sh executes unreviewed network content with full installer privileges, creating a strong supply-chain and content-injection risk. If the remote endpoint, transport, or DNS is compromised, the operator may run attacker-controlled code on every machine involved in the multi-agent infrastructure.

Chaining Abuse

High

• Category: Tool Misuse

Content

Install on all machines:

```bash
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --ssh
```

• Confidence: 99% confidence
• Finding: The | sh chain is dangerous because it turns a remote fetch directly into code execution without review or integrity verification. This is especially sensitive here because the commands are run on infrastructure hosts that provide cross-agent connectivity and persistence.

Intent-Code Divergence

Medium

• Confidence: 84% confidence
• Finding: The skill claims the sandbox isolates private data, but it explicitly grants the sandbox broad messaging and session tools such as sessions_send, sessions_history, sessions_list, and message. Those capabilities create a practical exfiltration path from the sandbox workspace to other agents or external channels, so the isolation claim is overstated unless strict data-flow controls are added.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

Enable, start, and open firewall:

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

Enable, start, and open firewall:

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

Enable, start, and open firewall:

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

Enable, start, and open firewall:

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

Enable, start, and open firewall:

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

Enable, start, and open firewall:

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Session Persistence

Medium

• Category: Rogue Agent

Content

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
sudo ufw allow in on docker0 to 172.17.0.1 port 18789 proto tcp comment "socat-gateway"
sudo ufw allow in on docker0 to 172.17.0.1 port 2222 proto tcp comment "socat-vps-ssh"
```

• Confidence: 80% confidence
• Finding: The skill instructs operators to enable persistent host services that automatically recreate network bridges across reboots. Persistence is intentional here, but it still increases attack surface because a misconfigured or later-compromised bridge remains available continuously and survives restarts.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The documented SSH command uses StrictHostKeyChecking=no, which disables host identity verification and makes man-in-the-middle interception much easier. In this design, the SSH path bridges containers to a shared VPS, so trust on first use or disabled verification materially weakens the boundary protecting shared workspace access.

Intent-Code Divergence

Low

• Confidence: 80% confidence
• Finding: The key-constraints section states "all exec runs through Docker, never on host," which reads as a broad safety/property claim. However, the skill's actual procedure depends on host modifications including systemd service creation, UFW changes, Tailscale installation, and Docker image rebuilds, so the statement overstates the effective boundary described by the overall instructions.

Static analysis

No suspicious patterns detected.