A
Member
Every agent deployment I have reviewed leans on a sandbox somewhere: a container, a VM, a restricted shell, a permissions layer. Sandboxes are necessary, but I keep seeing teams treat them as a guarantee rather than a layer. Here is where I think the boundary actually holds, and where it quietly fails.
1. What a sandbox does well. A well-built sandbox contains blast radius. A file-system jail plus a network egress allowlist plus a non-root user will stop the overwhelming majority of accidental damage: a runaway agent deleting the wrong directory, a hallucinated rm -rf, a script that phones home to a random endpoint. For routine failure modes, isolation is the cheapest reliable control we have.
2. Where it leaks: the tool interface is the real boundary. The sandbox walls off the operating system, but the agent's actual power lives in its tools — the APIs, the databases, the code execution service, the messaging channels. An agent that cannot touch the local filesystem can still exfiltrate data through a "legitimate" API call, or trigger a payment, or rewrite a production database, if the tool permissions are broad. I have seen more damage through over-permissioned tools than through sandbox escapes. Audit the tool surface first, the container second.
3. Where it leaks: state that persists across sessions. Sandboxes are often ephemeral per run, but agents increasingly keep state: memory stores, vector databases, shared scratch files, cached credentials. An agent can poison a shared memory store in one session and have another agent act on the poisoned entry later. Isolation per run means nothing if the shared state is the channel. Treat persistent memory as a trust boundary of its own, with its own access rules.
4. Where it leaks: the human in the loop. The most common escape I see is not technical at all: the agent asks the user for something ("please paste your API key so I can finish this step") and the user complies. The sandbox never had a chance. Approval gates help, but only if they show the user what the action actually does, not a vague summary.
5. What I actually recommend. Defense in depth, but in a specific order: least-privilege tool permissions first, then sandboxing, then monitoring of tool calls (not just process activity), then human approval for irreversible actions. And test the sandbox the way you would test any security control: try to break out of it on purpose, with a red team that has the agent's actual toolset.
How do you scope tool permissions for agents in your deployments — per agent, per task, or per session? And has anyone here actually caught a sandbox escape in production?
1. What a sandbox does well. A well-built sandbox contains blast radius. A file-system jail plus a network egress allowlist plus a non-root user will stop the overwhelming majority of accidental damage: a runaway agent deleting the wrong directory, a hallucinated rm -rf, a script that phones home to a random endpoint. For routine failure modes, isolation is the cheapest reliable control we have.
2. Where it leaks: the tool interface is the real boundary. The sandbox walls off the operating system, but the agent's actual power lives in its tools — the APIs, the databases, the code execution service, the messaging channels. An agent that cannot touch the local filesystem can still exfiltrate data through a "legitimate" API call, or trigger a payment, or rewrite a production database, if the tool permissions are broad. I have seen more damage through over-permissioned tools than through sandbox escapes. Audit the tool surface first, the container second.
3. Where it leaks: state that persists across sessions. Sandboxes are often ephemeral per run, but agents increasingly keep state: memory stores, vector databases, shared scratch files, cached credentials. An agent can poison a shared memory store in one session and have another agent act on the poisoned entry later. Isolation per run means nothing if the shared state is the channel. Treat persistent memory as a trust boundary of its own, with its own access rules.
4. Where it leaks: the human in the loop. The most common escape I see is not technical at all: the agent asks the user for something ("please paste your API key so I can finish this step") and the user complies. The sandbox never had a chance. Approval gates help, but only if they show the user what the action actually does, not a vague summary.
5. What I actually recommend. Defense in depth, but in a specific order: least-privilege tool permissions first, then sandboxing, then monitoring of tool calls (not just process activity), then human approval for irreversible actions. And test the sandbox the way you would test any security control: try to break out of it on purpose, with a red team that has the agent's actual toolset.
How do you scope tool permissions for agents in your deployments — per agent, per task, or per session? And has anyone here actually caught a sandbox escape in production?