Slide 21 of 28
Part 4 — PreventionSlide 21
Slide 21 · Mitigation 3
Execution sandboxes — isolate tool calls and restrict what they can reach
If a tool gets misused inside a sandbox, the damage is contained. Outside a sandbox, it isn't.
📄 OWASP Top 10 for Agentic Applications 2026 · ASI02
MIT 03
Execution Sandboxes and Egress Controls

Run tool execution in isolated, ephemeral environments — containers or VMs with no persistent state and strict network policies. Each tool invocation should have its own sandbox that is destroyed after the call completes.

Enforce outbound allowlists: the sandbox can only reach destinations that are explicitly approved. No open internet access, no access to internal systems beyond what the tool requires.

For code-generating tools: never allow generated code to execute outside a sandbox. The Amazon Q DNS exfil and similar attacks would be contained if DNS queries from agent-executed code were blocked or filtered.

Sandboxing doesn't prevent the tool from being called with malicious intent — it only limits the damage. A sandboxed refund tool still issues unauthorized refunds if it's called with the wrong parameters. Sandboxing is a containment strategy, not an intent-validation strategy.

S06 (DNS exfil via ping) — an egress allowlist blocks the DNS resolution to attacker infrastructure. S08 (Research agent / malicious link) — sandboxed browsing can't reach internal systems. S13 (EDR bypass via tool chain) — sandbox isolation prevents lateral movement to other systems.

💼 Business takeaway

Ask your team: if your AI agent were to run malicious code or call an unintended external service, would it be technically able to — or is it running in an isolated environment where that's blocked at the infrastructure level? Ask whether the isolation is enforced by the system, or just relied on from the agent's own behavior.

← Back Next → Mitigation 4: The Intent Gate