What breaks when Claude Code sandboxing is the only control?

What sandboxing actually contains, and what it does not

Sandboxing is a damage-limitation control, not a decision-integrity control. It constrains where code runs and what that code can reach, but it does not judge whether the code should have been run in the first place. An agent can still operate inside an agent sandbox while making a bad execution decision if the prompt, context, or tool output has been manipulated.

The practical break is simple: containment reduces blast radius after the fact, while execution authorisation prevents unsafe execution up front. If the model or agent can be induced to treat a malicious payload as acceptable, sandboxing only ensures the compromise stays bounded to the permitted process boundary.

That is why sandboxing should be read as one layer in a broader control stack. It is useful for constraining file system, network, and process effects, but it cannot by itself distinguish legitimate automation from adversarially steered automation. In agentic workflows, the most important failure mode is not always escape from the sandbox, it is legitimate execution of the wrong thing.

Why reasoning and tool use still fail inside the boundary

When the agent’s reasoning path is manipulated, the sandbox does not restore trust in the decision. A malicious instruction, poisoned context, or deceptive tool output can cause the agent to fetch, launch, or transform content that should never have been trusted, even though the runtime remains confined. The result is unsafe action with preserved containment.

That distinction matters because many attack paths target judgement rather than escape. The attacker wants the agent to act with authority, not necessarily to break out of the environment. Agentjacking examples show how deceptive input can steer coding agents into running attacker-chosen code while still appearing to follow normal workflow.

In other words, sandboxing reduces the cost of failure, but it does not stop the failure from happening. If the model accepts an attacker-controlled payload, the sandbox merely narrows the damage from execution, rather than preventing the unsafe branch of reasoning that led there.

What the real control stack needs beyond sandboxing

The missing layer is authorization, plus strong decision integrity around tool and execution choices. Sandbox boundaries should be paired with explicit execution policy, scoped permissions, and reviewable approval paths for actions that can launch binaries, change files, or reach sensitive systems. AI coding agent guidance is most useful when it treats sandboxing as a containment measure and not as a substitute for policy enforcement.

Practitioners should also separate trusted inference from trusted action. An agent may be good enough to summarise, classify, or propose, but still be too weak to execute directly. That is especially true where the action can trigger build steps, package installs, secret access, or code generation that persists beyond the session. The control objective is to make unsafe action hard to authorise, not merely hard to escape.

For higher-risk workflows, add monitoring for the kinds of actions the sandbox cannot reason about: unexpected binary execution, unusual child processes, abnormal file writes, or tool calls that are inconsistent with the task. Containment is most effective when paired with telemetry that shows whether the agent is staying inside an expected operational pattern.

Risk and Threat Considerations

Sandbox-only designs create a false sense of safety because they focus on confinement and ignore decision manipulation. If an attacker can shape the agent’s reasoning, they can often obtain harmful execution without needing a breakout, which means the control fails at the most important moment, before the action is authorised.

Failure mechanism: The agent accepts hostile input or a poisoned context, decides the payload is acceptable, and executes it within the sandboxed process tree. The sandbox limits lateral damage, but it does not prevent the initial unsafe action or the follow-on effects inside the permitted boundary.

Impact: You may still get code execution, data exposure, credential use, or workflow corruption, just with a narrower blast radius than an unconstrained host compromise. In practice, this shifts the problem from full compromise to bounded compromise, which is better but still a security failure.

Practitioner Guidance

What to verify: Treat sandboxing as a containment check, not a go-ahead signal. Verify that any action capable of running binaries, invoking tools, or changing state is separately authorised by policy or human approval, especially when the action was derived from model reasoning rather than a deterministic rule.

Common mistake: Teams often measure success by whether the sandbox blocked escape, when the more important question is whether the agent should have been allowed to act at all. If the only protection is runtime confinement, you still have an unsafe execution path.

Practitioner takeaway: The right standard is not “did the sandbox hold,” but “was the action properly authorised before the agent could make it real.”

Related resources from NHI Mgmt Group

• What breaks when Claude Code agents do not have a governed control layer?
• What breaks when malicious instructions are embedded in a Claude Code project file?
• What breaks when Claude Code hooks are left as local developer settings?
• What breaks when static analysis is used as the main AppSec control for AI code?