Running AI-generated code in production without proper isolation is like giving an unknown contractor the keys to your entire office building. As coding agents, LLM-powered assistants, and autonomous AI systems become standard development tools, the code they generate needs execution environments that prevent malicious or buggy outputs from compromising your infrastructure. AI sandbox platforms provide isolated execution environments designed to contain untrusted code, limiting its ability to access host systems, sensitive data, or other workloads, even when that code behaves unexpectedly. In production, that isolation also has to hold up at high concurrency, size CPU and memory efficiently for code whose resource needs no one can predict, and start sandboxes consistently under load.
Key Takeaways
Understanding the Risks: Why Untrusted Code Needs Sandboxing
When AI systems generate code, you're executing instructions written by a model that learned from vast datasets including potentially malicious examples. Unlike human-written code that goes through review processes, AI-generated code often executes immediately, creating a direct path from model output to system access.
The threat vectors are concrete:
These risks are not theoretical. In early 2026, PromptArmor disclosed a vulnerability in Snowflake's Cortex Code CLI (coordinated public disclosure March 16, 2026; fix shipped in version 1.0.25 on February 28, 2026). The incident demonstrated how indirect prompt injection combined with weak command validation allowed AI-generated instructions to bypass human-in-the-loop approval and escape the CLI's sandbox mode, enabling arbitrary code execution and unauthorized access to cached credentials. Separately, CVE-2024-21626, the "Leaky Vessels" runc vulnerability, showed how a file descriptor leak in the container runtime could enable container escape and host filesystem access. Together, these incidents illustrate that both AI agent frameworks and underlying container runtimes present exploitable attack surfaces. Without proper sandboxing, every AI code execution becomes a potential security incident.
What is an AI Sandbox? Redefining Secure Execution for ML Workloads
An AI sandbox is an isolated execution environment specifically designed to run code generated by AI systems without risking production infrastructure. Unlike traditional sandboxes built for testing, AI sandboxes must handle unpredictable outputs from language models that might generate anything from harmless scripts to sophisticated exploitation attempts.
These environments operate on a simple principle: assume all AI-generated code is potentially hostile, and constrain its capabilities accordingly.
The Role of Isolation Technologies (gVisor, VMs, Containers)
Different isolation technologies offer varying security-performance tradeoffs:
Standard Containers (Docker): Share the host kernel, providing namespace isolation but leaving kernel vulnerabilities exposed. As NIST SP 800-190 notes, containers involve OS-level virtualization where multiple applications share a host kernel. Container escapes remain possible through kernel or runtime vulnerabilities, as demonstrated by CVE-2024-21626.
gVisor: A user-space "application kernel" that intercepts system calls before they reach the host kernel. gVisor's Sentry component handles all workload syscalls and never passes any system call directly to the host; the Sentry itself is restricted to a small allowlist of roughly 68 host syscalls, significantly reducing the kernel attack surface. Overhead is highly workload-dependent: CPU-bound tasks may see modest impact, while syscall-heavy, filesystem-intensive, or network-heavy workloads can experience more substantial slowdowns, as documented in peer-reviewed benchmarking. Modal offers both gVisor sandboxes and VM sandboxes for its sandbox isolation, and its VM sandboxes support full Docker functionality.
Firecracker microVMs: Full hardware virtualization in lightweight packages, offering strong isolation with higher resource consumption than containers.
Kata Containers: Combines container orchestration with VM isolation, offering a middle ground between standard containers and full VMs by running each container inside a lightweight virtual machine while preserving the container API.
Key Characteristics of an Effective AI Sandbox
Production AI sandboxes require specific capabilities beyond basic isolation:
Overcoming Performance and Scalability Challenges with AI Sandboxes
Security isolation historically meant performance penalties that made sandboxed execution impractical for production workloads. Modern platforms have largely solved this tradeoff through infrastructure engineering.
Achieving Fast, Consistent Starts for Sandbox Environments
Cold start latency determines whether sandboxed execution feels responsive or sluggish. When an AI agent needs to run generated code, waiting several seconds for environment initialization kills user experience.
Well-designed platforms achieve fast, consistent starts through several techniques:
Modal's core platform emphasizes memory snapshotting and a custom filesystem specifically optimized for these fast-startup patterns. Its custom-built scheduler keeps sandbox starts sub-second and consistent as concurrency climbs, including with large, arbitrary custom images.
Scaling Sandboxed Execution to Massive Concurrency
Production AI applications generate thousands of code execution requests simultaneously. Each coding agent interaction, each batch job iteration, and each user request might spawn sandboxed execution.
Scaling requirements include:
Modal Sandboxes demonstrate these capabilities with support for up to 1M concurrent sandboxes. Modal has demonstrated creating 1M+ sandboxes in under a minute, exceeding 10,000 creations per second, and regularly runs tens of thousands of concurrent customer sandboxes as demand fluctuates.
Networking and Data Flow: Controlling Ingress and Egress in Sandboxes
Network access represents the highest-risk capability for untrusted code. An AI-generated script with unrestricted network access can exfiltrate data, download additional payloads, or attack external systems.
Network isolation should be the default configuration. Sandboxes start with no network access, and you explicitly enable only required connections.
Ingress controls determine how external requests reach sandboxed services. For AI sandboxes running web services, configure specific ports and protocols rather than exposing arbitrary network surfaces.
Tunneling capabilities enable controlled access when needed. Modal's sandbox networking documentation covers how to configure tunnels and port exposure for interactive processes while maintaining security boundaries.
Data flow logging tracks all network activity for audit purposes. Even when connections succeed, logging enables detection of unexpected communication patterns indicating compromise.
Observability and Auditing: Monitoring Untrusted Code Execution
You can't secure what you can't see. Comprehensive observability transforms sandbox security from reactive incident response to proactive threat detection.
Real-time logging captures stdout, stderr, and system events from every sandbox execution. Stream logs to centralized platforms for correlation and alerting.
Metrics collection tracks resource utilization patterns. Sudden spikes in CPU, memory, or network usage might indicate cryptomining, data processing, or attack activity.
Distributed tracing follows requests across sandbox boundaries. When AI-generated code calls external services or spawns additional processes, tracing maintains visibility.
Audit logs provide compliance evidence and forensic capability. Modal's Enterprise plan includes audit logs, and Modal can export audit logs to an OpenTelemetry provider alongside function logs and container metrics.
Alerting rules define thresholds for automatic notification. Configure alerts for failed executions, resource limit violations, and anomalous behavior patterns.
The Shared Responsibility Model: Your Role in Sandbox Security
Even with managed sandbox platforms handling infrastructure security, you maintain responsibility for application-level security decisions.
Your responsibilities include:
Platform responsibilities typically cover:
Modal articulates a shared responsibility model in which Modal ensures the durability of managed storage and operates the platform for high availability, while customers maintain backups of the data they store in Modal and design their applications for failover. Modal's vulnerability remediation SLAs target 24 hours for critical issues and one week for high-severity findings, measured from when a fix becomes available.
Why Modal's Sandbox is Worth Checking Out for Secure AI Code Execution
Modal is a scalable, high-performance sandbox platform for executing AI-generated code at production scale, built to run untrusted user or agent code with secure isolation at every level of concurrency.
Performance at scale: Modal has demonstrated creating 1M+ sandboxes in under a minute, exceeding 10,000 creations per second, and running over a million concurrent sandboxes. It reports running 3 billion sandboxes as of October 2026 and regularly supports tens of thousands of concurrent customer sandboxes; Quora, for example, uses Modal Sandboxes to run LLM-generated code for users of its Poe platform.
Active-resource pricing: Untrusted code is unpredictable: one execution prints a result in milliseconds, the next installs packages or loops until it hits a limit, and agents often sit idle between runs waiting on model responses. Fixed-reservation pricing, the model most Sandbox providers use, pushes teams to reserve for the heaviest run, so utilization stays low and costs run high relative to the work done. Modal's active-resourcing model lets sandboxes start from a configured CPU and memory baseline and burst above it automatically, so teams provision for typical usage instead of peak usage and face less risk of out-of-memory failures. Billing is per second on the greater of requested and actual resources.
Consistent startup under load: Modal Sandboxes deliver sub-second fast starts that stay consistent at high concurrency, including with large custom container images. The platform also provides memory snapshotting, a faster filesystem, and VM and gVisor isolation as core capabilities.
Technical foundation: Modal offers gVisor sandboxes and VM sandboxes. gVisor isolates workloads and adds custom logic to block malicious system calls: gVisor's Sentry never passes workload system calls through to the host, blocking the kernel-level exploits that standard containers leave exposed. VM sandboxes support full Docker functionality.
Developer experience: Modal provides code-first SDKs in Python, TypeScript, and Go. Sandbox environments, including large custom images with the dependencies untrusted code needs, are defined in code, and Modal Sandboxes support all programming languages.
Platform integration: Unlike standalone sandbox services, Modal integrates sandboxed execution with its broader AI infrastructure, including inference, training, and batch processing. Run inference, training, sandboxes, batch, and notebooks on the same Modal platform, with native observability and telemetry integrations.
Compliance readiness: Modal maintains SOC 2 Type II certification with no deviations found. Modal supports HIPAA-compliant workloads on Enterprise plans via a BAA for customers handling PHI. All public Modal APIs use TLS 1.3, and data is encrypted in transit and at rest. Modal supports region-pinning.
For teams evaluating sandbox platforms to run untrusted code in production, Modal pairs VM and gVisor isolation with high concurrency, active-resource billing, and consistent starts under load. Teams already running inference or training on Modal can add sandboxed execution on the same platform with minimal additional infrastructure.
Check the sandboxes documentation to explore implementation patterns.
