What It Does
Leash wraps AI coding agents (Claude, Codex, Gemini, Qwen, OpenCode) in containers and monitors every syscall — file access, network connections, process execution — using eBPF at the kernel level. Access policies are written in Cedar (Amazon’s open-source policy language), transpiled to eBPF rules, HTTP proxy configs, and MCP observer rules, then enforced in real-time with <1ms overhead per decision. Default posture is deny-all; forbid always wins over permit.
It also includes an MCP observer that intercepts Model Context Protocol traffic, correlates tool calls with OS-level telemetry, and lets Cedar policies govern which MCP servers and tools an agent can access. A web Control UI at localhost:18080 provides real-time observability.
Key Features
- eBPF syscall interception: Monitors all file, network, and process activity at the kernel level — not application-level hooks
- Cedar policy engine: Declarative policies transpiled to enforcement mechanisms; single policy file governs eBPF, HTTP proxy, and MCP layers
- MCP-native governance: Parses MCP traffic, enforces tool-level access control per MCP server (forbid in V1; permit informational only)
- Default-deny posture: Everything blocked unless explicitly permitted; forbid rules always override permit rules
- Multi-agent support: Ships Claude, Codex, Gemini, Qwen, OpenCode in a single container image with automatic API key forwarding
- Hot-reloadable policies: Iterate access rules without restarting agent sessions
- Control UI: Web dashboard at localhost:18080 for real-time activity monitoring
- HTTP header rewrite: Inject auth headers into outbound requests via Cedar policy
- Custom container images: Extend the base image with project-specific tooling
- TOML configuration: Per-project settings, volume mounts, image overrides
Use Cases
- Org-wide agent deployment: Platform team defines Cedar policies centrally; developers run agents within guardrails without per-project configuration
- Regulated industries: Audit trail of every agent action at the OS level answers “what did the AI do, when, and why?”
- Production infrastructure protection: Prevent agents from connecting to unauthorized hosts, reading secrets directories, or executing dangerous binaries
- MCP tool governance: Block specific MCP tools (e.g., shell execution) while allowing others, at the infrastructure level rather than relying on agent self-restraint
- Multi-tenant agent environments: Container isolation with per-container policies for different teams or security contexts
Adoption Level Analysis
Small teams (<20 engineers): Limited fit. The container overhead and Cedar policy learning curve are justified only if agents touch production infrastructure or sensitive data. Native agent permission systems (Claude Code’s built-in) may suffice.
Medium orgs (20-200 engineers): Good fit. Centralized policy management across multiple developers running agents becomes valuable. Cedar policies can be version-controlled and reviewed like code. The Control UI provides security team visibility.
Enterprise (200+ engineers): Strong fit in principle, but V1 limitations matter: no per-principal enforcement means you can’t differentiate agent permissions by team/role within a shared cluster. No IPv6/CIDR network rules. MCP allowlisting not enforced yet. These gaps will likely close — watch the roadmap.
Alternatives
| Alternative | Key Difference | Prefer when… |
|---|---|---|
| E2B | Firecracker microVMs — stronger isolation boundary (VM vs container) | You need VM-level isolation and don’t need a policy language or MCP governance |
| Daytona | Docker-compatible, sub-90ms cold starts | Provisioning speed matters more than policy expressiveness |
| Northflank | Kata Containers + gVisor, production-grade multi-tenant | You need proven multi-tenant isolation at scale, not agent-specific governance |
| Modal | gVisor + Python-native autoscaling | Your agents are Python-centric and you need massive scaling |
| Native agent permissions | Built into Claude Code, Codex, etc. | You trust application-layer enforcement and don’t need OS-level audit trails |
Evidence & Sources
- GitHub repository — 512 stars, Apache 2.0, Go
- Cedar policy documentation with examples
- StrongDM blog — technical architecture and motivations
- Northflank — independent comparison of agent sandbox approaches
Notes & Caveats
- Delinea acquisition (March 2026): StrongDM was acquired by Delinea. Open-source commitment post-acquisition is uncertain. Apache 2.0 provides a license floor, but community momentum and maintenance velocity could shift. Monitor for signs of reduced investment.
- V1 MCP limitation: MCP
permitrules are informational only — you can block tools but cannot build a true allowlist. Onlyforbidis enforced. - No per-principal enforcement: Policies apply at the container/cgroup level. Cannot differentiate between multiple agents or users in the same container.
- No argument filtering:
ProcessExeccontrols which binaries can run, but not what arguments they receive./usr/bin/curlis either allowed or not — you can’t restrict what it curls. - No IPv6 or CIDR: Network policies are host-based only. No subnet-level rules.
- Young codebase: 75 commits, 512 stars as of April 2026. Production battle-testing is limited. Evaluate carefully before high-stakes deployment.
- Container vs VM isolation: Bind-mounts provide access to host filesystem; container escape is a known risk class. For highest isolation, consider microVM-based alternatives (E2B, Northflank).