Designing an execution boundary that actually enforces limits

A coding agent may run a test suite that imports arbitrary project code. That code can read environment variables, start subprocesses, access network endpoints, and consume resources. A prompt saying only run tests does not constrain those operating-system operations. An execution boundary must be enforced outside the generated program. Begin by naming assets: host files, other tenants' data, service credentials, internal network services, and the availability of the machine.

Build a capability map for one concrete task. A formatter may need read and write access to one checkout, no network, a bounded temporary directory, and several seconds of CPU. A dependency installation step may need limited package access and a different trust decision. Giving both steps the same broad environment is convenient, but it makes the formatter inherit powers it does not need.

Docker's security documentation distinguishes namespaces, resource controls, the daemon's attack surface, capabilities, and other kernel mechanisms. Translate that into an engineering checklist with separate questions. Which files are visible? Which files are writable? Which identities and kernel operations are available? Which network destinations are reachable? How much CPU, memory, process count, and disk can the workload consume? No single yes-or-no sandbox flag answers all of them.

A read-only root filesystem does not make writable mounts read-only. A memory cap does not stop network access. Running as a non-root user does not revoke credentials already present in the environment. Mounting a powerful host control socket can undo the intended boundary. Verify the effective configuration and the observed behavior with harmless boundary tests, rather than treating a configuration file as proof that enforcement occurred.

Ordinary containers share the host kernel while isolating selected views and privileges. That can be appropriate for trusted application workloads with carefully chosen controls. Running arbitrary, potentially hostile code raises a different question about the host kernel attack surface. Additional isolation may be warranted, including dedicated virtual machines or an application-kernel approach such as gVisor.

gVisor provides a userspace application kernel and an OCI-compatible runtime. Its design interposes on application system calls, with compatibility and performance tradeoffs that depend on the workload. Do not infer that choosing a stronger boundary automatically secures mounted data or credentials. In a toy comparison, a test uses 30 seconds of compute and 20 seconds of filesystem operations. A boundary that doubles only the latter makes total time 70 seconds, not 100. Measure the actual workload instead of applying a universal overhead multiplier.

Separate the controller from the worker. The controller interprets the user's authorized task, allocates an execution environment, and exposes narrowly scoped operations. The worker should not receive the controller's broad credentials. When a tool needs a service call, a broker can check a structured request, apply policy, and perform the call using its own restricted identity. The broker becomes a high-value boundary that must validate every request.

Scope access along several axes: actor, tenant, tool, resource, operation, amount or volume when relevant, and expiry. If a worker can read one report, it should not automatically be able to list every report in the account. If it can propose a patch, publishing that patch can remain a separately authorized operation. Short-lived access reduces exposure after the immediate task finishes, although expiry cannot reverse data already disclosed.

The accompanying code rejects a few dangerous combinations in a fictional worker manifest. It can catch an accidentally enabled network flag or a writable input mount before a job is submitted. It does not create namespaces, configure a firewall, limit processes, inspect kernel behavior, or prove that a container is secure. A real launcher must translate a reviewed policy into runtime controls and verify those controls independently.

Add boundary tests to the project: an attempted write outside the workspace, an attempted connection to a forbidden destination, and a bounded resource spike. Run them only in an environment intended for such tests. Record which enforcement layer denied each attempt. If a check merely returns false in Python while the untrusted program can bypass it, it is validation logic, not containment. That distinction is fundamental to reviewing an agent execution system.

These fictional worker manifests are checked against a small local policy. The empty list means that the listed checks found no problem, not that any isolation was established. Add a forbidden mount to see rejection, then identify the real runtime control that would enforce the corresponding policy.