Multi-Agent Sandbox
ReviewAudited by ClawScan on May 18, 2026.
Overview
The guide is coherent for building a sandbox, but it creates persistent bridges and broad agent/session permissions that could expose the local gateway, shared VPS, or conversation data if not tightly scoped.
Review this carefully before using it. If you install it, restrict agent allowlists to named agents, avoid wildcard main-agent access, disable session history/spawn tools unless necessary, use dedicated low-privilege Discord and SSH credentials, and verify that the socat bridges are authenticated, firewalled, and removed when no longer needed.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A sandboxed agent or process could potentially reach local gateway functionality over the network rather than through the declared tool permissions.
The sandbox denies the gateway tool, but the setup also exposes the local gateway port to Docker containers while allowing sandbox exec/process. If the gateway endpoint is sensitive and not separately authenticated or scoped, this can weaken the intended tool boundary.
"allow": ["exec", "process", ...] ... "deny": ["gateway", ...] ... ExecStart=/usr/bin/socat TCP-LISTEN:18789,bind=172.17.0.1,... TCP:127.0.0.1:18789
Only create the gateway bridge if it is required, ensure the gateway endpoint is authenticated, restrict access to the intended container or network, and document exactly what the bridged port permits.
Conversation history, workspace context, or private agent data could be exposed across agents, Discord, or a shared VPS if permissions are broader than intended.
The configuration enables broad inter-agent communication, session listing/history access, and a wildcard outbound allowlist for the main agent. This is aligned with collaboration, but the visible instructions do not fully define data boundaries or review requirements for session history and cross-agent forwarding.
"agentToAgent": { "allow": ["*"] } ... `main-agent → anyone` ✅ ... "alsoAllow": ["message", "sessions_send", "sessions_list", "sessions_history"]Limit agentToAgent allowlists to named agents, disable sessions_history/sessions_spawn unless required, keep shared workspaces free of secrets, and add explicit approval rules for sending sensitive content.
The network bridges remain active until the user disables or removes the services.
The setup creates persistent systemd services that automatically restart. This is disclosed and purpose-aligned for infrastructure, but it means the bridges keep operating after the initial setup.
Restart=always ... sudo systemctl enable --now socat-bridge-docker0-gateway socat-bridge-docker0-vps-ssh
Track the created service units, disable them when no longer needed, and add cleanup instructions before using this in a sensitive environment.
Misconfigured or overprivileged tokens and SSH/Tailscale access could let sandbox agents affect accounts or infrastructure beyond the intended sandbox.
The skill expects users to provision Discord bot tokens, Tailscale access, and VPS/SSH access. These credentials are expected for the stated integration and there is no evidence of credential exfiltration, but they are sensitive authorities.
- A Discord bot token per sandbox agent ... - A shared VPS accessible via Tailscale
Use dedicated low-privilege Discord bots, separate SSH keys, restricted VPS accounts, and avoid storing secrets in the shared workspace.