Harness Engineering · Chapter 8
Environments, Sandboxes, and Custody
Why isolation, resource ownership, identity, and effect custody are separate contracts in an agent runtime.
An environment is where consequences become possible
The environment is the concrete world a run can observe and change: a repository, browser, container, database, device, tenant, or external account. A sandbox limits reach inside that world. Custody answers the harder question: whose resources are present, under whose identity, and who is accountable for changes.
These contracts must be named independently. A container can isolate processes while exposing the wrong repository. A browser profile can be technically sandboxed while logged into a personal account. Strong process isolation does not repair incorrect custody.
This chapter is a proposed design model, not a claim that one reference implementation enforces every control below. The model combines ordinary systems-security boundaries with public guidance to evaluate agent hijacking against explicit, realistic threat models.
Resolve the target before execution
Admission should resolve an explicit environment identity: tenant, repository and revision, workspace, account, region, device, or dataset. Record how it was selected. Avoid deriving a consequential target from a current directory, recently focused window, or default credential when the user’s intent names something else.
The environment record should also name ownership and retention: who may read it, who may mutate it, how long temporary artifacts survive, and which data must never cross into model context or logs.
Isolation is one layer of policy
Filesystem and process isolation constrain local damage. Network policy constrains destinations. Credential brokerage constrains identities and scopes. Resource budgets constrain time, compute, and storage. Approval gates constrain selected transitions. None of these layers should be treated as a synonym for the others.
Use the narrowest environment that still supports the task. Read-only mounts are preferable during discovery. Temporary worktrees or disposable containers are useful when changes must be reversible. Production effects need separate credentials and admission even if identical code ran successfully in a test sandbox.
Carry custody across handoffs
Delegation and external tools create custody transfers. A child run should receive an explicit subset of the parent’s environment and authority, not ambient access to everything the parent can reach. Artifacts returning from the child need identity, provenance, and validation before the parent treats them as trusted state.
Cleanup is also part of custody. The harness should know which temporary resources it created, which must be retained for evidence, and which must be removed or handed to an owner. “The process exited” does not prove that a cloud resource, file lock, browser session, or credential lease was released.
Failure boundary
Environment control fails when isolation is strong but the target is wrong; when a sandbox shares a secret-bearing home directory; when an ephemeral runner destroys the only recovery evidence; or when a delegated process retains authority after cancellation. Another failure is quiet escape through logs, caches, clipboard state, or generated artifacts even though the primary filesystem is restricted.
Test both containment and custody. Ask not only “can the process reach outside?” but “did we give it the correct inside?”
Retrieval check
A coding run operates in a disposable container with no outbound network, but the mounted directory is the user’s primary checkout and the token inside it can write to production. Which properties are isolated, and which custody boundaries are broken? Redesign the environment without assuming the container itself is sufficient.
Sources and further reading
- Strengthening AI Agent Hijacking Evaluations — official public guidance on explicit threat models and adversarial agent evaluation.
- Tools, Capability Manifests, and Binding — the action contract that must be reconciled with environment custody.
- Four Surface Classes — a mutation model for deciding which environment surfaces may change.