Why architecture matters here
Tool sandboxing matters because agents are effectively untrusted (LLM-driven, prompt-injectable, acting on adversarial inputs), and without sandboxing, a compromised or misguided agent can do serious harm -- so containing what the agent can do is essential to safe agentic systems. An agent that takes actions (runs code, accesses data, makes calls) is powerful, but it's untrusted: the LLM driving it can be wrong (hallucinating a harmful action), manipulated (prompt injection -- adversarial input making it take harmful actions), or acting on adversarial inputs (a malicious document/web page). So the agent is like untrusted code (you can't trust it to only do safe things). Without sandboxing (the tools running with full access), a compromised agent can do serious harm (exfiltrate sensitive data, damage systems, make unauthorized calls, run malicious code) -- a serious security risk (amplified as agents get more capable and autonomous). Sandboxing contains this (isolating the tool execution -- so even a compromised agent can only do what the sandbox allows -- limiting the harm). This is essential to safe agentic systems (containing untrusted agents' actions) -- and increasingly important as agents become more capable and are given more powerful tools. For anyone building agents that take actions (the direction of agentic AI), tool sandboxing is essential security, and understanding it is understanding how to contain untrusted agents.
The treat-the-agent-as-untrusted insight is the crucial security posture, and it reframes the whole problem. The mistake is treating the agent as trusted (assuming it will only do sensible, safe things -- so giving its tools full access). But the agent is NOT trustworthy: the LLM can be wrong (a hallucinated harmful action), manipulated (prompt injection -- an attacker's input in a document or web page manipulating the agent into harmful actions), or acting on adversarial data. So the correct posture is treating the agent as untrusted (like any untrusted code -- assuming it might do something harmful, whether through error, manipulation, or adversarial input) -- and therefore containing what it can do (sandboxing its tool execution -- so even if it tries something harmful, the sandbox contains it). This is the same security posture as running any untrusted code (you sandbox it -- you don't give untrusted code full access). Applying it to agents (treating the agent as untrusted -- containing its actions via sandboxing) is the crucial reframing (from 'the agent is a helpful assistant we trust' to 'the agent is untrusted code we must contain') -- and it's the foundation of agent security. This posture is validated by prompt injection (a real, serious threat -- adversarial input manipulating agents -- demonstrating that agents can be made to do harmful things, so they must be contained). Understanding the treat-as-untrusted posture (the agent is untrusted, so contain what it can do) is understanding the crucial security foundation of agent sandboxing.
And the least-privilege-plus-egress-control combination is what makes sandboxing effective, especially against the critical exfiltration threat. Sandboxing isn't just isolation -- it's about minimizing what the contained agent can do and access. Least privilege: the sandbox has only the minimal permissions the tools genuinely need (not full access -- e.g., if a tool only needs to read one directory, the sandbox has only that -- not the whole filesystem) -- so even a compromised agent has minimal capability (the least privilege limiting what it can do). Egress control: controlling outbound network access (what the sandbox can send data to) -- crucial because a primary harm is exfiltration (a compromised agent sending sensitive data to an attacker -- e.g., a prompt-injected agent reading secrets and POSTing them to an attacker's server). Egress control (restricting outbound network -- e.g., allowlisting only necessary destinations, or blocking egress entirely for sensitive tools) prevents exfiltration (the agent can't send data out to an attacker -- even if it reads the data, it can't exfiltrate it). So least privilege (minimal capability) plus egress control (preventing exfiltration) are what make sandboxing effective (not just isolating, but minimizing capability and preventing the key exfiltration harm) -- especially since exfiltration is a primary agent threat (prompt-injected agents exfiltrating data). Understanding least privilege (minimal permissions) and egress control (preventing exfiltration) is understanding what makes sandboxing effective against the real threats.
The architecture: every piece explained
Top row: the threat and approach. The threat: the agent runs arbitrary actions (code, file access, API calls) -- and it's untrusted (LLM-driven, prompt-injectable, acting on adversarial inputs) -- so a compromised agent can do serious harm. Sandboxing: isolating the tool execution (containing what the agent can do -- so even a compromised agent is limited to what the sandbox allows). Isolation levels: the strength of isolation -- process isolation (lightweight -- some separation), containers (stronger -- namespace/cgroup isolation), VMs (strongest -- full virtualization -- more overhead) -- stronger isolation for less-trusted/more-dangerous execution. Least privilege: the sandbox has only the minimal permissions the tools need (not full access) -- limiting the capability of even a compromised agent.
Middle row: the restrictions. Code execution: sandboxing untrusted code execution (if the agent runs code -- a common powerful tool -- the code runs in a strong sandbox, since it's untrusted). Network and filesystem: restricting access -- the sandbox can't reach arbitrary networks or files (only the minimal necessary -- least privilege applied to network/filesystem). Resource limits: CPU, memory, time limits (so a runaway or malicious tool can't consume all resources -- e.g., a fork bomb, an infinite loop) -- bounding resource consumption. Egress control: controlling outbound network (preventing exfiltration -- a compromised agent can't send sensitive data to an attacker -- allowlisting or blocking egress) -- the crucial anti-exfiltration control.
Bottom rows: gating and injection. Approval / human-in-the-loop: gating dangerous actions (a human approves before a consequential action executes -- e.g., a destructive operation, a payment) -- so the agent can't autonomously take the most dangerous actions (a human gate). Prompt injection defense: defending against prompt injection (adversarial input manipulating the agent into harmful actions -- a serious threat) -- the sandbox contains the damage even if the agent is injected (the injected agent still limited by the sandbox), plus input handling to reduce injection. The ops strip: isolation choice (choosing the isolation level -- process/container/VM -- for the trust/danger level and the overhead tradeoff -- stronger isolation for more-dangerous execution), monitoring (monitoring the agent's actions -- what tools it invokes, what it accesses, egress attempts -- for detecting and investigating malicious/anomalous behavior), and blast radius (minimizing the blast radius -- the damage a compromised agent can do -- via least privilege, isolation, egress control, approval gates -- so a compromise is contained).
End-to-end flow
Trace a prompt-injection attack contained by sandboxing. An agent processes a document (a tool reads and summarizes it). The document is malicious -- it contains a prompt injection (hidden text instructing the agent to read the system's secrets and send them to an attacker's server). The agent, prompt-injected, attempts the harmful actions: it tries to read the secrets (a file access) and exfiltrate them (a network call to the attacker's server). But the sandboxing contains the damage: least privilege means the sandbox doesn't have access to the secrets (the tool only needed access to the document, not the secrets -- so the sandbox can't read them -- the file access denied); and egress control means the sandbox can't reach the attacker's server (outbound network restricted to necessary destinations -- the exfiltration call blocked). So even though the agent was prompt-injected (manipulated into attempting harm), the sandbox contained it (the least privilege denying the secret access, the egress control blocking the exfiltration) -- no harm done (the attack contained). The sandboxing (least privilege, egress control) contained the prompt-injection attack -- the agent treated as untrusted, its harmful actions contained.
The isolation-level and resource-limit vignettes show more containment. An isolation-level case: the agent runs untrusted code (a code-execution tool -- a powerful, dangerous capability, since arbitrary code is fully untrusted). The team uses strong isolation for it (a container or VM -- not just process isolation -- since arbitrary code execution is the most dangerous, needing the strongest isolation) -- so even malicious code (e.g., trying to escape or access the host) is contained by the strong isolation (the container/VM boundary). The isolation level matched the danger (strong isolation for the dangerous code execution). A resource-limit case: a tool runs away (an infinite loop, or malicious code trying to consume all resources -- a fork bomb). The resource limits (CPU, memory, time) contain it (the sandbox's limits stopping the runaway consumption -- the tool killed when it exceeds the limits) -- so a runaway/malicious tool can't consume all the system's resources (the limits bounding it). The resource limits contained the resource-exhaustion threat.
The approval and blast-radius vignettes complete it. An approval case: the agent wants to take a dangerous action (a destructive operation, or a payment). Rather than letting it execute autonomously (too dangerous for an untrusted agent), the action is gated by approval (a human approves before it executes -- human-in-the-loop for the dangerous action) -- so the agent can't autonomously take the most dangerous actions (a human gate for them). A blast-radius case: the team designs for minimal blast radius (the damage a compromised agent could do) -- least privilege (minimal permissions -- so a compromise has minimal capability), isolation (containing a compromise), egress control (preventing exfiltration), and approval gates (for dangerous actions) -- so even a fully-compromised agent is contained (minimal blast radius -- it can't access much, can't exfiltrate, can't take dangerous actions autonomously). The consolidated discipline the team documents: treat the agent as untrusted (LLM-driven, prompt-injectable, adversarial-input-exposed -- like untrusted code), sandbox tool execution (isolating what the agent can do -- process/container/VM per the danger), apply least privilege (minimal permissions -- limiting capability), restrict network/filesystem access and set resource limits, control egress (preventing exfiltration -- the crucial anti-exfiltration control), gate dangerous actions with approval (human-in-the-loop), defend against prompt injection (the sandbox containing the damage even if injected), monitor the agent's actions, and minimize the blast radius (least privilege, isolation, egress control, approval -- so a compromise is contained) -- because agents are effectively untrusted (LLM-driven, prompt-injectable), and without sandboxing a compromised agent can do serious harm, so containing what the agent can do (sandboxing, least privilege, egress control) is essential to safe agentic systems.