Isolated environments for running untrusted Python from LLMs

A coding agent ships to production on Monday. Traffic ramps through the week. By Friday, the security team flags an execution path where LLM-generated Python imported an unexpected package, opened an outbound socket, and wrote files no developer authored. The team needs a python sandbox that holds against code nobody reviewed, and the one they have doesn't. What looked manageable in development is now a production incident with a compliance trail.

LLM-generated Python doesn't behave like developer-authored Python under a security review. The code is new every request, the imports shift between invocations, and the attack surface extends to anything the model reads. For AI engineering leaders, production risk lands on infrastructure they own, with board-level scrutiny when something breaks.

Sandbox LLM-generated code, then choose a python sandbox boundary that survives a production threat model for untrusted code when the source is non-deterministic and the workload runs alongside other tenants' data.

This article walks through several isolation patterns enterprise teams actually use, the honest tradeoffs of each, and which one holds when the threat model assumes the worst.

Why LLM-generated Python is a different threat model

The security playbook for first-party application code assumes a human wrote the code, a reviewer approved it, and the behavior is deterministic across deployments. LLM-generated code breaks all three assumptions.

The same prompt can produce different imports, different syscalls, and different network behavior across invocations.

CSET's 2024 issue brief on AI-generated code found that almost half of the code snippets produced by five evaluated LLMs contained bugs that were often impactful and could potentially lead to exploitation. That matters because a security assessment that passed yesterday may not apply to the code the model generates today.

Adversarial inputs turn the LLM into an attacker proxy. NIST AI 600-1 documents that indirect prompt injection attacks occur when adversaries inject prompts into data the model retrieves, enabling "stealing proprietary data or running malicious code remotely."

The attack surface extends to every document, web page, and database record the model reads. CVE-2025-59536 proved the vector concretely: cloning an untrusted repository and running Claude Code inside it triggered arbitrary shell command execution with no further user action.

Static review fails by design. Code is generated per request and executed within seconds, outside any human-in-the-loop review cadence. Some early commentary suggests that traditional static analysis may miss important security issues in LLM-generated code because it relies heavily on syntactic patterns and cannot verify runtime behavior.

Even when static analysis is used as an active feedback loop to refine generated code, security risks can remain. The security model can't rely on knowing what the code does ahead of time. The boundary has to hold against whatever code shows up. The security decision is whether the isolation boundary survives arbitrary Python.

The isolation patterns for python sandbox environments

Each pattern below addresses the prior pattern's failure mode. Process-level isolation constrains the interpreter. Container-level isolation constrains the operating system surface. MicroVM isolation constrains the kernel. The progression moves from trusting the Python runtime, to trusting the host kernel, to trusting only the hypervisor.

Process-level isolation

Process-level isolation runs untrusted Python inside the host's own kernel, typically in a separate process with operating-system-enforced restrictions such as subprocess execution, chroot jails, or Linux namespace isolation. The host kernel runs everything. The boundary is the interpreter itself.

This pattern holds up for trusted internal scripts, deterministic developer-authored automations, and sandboxes whose inputs the team controls end-to-end. When the team wrote the code, reviewed it, and validated the inputs, process-level constraints are proportionate to the risk.

The boundary breaks under untrusted Python because CPython was never designed as a security boundary. PEP 551 states it directly: "Do not attempt to implement a sandbox within the Python runtime... The best options are to run unrestricted Python within a sandboxed environment with at least hypervisor-level isolation."

The CVE record confirms this isn't hypothetical. CVE-2026-27952 described a Python sandbox allowlist bypass in the Agenta LLMOps platform by traversing from whitelisted numpy through numpy.ma.core.inspect into sys.modules and then os.system. CVE-2026-39888 escaped PraisonAI's sandbox via __traceback__ → tb_frame → f_back → f_builtins. CVE-2026-40158 used type.__getattribute__ to bypass AST attribute filters entirely, because the call resolves to an ast.Constant node rather than the ast.Attribute node the filter checks.

The setrlimit call constrains resource quantities (CPU time, memory, file size) but doesn't constrain syscalls. The setrlimit call controls resource quantities a process is already permitted to access. It has no constant for socket creation, arbitrary file reads, or execve(). A python sandbox built on process-level isolation works for deterministic code. It doesn't survive non-deterministic Python from an LLM.

Container-level isolation

Container-level isolation runs workloads on a shared host kernel with namespace, cgroup, and capability boundaries between tenants. Docker, OCI runtimes, and gVisor (as a middle ground) fall into this pattern. Each container sees its own filesystem, process table, and network stack, but the host kernel processes every syscall from every container.

Containers have real strengths. Tooling is mature and broadly familiar. Container ecosystems handle CI, image distribution, and orchestration well. Cold start times are competitive. Teams already know how to build, ship, and monitor containerized workloads.

The honest tradeoff for untrusted code is that the boundary sits at the application layer, with the host kernel shared across workloads. NIST SP 800-190 states the core limitation directly: "The level of isolation provided by container runtimes is not as high as that provided by hypervisors."

The escape CVE record is recurring. CVE-2024-21626 ("Leaky Vessels") exploited a file descriptor leak in runc for full container escape. CVE-2025-52881 allowed an attacker to misdirect writes to /proc through racing containers with shared mounts, exploitable using a standard Dockerfile. These aren't ancient history. They represent a recurring escape pattern, with new runtime vulnerabilities still being disclosed in recent years.

gVisor narrows the syscall surface by running a user-space kernel (Sentry) that intercepts application syscalls before they reach the host. gVisor narrows exposure, but it does not turn a container into a full microVM boundary. It reduces how many application syscalls reach the host kernel, while still depending on the host OS and hardware-level defenses. Benchmarks generally find that gVisor incurs higher CPU overhead than runc, though the reported gap varies widely by workload and test methodology.

That overhead matters when sandbox calls sit inside an agent loop, because isolation that adds latency or CPU cost changes the production tradeoff rather than removing the shared-kernel risk. Containers are a reasonable python sandbox for first-party application code where the team accepts the shared-kernel risk model. For multi-tenant execution of LLM-generated code under enterprise compliance, the boundary is thinner than the threat model requires.

MicroVM isolation

MicroVM isolation runs each workload in its own kernel on a hardware-enforced boundary. Firecracker, the open-source microVM monitor, uses Linux KVM to provide hardware-assisted CPU virtualization (VT-x/AMD-V) with a minimal device model. Each Firecracker process encapsulates exactly one microVM. The design document emphasizes a strict security posture: Firecracker treats guest workloads as untrusted and seeks to contain vCPU threads with reduced privileges and a minimized attack surface.

This is the same isolation pattern AWS Lambda uses for multi-tenant code execution. AWS Lambda runs functions inside Firecracker microVMs on AWS infrastructure, providing strong isolation between executions.

The NSDI 2020 peer-reviewed paper authored by AWS engineers documented that Firecracker supported "millions of production workloads, and trillions of requests per month" at time of publication.

Strengths under a production threat model: kernel-level exploits stay contained inside the microVM. The hypervisor boundary is hardware-assisted. Multi-tenant execution becomes contractually defensible because the architecture matches how regulated cloud workloads have been isolated for over a decade. Boot-from-snapshot patterns have significantly reduced the historical cold start gap.

Firecracker can restore a microVM snapshot in as little as 4 ms under controlled conditions. Those numbers show that stronger isolation does not have to break interactive agent workflows.

The honest tradeoff is that operating microVMs across a production fleet traditionally meant managing Firecracker pools, snapshot lifecycles, kernel tuning, and observability paths the team didn't build for. The work is real. Most teams don't want to own it. Managed platforms like Blaxel's perpetual sandbox platform run each Python execution in a microVM with hardware-enforced tenant isolation, removing the work of running the microVM layer in-house.

The python sandbox pattern that holds when code originates from non-deterministic sources is the one where the isolation boundary doesn't depend on the Python runtime or the host kernel being unexploitable.

Mapping isolation choice to workload risk

The isolation boundary has to match the threat model, not the demo target. A microVM boundary for a trusted ETL script adds work without changing the risk surface. A process-level boundary for LLM-generated code leaves the blast radius unbounded. The decision is a function of who wrote the code, what data the execution touches, and whether the workload is multi-tenant.

Trusted, single-tenant developer code

Internal data science scripts, developer-authored automations, and ETL jobs fall here. The team wrote it, reviewed it, and runs it against known inputs. Process-level isolation plus resource caps is usually proportionate. Adding microVM isolation here adds work without changing the risk surface. Start with resource.setrlimit for memory and CPU caps, a restricted virtual environment, and monitoring for unexpected syscall patterns. If the team owns the code and the inputs, the trust boundary is the team itself.

First-party agent code with deterministic inputs

Production agent logic the team owns, where the executable surface is the team's own code and the inputs are validated upstream. A data pipeline agent that runs team-authored SQL against a known schema, for example. Containers are a defensible choice here. The risk surface is closer to a typical multi-tenant SaaS than to untrusted code execution.

The team should track runc and containerd security advisories and maintain a patching cadence for container runtime vulnerabilities, including container escape issues that have affected runc and the broader container runtime ecosystem.

LLM-generated code, multi-tenant, or regulated data

Coding agents, data analysis agents, and anything where the executable surface is whatever Python the model produces this request. The workload either runs alongside other tenants' workloads, touches regulated data, or both. Hardware-enforced isolation becomes the procurement-defensible choice. NIST SP 800-190 describes hardware root of trust as a way to establish trusted computing for container environments.

HHS requires physical safeguards independent of encryption for ePHI. ISO 27001 A.5.23 focuses auditor attention on clarifying cloud shared responsibilities and avoiding control gaps between the provider and the customer. Audit the data classification of every input the agent can access, then match the isolation boundary to the highest classification in the dataset.

What production python sandbox infrastructure actually requires

Raw isolation is necessary but not sufficient. Production teams need start times that match the agent interaction model, compliance posture that survives procurement review, and lifecycle controls that limit blast radius even when execution does something unexpected.

Boot times that match the agent loop

Coding agents and data analysis agents call the sandbox once per tool invocation. A multi-second cold start multiplied across multiple tool calls per agent turn breaks the interaction. Jakob Nielsen popularized the guideline that 100ms is about the ceiling for users to perceive a system as reacting instantaneously.

Production-grade microVM platforms use snapshot-based starts to bring cold creation into the few-hundred-millisecond range and warm resume into the tens of milliseconds.

Blaxel Sandboxes resume from standby in under 25ms, which keeps the python sandbox boundary in place without breaking the agent's interaction model. For teams that also need to deploy the agent itself close to that execution layer, Blaxel's Agents Hosting product supports co-location with sandboxes to eliminate network roundtrip latency between agent and sandbox.

This gives the agent loop more room for processing overhead without the user noticing infrastructure latency. For teams building coding agents or PR review agents, this margin is the difference between a responsive product and a sluggish one.

Tenant isolation with an audit trail

Procurement teams ask for compliance artifacts, not architecture diagrams. SOC 2 Type II certification, HIPAA support with a Business Associate Agreement, and ISO 27001 certification are the typical floor for enterprise contracts. No compliance framework explicitly mandates hardware VM isolation by name, but the directional pressure is clear.

NIST SP 800-190 describes hardware root of trust as a way to establish trusted computing for container environments. HHS guidance on the HIPAA Security Rule requires covered entities and business associates to implement administrative, physical, and technical safeguards to protect ePHI, rather than relying on encryption alone.

Hardware-enforced isolation supports these frameworks because the boundary auditors evaluate is the same boundary the architecture enforces. The shared responsibility split documented in CSA CCM v4 places hypervisor and host-level virtualization controls under the cloud service provider's accountability, while the customer is responsible for controls within their allocated resources, such as guest OS hardening, patching, and access management.

When the CSP provides hardware isolation and holds SOC 2 Type II, the customer's audit scope narrows. Combine per-execution audit logs with the certifications and the procurement conversation gets materially shorter.

Resource caps, network controls, and short residency windows

Memory and CPU caps prevent a single workload from starving its neighbors. Network egress controls and secrets injection at the proxy layer keep credentials out of the executable surface. An LLM-generated script that calls socket.connect() to an arbitrary host shouldn't succeed just because the code ran. Network policy should default-deny outbound connections and allowlist only the endpoints the agent legitimately needs.

Short residency windows reduce the amount of state that exists in memory or snapshot storage at any given moment. Auto-shutdown triggered by network inactivity (rather than fixed timeouts) matches the bursty execution pattern of agent workloads.

A sandbox that returns to standby soon after inactivity limits the window during which an attacker could exploit a compromised execution environment. The cumulative effect is a python sandbox that limits blast radius even when an execution does something unexpected. Start by mapping every outbound endpoint the agent needs, then build the allowlist from that map. Any endpoint not on the list should be blocked at the network layer, not at the Python level.

Snapshots, state, and ephemerality tradeoffs

Standby snapshots are what make warm resume possible. They're also a data surface that procurement teams ask about. If a sandbox processed regulated data and its snapshot persists on disk, that snapshot becomes part of the data residency scope.

Production sandbox platforms expose ephemeral and zero-data-retention modes for workloads that can't tolerate snapshot persistence. Blaxel describes zero data retention as applying when a sandbox is deleted and has never entered standby mode; in that case, each sandbox's root filesystem runs in memory and all data is wiped when the sandbox is destroyed.

The tradeoff is latency: ZDR prevents standby snapshots, so every invocation pays the cold creation cost instead of the warm resume path. The right default depends on two factors.

First, is the workload regulated under HIPAA, GDPR, or a sector-specific framework that constrains data residency? If yes, ZDR or a short snapshot TTL is the safer default.

Second, does the workload run as part of a real-time agent loop where the user waits for results? If yes, the latency cost of ZDR may break the interaction. Teams running both regulated and non-regulated workloads often use separate sandbox templates with different lifecycle policies for each.

Picking the python sandbox boundary that holds in production

For production workloads that execute untrusted LLM-generated code, the isolation boundary has to survive arbitrary code from a non-deterministic source under the team's enterprise threat model. Each isolation pattern has a workload it fits. Process-level isolation is proportionate for trusted, developer-authored code. Containers are defensible for first-party agent logic with validated inputs. MicroVMs are often the preferred isolation boundary when code is LLM-generated, multi-tenant, or handling regulated data.

Blaxel Sandboxes run each execution in a Firecracker-based microVM with hardware-enforced tenant isolation. The platform holds SOC 2 Type II and ISO 27001 certifications, and offers HIPAA support with a Business Associate Agreement. For teams building coding agents, data analysis agents, or any workload where the executable surface is whatever Python the model produces this request, the isolation architecture matches the threat model without requiring the team to operate the microVM layer themselves.

Start free at app.blaxel.ai or book a demo at blaxel.ai/contact to walk through the isolation architecture with the founding team.

FAQs

What is the safest way to run LLM-generated Python in production?

The safest production pattern is to run LLM-generated Python inside an isolation boundary that does not depend on the Python runtime itself being secure. For trusted internal scripts, process-level controls may be enough. For first-party workloads, containers can be reasonable. But when the code is generated dynamically by an LLM, runs near tenant data, or touches regulated information, microVM isolation is usually the stronger boundary because each execution gets its own kernel and hardware-enforced separation.

Why are containers not always enough for sandboxing untrusted Python?

Containers provide useful isolation through namespaces, cgroups, and runtime controls, but they still share the host kernel. That shared-kernel model is the main tradeoff when the workload is truly untrusted. If LLM-generated Python can import unexpected packages, make system calls, or attempt escape paths, the container boundary depends heavily on runtime hardening and patching. Containers work well for many first-party applications, but multi-tenant untrusted code often calls for a stronger boundary.

When should teams use microVMs instead of process-level isolation?

Teams should consider microVMs when the code is not reviewed before execution, changes every request, runs in a multi-tenant environment, or can access sensitive data. Process-level isolation is better suited to trusted scripts where the team controls the source code and inputs. LLM-generated Python changes that risk profile because the executable surface is unpredictable. MicroVMs reduce the blast radius by placing each workload behind its own kernel and hardware-assisted virtualization boundary.

What controls matter beyond the sandbox boundary itself?

A strong sandbox still needs operational controls around it. Production teams should enforce CPU and memory limits, restrict network egress by default, inject secrets outside the executable surface, and keep per-execution audit logs. Lifecycle policies also matter. Short residency windows, automatic shutdown, ephemeral environments, and zero-data-retention options reduce the amount of sensitive state that persists after execution. The goal is not only to isolate untrusted Python, but to limit damage when code behaves unexpectedly.