AI Code Sandboxes: A Comparative Security Study. Part 1 of 2 -- Engine-Level Properties (Attack Surface, Leakage, Stackability, CVE History, Patch Cadence, Fuzzing)

A peer-reviewed security study comparing five AI code sandbox products across six engine-level metrics reveals significant architectural and operational differences in isolation capabilities. The research identifies critical gaps in fuzzing investment and patch deployment timelines, with downstream lag ranging from same-day to over 471 days, exposing potential vulnerabilities in production AI systems.

This arXiv paper addresses a critical blindspot in AI infrastructure security by systematizing how different sandbox architectures—microVMs, userspace kernels, and OCI containers—isolate untrusted code execution. The study matters because AI systems increasingly execute third-party or user-supplied code, making sandbox efficacy essential to preventing supply-chain attacks and privilege escalation.

The research emerged from growing concerns about AI security posture as models integrate external tools and code execution capabilities. Unlike traditional security research that focuses on individual vulnerabilities, this study examines structural properties across the entire isolation stack. The cross-axis methodology reveals that no single metric (CVE history, attack surface, patch speed) tells the complete story—a product with zero published CVEs may lack upstream fuzzing, leaving unknown vulnerabilities undetected.

The patch cadence finding carries immediate practical implications: while upstream vendors release fixes within days of coordinated disclosure, downstream adoption varies wildly. Some operators patch within days, others within months or indefinitely. This creates a fragmentation problem where deployment choices directly determine real-world security posture independent of underlying technology.

Most revealing is the unfilled gap: no product combines microVM architecture with continuous public fuzzing—the strongest defensive combination. This suggests either market misalignment or structural incentive problems in open-source sandbox development. The companion repository and threat-model qualification matrix provide operators with concrete tools for risk assessment rather than prescriptive rankings, respecting context-dependent deployment decisions.

• →Patch latency varies 0-471+ days downstream despite coordinated disclosure, making operator policy more consequential than engine choice.
• →Three sandbox architectures (microVM, userspace kernel, OCI container) exhibit clean architectural separation but inconsistent security maturity within classes.
• →No sandbox combines microVM isolation with continuous public fuzzing, leaving the strongest defensive posture unoccupied in the market.
• →Single-axis security metrics (CVE count, attack surface) are insufficient; cross-axis analysis reveals critical gaps in fuzzing coverage and defense-in-depth.
• →Open-source sandbox projects split into three fuzzing tiers, suggesting misaligned incentives between security requirements and resource allocation.