AI Agent Sandbox Isolation Boundary Checklist for Security Reviews

An AI agent sandbox isolation review should verify the execution boundary, filesystem exposure, process and resource controls, network and DNS policy, package-fetch behavior, secrets handling, logs, artifact capture, reset semantics, human approval points, and incident assumptions before generated code is allowed to run against real systems or data.

Why AI Agent Isolation Reviews Matter

Traditional sandbox reviews often start with one question: can this system run untrusted code without exposing the host? AI agent reviews need that question, but they also need a wider checklist because agents do more than execute a single script. They may clone repositories, install packages, browse sites, write files, call APIs, open GUI sessions, retry failed commands, and turn model output into shell actions.

That changes the risk model. A coding agent can behave like a junior engineer with terminal access. A data-analysis agent can behave like a notebook user who uploads files, fetches packages, and exports charts. A browser agent can behave like a user with cookies, downloads, screenshots, and form-fill actions. A reinforcement-learning or evaluation agent can run the same task thousands of times, which makes small egress, resource, or logging gaps matter at scale.

Use the checklist below to review the boundary before connecting a sandbox to sensitive repositories, customer data, internal APIs, privileged credentials, or production deployment systems.

Execution Boundary Security

Start with the boundary that separates the agent workload from the host and from other tenants. The review should be explicit enough that a security engineer can describe what fails if the agent runs hostile code.

Check:

• What isolation layer is used: container, microVM, full VM, gVisor-like syscall mediation, Kubernetes sandboxing, or another model?
• Does each sandbox get its own kernel boundary, or does it share the host kernel?
• Are CPU, memory, filesystem, process table, network stack, and device access separated from other workloads?
• Can the sandbox access container runtime sockets, host process namespaces, host paths, cloud metadata services, or privileged devices?
• How are browser sessions, GUI desktops, VNC streams, and code interpreters placed inside the same boundary?
• What is the documented host-escape assumption: containment, risk reduction, or a stronger guarantee?

Avoid accepting a generic “secure sandbox” statement as the whole answer. Ask for the concrete isolation mechanism, what is inside the boundary, what is outside it, and which assumptions still need compensating controls.

Filesystem and Mount Security

Agent filesystems deserve a separate review because agents often create, edit, and exfiltrate files as part of normal work. The risky part is not only read/write access; it is accidental carryover between tasks and implicit access to project files that the user did not intend to share.

Check:

• Is the default filesystem empty, template-based, or preloaded with project files?
• Which paths are writable by the agent, and which are read-only?
• Are host directories, repository mounts, SSH keys, package caches, browser profiles, or cloud config files mounted into the sandbox?
• Can the agent traverse symlinks or bind mounts into unintended paths?
• Is file access scoped per sandbox, per user, per project, or per organization?
• Are uploaded files deleted, retained, snapshotted, or made available to later sessions?
• Are generated files and diffs reviewable before they leave the sandbox?

For coding agents, the safest pattern is usually a narrow project workspace, explicit artifact export, and no ambient access to developer home directories or shared credential stores.

Process and Resource Controls

An agent can create a fork bomb by accident, hang a build, fill a disk, run a background server, or keep retrying an expensive command. Resource controls turn those failures into bounded failures.

Check:

• Are CPU, memory, disk, file descriptor, process count, and runtime limits enforced?
• Is there a maximum wall-clock duration for commands and sessions?
• Can background processes survive after a command finishes?
• Are child processes killed when the sandbox is stopped or reset?
• Can the agent open listening ports, and if so, are those ports exposed only through an explicit preview mechanism?
• Are large stdout/stderr logs truncated, streamed, or stored?
• Are quota failures visible to the caller rather than silently retried?

For production agent workflows, limits should be part of the API contract, not only a billing concept. The security team should know what happens when an agent reaches a limit and whether the failure leaves partial state behind.

Network and Egress Controls

Network policy is where many sandbox reviews become too vague. Some agent workloads need internet access; others should not have it by default. The right answer depends on whether the sandbox is running tests, browsing public pages, fetching packages, calling internal APIs, or processing sensitive data.

Check:

• Is outbound internet access enabled by default?
• Can network access be disabled per sandbox, per template, or per project?
• Are egress allowlists available for domains, IP ranges, ports, or protocols?
• Is access to cloud metadata endpoints blocked?
• Can the sandbox reach private VPCs, internal services, databases, or deployment systems?
• Are browser traffic, CLI traffic, package manager traffic, and direct socket connections governed by the same policy?
• Are outbound requests logged with timestamp, destination, process or command context, and response status?

Treat agent egress like build-system egress. If the agent can install packages, upload artifacts, call webhooks, or browse arbitrary sites, the review should cover both malicious code and prompt-injection-driven behavior.

DNS and Package Access Risks

DNS and package managers are easy to overlook because they feel like infrastructure plumbing. For agents, they are part of the execution surface. A generated script can encode data in DNS queries, fetch a typosquatted package, or pull a script from a URL that was never reviewed.

Check:

• Does DNS traffic follow the same egress policy as HTTP and HTTPS?
• Are DNS queries logged, filtered, or forced through controlled resolvers?
• Can package managers reach public registries by default?
• Are package registries allowlisted, proxied, cached, or pinned?
• Are installed package names, versions, URLs, hashes, and lockfile changes captured?
• Can the agent run install scripts, postinstall hooks, or arbitrary package build steps?
• Is there a review gate before new dependencies are persisted into a template or production workflow?

If package access is required, prefer pinned versions, lockfiles, registry allowlists, and logs that let reviewers reconstruct what was downloaded and executed.

Secrets Handling

Secrets are usually the fastest way for a sandbox boundary to become irrelevant. If an agent sees a broad token, it can leak data without escaping the host.

Check:

• Are secrets injected only when a task explicitly needs them?
• Are secrets scoped to the sandbox, task, repository, environment, and lifetime?
• Can secrets be read from environment variables, files, shell history, process lists, logs, screenshots, or browser storage?
• Are logs and artifacts redacted before storage or export?
• Are short-lived tokens used instead of long-lived credentials?
• Can the agent access user-level SSH keys, Git credentials, cloud credentials, browser cookies, or API keys from the host?
• Is secret access visible in audit logs?

A practical rule: if a human would not paste a credential into an untrusted build job, do not give it to an autonomous agent without narrower scope and stronger logging.

Logs and Audit Trails

Security teams need more than success or failure. They need to know what code ran, what files changed, what network calls happened, and what outputs were produced.

Check:

• Are command invocations logged with arguments, working directory, exit code, start time, and duration?
• Are file reads, writes, deletes, uploads, downloads, and permission changes recorded?
• Are package installs and external fetches logged?
• Are browser actions, screenshots, downloads, and form submissions captured where relevant?
• Are API calls, tool invocations, and model-to-tool transitions correlated to the same session?
• Are logs tamper-resistant from inside the sandbox?
• What is the retention period, and who can access logs?

For regulated or enterprise workflows, the audit trail should support both debugging and post-incident reconstruction. A partial terminal transcript is usually not enough.

Artifact Capture and Review

Agents create useful output: diffs, test results, reports, screenshots, generated files, preview URLs, and datasets. Artifact handling should make those outputs reviewable without exposing more state than needed.

Check:

• Which artifacts are exported automatically, and which require explicit selection?
• Can reviewers inspect generated files before they are committed, uploaded, or sent to another service?
• Are artifacts scanned for secrets, malware, unsafe file types, or unexpected size?
• Are browser downloads stored separately from source-code diffs and test outputs?
• Can artifacts be linked back to the exact command, agent step, and sandbox session that produced them?
• Are artifacts retained after sandbox deletion, and can they be purged?

The goal is to preserve useful evidence while avoiding a second data-leak channel through logs, screenshots, archives, or generated bundles.

Lifecycle and Reset Controls

Agent sessions can be short-lived, long-running, paused, resumed, snapshotted, or cloned from templates. Each lifecycle mode changes the boundary.

Check:

• Is each sandbox created fresh, resumed from state, or cloned from a template?
• What data survives pause, resume, snapshot, template creation, and deletion?
• Are temporary files, package caches, shell history, browser cookies, and local databases cleared on reset?
• Can a compromised session poison a reusable template?
• Is there a maximum session lifetime?
• Are stopped sandboxes truly terminated, or can background tasks continue?
• Can the same task be reproduced from a clean environment?

Resetability matters for evaluation and reinforcement-learning workloads too. If each trial begins from slightly different state, security findings and model behavior become harder to trust.

Human Approval Controls

Human approval is not only a UX feature. It is a control plane for actions that cross trust boundaries.

Check:

• Which actions can run autonomously, and which require approval?
• Are approval prompts specific enough to show command, files, destination, credential scope, and expected effect?
• Can policies require approval for package installs, external network access, repository writes, deployment commands, or secret access?
• Are approvals logged with user, timestamp, action, and resulting command?
• Can approvals be time-bound and task-bound instead of granting broad future permission?
• Is there a break-glass path, and is it audited?

Use human approval for irreversible or high-impact actions: deleting files, writing to production branches, calling deployment APIs, accessing customer data, and changing sandbox templates.

Incident Response Assumptions

No sandbox review is complete without asking what happens when a boundary fails or a workflow behaves unexpectedly. This is especially important for agent systems because a risky action may be caused by model output, prompt injection, dependency compromise, or ordinary software bugs.

Check:

• Who owns triage when a sandbox is suspected of leaking data or running hostile code?
• Can sandboxes be killed, quarantined, or blocked by project or organization?
• Can network egress be disabled quickly?
• Are logs and artifacts preserved for investigation?
• Are affected templates, package caches, and snapshots invalidated?
• Are credentials rotated automatically or through a documented runbook?
• Is there a clear distinction between a sandbox containment issue and an agent-policy issue?

The review should end with a written threat model and a short runbook. Even if the final decision is “approved for non-sensitive workloads only,” that boundary is useful.

How Novita Agent Sandbox Fits

Novita Agent Sandbox is designed for AI-generated code, browser workflows, computer use, evaluations, reinforcement-learning environments, and long-running tasks. The product page describes isolated sandboxes, sub-second startup, persistent sessions, VNC-based live session viewing, usage-based pricing, templates, and isolated filesystem support. The Novita Agent Sandbox quickstart shows SDK-based sandbox creation, command execution, file listing, and sandbox shutdown.

Those capabilities can support many of the workflows in this checklist, but evaluation criteria and product claims should stay separate. When your team reviews Novita Agent Sandbox, or any other agent runtime, map the live configuration you plan to use against the controls above: boundary, files, process limits, network, DNS, package fetches, secrets, logs, artifacts, lifecycle, approval, and incident response.

For engineering teams already using Novita AI model APIs, pairing model inference with sandbox execution can reduce platform sprawl for agent workloads. For security-sensitive production use, still run a workload-specific review before connecting the sandbox to private repositories, sensitive datasets, internal services, or deployment credentials.

Conclusion

Approve an AI agent sandbox only after the review can answer three questions clearly: what is isolated, what can still leave the boundary, and what evidence remains if something goes wrong. If those answers are vague, limit the sandbox to non-sensitive workloads until the missing controls are documented and tested.

FAQ

What should a security team verify first in an AI agent sandbox review?

Start with the execution boundary, filesystem exposure, and network defaults. Those three controls determine whether hostile code can reach the host, sensitive files, or external destinations before you even get to workflow-specific details like approvals and artifact export.

Is a container-only sandbox enough for autonomous coding agents?

It depends on the workload and the data it can reach. A container may be acceptable for low-sensitivity tasks with tight mounts, strict egress policy, short-lived credentials, and strong logging, but security teams should make that decision from documented controls rather than from the word “container” alone.

Why should DNS and package access be reviewed separately from general egress?

Because agents often install dependencies and resolve external hosts as part of normal operation. DNS queries and package fetches can become both a data-exfiltration path and a supply-chain risk if they are not logged, filtered, or restricted.

Recommended articles:

• How Agent Sandboxes Power Secure, Scalable AI Innovation
• Building a Coding Agent with Novita’s Agent Sandbox
• Novita vs E2B: The Ultimate Agent Sandbox Comparison for Developers and Businesses