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 · Quick Start · Why SILO? · Capabilities · Frameworks · Examples · Docs · 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): Command orchestration and interactive onboarding wizard (onboard.ts).
- Inference & Integration Proxy (server.ts): Intercepts and logs LLM/egress requests, injects credentials on the host side, and manages the interactive prompter (interceptor.ts).
- Docker Sandbox Core (runner.ts): Spawns and manages hardened, capability-restricted Docker containers with resource limits.
- Policy Engine (engine.ts): Evaluates egress HTTP requests against declarative YAML policies.
- Audit Logger (audit.ts): Standardizes and records all proxy and tool-calling event streams to standard JSONL log files.
- Config & Encryption Layer (manager.ts): Secures keys at rest using machine-bound PBKDF2 AES-256-GCM encryption (encryption.ts).
Requirements: Node.js 18+, npm, Docker, and an LLM provider key or local OpenAI-compatible endpoint.
Note
SILO is not published to npm yet, so install it from source for now.
From source:
git clone https://github.com/SilosLabs/silo-cli.git
cd silo-cli
npm install
npm run build
npm linkFrom npm (once published):
npm install -g cli-silo
silo --helpThe npm package is named cli-silo; the installed command is silo.
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 didsilo 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, connectRun 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-agentBuilt-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 crewBrowser-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 --browserBrowser 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 rootfsA 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.
$ 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 viewRun 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 everythingEvery 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 <host>:<guest>:<mode> |
Map specific host directories to /host/... |
Selectively exposes specific folders (e.g. read-only) |
| Browser Mode | --browser |
Sandboxed Chromium; /tmp noexec; raises memory to 2g & /dev/shm to 512m |
Enables browser automation (e.g., OpenClaw) without host compromise |
Detailed design guidelines on these profiles can be found in the Capability Profiles Guide.
Opt-in local filesystem access:
# Let the agent create/read files on your Desktop
silo start --framework openclaw --desktop
# Mount any host path under /host in the sandbox (read-only for extra safety)
silo start --mount ~/Downloads:/host/Downloads:roAgents can always read and write to /workspace. Host paths like Desktop, Downloads, or Documents are completely invisible to the sandboxed agent unless explicitly exposed.
AI agents often need to interact with local development services (like a database, backend API, or local dev server) running directly on your host machine. Since the agent executes inside an isolated Docker sandbox, localhost or 127.0.0.1 inside the container refers to the container itself, not your host.
To allow the agent to reach services running on your host machine:
- Access via host gateway: Use
host.docker.internalinstead oflocalhostin your commands or configs. For example, to query a host API on port3000, the agent should connect tohttp://host.docker.internal:3000. - Authorize Egress: In Strict policy mode, the proxy will intercept this egress attempt. You will be prompted in the interactive TUI to allow the connection, or you can add it permanently to your active policy file:
# Add to your policy file rules: - host: "host.docker.internal" action: allow comment: "Local Host Development Server"
A host-side HTTP proxy sits between the agent and the outside world. The agent makes plain HTTP calls to http://llm.gateway:8199 — the proxy intercepts, injects the real API key, and forwards to the actual LLM provider. The agent never sees the key.
# Inside the sandbox — the agent doesn't need any credentials:
curl http://llm.gateway:8199/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"gpt-4o","messages":[{"role":"user","content":"Hello"}]}'Declarative egress control. Define which hosts the agent can reach with a simple YAML file. During silo onboard, you choose between Strict (deny by default) and Audit Only (allow by default). Both modes log every request.
# Strict mode (chosen during onboard) — safest, blocks unknown traffic
version: "1"
name: "strict"
default: deny
rules:
- host: "llm.gateway"
action: allow
comment: "LLM inference proxy"
- host: "pypi.org"
action: allow
- host: "files.pythonhosted.org"
action: allow# Audit-only mode (chosen during onboard) — least friction, full visibility
version: "1"
name: "audit-only"
default: allow
rules:
- host: "llm.gateway"
action: allowBuilt-in presets and one-liner management:
silo policy apply pypi # Allow pip installs
silo policy apply npm # Allow npm/yarn installs
silo policy add api.github.com # One-liner: add a single host
silo policy reload # Hot-reload without restartWhen the agent tries to reach a host not in the policy, the proxy prompts you in real-time:
⚠ Sandbox is requesting access to an unauthorised host
Method : POST
Host : suspicious-api.example.com
URL : http://suspicious-api.example.com/webhook
? How should this request be handled?
❯ Allow once (this request only)
Allow always (add to active policy)
Deny (block this request)
In headless/CI mode, unauthorised requests are auto-denied and logged.
Connect agents to productivity APIs — Slack, GitHub, HubSpot, and more — without exposing credentials.
silo integrations add slack # Stores token host-side
silo integrations add github # Same pattern
# Inside the sandbox — no credentials needed:
curl http://slack.gateway:8199/chat.postMessage \
-H "Content-Type: application/json" \
-d '{"channel":"#general","text":"Hello from SILO agent!"}'Built-in templates for Slack, GitHub, HubSpot, Linear, and Notion. See integrations.md for the full guide.
Integration gateways keep working in --browser mode. The browser profile only changes the framework container image and runtime browser mounts; slack.gateway, github.gateway, and other credential-managed aliases are still routed through the host proxy with credentials injected outside the sandbox.
Save and restore container state:
silo snapshot create "clean-install" # Save current state
silo snapshot list # View snapshots
silo snapshot rollback "clean-install" # Restore
silo snapshot delete "clean-install" # Clean upsilo doctor # Check Docker, Node, config, proxy health
silo status # Full dashboard: container, proxy, audit statssilo quickstart
silo run "Write a Python script that fetches the top 10 HN stories and saves them as CSV"
silo logs
silo stop# Setup
silo build --framework crewai
silo start --framework crewai
silo connect
# Inside the container:
python3 << 'EOF'
from crewai import Agent, Task, Crew
researcher = Agent(role="Researcher", goal="Find key facts", backstory="Expert researcher.", verbose=True)
writer = Agent(role="Writer", goal="Write a summary", backstory="Skilled writer.", verbose=True)
research = Task(description="Research Docker container security. List 5 key points.", expected_output="5 bullet points.", agent=researcher)
summary = Task(description="Write a 2-paragraph summary from the research.", expected_output="2 paragraphs.", agent=writer)
crew = Crew(agents=[researcher, writer], tasks=[research, summary], verbose=True)
print(crew.kickoff())
EOF
# Back on host — see everything that happened:
exit
silo logs --framework crewai
silo stopsilo onboard
silo build
silo integrations add github
silo integrations add slack
silo start
silo policy apply github
silo policy add slack.com
silo run "Fetch open issues from the GitHub repo, label bugs as priority, \
generate a triage report in /workspace, and post a summary to #engineering on Slack"
# Inspect: 4 LLM turns, 2 GitHub calls, 1 Slack post — zero credentials exposed
silo logs
silo stopsilo start # Uses the policy mode chosen during onboard
silo connect
python3 /workspace/third-party-agent.py # Run the untrusted code
exit
silo logs --verdict deny # See what was blocked
# Output:
# evil-c2-server.io → deny
# pastebin.com → deny
# webhook.site → deny
silo stopSet up OpenClaw with browser automation and local Desktop access to have the agent work with your local files and browse websites safely.
# 1. Build the browser-capable OpenClaw image
silo build --framework openclaw --browser
# 2. Start the container with browser support and mount your Desktop
silo start --framework openclaw --browser --desktop
# 3. Connect to the container's shell
silo connect
# 4. Inside the container, run an OpenClaw task to browse a site and save results to your host Desktop
openclaw run "Search for 'Docker container security presets', take a screenshot of the top result, and save it to /host/Desktop/screenshot.png"
# 5. Exit the container
exit
# 6. Verify what connections the agent made or attempted
silo logs
silo stopFull command reference: cli-reference.md
SILO implements defence in depth across multiple layers:
| Layer | What It Does | How |
|---|---|---|
| Container hardening | Prevents privilege escalation and system damage | Non-root user, read-only fs, no capabilities, PID limits |
| Network isolation | Restricts egress paths | Internal (no-NAT) Docker bridge on every platform; silo-gateway sidecar relays the proxy on Docker Desktop |
| Policy engine | Controls which hosts the agent can reach | YAML rules evaluated per-request; deny by default |
| Credential isolation | Keeps API keys away from the agent | Keys stored host-side; proxy injects at request time |
| Audit trail | Full visibility into agent behaviour | Unified JSONL log with LLM, tool, egress, trace events |
Additional protections:
- API keys encrypted at rest using AES-256-GCM with a machine-bound key (PBKDF2)
- Auth headers from the container are stripped before forwarding (prevents key forgery)
- HTTPS CONNECT to
llm.gatewayis rejected (forces plain HTTP so the proxy can inspect) silo runLLM calls are routed through the proxy for unified audit logging- "Allow always" interceptor decisions are persisted to the policy file automatically
- Session-based audit trail with unique session IDs for forensic correlation
- Automatic log rotation (10MB default, 5 rotated files)
- Proxy health check (
/_silo/health) with auto-restart on crash
Project structure and architecture: architecture.md
npm install # Install dependencies
npm run dev -- <command> # Run in dev mode (tsx, no build step)
npm test # Run test suite
npm run typecheck # TypeScript type checking
npm run build # Bundle to dist/
SILO_DEBUG=1 npm run dev -- start # Verbose debug loggingProject structure:
src/
cli.ts # Command definitions
commands/ # Command implementations
proxy/ # Inference proxy (server, daemon, interceptor, spawner)
policy/ # YAML policy engine + presets
audit/ # Audit log, tool call extraction, trace collector
frameworks/ # Framework registry, definitions, Docker builder
integrations/ # Credential-managed API integrations
config/ # Config schema, manager, AES-256 encryption
docker/ # Docker container management (templates + runner)
utils/ # Logger, system checks, health, PID management
sandbox/ # Dockerfile, entrypoint, Python callbacks
tests/ # Vitest test suite
policies/ # Example policy YAML files
docs/ # [Full documentation](docs)
Contributions are welcome! Whether it's a bug fix, new feature, documentation improvement, or just a typo — we appreciate it all.
For vulnerability reports, please follow SECURITY.md instead of opening a public issue.
- Fork the repo
- Create a feature branch (
git checkout -b feat/amazing-feature) - Commit your changes (
git commit -m 'feat: add amazing feature') - Push to the branch (
git push origin feat/amazing-feature) - Open a Pull Request
First time contributing? Look for issues labeled
good first issue.
MIT © SILO contributors. See LICENSE.