Show HN: Silo – an open source secure CLI sandbox for running agents locally A developer released SILO, an open-source, self-hosted command-line tool that runs untrusted AI agents inside hardened Docker sandboxes with controlled egress, credential-managed integrations and inference auditing, installable via the npm package `cli-silo` (command `silo`) on Node.js 18+ with Docker. SILO routes agent LLM and HTTP requests through a host-side inference proxy on port 8199 that injects real API keys and integration tokens, evaluates each request against declarative YAML egress policies, and writes all proxy and tool-calling events to standard JSONL audit logs, while keys at rest are protected with machine-bound PBKDF2 AES-256-GCM encryption. The tool is built to support agentic workflows including the OpenClaw browser automation framework, and its author frames it as a defense-in-depth response to agents that can exfiltrate API keys, run destructive commands such as `rm -rf /`, or reach arbitrary internet hosts unsupervised. Self-hosted CLI for running untrusted AI agents locally inside hardened Docker sandboxes with controlled egress, credential-managed integrations, and transparent inference auditing. Built-in agent runner · OpenClaw browser automation · Agent framework support · Policy-governed egress · Transparent inference proxy · Unified audit logging · Framework trace collection · Multi-agent orchestration · Credential-managed integrations Install -install · Quick Start -quick-start · Why SILO? -why-silo · Capabilities -capabilities · Frameworks -framework-support · Examples examples · Docs https://github.com/Asdivyansh/silo-cli/blob/main/docs · Contributing contributing SILO is a self-hosted developer CLI tool designed to run untrusted AI agents inside hardened Docker sandboxes with controlled egress, credential-managed integrations, and transparent inference auditing. Out of the box, it is built to support advanced agentic workflows including browser automation frameworks such as OpenClaw . It relies on several decoupled components: - CLI Entrypoint & Commands cli.ts https://github.com/Asdivyansh/silo-cli/blob/main/src/cli.ts : Command orchestration and interactive onboarding wizard onboard.ts https://github.com/Asdivyansh/silo-cli/blob/main/src/commands/onboard.ts . - Inference & Integration Proxy server.ts https://github.com/Asdivyansh/silo-cli/blob/main/src/proxy/server.ts : Intercepts and logs LLM/egress requests, injects credentials on the host side, and manages the interactive prompter interceptor.ts https://github.com/Asdivyansh/silo-cli/blob/main/src/proxy/interceptor.ts . - Docker Sandbox Core runner.ts https://github.com/Asdivyansh/silo-cli/blob/main/src/docker/runner.ts : Spawns and manages hardened, capability-restricted Docker containers with resource limits. - Policy Engine engine.ts https://github.com/Asdivyansh/silo-cli/blob/main/src/policy/engine.ts : Evaluates egress HTTP requests against declarative YAML policies. - Audit Logger audit.ts https://github.com/Asdivyansh/silo-cli/blob/main/src/audit/audit.ts : Standardizes and records all proxy and tool-calling event streams to standard JSONL log files. - Config & Encryption Layer manager.ts https://github.com/Asdivyansh/silo-cli/blob/main/src/config/manager.ts : Secures keys at rest using machine-bound PBKDF2 AES-256-GCM encryption encryption.ts https://github.com/Asdivyansh/silo-cli/blob/main/src/config/encryption.ts . Requirements: Node.js 18+, npm, Docker, and an LLM provider key or local OpenAI-compatible endpoint. npm install -g cli-silo silo --help The npm package is named cli-silo ; the installed command is silo . From source: git clone https://github.com/AsDivyansh/silo.git cd silo npm install npm run build npm link Docker Desktop must be running before silo build , silo start , or silo quickstart . Running AI agents with shell access, file system privileges, and API credentials is dangerous . An agent can: - Exfiltrate your API keys by POST-ing them to an external server - Execute destructive commands — rm -rf / , credential harvesting, crypto mining - Access arbitrary internet hosts to download malware or exfiltrate data - Run unsupervised with no visibility into what it's doing SILO reduces these risks with a defense-in-depth security architecture: ┌─────────────────────────────────────────────────────────────────────────────┐ │ HOST MACHINE │ │ │ │ ┌──────────────────────┐ ┌─────────────────────────────────────┐ │ │ │ silo CLI │ start │ Inference Proxy :8199 │ │ │ │ Node.js │───────▶│ • Injects real API key │ │ │ │ │ │ • Injects integration tokens │ │ │ │ $ silo quickstart │ │ • Evaluates policy per-request │ │ │ │ $ silo run "task" │ │ • Records unified audit trail │ │ │ │ $ silo logs │ │ • Collects framework traces │ │ │ │ $ silo logs -F │ │ • Encrypts API keys at rest │ │ │ │ $ silo traces │ │ • Health check + auto-restart │ │ │ └──────────────────────┘ └──────────┬─────────┬────────────────┘ │ │ │ │ │ │ ┌──────────▼──┐ ┌──▼───────────────┐ │ │ │ LLM Provider │ │ APIs Slack, │ │ │ │ OpenAI / etc │ │ GitHub, HubSpot │ │ │ └─────────────┘ └──────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ Docker Sandbox │ │ │ │ --read-only --cap-drop ALL --user 1001:1001 --pids-limit 128 │ │ │ │ --network silo-sandbox-net SILO bridge │ │ │ │ │ │ │ │ Agent ──▶ http://llm.gateway:8199 ──▶ LLM via proxy │ │ │ │ Agent ──▶ http://slack.gateway:8199 ──▶ Slack API via proxy │ │ │ │ Agent ──▶ POST / silo/traces ──▶ Unified audit log │ │ │ │ │ │ │ │ ✓ HTTP egress routes through the policy proxy │ │ │ │ ✗ Cannot see API keys or tokens │ │ │ │ ✗ Cannot escalate privileges │ │ │ │ ✗ Cannot modify the root filesystem │ │ │ │ ✓ Can call LLMs through the proxy │ │ │ │ ✓ Can call integrations through gateways │ │ │ │ ✓ Can push framework traces to the audit log │ │ │ │ ✓ Can read/write /workspace │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────────┘ Important SILO reduces risk; it does not make arbitrary code safe. Treat sandboxed agents as untrusted, review policy prompts carefully, and only expose host folders with --desktop or --mount when you are comfortable sharing those files. One command does everything — onboard, build, start, connect silo quickstart Or step by step: silo onboard Interactive setup provider, API key, security mode silo build Build the sandbox Docker image silo start Launch sandbox + proxy silo run "List files in /workspace and describe what you find" silo logs See exactly what the agent did silo quickstart asks for your provider, API key, model, workspace, resource limits, and policy mode before launching the first sandbox. With a framework: silo quickstart --framework crewai Build CrewAI image, start, connect Run tasks directly from the CLI. SILO orchestrates the full LLM tool-calling loop — sending prompts, executing tools inside the sandbox, feeding results back, and repeating until done. All LLM calls are routed through the inference proxy for unified audit logging. silo run "Create a Python script that calculates fibonacci numbers" silo run "Install numpy and run the test suite" --max-turns 20 silo run "Refactor the auth module" --name my-agent Built-in agent tools: | Tool | Description | |---|---| | execute command | Run any shell command inside the sandbox | | read file | Read file contents with optional line limit | | write file | Create/overwrite files with arbitrary content | Supports both OpenAI and Anthropic function calling formats. All tool execution happens inside the sandboxed container — the agent can never touch the host. Run popular agent frameworks inside the sandbox with pre-configured Docker images, policy presets, and optional trace collection. silo frameworks list See available frameworks silo build --framework crewai Build a CrewAI-ready image silo start --framework crewai Start with CrewAI installed silo connect Shell in and run your crew Browser-capable framework image: silo build --framework openclaw --browser silo start --framework openclaw --browser --desktop Or build browser variants for every supported framework silo build --all-frameworks --browser Browser mode bakes Chromium into a separate framework image, routes common browser executable names through a SILO launcher, keeps /tmp mounted noexec , and uses disposable tmpfs mounts for browser cache/profile/downloads. At runtime SILO also gives the container a larger /dev/shm and raises the memory limit to at least 2g for browser stability. The --browser profile is available for every supported framework image. OpenClaw is the primary browser-automation use case, but silo build --all-frameworks --browser builds browser variants for CrewAI, LangGraph, Aider, SWE-Agent, and OpenClaw. Supported frameworks: | Framework | Install | TUI | Trace Callbacks | |---|---|---|---| | 🚢 CrewAI | pip | — | ✅ SiloCrewCallbacks event listener | | 🔀 LangGraph | pip | — | ✅ SiloLangChainCallbacks BaseCallbackHandler | | 🧑💻 Aider | pip | ✅ silo connect --tui | — | | 🔧 SWE-Agent | pip | — | — | | 🦞 OpenClaw | npm | ✅ silo connect --tui | — | Any agent not listed above can be added without forking SILO. Drop a YAML definition into ~/.silo/frameworks/ and it behaves like a built-in — silo build --framework my-agent , silo start --framework my-agent , policies, audit logging, and optionally silo connect --tui all work identically: ~/.silo/frameworks/my-agent.yaml id: my-agent name: My Agent description: My experimental autonomous agent install: method: pip pip | npm | custom raw Dockerfile snippet packages: "my-agent-pkg" healthCheck: my-agent --version tuiCommand: my-agent optional requiredPolicies: "pypi" envVars: route its LLM calls through the SILO proxy OPENAI API BASE: "http://llm.gateway:8199/v1" OPENAI API KEY: "silo-proxy-injected" tmpfsMounts: "/home/agent" writable home on the read-only rootfs A custom definition with the same id as a built-in overrides it, so you can also tweak how SILO runs the bundled frameworks. OpenClaw is the primary target for browser automation within SILO. When you build and run OpenClaw with the --browser profile, SILO automatically starts a background OpenClaw Gateway daemon inside the container. This gateway coordinates headless Chromium sessions and forces all outbound LLM calls to route securely through the host-side SILO inference proxy. Each framework image layers on top of the base sandbox — security hardening, policy engine, and audit logging all work identically. Tip Memory Allocation for Browser & GUI-Based Agents: SILO keeps the default 512m limit for text-based frameworks. When you start with --browser , SILO uses at least 2g of container memory and a 512m shared-memory segment so headless Chromium does not randomly die from Docker OOM or /dev/shm pressure. Every event flows into a single ~/.silo/audit.jsonl timeline — LLM calls, tool invocations, egress requests, blocked attempts, and framework traces. One file, one command, fully queryable. bash $ silo logs ┌──────────┬──────────┬────────┬───────────┬────────────────────────────┬────────┬─────────┬─────────────┐ │ Time │ Category │ Verdict│ Method │ Host │ Status │ Latency │ Detail │ ├──────────┼──────────┼────────┼───────────┼────────────────────────────┼────────┼─────────┼─────────────┤ │ 18:30:12 │ llm │ allow │ POST │ llm.gateway │ 200 │ 1423ms │ crewai │ │ 18:30:14 │ tool call│ allow │ TOOL CALL │ llm.gateway │ 200 │ 0ms │ read file │ │ 18:30:15 │ trace │ allow │ TRACE │ framework │ 0 │ 0ms │ agent start │ │ 18:31:02 │ egress │ allow │ GET │ pypi.org │ 200 │ 156ms │ — │ │ 18:32:10 │ blocked │ deny │ POST │ evil.example.com │ 403 │ 2ms │ — │ └──────────┴──────────┴────────┴───────────┴────────────────────────────┴────────┴─────────┴─────────────┘ Filter everything: silo logs --category llm Just LLM calls silo logs --category trace Framework lifecycle events silo logs --framework crewai All CrewAI activity silo logs --agent Researcher Just one agent silo logs --verdict deny --since 1h Blocked requests in the last hour silo logs --follow Live tail like tail -f silo logs --follow --verdict deny Live tail only blocked requests silo logs --json | jq '.host' | sort -u All unique hosts accessed silo traces Shortcut for trace view Run multiple isolated agents simultaneously, each with its own container, workspace, and resource limits — sharing a single proxy daemon. silo start --name alpha --workspace ~/project-a silo start --name beta --workspace ~/project-b silo list See all running agents silo connect --name alpha Shell into a specific agent silo run "Run tests" --name beta Run a task on a specific agent silo stop --all Stop everything Every agent runs as a non-root user inside a read-only container with all Linux capabilities dropped. On every platform, SILO uses an internal Docker bridge with no NAT gateway, so sandboxes have no direct internet route. On native Linux the proxy is reached via host-gateway ; on Docker Desktop for macOS/Windows, a hardened socat sidecar silo-gateway relays the proxy port across the VM boundary — the policy proxy remains the only egress path. --user 1001:1001 Non-root execution --read-only Immutable root filesystem --cap-drop ALL All capabilities removed --security-opt no-new-privileges No setuid/setgid escalation --pids-limit 128 Fork-bomb protection --tmpfs /tmp:noexec,nosuid Ephemeral scratch only --network silo-sandbox-net SILO bridge network Capability profiles: | Profile | Command Flag | Resources & Mounts | Security Implications | |---|---|---|---| | default | None Default | Isolated /workspace only; 512m memory limit | Safe coding, text, API, shell execution | | Desktop | --desktop | Read-write host Desktop mounted as /host/Desktop | Agent can read/write host Desktop files | | Custom Mounts | --mount