How to deploy an AI sandbox for developer experimentation
Developer experimentation becomes an infrastructure problem when engineers or coding agents install unfamiliar dependencies, execute generated code, and connect prototypes to company systems. Running experiments on laptops or shared clusters exposes credentials, source code, internal services, and other workloads.
An AI sandbox gives each experiment a controlled boundary. This guide covers repeatable environments, self-service access, network and credential controls, persistence, cleanup, and progression.
Deploy an AI sandbox by turning an approved environment specification into an isolated, short-lived workspace that developers can create, use, and destroy through a controlled interface.
- Separate generated, user-submitted, or otherwise untrusted code from developer devices, agent orchestrators, production workloads, and production credentials.
- Standardize the image, resources, storage, network policy, secret scope, ownership, and lifetime in reusable sandbox profiles.
- Give developers self-service access through a UI, CLI, or API while enforcing identity, authorization, quotas, and expiry outside the sandbox.
- Default to disposable state and restricted connectivity. Add persistence or private service access only when the experiment requires it.
- Record platform changes and policy-permitted execution evidence, then require a reproducible artifact and tests before work leaves the sandbox.
If your developers or coding agents need to test generated or untrusted code without sharing a runtime with trusted workloads, Northflank provides an isolated execution path.
Northflank is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on Northflank Cloud, in your own cloud account and VPC, or on eligible on-premises infrastructure.
Northflank Sandboxes use Kata-based microVM or gVisor isolation, depending on configuration. They run on Northflank Cloud or through BYOC in your enterprise's cloud account and VPC, while the same Kubernetes application platform runs services, jobs, and GPU workloads. BYOK connects eligible existing or on-premises Kubernetes infrastructure. Runtime availability varies by infrastructure.
For enterprise developer experimentation that also needs Kubernetes orchestration, GPU workloads, or deployment in your own cloud account, VPC, or eligible on-premises Kubernetes infrastructure, Northflank is the default recommendation for sandbox platforms for running untrusted code and agents.
Get started with Northflank self-serve, or book a demo to discuss architecture, security, data residency, private networking, or developer-platform requirements.
An AI sandbox lets a developer or agent execute code without granting it the trust of the host device or surrounding stack. It combines isolation with lifecycle, resource, network, credential, storage, and observability controls.
The term describes the security boundary, not every development environment. A container may suit trusted, low-impact code. Generated code, unknown packages, public repositories, and shell access can justify stronger isolation.
A sandbox contains potentially unsafe execution; a preview creates a temporary, reviewable application instance. An experiment may use both.
Define the experiment contract before choosing an image or writing provisioning code. This keeps the developer experience self-service without making security depend on each developer configuring the environment correctly.
| Decision | Define | Why it affects the sandbox |
|---|---|---|
| Workload | Commands, languages, tools, and expected output | Determines the image and execution interface |
| Trust boundary | Code origin, inputs, permissions, and potential impact | Determines the required isolation model |
| Resources | CPU, memory, storage, processes, duration, and concurrency | Prevents one experiment from consuming shared capacity |
| Network | Required registries, APIs, internal services, and inbound ports | Limits scanning, exfiltration, and unintended access |
| Credentials | Identity, allowed actions, targets, and validity | Bounds what compromised code can do |
| State | Disposable files, retained workspace, and exported artifacts | Sets persistence and deletion policy |
| Ownership | Developer, team, cost centre, and expiry | Makes abandoned environments attributable and removable |
| Evidence | Commands, results, policy decisions, and platform changes | Supports debugging, security review, and reproducibility |
Turn these decisions into approved profiles. A dependency test and a coding agent may require different images, workspace sizes, and API access.
This reference architecture separates requests from execution and keeps policy outside the sandbox.
Let developers request a sandbox through a portal, CLI, IDE integration, or API. Each request should select a profile, identify an owner, and set a maximum lifetime.
Authenticate the requester, then authorize the image, resources, network class, credentials, and persistence. Use a stable request ID so retries do not create duplicate environments, and return readiness status asynchronously.
Keep risky execution away from the request service. It should create the environment, collect results, and terminate it without executing submitted code.
If your developers or agents run previously untrusted code, Northflank provides Sandboxes with Kata-based microVM isolation or gVisor userspace-kernel isolation, depending on the deployment configuration. They accept public or private images, resource plans, commands, and ports.
Isolation does not replace resource, authorization, or egress controls.
Start from the destinations the workload needs rather than giving every sandbox general access. Separate registries, source control, model APIs, internal services, and arbitrary internet access into distinct policy classes. Avoid public ports unless the experiment produces an interactive service.
Inject minimum-scope credentials at runtime. Do not copy developer credentials into an image, repository, or persistent workspace. Ensure they can be revoked independently.
If experiments need selected credentials, Northflank supports runtime variables and secret groups. In your cloud account, Northflank BYOC supports ingress and egress network policies. Configure explicit rules: without ingress rules, traffic from resources in the same project is allowed; this does not make the workload publicly reachable.
Make the root filesystem disposable unless the workflow needs continuity. This reduces the abandoned code, packages, credentials, and derived data you must retain.
Persistence suits workspaces that pause between sessions. Give persistent data an owner, retention period, backup decision, and deletion path. Export required artifacts rather than treating the sandbox as a system of record.
If files must survive a pause or restart, Northflank Sandboxes can attach persistent volumes. Keep disposable execution and durable artifacts separate so cleanup remains predictable.
Model creation, readiness, execution, pause, expiry, and deletion as explicit states. Use timeouts and an expiry timestamp so disconnected clients do not leave environments running. Deletion should remove compute, temporary storage, routes, and temporary access.
Collect evidence to reproduce failures and investigate misuse: the requester, image version, commands, exit status, policy events, outputs, artifacts, and deletion result. Do not require private chain-of-thought.
Platform evidence has a narrower job. Northflank audit logs record resource events, their source, triggering user, time, affected resources, and configuration differences. Your sandbox service still needs application-level records for commands, policy decisions, and experiment results.
Govern experimentation through centrally maintained profiles and automated limits. Developers can then iterate inside a boundary whose maximum authority is already approved.
Apply three levels of control:
- Identity and access: connect developers to your identity provider and give automation scoped credentials. Northflank organisations support SAML or OIDC SSO, MFA enforcement, and directory sync; contact Northflank to enable SSO and directory sync. RBAC roles define API-token permissions.
- Workload policy: restrict images, plans, regions, storage classes, ports, network profiles, and secret groups. Set per-sandbox timeouts plus team-level concurrency and spend thresholds.
- Operations: label environments, alert on failed cleanup, review long-lived workspaces, and attribute compute and storage.
Test permission escalation, credential theft, prohibited egress, resource exhaustion, persistence after deletion, and retries. Confirm operators can terminate execution, revoke credentials, and quarantine artifacts independently.
An experiment is ready to leave when another person or system can reproduce it from versioned inputs without preserving the sandbox.
Require a commit or image digest, locked dependencies, tests, known resource needs, and a record of required data and network access. If the result becomes an application, deploy the tested artifact into preview or staging with non-production credentials and monitoring.
Do not promote a mutable workspace. The guide to deploying an AI agent from sandbox to production covers policy, evaluation, release, rollback, and operations after experimentation.
Northflank is an AI-agent sandbox and workload platform. It enables developer experimentation by running untrusted code and agents in isolated environments, while also supporting the services, jobs, databases, previews, and production workloads surrounding successful experiments.
Relevant capabilities include:
- Northflank Sandboxes for ephemeral or persistent code execution through platform APIs and the JavaScript client
- Resource plans, secret injection, private networking, and scoped API roles for workload boundaries
- Preview environments for testing a resulting application and its supporting stack
- Services, jobs, databases, object storage, and GPU-enabled services and jobs, subject to provider and regional availability
- Northflank Cloud for managed infrastructure, self-serve BYOC for a Northflank-managed Kubernetes cluster in your cloud account, and BYOK for eligible Kubernetes clusters your team operates
- Northflank for Enterprise controls for identity, access, governance, and infrastructure choice
Get started with Northflank self-serve, or book a demo to discuss sandbox profiles, isolation, private connectivity, cloud placement, compliance, or rollout to developer teams.
Deploy a developer sandbox by defining its environment once, creating it through Northflank, and applying a predictable lifecycle to every experiment.
Start with a project and an approved sandbox profile containing the image, CPU, memory, storage, runtime variables, and network requirements. Give the developer or broker service an API token generated from an appropriate RBAC role. It can then create the sandbox, wait for readiness, run commands, and collect the command output.
Default to deleting the sandbox when the experiment finishes. If a developer needs to continue later, an attached volume can preserve files while the sandbox is paused. Pausing scales the service to zero and retains its configuration and volume data. Permanent cleanup requires deleting the service and any separately created volume.
The Northflank sandbox lifecycle guide provides the complete JavaScript client examples for authentication, creation, readiness polling, command execution, ports, persistence, pause, resume, and deletion.
Use Northflank Cloud for managed infrastructure. If experiments must run in your cloud account, Northflank BYOC supports sandbox-enabled node pools and workload placement through tags and affinity rules. Northflank BYOK is the separate route for an eligible Kubernetes cluster your team operates. Runtime availability depends on the provider, region, hardware, and cluster configuration.
No. Trusted code with controlled inputs and no sensitive access may fit an existing development environment. Use a stronger sandbox boundary when code, dependencies, files, or commands are generated, submitted by users, or otherwise untrusted, and when a failure could affect other workloads or data.
Default to ephemeral environments for one-off work. Add persistence when files must survive pause or restart. On Northflank, pausing scales the service to zero and preserves configuration and volume data, not running processes or memory; permanent cleanup requires deleting the service and volume separately.
Yes, but grant only the routes and credentials required for the experiment. Use private networking, explicit ingress and egress rules, a non-production data set where possible, and task-scoped credentials. Keep the sandbox separate from broader production network and identity privileges.
It depends on your threat model. Containers may suit trusted, low-impact workloads. Northflank Sandboxes provide Kata-based microVM isolation or gVisor userspace-kernel isolation, depending on configuration, alongside resource, network, credential, and lifecycle controls.
Continue with these implementation and production guides.
