What is an AI sandbox? Development environments and execution isolation

An AI sandbox is an environment used to develop, inspect, or execute AI workloads with a defined set of resources and access. The term describes both interactive development environments and isolated execution environments for generated or untrusted code. Those uses have different requirements.

Before choosing a sandbox, ask who supplies the code, what it may access, how long it runs, and which effects must be contained. A notebook for a trusted researcher and a code runner exposed to external users should not inherit the same permissions simply because both are called sandboxes.

Distinguish the environment from its isolation

An interactive API does not establish all those boundaries. Kubernetes multi-tenancy guidance explains the role of workload isolation and the limits of shared infrastructure. The suitable runtime depends on the trust model; separate containers alone should not be assumed sufficient for every hostile workload.

Define an execution contract

Write down the image and dependency versions, user identity, accessible files, outbound destinations, injected credentials, CPU and memory limits, GPU allocation, and maximum lifetime. Include what survives after the workload stops.

For an agent that reads a repository and writes a patch, a useful contract might allow one workspace and a synthetic test service, provide no production credentials, and export only selected output files. A training workspace might instead need a dataset mount and a GPU queue but no authority to promote a model to production.

Make each permission necessary for the task. If generated code can read a credential from its environment, that credential is part of the code's effective authority. Hiding it from the chat interface does not remove that access.

Choose runtime controls deliberately

Kubernetes Pod Security Standards define baseline and restricted policy requirements for workloads. Use the policies supported by your platform, and assess stronger runtime or node separation when the code's trust level requires it.

Inspect storage mounts and host access as carefully as process settings. A read-only dataset mount has a different risk from a writable shared workspace. Test network policy against the actual networking implementation, including DNS and intended service destinations. An untested policy file is not evidence that egress is constrained.

For evaluation environments, reset writable state between independent attempts. Otherwise a file, cached answer, or remembered permission from one case can influence another. Preserve state only when persistence is part of the scenario being tested.

Understand what Polyaxon's sandbox provides

The Polyaxon sandbox plugin exposes process, filesystem, and PTY access inside the main container of a running service. It uses that service's image, user, mounts, connections, and network configuration. Enabling the plugin does not create a separate isolation boundary.

This minimal development service enables interactive access:

kind: component
version: 1.1
name: sandbox-dev
plugins:
  sandbox: true
run:
  kind: service
  container:
    image: python:3.11
    command: [sh, -lc, "mkdir -p /workspace && exec sleep infinity"]

It is a starting point for a trusted development workspace. Add the image pinning, scheduling, storage, identity, and isolation settings appropriate to your deployment before using it for other trust levels. The sandbox quick start explains how to launch and connect to the service.

Treat GPU allocation and lifetime as part of the design

A GPU-backed development service can hold capacity while the user is idle. Decide how sessions stop, what inactivity means, and how work is saved before choosing a default GPU allocation.

Use sandbox resources and GPUs to select an appropriate resource configuration. If the cluster exposes shared GPUs or MIG instances, document that contract for users; “one GPU” can mean different things under different sharing modes. See MIG versus time-slicing.

Keep durable results in managed artifacts or approved persistent storage. A process surviving an SSH disconnect does not guarantee that its files survive a service restart, node replacement, or volume deletion.

Verify the contract with a small task

Before expanding usage, run a representative task and check its permitted files, reachable services, resource limits, stop behavior, and exported outputs. For agent security tests, use synthetic data and independently recorded tool actions.

The agent red teaming guide provides cases for permissions, memory, and handoffs. Follow the sandboxes learning path for interactive workflows, then move repeatable execution into tracked jobs or pipelines when exploration becomes a routine process.