Shell execution & containment

When an agent runs a shell command, that command is governed by layered protections, a credential denylist, a policy-scoped file allowlist, and, where the platform supports it, an OS-level sandbox. How strong the OS layer is depends on your install path.

Ceiling: We never claim the standard install is "fully contained." The honest gist: macOS installs are kernel-sandboxed; new docker-vps installs run shell in a contained, no-secrets, no-egress sibling; other configurations are best-effort. If you need a hard guarantee (no reachable secrets, allow-listed egress, disposable execution) that's the enterprise containment tier, identical on every platform.

The layers#

• Credential denylist (unconditional). Commands that reference sensitive paths are refused and audited, on every agent, every trust tier, every workspace, even after a human approves. There is no opt-out. On its own it's best-effort, which is why the OS layer sits on top.
• Policy file-scope (seeded-gated). Once an operator saves a policy, reads outside a permitted scope are refused.
• OS sandbox. Where the platform supports it, the kernel confines what a command can read, write, and reach on the network. This is where containment becomes real, and where the platform matters most.

The sovereignty guarantee, always true#

Regardless of sandbox tier, your data never leaves your perimeter. Sovereignty is a property of where the software runs, not of the OS sandbox, it holds on every platform and every install path.

Full detail#

The exact per-platform containment ceiling (what each install path does and does not physically prevent) is part of our detailed security posture. We share it in full, candidly, under NDA with teams evaluating for a real threat model. Talk to us.

Note: Per-agent folder and secret grants layer on top of these tiers. The host machine, runtime mounts, and operators always remain trusted.

Next#

• Enforced vs Trusted, the enforced/trusted posture.
• Enterprise & advanced controls, full containment.