AI-agent sandbox security checklist: What enterprises should evaluate
An AI agent can install packages, read files, call APIs, and change infrastructure. If its sandbox inherits broad access, a manipulated instruction can become an incident.
A sandbox limits that blast radius, but isolation is only one part of the decision. This checklist covers the runtime boundary, identity, secrets, networking, data, supply chain, lifecycle, evidence, testing, and containment controls your enterprise should evaluate.
Enterprises should evaluate an AI-agent sandbox as a complete execution boundary, not accept “isolated” as a sufficient security claim.
- Define the code, inputs, tools, data, and destinations you do not trust, then identify every system the sandbox shares with other workloads.
- Match runtime isolation to the threat model and verify the boundary with architecture evidence and escape testing.
- Give each run a scoped identity, short-lived credentials, restricted egress, and limits on compute, storage, duration, and concurrency.
- Require traceable lifecycle operations, reliable deletion, platform audit evidence, application-level agent telemetry, and independent containment controls.
- Test prompt injection, privilege escalation, cross-tenant access, exfiltration, persistence, approval bypass, and sandbox escape before granting production authority.
If your enterprise needs agents to execute generated or untrusted code without sharing the orchestrator's trust boundary, Northflank provides API-driven Sandboxes with microVM or gVisor isolation, optional persistence, and lifecycle controls. Enterprise teams can use SSO, RBAC, scoped API roles, secret injection, private networking, and audit logs to govern platform access around each run.
Run workloads on Northflank Cloud, or use self-serve BYOC when execution needs to run in your cloud account with its network, regional, and infrastructure controls. Compatible coding agents can use Northflank Skills to operate sandboxes and services within their assigned permissions.
Get started with Northflank self-serve, or book a demo to discuss architecture, security, compliance, data residency, or migration requirements.
An enterprise sandbox should contain the effects of untrusted execution even when the model, generated code, dependency, file, webpage, or tool response behaves maliciously.
Map the sandbox host and kernel, orchestration service, credentials, mounted files, persistent state, network routes, internal APIs, telemetry, and cleanup path. A compromise becomes serious when it can cross into another tenant, the control plane, company data, or production.
This is why sandboxing cannot replace authorization or policy enforcement. OWASP's excessive-agency guidance recommends limiting agent functionality, permissions, and autonomy, with independent authorization for high-impact actions. The sandbox should enforce the result of those decisions, not let the model decide its own limits.
Use the table to screen each platform.
| Check | Evidence to request | Rejection signal |
|---|---|---|
| Trust boundary | Data-flow and shared-resource architecture | The provider cannot explain what the guest shares |
| Isolation | Runtime design and escape-test results | “Containerized” is the complete isolation answer |
| Identity | Per-run identity and authorization model | Runs inherit developer or administrator access |
| Secrets | Issuance, scope, expiry, and revocation flow | Long-lived credentials are embedded in images |
| Networking | Ingress and egress policy with deny behavior | Arbitrary outbound or private-network access |
| State | Ownership, encryption, retention, and deletion | Persistent data survives without an accountable owner |
| Supply chain | Image provenance and dependency controls | Mutable, untracked images reach execution |
| Resources and lifecycle | Quotas, leases, retries, and cleanup evidence | Termination leaves processes, routes, or credentials active |
| Auditability | Correlated platform and agent events | Operators cannot reconstruct a consequential action |
| Containment | Live-run kill, revoke, block, and quarantine tests | Stopping the model is the only incident control |
Test each control before production approval.
Name hostile inputs and protected systems.
Include generated commands, user uploads, repositories, package scripts, retrieved content, tool responses, and stored memory. Identify whether sandboxes share a host, kernel, cluster, network, cache, volume system, or privileged service.
Test what code inside the sandbox can reach and what a compromised platform credential can change. Produce a data-flow diagram and assumptions your red team can challenge.
Choose the isolation boundary based on code trust, tenancy, accessible data, and potential impact.
A conventional container may suit controlled, single-tenant automation with trusted code and restrictive privileges. User-submitted or model-generated code, unknown dependencies, and multi-tenant execution can justify a separate-kernel boundary such as a microVM. Ask whether the guest has its own kernel, how host devices and filesystems are exposed, which privileges are removed, how the host and sandbox runtime are patched, whether running sandboxes must restart, and how base images are rebuilt and redeployed.
Do not accept architecture labels as proof. Run applicable escape, malformed syscall, mount, host-discovery, metadata, and cross-sandbox tests. For GPU sandboxes, also request evidence about side channels, noisy-neighbour behavior, and hardware-device passthrough.
If untrusted execution requires a separate boundary, Northflank sandboxes support microVM-backed isolation; GPU workloads on Northflank Cloud use gVisor isolation by default. Unlike a microVM, gVisor interposes a user-space application kernel between the workload and host. For the broader platform decision, compare the requirements for running AI-generated code securely at scale.
Every run should have an attributable initiator and a narrower execution identity.
Do not forward a developer session or shared administrator token. Authorize the operation using the initiator, agent, policy version, target, parameters, and time window. Moving to production should create a new authorization decision.
If sandbox access must follow enterprise identity policy, Northflank Enterprise supports SAML or OIDC SSO, directory sync, and MFA enforcement. RBAC and scoped API roles can limit platform actions by project and permission. Application authorization remains your responsibility.
Start a sandbox without ambient credentials and add only the access its approved task requires.
Prefer short-lived credentials bound to one service, action, environment, and duration. Keep production secrets out of evaluation runs. Revoke a credential during execution and measure whether copied tokens, child processes, cached credentials, or established sessions remain usable. Define an acceptable revocation window.
For selected runtime values, Northflank secret groups inject secrets into specific workloads. The receiving service must still authorize each business operation.
Begin with no public inbound route and default-deny workload ingress and egress, permitting documented control-plane paths and task-required destinations.
Allow required source hosts, registries, model endpoints, and internal APIs explicitly. Keep metadata endpoints, cluster APIs, credential services, production databases, and unrelated networks unreachable. Where destination controls are insufficient, use a gateway that validates the operation and payload.
If the execution fleet runs in your cloud account, Northflank BYOC network policies can restrict traffic by workload, project, IP or CIDR, FQDN, and hostname. Configure the rules deliberately: without a rule in a direction, traffic is allowed. The guide to networking for secure AI-agent sandboxes covers the wider egress design.
Treat state as a separate security boundary from compute.
An ephemeral runtime can still write logs, caches, artifacts, or external memory. For every persistent store, define ownership, allowed data, encryption, access, retention, and deletion. Prevent a run from attaching another user's volume or retrieving unvalidated memory.
When a workspace must survive a pause or restart, Northflank sandboxes support persistent volumes. Your retention and authorization design should reflect the difference between persistent and ephemeral AI sandboxes.
The sandbox runtime, host integration, image bootstrap components, and deployment pipeline form part of the trusted computing base. Treat packages and tools installed inside the sandbox as potentially hostile inputs unless explicitly trusted.
Require approved base images, build provenance, signature or attestation verification at admission, digest pinning where practical, controlled registries, patch ownership, and scanning. Apply policy to packages, plugins, MCP servers, tool definitions, and updates.
Test the control with a malicious package, dependency confusion attempt, altered image tag, and hostile tool response. Scanning does not prove runtime behavior is safe.
Put hard limits on both an individual sandbox and the tenant that can create it.
Set CPU, memory, process, storage, output, network, duration, idle, and concurrency limits. Use leases and make lifecycle operations retry-safe. Deletion should remove compute, routes, temporary credentials, and ephemeral data while retained volumes follow a separate policy.
Northflank exposes sandbox lifecycle operations for creation, status, commands, pause, resume, and deletion. Test those operations during load and partial infrastructure failure, not only in a clean demonstration.
Record enough evidence to reconstruct why a run was allowed, what it affected, and how it ended.
Correlate the initiator, agent and policy version, artifact, environment, policy decision, credentials, tool activity, approvals, affected resources, and termination reason. Capture inputs and outputs only where policy permits. Do not require private chain-of-thought.
Keep application-level agent traces separate from platform events. Northflank audit logs record the identity, source, time, parent events, and affected platform resources for supported changes. Your application must trace model, tool, and business-data activity. See how the layers fit together when you govern AI-agent code execution.
Security approval should depend on demonstrated failure behavior.
Test prompt injection, tool confusion, malformed arguments, permission escalation, malicious dependencies and tool responses, memory poisoning, cross-tenant access, exfiltration, resource exhaustion, replay, approval bypass, persistence, and sandbox escape.
During a live test, terminate the runtime, revoke its credentials, block its network paths, disable the relevant tool or policy, quarantine retained state, preserve evidence, and prevent another run. These controls must work independently of the agent and any system it can manipulate.
Block production adoption when a provider or internal platform cannot make its security boundary testable.
Warning signs include an unexplained “isolated container” claim, shared human credentials, unrestricted egress, privileged host mounts, unowned persistent state, deletion without observable cleanup, platform logs that cannot correlate with agent activity, or a kill switch that only stops the model request. Also pause adoption when the team cannot identify where workload data, control-plane metadata, and telemetry travel.
A missing feature is not always disqualifying. An unacknowledged boundary is. Record compensating controls, owners, and expiry evidence.
Northflank provides an additional isolation boundary for untrusted execution alongside the platform controls needed to run agents beside APIs, workers, jobs, databases, and release workflows.
- Northflank sandboxes provide microVM-backed isolation for untrusted execution, while GPU workloads on Northflank Cloud use gVisor by default. Sandboxes support ephemeral roots or attached persistent storage.
- Enterprise identity controls, RBAC, and scoped API roles restrict who or what can operate platform resources.
- Secret groups control which workloads receive configured values, while deliberately configured private networking and BYOC network policies can restrict runtime connectivity.
- Audit logs provide platform-side accountability that you can correlate with application agent traces.
- The API, CLI, JavaScript client, and Northflank Skills let approved automation operate the lifecycle through assigned permissions.
Use Northflank Cloud when you want managed infrastructure. With self-serve Northflank BYOC, workloads run in your cloud environment and you own the cloud account and infrastructure while Northflank manages platform orchestration. Available sandbox runtimes depend on provider and region, and Northflank-hosted control-plane metadata remains outside the workload-data boundary.
Northflank is SOC 2 Type 2 compliant and HIPAA compliant, with BAAs supported under Enterprise contracts.
Get started with Northflank self-serve, or book a demo to discuss sandbox architecture, isolation, networking, data boundaries, and compliance requirements.
These answers address common enterprise sandbox decisions.
It depends on the threat model. A container may suit trusted, single-tenant automation with restricted inputs and privileges. Generated code, hostile inputs, unknown dependencies, or multi-tenant workloads may justify stronger isolation such as a separate-kernel microVM.
Not on its own. A microVM strengthens the runtime boundary, but the agent still needs scoped identity, secrets, network and data policy, resource limits, audit evidence, supply-chain controls, and independent containment.
Not necessarily. BYOC can place workload runtime and workload data in your cloud environment, but you must verify which control-plane metadata, logs, support data, and external service traffic cross that boundary. Northflank BYOC keeps workloads in your cloud while Northflank-hosted control-plane metadata remains outside that workload boundary.
Test prompt injection, malicious inputs and dependencies, permission escalation, cross-tenant access, disallowed egress, exfiltration, resource exhaustion, approval bypass, replay, persistence, sandbox escape, and the complete containment procedure. Grant more authority only after the platform passes tests shaped like your production workload.
Use these guides to extend the checklist into architecture, data access, networking, lifecycle, and enterprise operations.
