When sandboxing covers only the first command, separators such as semicolons can move later commands into the outer shell where protection no longer applies. That breaks the trust boundary between the model output and the host system, allowing arbitrary code execution from seemingly normal user input. The failure is not the model itself, but incomplete command wrapping.
How the trust boundary fails when only the first command is sandboxed
The core failure is command boundary confusion. A model-generated string may look like one command, but shell syntax lets separators, substitutions, and chaining operators split it into multiple execution contexts. If the sandbox wrapper protects only the first parsed command, everything after the separator can execute in the outer shell with the host’s real privileges.
That means the protection is applied to a fragment of the instruction stream, not to the full effect of the string. The dangerous part is not limited to a semicolon, either, because shell grammar can also redirect control flow through pipelines, subshells, command substitution, and quoted fragments that expand later.
The practical consequence is that the sandbox becomes a partial filter instead of an execution boundary. A string that was assumed to be constrained can still trigger filesystem writes, network calls, process launches, or environment inspection outside the intended restriction model.
When command wrapping is incomplete, the system is no longer enforcing “run this entire request in isolation.” It is enforcing “run the first token sequence safely, then trust the rest,” which is exactly the wrong security assumption for untrusted model output.
Why partial sandboxing is dangerous in practice
Partial sandboxing fails because the shell is not a simple linear parser. The outer shell interprets separators before the sandboxed execution context can contain them, so the attacker only needs one boundary-breaking character or expansion path to move execution into a less restricted context. The result is arbitrary code execution from input that may appear normal at the application layer.
That failure mode is especially risky when the wrapper assumes the model output is already “mostly safe.” In practice, the model does not need to be malicious for the exploit to work, because any generated string that includes chained commands, shell metacharacters, or injected arguments can become a carrier for unintended host execution.
For practitioners, the key distinction is between sanitising content and containing execution. Sanitisation can reduce accidental breakage, but only full parsing, quoting, or non-shell execution paths reliably preserve the trust boundary between generated text and operating-system side effects.
The safest mental model is that the entire model-produced string is untrusted until it is either parsed into an allowlisted argument vector or executed inside a boundary that encloses every command path, not just the first one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Shell chaining and injected commands are command-interpreter abuse. |
| Recommendation — Use T1059 to hunt for injected shell execution and constrain command interpreters. | ||
| CIS Controls v8 | 6.3 — User Access Management | Execution boundaries should limit what launched commands can access. |
| Recommendation — Restrict execution paths so untrusted input cannot gain host-level command access. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | The wrapper must enforce the full intended execution boundary and privilege scope. |
| Recommendation — Enforce least-privilege execution so untrusted command text cannot escape its authorization scope. | ||
Practitioner Guidance
What to verify: Confirm whether the sandbox encloses the whole command invocation, including separators, subshells, expansions, and any follow-on commands. If the wrapper only guards the first command, treat the control as broken, not degraded.
Decision rule: If the task can be expressed without a shell, prefer direct process execution with explicit arguments. If a shell is unavoidable, require complete quoting, strict allowlisting, and an execution environment that constrains the full string rather than a prefix.
Common mistake: Teams often test only the “happy path” command and miss payloads that append extra instructions after a separator. The first reliable test is whether a benign first command can be followed by an arbitrary second command without changing the wrapper’s protection model.
Practitioner takeaway: Partial sandboxing is not a weak sandbox, it is a broken trust boundary. Once any untrusted suffix can escape the intended wrapper, the security property you thought you had is gone.
