Learn

Consequence containment

If an autonomous LLM-driven system will sometimes make mistakes, how can the consequences of those mistakes be bounded?

Consequence containment means constraining the execution environment and authority available to an autonomous process so that a bad decision cannot produce arbitrary effects. The model remains probabilistic; enforcement must not depend solely on the model deciding to obey.

A useful framing:

probabilistic reasoning + deterministic environmental limits

The model can make a poor decision while the environment still limits what that decision can affect. That boundary is the subject here. OpenTendril does not guarantee correct, safe, or high-quality output.

Behavioural control versus consequence control

Two different mechanisms are often described with the same security vocabulary. They are complementary, not interchangeable.

Behavioural control

“Do not access X.”

Prompt, policy text, classifier, model judgement

Consequence control

“The process cannot access X.”

OS isolation, capability boundary, mediated interface

Behavioural controls reduce the likelihood of unwanted actions. Consequence controls limit what is available when those systems fail.

Prompts, evaluations, classifiers, and approval systems can reduce unwanted behaviour. They still leave enforcement partly dependent on compliance or on a human in the path. Environmental controls (filesystem seals, network policy, credential placement, runtime isolation) limit the blast radius when the probabilistic layer errs.

Approval is a control, not containment

Human approval is a legitimate control. It remains appropriate for exceptional boundary crossings, irreversible actions, authority expansion, and high-risk external effects. Nothing here declares human-in-the-loop obsolete.

Approval fatigue is a real operational failure mode. When every meaningful step requires a click, the human remains on the critical path of the work itself: useful supervision for rare events, poor ordinary execution mechanism for long autonomous runs. Anthropic’s Claude Code sandboxing work frames isolation partly as a way to reduce permission prompts while keeping work inside defined boundaries. OpenAI’s “Running Codex safely” treats the sandbox as the technical execution boundary and approval policy as the mechanism for actions that need to cross that boundary; the two are complementary, not competitive.

Containment is what makes reduced approval tolerable. Without a boundary, “fewer prompts” is simply more trust. With a boundary, “fewer prompts” can mean more freedom inside declared limits. See why governed autonomous work for the approval paradox in full.

Dimensions of containment

“Sandboxed” is not one binary property. An execution boundary has multiple dimensions. Weakness on any one can dominate the effective blast radius.

Filesystem

What paths can be read or written? Can the process reach host configuration, secrets, or sibling projects?

Network

What destinations can be reached? Can data leave? Can arbitrary packages be pulled in?

Process, kernel, and runtime

What execution substrate runs the work? What is shared with the host? What isolation primitive enforces the wall?

Credentials

What credentials are present inside the boundary? Can long-lived secrets be read or reused outside the audit path?

Resources

What CPU, memory, process, token, or spend limits apply?

External capabilities

Which APIs, tools, and operations are exposed, and under whose identity?

Industry systems increasingly combine several of these: workspace write roots, network allowlists, managed config, scoped credentials, and telemetry. Execution isolation is only one part of a delegation contract.

OpenTendril decomposition

OpenTendril decomposes “the agent” and “the sandbox” into separate jobs. Precise mapping:

  • Terrarium Isolation boundary (filesystem, network, and related limits) around a Sprout; not the worker itself.
  • Sprout Ephemeral worker body that does one unit of work inside a Terrarium.
  • Stoma The single controlled aperture in a Terrarium wall through which commands enter and results leave. A Terrarium has exactly one. Concrete transport is provider-specific; Firecracker materializes it through the guest init process over vsock.
  • Stem Deterministic routing, lifecycle kernel, and governed capability registry. Not a reasoning component.
  • Pollinator External requester that reaches in and asks for governed work; not the agent body.
  • Pollen Principal (identity) a Pollinator presents and a grant names.
  • Grant Permitted operation classes and substrates (and optional egress hosts) for a Pollen. No grant means denied.
  • Branches Capability and security groups the Stem initialises: zones of authority, not Git branches.
  • Hardiness Deployment security posture: whether the Terroir permits the intended delegation boundary to be enforced rather than merely recorded. Reports posture; does not gate runtime execution or certify security.
Taxonomy check: the Terrarium is the wall; the Sprout is the body inside it. They are not synonyms.

Identity and authority belong beside sandboxing

A sandbox alone does not answer:

  • who requested the work;
  • what operation classes they were granted;
  • which Substrates they may target;
  • what credentials the caller can impersonate or read;
  • whether they can alter the control plane that enforces the policy.

OpenTendril treats those as first-class. Grants authorise a Pollen for named operation classes on named substrates. Zero grants is a deny-all default. Grants live in the control plane, not inside a cloned repository that could widen its own access. Stoma-mediated external fetch, where used, is Stem-supplied from the grant’s egress allow-list; a caller cannot widen its own egress through request payload alone.

Trust path overview. Identity and grants sit beside the sandbox; neither replaces the other.

Install documentation describes governed-installation invariants (distinct Stem principal, credential exclusivity, issued rather than merely declared identity, and binary integrity) as properties that decide whether delegation is enforced by the operating system or only recorded. Operational steps live in docs. The architectural point: sandboxing without identity and authority is incomplete for unattended delegation.

Deployment Hardiness

The same software can provide different effective boundaries depending on how it is deployed. Hardiness is OpenTendril’s name for that deployment posture: whether the Terroir (host conditions) permits the intended delegation boundary to be enforced rather than merely recorded.

tendril hardiness reports findings from the invoking account. It does not gate execution, block weak deployments, or certify that a site is secure. A single-user laptop where the Stem shares a principal with its Pollinators may record grants and audit intent while still leaving the caller able to rewrite those grants or read credential material: advisory recording rather than OS-enforced boundary. A multi-principal installation aims at the opposite: a Stem principal callers cannot become, credentials they cannot read, and a control plane they cannot rewrite.

Hardiness measures site conditions. It is a deployment-posture report, not a runtime permission decision, not a Sprout, and not a security certification. Details: operational documentation.

Current Terrarium providers

OpenTendril’s Stem implements a TerrariumProvider contract with multiple backends. The following describes mechanics currently present in code and covered by tests, not marketing tiers. There is no bronze, silver, or gold ranking. No provider is described here as universally dominant.

Provider Execution primitive Boundary mechanics (current) Meaningful limitations
Docker Local Docker daemon; Linux namespaces and cgroups Launch path uses --network none, --cap-drop=ALL, --security-opt=no-new-privileges:true, configurable memory limits, and a default pids limit of 512. Optional read-only rootfs and run-as user. Shares the host kernel. Breakouts and kernel exploits remain in the threat model.
gVisor Docker with the runsc runtime Same Docker launch path plus --runtime=runsc. Syscalls go through gVisor’s userspace kernel (Sentry). Readiness checks that runsc is registered on the daemon. Requires host/runtime registration. Compatibility and performance trade-offs for syscall-heavy work. Still container-shaped rather than a full VM.
Firecracker Firecracker micro-VM via KVM Separate kernel and rootfs; guest communication over vsock to a Stoma init process. Network modes limited to none. Memory size configurable. No Docker network bridge. Requires KVM, kernel/rootfs bootstrap, and Firecracker on the host. Different feature surface than Docker (for example, interactive stdin and arbitrary image selection are constrained). Integration tests depend on host readiness.

Provider implementation and generic Conductor RunSprout compatibility are separate. Current generic RunSprout compatibility:

  • Docker: compatible.
  • gVisor: compatible.
  • Firecracker: implemented provider, incompatible with the generic RunSprout spec because that path requests selectable images, host mounts, and interactive stdin that Firecracker does not declare.
  • Host: implemented explicit isolation escape, incompatible with the generic RunSprout spec because that path requests capabilities Host does not declare.

Technical detail: docs/TERRARIUM.md.

Default selection: the low-level terrarium factory defaults to Docker. The Conductor prefers gVisor when runsc is registered and no provider is explicitly set; an explicit Docker (or other) selection is not auto-upgraded. A host provider also exists and intentionally bypasses isolation; it activates only under an explicit environment gate and is treated as a posture weakness for Hardiness reporting.

Stoma-related core code treats the Terrarium as network-sealed at the wire for command execution, with any external fetch mediated by the Stem under grant egress policy. That is the intended egress model for sealed work, still subject to provider correctness and deployment Hardiness.

Containment protects boundaries, not work quality

Work quality is separate

Contained code can still be bad code. Tests can still fail. Model reasoning can still be wrong. A Sprout can waste time, misunderstand the task, or produce an undesirable change, entirely inside the declared boundary.

Containment protects the boundary, not work quality. Whether the change is worth keeping is a separate judgment for the Botanist via Git acceptance. The project’s measurement protocol is on the experiment page.

Containment leaves residual risk

Conservative security language

Boundary mechanisms can have vulnerabilities. Kernel shared with containers is a different surface than micro-VMs. Deployment posture matters. Misconfiguration matters, especially host-provider bypass, rootful container daemons that undermine principal separation, and credentials readable by callers. Measured runs do not prove universal security.

OpenTendril should not be described as perfectly secure, enterprise-ready by adjective, or free of residual risk. The honest claim is narrower: enforce and observe a declared boundary, report when the deployment cannot enforce it, and measure whether anything outside that boundary was touched during qualifying work.

Measurement

OpenTendril’s Objective is stated as a capability a Botanist should have: grant an LLM full freedom inside a Terrarium, be asked for nothing while it works, find that nothing outside the boundary was touched, and receive the result in Git for review, with work quality judged separately.

Containment claims should ultimately be measured that way: whether anything outside the declared boundary was touched during qualifying runs that actually changed something. Assertion without measurement is the backlog the Objective exists to replace. Protocol details: the OpenTendril experiment.

Industry convergence

Modern agent systems are moving beyond simple repeated permission prompts. Sandboxing, network controls, scoped credentials, managed configuration, and agent-native telemetry are active first-party concerns at OpenAI and Anthropic, among others. That convergence is evidence that containment is a shared industry problem, not a claim that OpenTendril is the only system that addresses any piece of it.

As agents become more capable and more contained, the full delegated-authority contract (identity, authority, deterministic governance, boundary, observation, Git handoff, and measurement) becomes more important. That is the framing OpenTendril is testing.

Primary sources used for industry context