Each agent and each compose service runs in its own microVM with its own Linux kernel. The code stays on your machine.
macOS 26+ Apple Silicon today · Linux next · Apache-2.0 · no account
Isolation runs in the hypervisor, outside the guest, so it never depends on the agent’s cooperation. brig adds four things the runtime underneath does not provide.
Each agent and each compose service runs in its own VM with its own kernel.
The guest runs your workload and a kernel. It has no helper agent and no channel from the host.
Only the secrets you name at launch enter the guest, and only for that sandbox.
OCI images, Docker verbs, compose. The same model runs under containerd on Linux.
Run the commands on your own machine before you trust any of this. The repository documents each claim next to its check.
| The boundary is hardware | uname -r in a sandbox returns the guest kernel, not yours. |
| Nothing runs in the guest but your workload | Inspect a strict-profile image. No agent binary, no vsock endpoint. |
| Secrets stay out of the process table | Run ps on the host during a live session. |
| Sandboxes are ephemeral | Write a marker, tear down, search for it. |
| The image is the specification | Rebuild from the spec and compare digests. |
| It is open end to end | Read the LICENSE, build from source, diff against the release. |
Read these six limits before you adopt brig. docs/security.md explains each one.
It limits what an injected agent can reach.
brig protects your machine from the agent. It does not protect the agent from your machine.
brig does not test for or claim protection against microarchitectural side channels.
Code the agent writes into a shared directory runs outside the sandbox when you use it.
Isolation, egress scoping and resource limits ship today. Runtime policy is roadmap.
macOS at launch, arm64 guests, and a documented subset of compose.
brig is the CLI and the session daemon. hull is the macOS runtime it drives, and urunc is the Linux one. All three are Apache 2.0.
The CLI and the session daemon. It runs the agent or the stack and holds the boundary.
brig-sh/brigThe Linux runtime underneath brig, and a CNCF Sandbox project. The same team builds urunc and brig.
urunc-dev/urunc| macOS 26+, Apple Silicon | hull over Virtualization.framework | Today |
| Linux, x86_64 and arm64 | urunc over KVM | Next release |
| macOS, Intel | No hardware virtualization path | Not supported |
Neither brig nor hull is a CNCF project, and neither is endorsed by the CNCF.
Each answer links to the file that documents it.
Keep it. It keeps working inside brig. Process sandboxes share the host kernel, so a kernel bug escapes to your machine. In brig the same bug reaches a disposable guest kernel.
No. A sandbox does not prevent injection. An injected agent still holds the files, secrets and endpoints you granted it, and nothing else.
Yes. One syntax line at the top of your Dockerfile adds the kernel at build time. Nothing else about the Dockerfile changes.
512 MB per service, on a kernel sized for one application. The benchmarks and their methods are in the repository, so measure it on your own hardware.
No. Sandboxes run locally. There is no account, and telemetry stays off until you turn it on.
Every issue is public and the disclosure policy is written down. The boundary you are trusting is the part you can audit.
urunc is an Apache 2.0 cloud-native runtime and a CNCF Sandbox project. The same team builds brig and hull at NOFire AI.
One command, one microVM per workload, and a boundary you can check.