Some AI-generated actions, particularly generated code that gets executed directly, are too dynamic and too varied for static schema validation and predefined limits to fully bound safely, covered in output validation guidance elsewhere. For this category, a sandbox, an isolated execution environment with tightly controlled resources and access, provides a complementary containment layer, limiting the consequence of executing something unexpected even when the specific content couldn't be fully validated in advance.
Sandboxing addresses a different risk than schema validation
Schema and output validation, covered elsewhere in this content series, work well for structured actions with a defined, checkable format: a tool call with named parameters. Generated code, by contrast, can express an essentially unbounded range of behaviors within valid syntax, which means validating its safety through static analysis alone is fundamentally harder than validating a structured parameter set. Sandboxing addresses this gap by containing what the code can actually do at execution time, regardless of what the code's content specifically claims it will do.
Isolate execution from sensitive credentials and data by default
The sandbox environment should have no access to production credentials, sensitive data, or internal network resources by default, requiring explicit, narrow provisioning of only what a specific execution context genuinely needs. This default-isolated posture means a generated action attempting something unexpected or malicious has limited practical reach, regardless of what it attempts, because the sandbox simply doesn't have the access needed to cause broader harm.
Limit resource consumption explicitly
Configure the sandbox with explicit limits on CPU, memory, execution time, and network access, so a generated action that loops indefinitely, burns excessive resources, or attempts unexpected network communication gets contained by these limits rather than consuming resources without bound. This connects to the rate limiting and resource control discussion elsewhere, applied specifically at the execution environment level rather than only at the request or tool-call level.
Use ephemeral, disposable environments rather than persistent ones
Prefer ephemeral sandbox environments created fresh for each execution and destroyed afterward, rather than a persistent environment reused across multiple executions. This stops state or side effects from one execution from sticking around and potentially affecting a later, unrelated execution, and it limits the value of any successful compromise of the sandbox itself, since the compromised environment ceases to exist once that specific execution completes.
Capture and review sandbox output and behavior
Log what a sandboxed execution actually did, what resources it attempted to access, what network requests it attempted, even ones the sandbox's own restrictions blocked, following the traceability discussion elsewhere. This log is valuable both for immediate safety review, catching an attempt to access something unexpected even if the sandbox successfully blocked it, and for understanding patterns over time that might point to a recurring issue worth addressing more directly.
Apply network egress restrictions specifically
Restrict what network destinations a sandboxed execution can reach, following the network control discussion in related guidance, since unrestricted network access from within a sandbox can otherwise become an exfiltration path even if the sandbox successfully contains the execution environment from a compute and credential perspective.
Validate sandbox escape resistance directly through testing
Periodically test the sandbox's own isolation properties directly, attempting known sandbox escape techniques relevant to the specific sandboxing technology in use, since a sandbox with a known escape vulnerability provides considerably weaker containment than its configuration might suggest on paper. This testing should be part of the same adversarial testing discipline running throughout secure development guidance, applied specifically to the sandbox infrastructure itself.
Combine sandboxing with the other layers, not as a sole control
A sandbox contains what generated code can do during execution. It doesn't validate whether the code should get generated or executed at all in the first place. Combine sandboxing with the authorization and approval discussion elsewhere, requiring appropriate authorization before code execution even gets attempted, so sandboxing functions as a containment layer within a broader set of controls rather than the sole safeguard against generated code risk.
Where TELEON fits
TELEON's policy enforcement, applied through the gateway or supported middleware, can require authorization or approval before a sandboxed execution capability is invoked at all, complementing the sandbox's own execution-time containment with an upstream authorization check.
Building and hardening the sandbox environment itself, its resource limits, network restrictions, and escape resistance, remains infrastructure engineering work specific to each organization's execution environment and technology choices.
A short checklist
- Isolate sandbox execution from sensitive credentials and data by
default.
- Set explicit resource consumption limits for CPU, memory, time, and
network.
- Prefer ephemeral, disposable environments over persistent, reused
ones.
- Capture and review sandbox execution behavior, including blocked
attempts.
- Apply specific network egress restrictions to prevent exfiltration
through the sandbox.
- Test the sandbox's own escape resistance directly, not only its
configured limits.
- Combine sandboxing with authorization controls rather than relying on
it as a sole safeguard.
Sandboxing AI-generated actions provides a valuable containment layer specifically for dynamic, hard-to-statically-validate content like generated code, complementing rather than replacing the authorization and validation controls discussed throughout this content series for more structured action types.