Coding Agent Sandbox: Why Control-Plane Access Determines the Runtime Boundary

A coding agent sandbox cannot preserve its runtime boundary if the confined agent can reach the control plane, pass its trust checks, and change the policy governing its own session. Filesystem confinement alone does not break that chain. The control plane, mutable policy state, credentials, and enforcement runtime must remain outside the agent workload's authority.

A documented DeepSeek Harness state shows why this separation matters. In that version, the sandbox restricted filesystem writes but left host loopback reachable. The agent could reach a local HTTP API, satisfy a trust check with client-supplied routing data, change its session to unconstrained execution, and continue without approval prompts. The upstream change at commit 3e24087bfaeabe40b58ba2f7b936895b8f93fe27 added identity controls while retaining Host and Origin as request-routing fences. The case demonstrates the mechanism; it does not describe later releases or other deployments.

The system boundary and its prerequisites

The relevant system has four distinct components:

• The agent workload executes model-selected tools and commands under an operating-system identity.
• The isolation layer constrains what that workload can affect.
• The control plane accepts requests that inspect or modify session behavior.
• The policy state and enforcement runtime determine whether later execution remains confined.

Several conditions must coincide for self-deactivation. The workload needs a communication path to the control plane. The control plane must then mistake a workload-supplied value for evidence of a trusted caller, or otherwise accept the workload's identity. That caller must have authority to mutate effective policy, and the execution path must consume the changed state. Removing any necessary condition stops the complete chain.

This boundary extends beyond a writable-workspace rule. A process may be unable to write outside its workspace while remaining able to send requests over a shared network namespace. In the documented Harness state, the Linux profile did not unshare the network namespace, the macOS profile allowed networking, and loopback remained reachable from inside the sandbox.

The causal chain to unconstrained execution

The chain begins with reachability. A local API may be hidden from the public internet yet remain reachable by a sandboxed process on the same host network. “Local” describes routing, not caller identity.

Next comes misplaced trust. The documented API checked the HTTP Host value and allowed loopback authorities or configured trusted hosts, but did not compare that value with the connection's actual peer. HTTP defines Host as application-level routing information. Because a non-browser client can set the field, a trusted-looking value does not prove where the connection originated or which principal sent it.

That trust decision enables policy mutation. In the documented state, the reachable API could change a session to danger-full-access and set approval behavior to never. Subsequent commands were then treated as unconfined and ran without approval. The policy event was attributed as user-originated, so the recorded identity did not distinguish the agent's shell from the human operator.

Finally, the changed policy produces an enforcement effect. Researchers compared two otherwise equivalent sessions by giving each the same operation outside the workspace. The confined session blocked it. The session whose policy had been changed through the API succeeded. This comparison connects the mutation to the changed execution result rather than relying on the attempted operation alone.

The chain is therefore:

agent workload → reachable control plane → accepted caller → mutable session policy → enforcement consumes changed state → unconstrained effect

A stronger filesystem rule changes the final effect only if it remains independently enforced. It does not repair caller identity, remove the network path, or revoke policy-mutation authority.

Separate identity, connection origin, and policy state

Host and Origin checks can reject requests that arrive through an unexpected serving authority, but they do not provide sufficient identity proof. The upstream Harness fix separates these roles. Host and Origin remain routing fences, while a process token and signed cookie establish browser identity. Extending the trusted-host set changes the fence; it does not grant identity by itself.

Authentication and authorization are also separate decisions. Authentication establishes which principal made a request. Authorization determines whether that principal may perform the requested policy operation. Kubernetes illustrates the distinction with a 401 response for an unauthenticated request and a 403 response when an authenticated request is denied, although other APIs may use different status codes.

The critical authorization rule goes beyond “the agent may call the API.” The agent principal must not be able to weaken the requirements constraining that same principal. Non-overridable requirements provide one side of this invariant. On the other, the principal must lack escalation mechanisms. Kubernetes, for example, warns that escalate and bind permissions can bypass built-in restrictions on privilege escalation.

Policy separation also fails when the workload can rewrite the enforcement runtime instead of calling its API. If a sandbox runtime is installed inside an agent-writable project, the agent can replace it so that a later invocation runs modified code. The same principle applies to credentials. Storing them where the sandbox identity cannot read them preserves the identity boundary; placing usable administrator credentials inside the workload collapses it.

Four control classes interrupt different causal steps

Isolation limits execution effects. A filesystem sandbox can prevent a command from changing protected paths, but it does not remove a network path unless network isolation is part of the boundary. In the Harness case, filesystem restrictions and open networking coexisted.

Egress controls limit reachability. A deny rule interrupts the first causal step only when an active enforcer covers the relevant traffic. Kubernetes NetworkPolicy, for example, requires a supporting network plugin. Its documented limits matter too: pods cannot use NetworkPolicy to block localhost or traffic from their resident node. The presence of a policy object is not, by itself, evidence that the path is closed.

Credential scope limits available authority. Short-lived, workload-bound credentials reduce how long and where a stolen token can be used. Kubernetes TokenRequest credentials can be tied to a pod, carry a defined audience, and expire after a defined lifetime. These properties do not replace restrictive authorization: a narrowly scoped identity can still be overprivileged for its intended role.

Host integrations can reintroduce privileged paths. A host filesystem mount may expose system credentials or a container-runtime socket to the workload. Either can bypass assumptions made by the surrounding isolation. Every mounted socket, forwarded credential, helper process, or local service therefore belongs in the boundary model rather than being treated as neutral plumbing.

The controls complement one another because they act on different links. Isolation limits effects; egress limits paths; credential scope limits authenticated authority; authorization limits operations; and runtime integrity prevents replacement of the enforcer. Using one as a substitute for the others leaves a different causal step intact.

Signals, counterconditions, and limits

A useful test observes where the chain breaks, not only whether the final operation failed. In a controlled environment:

1. Send a policy request without valid workload identity. It should fail at authentication.
2. Repeat with a valid agent identity that lacks mutation rights. It should fail at authorization.
3. Confirm that policy, tool, and network telemetry attributes both attempts to the agent principal.
4. Run the same boundary operation without policy mutation and confirm that it cannot act outside the allowed area.

Record the API, policy, and telemetry versions with the result. Status codes depend on the implementation; the useful signals are the rejecting control point, correct attribution, and absence of the protected effect. A missing approval event can indicate a path that bypassed approval. An event attributed to the human when the agent initiated it points to an identity gap.

Each test has limits. An authentication failure proves that one request lacked accepted identity, not that no alternate credential exists. An authorization denial proves that one principal lacked one operation under the tested policy, not that escalation rights are absent. A blocked network attempt proves that the active enforcement stack denied the observed path. It does not rule out an alternative through loopback, resident-node traffic, host mounts, or helper processes.

A coding agent sandbox resists self-deactivation only when reachability, identity, mutation authority, policy-state integrity, and enforcement-runtime integrity are verified as separate boundaries. The decisive question is not whether the agent begins inside a sandbox. It is whether any path available to that agent can alter the instance that decides what “inside” means.