I’ve mentioned “sandbox” and “isolation” in enough posts now that it’s worth stopping to explain what that word is actually doing, especially after what GhostJacking showed about what happens when it’s missing.

A sandbox is a restricted execution environment — the agent runs commands, writes files, and executes code inside a walled-off space instead of directly on your real machine. If something goes wrong, whether that’s a genuine bug, a hallucinated command, or a malicious instruction the agent got tricked into following, the damage is contained to a disposable container instead of your actual filesystem, credentials, and network access.

OpenHands is a good concrete example of what this looks like built out properly. Its 1.x architecture runs every action — shell commands, file edits, code execution — inside a Docker container, with the reasoning that untrusted code execution is inherently risky, environments should stay consistent across machines, and resource limits should stop a runaway process from taking down the host. Everything the agent does is logged as an immutable event, so a session that goes sideways can be replayed exactly rather than reconstructed from a chat transcript.

The isolation itself has layers, and skipping any one of them is usually how things go wrong. A reasonably complete sandbox setup restricts at least four things independently:

  • Filesystem — the agent can only read and write inside specific allowed paths, locked at container creation
  • Network — outbound connections need explicit allow rules; one increasingly common and specific fix is gating DNS lookups on the same network policy, since a sandboxed process resolving a domain it’s not allowed to reach is its own quiet exfiltration channel
  • Process — blocking privilege escalation and dangerous syscalls, so even a compromised agent can’t climb out of its own container
  • Credentials — API keys and tokens get injected as environment variables at runtime rather than sitting in the sandbox’s filesystem where a curious or compromised process could just read them off disk

This is exactly the layered approach that would have blocked GhostJacking. That technique worked specifically because an agent trusted logged output and executed it with the same permissions as everything else it was doing. Default-deny network egress, process-level confinement, and policy enforcement that fails secure on a timeout are the layered defense researchers pointed to afterward — which is a description of a properly built sandbox, not a separate fix.

None of this is exciting to configure, and it’s clearly more setup than the one-line install most of these tools advertise on their landing page. But an agent that can read your codebase, run arbitrary shell commands, and reach the network is functionally a remote code execution engine that happens to be pointed at helpful tasks most of the time. The sandbox is what keeps “most of the time” from becoming a real problem the one time it isn’t.