Context Agent Sandboxes vs Sandlock

Context Agent Sandboxes gives each agent task a separate sandbox on the customer's cluster, using the permissions of the person who requested it. Each run begins in a fresh environment, which is destroyed after an idle period set to 30 minutes by default. Sandboxes run as non-root container pods with capabilities dropped, a seccomp profile, and no cluster service-account token. Administrators can choose open, domain-allowlist, or workspace-only network access, with allowlist decisions logged. In the supervised preset, commands require human approval and connections outside the allowlist prompt for a decision. Drive is not mounted: files pass through a permission-checking gateway, and outputs are pushed explicitly. Credentials are injected at the edge only after authorization. An append-only audit log records commands, files, connections, and permission decisions, including the actor and decision maker. Context lists more than 180 integrations across business categories, plus remote MCP servers. Enterprise sandboxes run on the customer's Kubernetes cluster, with KOTS installation options for EKS or AKS and an air-gapped bundle. Plans include Free at free, Plus at $20 a month, Pro at $200 a month, and custom-priced Enterprise.

Sandlock is a Linux process sandbox for confining untrusted code with policies enforced by the kernel. It uses Landlock, seccomp-bpf, and seccomp user notification to control filesystem access, network activity, system calls, and resource use. Policies can deny network egress by default, apply HTTP method, host, and path rules, stage writes through copy-on-write, and set resource limits. A supervisor can attach credentials through a proxy after an HTTP access check, keeping the secret value out of the sandboxed workload. Interfaces include a CLI, Python SDK, Rust API, Go SDK, OCI runtime, and MCP server. The OCI runtime works with containerd, CRI-O, and Kubernetes, while the remote MCP API can connect to Claude Desktop, Cursor, or another MCP client. Sandlock runs as an ordinary user without root, a container runtime, or a hypervisor. Linux 6.12 or later supports the full protection set by default; older kernels require explicit waivers for missing protections. It shares the host kernel, excluding kernel vulnerabilities and hardware side channels from its guarantees.