Code Execution Sandbox

"Let the agent compute. Don't let it escape."

Context

An agent needs to execute generated code — data analysis scripts, transformations, calculations, test suites. The code must actually run, not just be generated. But the execution environment must be isolated from production systems, credentials, and sensitive data.

Problem

Code generated by an agent may contain bugs, security vulnerabilities, or unintended system interactions. Executing it in the same environment where the agent operates — with access to the network, the file system, environment variables, and credentials — turns every code generation task into a potential security incident. The agent doesn't intend harm; but generated code that imports a library, makes a network call, or reads credentials creates risk regardless of intent.

Forces

  • Utility vs. isolation. The code needs access to data and libraries to be useful. But access to anything beyond the minimum creates attack surface.
  • Performance vs. containment. Sandboxed environments add overhead — container startup, data copying, restricted I/O. For quick computations, the overhead may exceed the computation time.
  • Reproducibility vs. dynamism. A fixed sandbox environment is reproducible but may lack libraries the code needs. A dynamic environment that installs dependencies on the fly is flexible but less controllable.

The Solution

Provide a sandboxed execution environment that the agent can invoke as a tool. The sandbox runs generated code in isolation with declared resource limits and no access to credentials, network, or production systems.

Sandbox requirements:

  1. No network access by default. If the task requires network calls, they are proxied through declared endpoints — not open access.
  2. No credential access. Environment variables, secrets managers, and authentication tokens are not available inside the sandbox.
  3. Scoped file system. The sandbox has access to a declared working directory and nothing else. No reading the host file system, no writing outside the sandbox.
  4. Resource limits. CPU time, memory, and execution duration are capped. Runaway code is terminated, not tolerated.
  5. Output capture. Stdout, stderr, and generated files are captured and returned to the agent as structured output. The agent interprets the results; it does not re-execute blindly.
  6. Ephemeral lifecycle. The sandbox is created for the execution and destroyed afterward. No persistent state between executions unless explicitly designed.

Resulting Context

  • Agents can compute safely. Data analysis, transformations, and test execution happen in isolation, reducing the risk of unintended system interaction.
  • Code quality issues are contained. Bugs in generated code crash the sandbox, not the host system.
  • Security boundaries hold. Even if generated code contains a vulnerability or exfiltration attempt, the sandbox prevents it from reaching production resources.

Therefore

Provide code execution as a sandboxed tool with no network access, no credential access, scoped file system, resource limits, and ephemeral lifecycle. The agent invokes the sandbox; the sandbox returns results. Generated code never runs in production context.

Connections