Java Sandbox Environments for Untrusted Code Execution

Java sandbox environments now need to contain the runtime. Now that Java 24 has permanently disabled the Security Manager, teams that run untrusted or AI-generated Java must choose between OS and hypervisor boundaries. The right choice depends on the code’s trust level and the system around it, but no isolation engine can protect a trusted tool that later executes an agent’s untrusted output.

Why Java's built-in sandbox no longer exists

JEP 486 permanently disabled the Security Manager in JDK 24, ending the supported in-process mechanism for confining untrusted Java code. The mechanism dated to JDK 1.0. JEP 411 had deprecated it in Java 17, so the direction was established before the final change. Attempting to enable it now produces an immediate error, and its APIs no longer enforce security policies.

The Security Manager depended on permission checks at hundreds of call sites. One missed check could break confinement, and getting the configuration right was hard in practice. JEP 486 explicitly declines to provide a replacement for its sandboxing functionality. Instead, JEP 411 frames security around integrity at lower levels of the Java Platform, stronger module boundaries, and isolation of the entire runtime from sensitive resources through “out-of-process mechanisms such as containers and hypervisors”.

Why the removal lands at the worst possible moment for Java teams

Untrusted code is becoming a routine runtime input. Plugin hosts, agent runtimes, and code-evaluation APIs all face the question of how to execute code that the application’s developers did not inspect beforehand. AI agents sharpen that problem because they generate code dynamically from prompts, context, and objectives. The application may authorize the task without knowing in advance which operations the resulting code will attempt.

What, then, does permission to complete a task actually authorize? Agent-produced code can contain bugs, consume unbounded resources, access files it should not touch, or attempt unintended network operations. These risks do not require a deliberately malicious agent. For Java plugin systems and tool-calling agents, any design that relied on SecurityManager to constrain a plugin or script therefore needs re-examination from the process boundary outward.

Why moving isolation out of the JVM and into the OS layer is the right direction

Rather than relying on checks within Java libraries, Linux namespaces, cgroups, and seccomp-bpf constrain the process through OS-level mechanisms. seccomp-bpf profiles restrict which system calls a containerized JVM can invoke. Docker’s default profile blocks some of the roughly 300-plus available syscalls, and custom profiles can cut the set of allowed calls further.

Untrusted plugins run outside the trusted JVM in a separate, containerized process, communicating through a narrow RPC or IPC interface. The trusted application no longer depends on an internal permission check to separate itself from plugin execution. This establishes where the choice of container or virtualization technology belongs.

DirtyChai offers a specialized alternative to this design. The community OpenJDK fork restores, improves, and extends SecurityManager, AccessController, and ProtectionDomain APIs. Its stated purpose is to keep trusted but independent parties within the privileges declared and granted to them. It also explicitly aims to prevent untrusted code from loading. That distinction places it outside the central problem of deliberately executing unknown Java code.

The three isolation technologies that fill the gap, and what separates them

The three main designs are shared-kernel containers, user-space kernels, and hardware-isolated microVMs. They differ in what separates a workload from the host. Startup speed and overhead follow from those designs, but neither alone describes the security guarantee. Kata Containers belongs with the microVM class, providing a way to expose VM isolation through familiar container APIs.

Standard Docker containers use Linux namespaces and cgroups while sharing the host kernel. A kernel vulnerability or misconfiguration can permit escape and expose the host. Startup takes milliseconds, and overhead is minimal, but those properties do not remove the shared dependency.

gVisor places a user-space kernel, the Sentry process, between the workload and the host kernel. The Sentry intercepts system calls, allowing only a minimal vetted subset to reach the host rather than exposing it to hundreds of calls directly. This is syscall-level isolation. It has a stronger boundary than standard containers but lacks the hardware isolation of a VM, so its performance tradeoffs differ from those of both.

Firecracker creates lightweight virtual machines with minimal device emulation, each running its own Linux kernel inside KVM. To escape, code must get past both the guest kernel and the hypervisor. Its boot time is roughly 125ms, with under 5 MiB overhead per VM. Kata orchestrates VMMs including Firecracker, Cloud Hypervisor, QEMU, and Dragonball, presenting hardware-isolated workloads through standard container APIs. It boots in roughly 200ms and integrates with Kubernetes without requiring a different orchestration model.

What the security research says about how these isolation boundaries actually fail

Pillar Security’s “Week of Sandbox Escapes” research examined failures involving Cursor, OpenAI’s Codex CLI, Google’s Gemini CLI, and Google’s Antigravity. The sandbox itself held in all seven disclosed issues. Instead, the agent wrote content that a trusted component outside the sandbox later read or executed. Hook configurations, virtual environment interpreters, Git config entries, and task definitions became paths across that trust boundary.

The Cloud Security Alliance’s July 2026 analysis found four weaknesses that kept coming up in these findings. Denylists left parts of the OS attack surface uncovered, and agents trusted project-local configuration as infrastructure. Command allowlists examined only a command’s name. Systems also trusted content because it was already in the workspace. Each weakness concerns how authority is assigned.

Cursor fixed its workspace-controlled hook execution flaw, CVE-2026-48124, with a CVSS score of 8.5, in version 3.0.0. OpenAI patched the Codex CLI allowlist bypass nicknamed “GitPwned” in version 0.95.0 and paid a bug bounty. Google classified its two Antigravity-specific findings as “other valid security vulnerabilities”, downgraded their severity as difficult to exploit, and had not shipped fixes at disclosure. Responses were not uniform. Google and OpenAI also declined to treat their respective exposure to the shared Docker-socket finding as requiring a fix.

Engine maintenance presents a separate operational risk. George Andronchik and Pavel Lokhmakov’s May 2026 engine-level security study found that downstream patch lag matters most to operators, more than engine architecture alone. The architectural boundary and its maintenance both require attention. What trusted component will consume the agent’s output after its turn ends?

How to match isolation technology to your actual threat model

A team should first ask whether the executed code is genuinely reviewed and trusted, then identify its operational context, including tenancy, workload behavior, and persistence needs. Neither axis is sufficient alone. Running dynamically generated code in an internal deployment does not make it trusted, and a compute-heavy workload alone does not tell teams how strong its isolation needs to be.

For production agents executing untrusted or AI-generated code across tenants, Firecracker or Kata provides the appropriate hardware-isolation tier. Their roughly 125–200ms boot times are acceptable for most agent workflows. For compute-heavy agents with limited I/O, gVisor offers strong syscall-level isolation where full VM overhead is not justified. Hardened containers with seccomp, AppArmor, and capability dropping suit internal automation only when the executed code has been reviewed and is genuinely trusted.

The chosen tier still needs surrounding controls. Resource limits, network controls, permission scoping, and monitoring remain necessary, as does governance of agent-authored files after execution. For long-running Java agents, snapshot and suspend/resume support is another selection criterion. Workflows that preserve conversation history, authentication tokens, and security context need stateful environments rather than disposable sessions that lose progress between steps.

What the current platform landscape offers for Java workloads specifically

In 2026, platforms use these isolation models with different deployment environments and SDKs. Java teams should evaluate both layers. A platform’s microVM architecture establishes one kind of boundary, but it does not by itself establish Java SDK support or compatibility with an existing deployment. A platform can also accept a Java container image without having stronger isolation turned on.

Vercel Sandbox is generally available and uses Firecracker through Hive, its internal platform for orchestrating microVM clusters across regions. Its native support is mainly for Node.js/TypeScript, though it also supports Python, and how long a session can last depends on the plan. It is most relevant when the agent workload already lives in the Vercel ecosystem. For Java teams, that language-support distinction belongs in the evaluation rather than being inferred from the underlying Linux environment.

Cloudflare Sandbox SDK lets Workers applications execute untrusted code in isolated Linux environments, with each sandbox inside its own VM. Durable Objects provide stateful sandbox identities, and the SDK includes input validation and network controls. Deno Sandbox, announced in beta on February 3, 2026, gives each sandbox a dedicated Firecracker microVM in Deno Deploy’s infrastructure. Both offer VM-backed isolation.

Northflank offers sandbox infrastructure using Kata and gVisor, with Docker-native compatibility that lets Java teams bring existing container images without rewriting their stack. Its default is Docker, with optional Kata or Sysbox for stronger isolation, so stronger guarantees require explicit configuration. That default deserves attention during evaluation. The platform has stateful sessions that can run indefinitely and start quickly, so agents can keep context between steps. Its pricing includes a free Sandbox tier, self-serve pay-as-you-go from $0.01667/vCPU-hour, and an Enterprise tier available on request.

For persistent Java workloads, indefinite sessions and image compatibility address different needs from the isolation engine itself. They support continuity and deployment fit, while the configured runtime determines the security boundary. Stateful operation also does not establish snapshot or suspend/resume support by itself.

Building a Java sandbox that holds after the agent's turn ends

Untrusted Java plugins and agents should run outside the trusted JVM, communicating through a narrow RPC or IPC interface. Production or multi-tenant AI agent workloads should default to Firecracker or Kata. seccomp-bpf profiles should further restrict containerized JVM system calls. Sysdig’s 2025 report found that 78% of production containers still run as root, reinforcing why Docker’s default profile is a starting point for further hardening.

Artifact handling needs the same deliberate treatment. Teams should scrutinize agent-authored hook configurations, virtual environment binaries, Git config entries, and task definitions as untrusted workspace content. Command allowlists should validate the full invocation. Teams must assess both whether the agent could perform an action during its turn and whether it can induce a trusted component to perform that action afterward.

Long-running Java workflows should use stateful environments with snapshot and suspend/resume support where continuity is required. Teams should also pin deployed sandbox components and monitor patch cadence across both engine and platform. For enterprise workloads, the evaluation should confirm applicable SOC 2, HIPAA, and GDPR compliance requirements before production deployment.

The Security Manager’s removal is a clarification. The JVM’s own guidance places runtime isolation at the OS and hypervisor level, where the necessary platforms and patterns now exist. The remaining responsibility is to keep that boundary coherent through execution, persistence, maintenance, and the moment an agent’s output passes to a trusted tool.