{"slug": "show-hn-silo-an-open-source-secure-cli-sandbox-for-running-agents-locally", "title": "Show HN: Silo – an open source secure CLI sandbox for running agents locally", "summary": "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.", "body_md": "**Self-hosted CLI for running untrusted AI agents locally inside hardened Docker sandboxes with controlled egress, credential-managed integrations, and transparent inference auditing.**\n\nBuilt-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\n\n[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)\n\nSILO 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:\n\n- **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) ).\n- **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) ).\n- **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.\n- **Policy Engine** ([engine.ts](https://github.com/Asdivyansh/silo-cli/blob/main/src/policy/engine.ts) ): Evaluates egress HTTP requests against declarative YAML policies.\n- **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.\n- **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) ).\n\n**Requirements:** Node.js 18+, npm, Docker, and an LLM provider key or local OpenAI-compatible endpoint.\n\n```\nnpm install -g cli-silo\nsilo --help\n```\n\nThe npm package is named `cli-silo`; the installed command is `silo`.\n\n**From source:**\n\n```\ngit clone https://github.com/AsDivyansh/silo.git\ncd silo\nnpm install\nnpm run build\nnpm link\n```\n\nDocker Desktop must be running before `silo build`, `silo start`, or `silo quickstart`.\n\nRunning AI agents with shell access, file system privileges, and API credentials is **dangerous**. An agent can:\n\n- **Exfiltrate your API keys** by POST-ing them to an external server\n- **Execute destructive commands** —`rm -rf /` , credential harvesting, crypto mining\n- **Access arbitrary internet hosts** to download malware or exfiltrate data\n- **Run unsupervised** with no visibility into what it's doing\n\n**SILO reduces these risks** with a defense-in-depth security architecture:\n\n```\n┌─────────────────────────────────────────────────────────────────────────────┐\n│  HOST MACHINE                                                               │\n│                                                                             │\n│  ┌──────────────────────┐        ┌─────────────────────────────────────┐   │\n│  │   silo CLI            │ start  │   Inference Proxy (:8199)           │   │\n│  │   (Node.js)           │───────▶│   • Injects real API key            │   │\n│  │                       │        │   • Injects integration tokens       │   │\n│  │   $ silo quickstart   │        │   • Evaluates policy per-request     │   │\n│  │   $ silo run \"task\"   │        │   • Records unified audit trail      │   │\n│  │   $ silo logs         │        │   • Collects framework traces        │   │\n│  │   $ silo logs -F      │        │   • Encrypts API keys at rest        │   │\n│  │   $ silo traces       │        │   • Health check + auto-restart      │   │\n│  └──────────────────────┘        └──────────┬─────────┬────────────────┘   │\n│                                              │         │                    │\n│                                   ┌──────────▼──┐  ┌──▼───────────────┐    │\n│                                   │ LLM Provider │  │ APIs (Slack,     │    │\n│                                   │ OpenAI / etc │  │ GitHub, HubSpot) │    │\n│                                   └─────────────┘  └──────────────────┘    │\n│                                                                             │\n│  ┌─────────────────────────────────────────────────────────────────────┐   │\n│  │  Docker Sandbox                                                     │   │\n│  │  --read-only --cap-drop ALL --user 1001:1001 --pids-limit 128       │   │\n│  │  --network silo-sandbox-net (SILO bridge)                           │   │\n│  │                                                                     │   │\n│  │  Agent ──▶ http://llm.gateway:8199     ──▶ LLM (via proxy)         │   │\n│  │  Agent ──▶ http://slack.gateway:8199   ──▶ Slack API (via proxy)   │   │\n│  │  Agent ──▶ POST /_silo/traces          ──▶ Unified audit log       │   │\n│  │                                                                     │   │\n│  │  ✓ HTTP egress routes through the policy proxy                      │   │\n│  │  ✗ Cannot see API keys or tokens                                    │   │\n│  │  ✗ Cannot escalate privileges                                       │   │\n│  │  ✗ Cannot modify the root filesystem                                │   │\n│  │  ✓ Can call LLMs through the proxy                                  │   │\n│  │  ✓ Can call integrations through gateways                           │   │\n│  │  ✓ Can push framework traces to the audit log                       │   │\n│  │  ✓ Can read/write /workspace                                        │   │\n│  └─────────────────────────────────────────────────────────────────────┘   │\n└─────────────────────────────────────────────────────────────────────────────┘\n```\n\nImportant\n\nSILO 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.\n\n```\n# One command does everything — onboard, build, start, connect\nsilo quickstart\n\n# Or step by step:\nsilo onboard                  # Interactive setup (provider, API key, security mode)\nsilo build                    # Build the sandbox Docker image\nsilo start                    # Launch sandbox + proxy\nsilo run \"List files in /workspace and describe what you find\"\nsilo logs                     # See exactly what the agent did\n```\n\n`silo quickstart` asks for your provider, API key, model, workspace, resource limits, and policy mode before launching the first sandbox.\n\n**With a framework:**\n\n```\nsilo quickstart --framework crewai    # Build CrewAI image, start, connect\n```\n\nRun 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.\n\n```\nsilo run \"Create a Python script that calculates fibonacci numbers\"\nsilo run \"Install numpy and run the test suite\" --max-turns 20\nsilo run \"Refactor the auth module\" --name my-agent\n```\n\n**Built-in agent tools:**\n\n| Tool | Description | \n|---|---|\n| `execute_command` | Run any shell command inside the sandbox | \n| `read_file` | Read file contents (with optional line limit) | \n| `write_file` | Create/overwrite files with arbitrary content | \n\nSupports both **OpenAI** and **Anthropic** function calling formats. All tool execution happens inside the sandboxed container — the agent can never touch the host.\n\nRun popular agent frameworks inside the sandbox with pre-configured Docker images, policy presets, and optional trace collection.\n\n```\nsilo frameworks list                    # See available frameworks\nsilo build --framework crewai           # Build a CrewAI-ready image\nsilo start --framework crewai           # Start with CrewAI installed\nsilo connect                            # Shell in and run your crew\n```\n\n**Browser-capable framework image:**\n\n```\nsilo build --framework openclaw --browser\nsilo start --framework openclaw --browser --desktop\n\n# Or build browser variants for every supported framework\nsilo build --all-frameworks --browser\n```\n\nBrowser 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.\n\nThe `--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.\n\n**Supported frameworks:**\n\n| Framework | Install | TUI | Trace Callbacks | \n|---|---|---|---|\n| 🚢 **CrewAI** | `pip` | — | ✅ `SiloCrewCallbacks` (event listener) | \n| 🔀 **LangGraph** | `pip` | — | ✅ `SiloLangChainCallbacks` (BaseCallbackHandler) | \n| 🧑💻 **Aider** | `pip` | ✅ `silo connect --tui` | — | \n| 🔧 **SWE-Agent** | `pip` | — | — | \n| 🦞 **OpenClaw** | `npm` | ✅ `silo connect --tui` | — | \n\nAny 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:\n\n```\n# ~/.silo/frameworks/my-agent.yaml\nid: my-agent\nname: My Agent\ndescription: My experimental autonomous agent\ninstall:\n  method: pip            # pip | npm | custom (raw Dockerfile snippet)\n  packages: [\"my-agent-pkg\"]\nhealthCheck: my-agent --version\ntuiCommand: my-agent     # optional\nrequiredPolicies: [\"pypi\"]\nenvVars:                 # route its LLM calls through the SILO proxy\n  OPENAI_API_BASE: \"http://llm.gateway:8199/v1\"\n  OPENAI_API_KEY: \"silo-proxy-injected\"\ntmpfsMounts: [\"/home/agent\"]   # writable home on the read-only rootfs\n```\n\nA custom definition with the same `id` as a built-in overrides it, so you can also tweak how SILO runs the bundled frameworks.\n\nOpenClaw 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.\n\nEach framework image layers on top of the base sandbox — security hardening, policy engine, and audit logging all work identically.\n\nTip\n\n**Memory Allocation for Browser & GUI-Based Agents:**\nSILO 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.\n\nEvery 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.\n\n``` bash\n$ silo logs\n\n┌──────────┬──────────┬────────┬───────────┬────────────────────────────┬────────┬─────────┬─────────────┐\n│ Time     │ Category │ Verdict│ Method    │ Host                       │ Status │ Latency │ Detail      │\n├──────────┼──────────┼────────┼───────────┼────────────────────────────┼────────┼─────────┼─────────────┤\n│ 18:30:12 │ llm      │ allow  │ POST      │ llm.gateway                │ 200    │ 1423ms  │ crewai      │\n│ 18:30:14 │ tool_call│ allow  │ TOOL_CALL │ llm.gateway                │ 200    │ 0ms     │ read_file   │\n│ 18:30:15 │ trace    │ allow  │ TRACE     │ framework                  │ 0      │ 0ms     │ agent_start │\n│ 18:31:02 │ egress   │ allow  │ GET       │ pypi.org                   │ 200    │ 156ms   │ —           │\n│ 18:32:10 │ blocked  │ deny   │ POST      │ evil.example.com           │ 403    │ 2ms     │ —           │\n└──────────┴──────────┴────────┴───────────┴────────────────────────────┴────────┴─────────┴─────────────┘\n```\n\n**Filter everything:**\n\n```\nsilo logs --category llm                 # Just LLM calls\nsilo logs --category trace               # Framework lifecycle events\nsilo logs --framework crewai             # All CrewAI activity\nsilo logs --agent Researcher             # Just one agent\nsilo logs --verdict deny --since 1h      # Blocked requests in the last hour\nsilo logs --follow                       # Live tail (like tail -f)\nsilo logs --follow --verdict deny        # Live tail only blocked requests\nsilo logs --json | jq '.host' | sort -u  # All unique hosts accessed\nsilo traces                              # Shortcut for trace view\n```\n\nRun multiple isolated agents simultaneously, each with its own container, workspace, and resource limits — sharing a single proxy daemon.\n\n```\nsilo start --name alpha --workspace ~/project-a\nsilo start --name beta --workspace ~/project-b\nsilo list                         # See all running agents\nsilo connect --name alpha         # Shell into a specific agent\nsilo run \"Run tests\" --name beta  # Run a task on a specific agent\nsilo stop --all                   # Stop everything\n```\n\nEvery 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.\n\n```\n--user 1001:1001                  Non-root execution\n--read-only                       Immutable root filesystem\n--cap-drop ALL                    All capabilities removed\n--security-opt no-new-privileges  No setuid/setgid escalation\n--pids-limit 128                  Fork-bomb protection\n--tmpfs /tmp:noexec,nosuid        Ephemeral scratch only\n--network silo-sandbox-net        SILO bridge network\n```\n\n**Capability profiles:**\n\n| Profile | Command Flag | Resources & Mounts | Security Implications | \n|---|---|---|---|\n| **default** | *None (Default)* | Isolated `/workspace` only;`512m` memory limit | Safe coding, text, API, shell execution | \n| **Desktop** | `--desktop` | Read-write host Desktop mounted as `/host/Desktop` | Agent can read/write host Desktop files | \n| **Custom Mounts** | `--mount <host>:<guest>:<mode>` | Map specific host directories to `/host/...` | Selectively exposes specific folders (e.g. read-only) | \n| **Browser Mode** | `--browser` | Sandboxed Chromium; `/tmp`` noexec` ; raises memory to`2g` &`/dev/shm` to`512m` | Enables browser automation (e.g., OpenClaw) without host compromise | \n\nDetailed design guidelines on these profiles can be found in the [Capability Profiles Guide](https://github.com/Asdivyansh/silo-cli/blob/main/docs/capability-profiles.md).\n\n**Opt-in local filesystem access:**\n\n```\n# Let the agent create/read files on your Desktop\nsilo start --framework openclaw --desktop\n\n# Mount any host path under /host in the sandbox (read-only for extra safety)\nsilo start --mount ~/Downloads:/host/Downloads:ro\n```\n\nAgents can always read and write to `/workspace`. Host paths like Desktop, Downloads, or Documents are completely invisible to the sandboxed agent unless explicitly exposed.\n\nAI 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.\n\nTo allow the agent to reach services running on your host machine:\n\n1. **Access via host gateway** : Use`host.docker.internal` instead of`localhost` in your commands or configs. For example, to query a host API on port`3000` , the agent should connect to`http://host.docker.internal:3000` .\n2. **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:\n\n```\n# Add to your policy file\nrules:\n  - host: \"host.docker.internal\"\n    action: allow\n    comment: \"Local Host Development Server\"\n```\n\nA 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.\n\n```\n# Inside the sandbox — the agent doesn't need any credentials:\ncurl http://llm.gateway:8199/v1/chat/completions \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"model\":\"gpt-4o\",\"messages\":[{\"role\":\"user\",\"content\":\"Hello\"}]}'\n```\n\nDeclarative 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.\n\n```\n# Strict mode (chosen during onboard) — safest, blocks unknown traffic\nversion: \"1\"\nname: \"strict\"\ndefault: deny\nrules:\n  - host: \"llm.gateway\"\n    action: allow\n    comment: \"LLM inference proxy\"\n  - host: \"pypi.org\"\n    action: allow\n  - host: \"files.pythonhosted.org\"\n    action: allow\n# Audit-only mode (chosen during onboard) — least friction, full visibility\nversion: \"1\"\nname: \"audit-only\"\ndefault: allow\nrules:\n  - host: \"llm.gateway\"\n    action: allow\n```\n\nBuilt-in presets and one-liner management:\n\n```\nsilo policy apply pypi                     # Allow pip installs\nsilo policy apply npm                      # Allow npm/yarn installs\nsilo policy add api.github.com             # One-liner: add a single host\nsilo policy reload                         # Hot-reload without restart\n```\n\nWhen the agent tries to reach a host not in the policy, the proxy prompts you in real-time:\n\n```\n⚠  Sandbox is requesting access to an unauthorised host\n  Method : POST\n  Host   : suspicious-api.example.com\n  URL    : http://suspicious-api.example.com/webhook\n\n? How should this request be handled?\n  ❯ Allow once   (this request only)\n    Allow always (add to active policy)\n    Deny         (block this request)\n```\n\nIn headless/CI mode, unauthorised requests are auto-denied and logged.\n\nConnect agents to productivity APIs — Slack, GitHub, HubSpot, and more — without exposing credentials.\n\n```\nsilo integrations add slack              # Stores token host-side\nsilo integrations add github             # Same pattern\n\n# Inside the sandbox — no credentials needed:\ncurl http://slack.gateway:8199/chat.postMessage \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"channel\":\"#general\",\"text\":\"Hello from SILO agent!\"}'\n```\n\nBuilt-in templates for **Slack**, **GitHub**, **HubSpot**, **Linear**, and **Notion**. See [integrations.md](https://github.com/Asdivyansh/silo-cli/blob/main/docs/integrations.md) for the full guide.\n\nIntegration 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.\n\nSave and restore container state:\n\n```\nsilo snapshot create \"clean-install\"     # Save current state\nsilo snapshot list                       # View snapshots\nsilo snapshot rollback \"clean-install\"   # Restore\nsilo snapshot delete \"clean-install\"     # Clean up\nsilo doctor                              # Check Docker, Node, config, proxy health\nsilo status                              # Full dashboard: container, proxy, audit stats\nsilo quickstart\nsilo run \"Write a Python script that fetches the top 10 HN stories and saves them as CSV\"\nsilo logs\nsilo stop\n# Setup\nsilo build --framework crewai\nsilo start --framework crewai\nsilo connect\n\n# Inside the container:\npython3 << 'EOF'\nfrom crewai import Agent, Task, Crew\n\nresearcher = Agent(role=\"Researcher\", goal=\"Find key facts\", backstory=\"Expert researcher.\", verbose=True)\nwriter = Agent(role=\"Writer\", goal=\"Write a summary\", backstory=\"Skilled writer.\", verbose=True)\n\nresearch = Task(description=\"Research Docker container security. List 5 key points.\", expected_output=\"5 bullet points.\", agent=researcher)\nsummary = Task(description=\"Write a 2-paragraph summary from the research.\", expected_output=\"2 paragraphs.\", agent=writer)\n\ncrew = Crew(agents=[researcher, writer], tasks=[research, summary], verbose=True)\nprint(crew.kickoff())\nEOF\n\n# Back on host — see everything that happened:\nexit\nsilo logs --framework crewai\nsilo stop\nsilo onboard\nsilo build\nsilo integrations add github\nsilo integrations add slack\nsilo start\nsilo policy apply github\nsilo policy add slack.com\n\nsilo run \"Fetch open issues from the GitHub repo, label bugs as priority, \\\n  generate a triage report in /workspace, and post a summary to #engineering on Slack\"\n\n# Inspect: 4 LLM turns, 2 GitHub calls, 1 Slack post — zero credentials exposed\nsilo logs\nsilo stop\nsilo start                               # Uses the policy mode chosen during onboard\n\nsilo connect\npython3 /workspace/third-party-agent.py  # Run the untrusted code\nexit\n\nsilo logs --verdict deny                 # See what was blocked\n# Output:\n#   evil-c2-server.io        → deny\n#   pastebin.com             → deny\n#   webhook.site             → deny\n\nsilo stop\n```\n\nSet up OpenClaw with browser automation and local Desktop access to have the agent work with your local files and browse websites safely.\n\n```\n# 1. Build the browser-capable OpenClaw image\nsilo build --framework openclaw --browser\n\n# 2. Start the container with browser support and mount your Desktop\nsilo start --framework openclaw --browser --desktop\n\n# 3. Connect to the container's shell\nsilo connect\n\n# 4. Inside the container, run an OpenClaw task to browse a site and save results to your host Desktop\nopenclaw run \"Search for 'Docker container security presets', take a screenshot of the top result, and save it to /host/Desktop/screenshot.png\"\n\n# 5. Exit the container\nexit\n\n# 6. Verify what connections the agent made or attempted\nsilo logs\nsilo stop\n```\n\nFull command reference: [cli-reference.md](https://github.com/Asdivyansh/silo-cli/blob/main/docs/cli-reference.md)\n\nSILO implements **defence in depth** across multiple layers:\n\n| Layer | What It Does | How | \n|---|---|---|\n| **Container hardening** | Prevents privilege escalation and system damage | Non-root user, read-only fs, no capabilities, PID limits | \n| **Network isolation** | Restricts egress paths | Native Linux no-NAT bridge; Docker Desktop proxy-routed egress with source allowlist | \n| **Policy engine** | Controls which hosts the agent can reach | YAML rules evaluated per-request; deny by default | \n| **Credential isolation** | Keeps API keys away from the agent | Keys stored host-side; proxy injects at request time | \n| **Audit trail** | Full visibility into agent behaviour | Unified JSONL log with LLM, tool, egress, trace events | \n\n**Additional protections:**\n\n- **API keys encrypted at rest** using AES-256-GCM with a machine-bound key (PBKDF2)\n- Auth headers from the container are **stripped** before forwarding (prevents key forgery)\n- HTTPS CONNECT to `llm.gateway` is**rejected** (forces plain HTTP so the proxy can inspect)\n- `silo run` LLM calls are**routed through the proxy** for unified audit logging\n- \"Allow always\" interceptor decisions are **persisted** to the policy file automatically\n- Session-based audit trail with unique session IDs for forensic correlation\n- Automatic log rotation (10MB default, 5 rotated files)\n- Proxy health check (`/_silo/health` ) with auto-restart on crash\n\nProject structure and architecture: [architecture.md](https://github.com/Asdivyansh/silo-cli/blob/main/docs/architecture.md)\n\n```\nnpm install                       # Install dependencies\nnpm run dev -- <command>          # Run in dev mode (tsx, no build step)\nnpm test                          # Run test suite\nnpm run typecheck                 # TypeScript type checking\nnpm run build                     # Bundle to dist/\n\nSILO_DEBUG=1 npm run dev -- start # Verbose debug logging\n```\n\n**Project structure:**\n\n```\nsrc/\n  cli.ts                          # Command definitions\n  commands/                       # Command implementations\n  proxy/                          # Inference proxy (server, daemon, interceptor, spawner)\n  policy/                         # YAML policy engine + presets\n  audit/                          # Audit log, tool call extraction, trace collector\n  frameworks/                     # Framework registry, definitions, Docker builder\n  integrations/                   # Credential-managed API integrations\n  config/                         # Config schema, manager, AES-256 encryption\n  docker/                         # Docker container management (templates + runner)\n  utils/                          # Logger, system checks, health, PID management\nsandbox/                          # Dockerfile, entrypoint, Python callbacks\ntests/                            # Vitest test suite\npolicies/                         # Example policy YAML files\ndocs/                             # [Full documentation](docs)\n```\n\nContributions are welcome! Whether it's a bug fix, new feature, documentation improvement, or just a typo — we appreciate it all.\n\nFor vulnerability reports, please follow [SECURITY.md](https://github.com/Asdivyansh/silo-cli/blob/main/SECURITY.md) instead of opening a public issue.\n\n1. **Fork** the repo\n2. **Create** a feature branch (`git checkout -b feat/amazing-feature` )\n3. **Commit** your changes (`git commit -m 'feat: add amazing feature'` )\n4. **Push** to the branch (`git push origin feat/amazing-feature` )\n5. **Open** a Pull Request\n\n**First time contributing?** Look for issues labeled [`good first issue`](https://github.com/AsDivyansh/silo/labels/good%20first%20issue).\n\nMIT © SILO contributors. See [LICENSE](https://github.com/Asdivyansh/silo-cli/blob/main/LICENSE).", "url": "https://wpnews.pro/news/show-hn-silo-an-open-source-secure-cli-sandbox-for-running-agents-locally", "canonical_source": "https://github.com/Asdivyansh/silo-cli", "published_at": "2026-10-28 19:33:24+00:00", "updated_at": "2026-10-28 19:42:12.449538+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-tools", "developer-tools", "ai-infrastructure"], "entities": ["SILO", "OpenClaw", "Docker", "Node.js", "npm", "AsDivyansh"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/show-hn-silo-an-open-source-secure-cli-sandbox-for-running-agents-locally", "markdown": "https://wpnews.pro/news/show-hn-silo-an-open-source-secure-cli-sandbox-for-running-agents-locally.md", "text": "https://wpnews.pro/news/show-hn-silo-an-open-source-secure-cli-sandbox-for-running-agents-locally.txt", "jsonld": "https://wpnews.pro/news/show-hn-silo-an-open-source-secure-cli-sandbox-for-running-agents-locally.jsonld"}}