PaperlayerView exact revision on arXiv

Source-linked AI summary

SideKernel: A Usable microVM Sandbox for AI Coding Agents on macOS

Dimitrios Prasakis

arXiv:2610.02456v1cs.CRcs.AI

TL;DR

AI coding agents are untrusted components, yet many users run them without a sandbox, leaving the security risks of untrusted execution relevant. The paper develops SideKernel using survey signals and evaluates its capabilities against similar sandboxes; Docker Sandboxes and SideKernel pass the most tests in the study. These findings are bounded by the tested usability barriers and the informal survey’s non-generalizable scope.

  • Problem

    AI coding agents are untrusted system components, yet many users run them without a sandbox, exposing machines to risks including prompt injection, data exfiltration, and malware.

    Source: A. Motivation · p. 1

  • Method

    The paper uses an informal formative survey and predefined binary capability tests to guide SideKernel’s development and compare it with market sandboxes.

    Source: A. User Survey Methodology · p. 4, D. Benchmark Construction · p. 4

  • Results

    Across 23 capability tests, Docker Sandboxes and SideKernel each pass 19, while SmolVM, Microsandbox, and Shuru each pass 12.

    Source: A. Interpreting the Aggregate Results · p. 10

  • Takeaways & Limitations

    SideKernel provides several agent-specific usability capabilities, while Docker Sandboxes offers distinct capabilities including DNS controls, credential management, and observability.

    Source: §XI · p. 12

    The survey is informal and not designed to produce generalizable knowledge, and the comparison supports conclusions only within the usability barriers tested.

    Source: A. Interpreting the Aggregate Results · p. 10, §IX · p. 11

Abstract

from arXiv · show

AI coding agents are untrusted system components, yet they require autonomy on the developer machines they run on. This contradiction is a security problem. Sandboxes provide an isolated environment, but for local macOS development, the existing local, open-source options for AI coding agents are few in number and cumbersome to use. I conducted a formative online user survey which indicates that fewer than 40% of AI coding agent users run their agents in a sandbox and identifies the top usability barriers hindering AI coding agent sandbox adoption. These findings are used to develop SideKernel: an open-source, local, microVM-based macOS sandbox for AI coding agents designed for usability. To evaluate SideKernel, I compiled a list of sandboxes available on the market and filtered it against five inclusion criteria. Then I performed a comparative analysis between SideKernel and the sandboxes that satisfy these criteria, across 23 capability tests derived from the usability barriers revealed by the user survey. I discovered that only a few sandboxes are similar to SideKernel, and that among those, Docker Sandboxes and SideKernel score highest on capability features related to usability. A secondary contribution of this paper is a survey of the existing solution space for local, open-source, microVM-based macOS sandboxes for AI coding agents.

I. INTRODUCTION

The paper frames AI-agent sandboxing as a security problem and examines the limited local macOS options for coding agents. It presents SideKernel, an informal survey of usability barriers, and a comparative analysis of similar sandboxes.

A. Motivation

  • AI agents are untrusted components, and running them without sandboxing can expose machines to prompt injection, remote code execution, data exfiltration, and malware risks.Source: A. Motivation · p. 1

B. Isolation Primitives

  • Sandbox isolation boundaries may reside in a shared host kernel, a managed language runtime, or a separate virtualized kernel such as a microVM.Source: B. Isolation Primitives · p. 1

C. Scope

  • The paper focuses on microVM sandboxes, whose separate, stripped-down guest kernel requires an attacker to escape the VMM to reach the host; comparative security analysis of other primitives is out of scope.Source: C. Scope · p. 1

D. Research Question and Contributions

  • The paper asks which usability barriers hinder macOS developers’ adoption of AI coding-agent sandboxes and presents SideKernel, an informal survey, and a market comparison as contributions.Source: D. Research Question and Contributions · p. 2

A. Terminal-Based vs. Programmatic AI Agents

The paper distinguishes interactive terminal-based coding agents from programmatic SDK agents and models the coding agent itself as the adversary. It defines host-facing and external-network boundaries, then surveys sandboxes similar to SideKernel.

A. Terminal-Based vs. Programmatic AI Agents

B. Threat Model

  • SideKernel treats the agent as a fully privileged adversary inside the sandbox, regardless of whether prompt injection or its own inference made it hostile.Source: B. Threat Model · p. 2

1) South Boundary Threat Model:

A. Existing Sandboxes

  • The market includes shared-kernel and language-isolated tools, while other microVM products may be remote, closed-source, general-purpose, or aimed at other agent interfaces.Source: A. Existing Sandboxes · p. 3
  • The paper identifies SmolVM, Microsandbox, Shuru, and VibeBox as the only known tools meeting its five properties for similarity, while noting that its market survey is not exhaustive.Source: A. Existing Sandboxes · p. 3

IV. METHODOLOGY

SideKernel’s development combines formative survey research with comparative testing of the final prototype. The survey collects user-reported barriers, while the comparison filters market sandboxes and evaluates capabilities related to those barriers.

IV. METHODOLOGY

  • SideKernel’s development draws on a formative user survey and a summative comparative analysis of the final prototype against qualifying market sandboxes.Source: §IV · p. 3

A. User Survey Methodology

  • The online survey uses multiple-choice, multi-select, and free-text questions to gather sandbox users’ reported usability barriers after screening and categorizing respondents.Respondents were recruited through the author’s professional network, Zurich’s JFloor community, and Georgia Tech channels; the survey is informal and its results are treated as anecdotal signals, not statistically generalizable findings.Source: A. User Survey Methodology · pp. 3–4

B. Comparative Analysis Methodology

  • The comparative analysis compiles similar sandboxes, filters them against five inclusion criteria, and tests the final SideKernel prototype against the included market tools.The study includes sandboxes meeting criteria two through five and does not filter out Docker Sandboxes on open-source status.Source: B. Comparative Analysis Methodology · p. 4

C. Deriving Tests from the Usability Barriers

The paper translates survey-reported usability barriers into concrete capability tests, then uses predefined binary pass criteria and friction notes to compare sandboxes. Scores are unweighted signals, not definitive measures of usability.

C. Deriving Tests from the Usability Barriers

D. Benchmark Construction

  • Each capability test has a binary outcome and passes only when the sandbox has a documented built-in mechanism; a workaround does not count as a pass.The success criteria are fixed before evaluation, and limiting scores to built-in capabilities is intended to make results objective and auditable.Source: D. Benchmark Construction · pp. 4–5
  • The binary benchmark measures capabilities related to survey-identified usability barriers, but does not establish that mechanisms are intuitive or frictionless.Friction notes preserve qualitative descriptions without changing binary outcomes; the unweighted capability sum is a signal to read alongside those notes.Source: D. Benchmark Construction · p. 5

E. Evaluation Protocol

The evaluation protocol uses a fresh, standardized test directory and treats its capability tests as transparent but non-exhaustive indicators tied to survey-identified barriers. The survey finds low sandbox use among respondents and highlights practical friction around networking, setup, file sharing, and reproducible environments.

E. Evaluation Protocol

  • Each sandbox evaluation starts from a fresh template directory containing host-only, large, mounted, workspace, dependency, and shell test files.The directory is redeployed for each evaluation.Source: E. Evaluation Protocol · pp. 5–6
  • The capability tests are extensive but non-exhaustive indicators of sandbox capability and usability relative to survey-identified barriers.SideKernel’s iterative development permits tests to be added or amended as the product improves.Source: E. Evaluation Protocol · p. 6

A. Google Survey Report Analysis

  • 51.5% (35 users) of AI coding agent users had never used a sandbox, while 38.2% (26 users) were current sandbox users.The survey gathered 80 respondents, of whom 68 used AI coding agents.Source: A. Google Survey Report Analysis · p. 6
  • Eight of 33 current and former sandbox users cited networking and setup-from-scratch as difficult; seven cited file sharing, and five cited confusing multisandbox management and installation.Among current users, nine of 26 reported no significant difficulties.Source: A. Google Survey Report Analysis · p. 6
  • Free-text responses emphasized easy, nearly invisible operation, reproducible provisioning, granular security controls, and observability.A request for a preloaded “golden image” inspired SideKernel’s personalized image.Source: A. Google Survey Report Analysis · p. 6

B. Usability Barriers

The survey groups sandbox usability barriers into host–sandbox file sharing, networking, and environment provisioning. SideKernel’s architecture and design respond to these barriers, while selectively relaxing deny-all-by-default and leaving several initially envisioned controls unimplemented.

B. Usability Barriers

  • The three primary usability barriers are host–sandbox file sharing, networking, and environment provisioning, including first use and persistence.Users also raised installation, multisandbox management, reliability, and performance, but the project focused on the top three categories.Source: B. Usability Barriers · pp. 6–7

A. Architecture

  • SideKernel runs a stripped-down Linux kernel and curated Ubuntu root filesystem in a Swift VMM built on Apple’s Virtualization framework.A minimal Rust agent inside the microVM mounts the host filesystem via VirtioFS and handles automatic port detection and forwarding.Source: A. Architecture · p. 7

B. Design Goals and Implementation

  • SideKernel’s usability-led design selectively applies deny-all-by-default rather than enforcing it absolutely.Its goals map to survey barriers and can entail deliberate risk acceptance.Source: B. Design Goals and Implementation · p. 7
  • Credential management, agent-event observability, outbound-connection visibility, and more granular north-boundary controls were scoped out of this paper’s implementation.The paper notes that some of these features exist in Docker Sandboxes.Source: B. Design Goals and Implementation · p. 7

1) Entering a sandbox:

SideKernel launches an ephemeral microVM from the host’s current directory and supports shared authentication. Its other described capabilities address file exchange, networking, and environment continuity through explicit mechanisms.

1) Entering a sandbox:

  • The `sidekernel` command launches an ephemeral microVM and mounts the host’s current directory; Claude Code is preinstalled on first launch, and `sclaude` offers a direct launch path.The implicit mount is intended to match the host-directory behavior users expect from a Claude session.Source: 1) Entering a sandbox · p. 7

3) Sharing External Files:

  • Host files outside the mounted directory can be brought in with `sk-drop` after user approval, and host clipboard content can be pasted into SideKernel, including images in Claude sessions.SideKernel’s preloaded Claude instructions support requesting files or triggering a drop through drag-and-drop.Source: 3) Sharing External Files · p. 7

4) Ports and networking:

  • SideKernel automatically exposes newly opened guest ports on the host’s loopback address without requiring manual port forwarding.The Rust agent detects the opened ports.Source: 4) Ports and networking · p. 8

5) Network (NAT) kill switch:

  • The `sk-net` kill switch blocks northbound outbound traffic except to `api.anthropic.com`; restoring traffic requires explicit user approval.The Rust agent and VMM coordinate the capability.Source: 5) Network (NAT) kill switch · p. 8

6) Persistence and host parity:

  • Saving creates a personalized overlay filesystem that persists changes across restarts and sandboxes, while Claude skills, plugins, and agents are copied from the host before boot.Each start or restart launches a new ephemeral microVM.Source: 6) Persistence and host parity · p. 8

VII. EVALUATION: A COMPARATIVE ANALYSIS

The evaluation filters market sandboxes against inclusion criteria and compares them through capability tests tied to usability barriers. SideKernel leads the reported file-sharing tests, while VibeBox is excluded from evaluation after installation failures on two Macs.

VII. EVALUATION: A COMPARATIVE ANALYSIS

  • The study filters sandboxes against IR-2–IR-5 while excluding the open-source criterion to retain Docker Sandboxes, then evaluates those that pass alongside SideKernel.The passing set is Docker Sandboxes, Microsandbox, SmolVM, Shuru, VibeBox, and SideKernel; VibeBox is subsequently excluded from evaluation.Source: §VII · pp. 8–9, B. UB-1: Host–Sandbox File Sharing · p. 9

A. Comparative Analysis Process

  • Each capability test is a specific sequence of unit actions, with a binary outcome and optional qualitative friction notes.The paper labels experiences native, frictionless, or with friction according to whether they require zero, one or two, or at least three additional actions.Source: A. Comparative Analysis Process · p. 9

B. UB-1: Host–Sandbox File Sharing

  • Across nine host–sandbox file-sharing tests, SideKernel passes 8, Docker Sandboxes 6, and Microsandbox, Shuru, and SmolVM 5 each.VibeBox passed the inclusion criteria but was not evaluated.Source: B. UB-1: Host–Sandbox File Sharing · p. 9, Table III · p. 9
  • VibeBox met the inclusion criteria but was unsuitable for evaluation after installation failed on two separate macOS machines despite following its README instructions.The paper also describes VibeBox as unmaintained and having one contributor, its author.Source: B. UB-1: Host–Sandbox File Sharing · p. 9
  • Docker Sandboxes and SideKernel automount the current working directory; the other evaluated sandboxes require pre-launch mounts, and Microsandbox and SmolVM do not preserve permission bits across the boundary.External file dropping on Docker Sandboxes, Microsandbox, and SmolVM requires a host-side command; SideKernel’s sk-drop and Claude-session drag-and-drop are frictionless, with one in-guest command and macOS approval per file.Source: B. UB-1: Host–Sandbox File Sharing · p. 9
  • SideKernel alone passes both clipboard tests, supporting bidirectional text copy-and-paste and host-to-sandbox image pasting.The host Claude Code session supports pasting text and images in interactive mode.Source: B. UB-1: Host–Sandbox File Sharing · p. 9

C. UB-2: Networking, Ports & Localhost

The networking and setup comparisons reveal different strengths: Docker Sandboxes passes all networking tests, while Docker Sandboxes and SideKernel tie on setup tests. Their capabilities differ in runtime port forwarding, network controls, agent support, and persistence.

C. UB-2: Networking, Ports & Localhost

  • Across five networking tests, Docker Sandboxes passes 5, while Microsandbox, Shuru, SmolVM, and SideKernel pass 3 each.Source: C. UB-2: Networking, Ports & Localhost · p. 10, Table IV · p. 10
  • SideKernel provides automatic runtime port forwarding without user interaction; Docker Sandboxes provides manual runtime forwarding, while Microsandbox, SmolVM, and Shuru require ports to be set before launch.Predefining ports can add friction when developers do not know in advance which ports they will need.Source: C. UB-2: Networking, Ports & Localhost · p. 10
  • Docker Sandboxes alone provides DNS observability and granular egress allowlists; SideKernel has an in-guest kill-switch but lacks comparable granularity.Docker’s built-in TUI monitors DNS connections and lets users toggle or add allowlist entries during runtime.Source: C. UB-2: Networking, Ports & Localhost · p. 10

D. UB-3: Environment Provisioning & Setup

  • Across nine environment-provisioning and setup tests, Docker Sandboxes and SideKernel pass 8 each, compared with 4 each for SmolVM, Microsandbox, and Shuru.Source: D. UB-3: Environment Provisioning &… · p. 10, Table V · p. 10
  • Docker Sandboxes and SideKernel are the only sandboxes with preinstalled agents; Docker supports multiple major agents, while SideKernel supports Claude Code and alone inherits host authentication and Claude Code skills, plugins, and agents.SideKernel’s first-run authentication requires entering the macOS password once at the Keychain access-control prompt.Source: D. UB-3: Environment Provisioning &… · p. 10
  • Docker Sandboxes and SideKernel persist configuration and package changes across runtime restarts without friction; Docker alone provides a built-in store for custom credentials.Source: D. UB-3: Environment Provisioning &… · p. 10

VIII. DISCUSSION

Across 23 capability tests, Docker Sandboxes and SideKernel each pass 19, compared with 12 for SmolVM, Microsandbox, and Shuru; this usability ranking is limited to the tested barriers. SideKernel adds several barrier-specific features, while the evaluation and product have important scope limits.

A. Interpreting the Aggregate Results

  • Across 23 capability tests, Docker Sandboxes and SideKernel each pass 19, while SmolVM, Microsandbox, and Shuru each pass 12.These results indicate the strongest usability capabilities within the tested barriers, not a general ranking of sandbox usefulness; Docker Sandboxes also targets enterprise deployments and multi-sandbox orchestration.Source: A. Interpreting the Aggregate Results · p. 10

B. Comparison with Docker Sandboxes

  • SideKernel uniquely provides external file drops, automatic port forwarding, bidirectional clipboard use in Claude sessions, and synchronized host authentication.These features address specific usability barriers identified in the user study.Source: B. Comparison with Docker Sandboxes · p. 11
  • Docker Sandboxes has broader features, including observability, auditing, governance, granular policies, multi-sandbox management, and mature credential management.Several of these capabilities were outside the study’s scope.Source: B. Comparison with Docker Sandboxes · p. 11

C. Real-World Considerations •

  • SideKernel is designed for single macOS machines and was tested only on M1 and M4 chips running Tahoe 26.2; bugs and rough edges may remain.It has not undergone a formal security review, is self-signed and not notarized, and lacks out-of-the-box observability and enterprise features.Source: C. Real-World Considerations • · p. 11

IX. LIMITATIONS AND THREATS TO VALIDITY

  • The evaluation has developer-evaluator bias, and the developer-designed survey’s multiple-choice formats may anchor respondents despite free-text options.The author says multiple evaluators would be better but were infeasible within the practicum timeline; free-text options likely reduce survey bias without eliminating it.Source: §IX · p. 11
  • The survey sample tilts toward a security-aware audience, and its 80 respondents provide formative signals rather than statistically generalizable data.The study was informal practicum research and did not undergo formal Georgia Tech IRB review.Source: §IX · p. 11
  • Capability tests measure responses to the survey’s usability barriers, not usability generally, and binary scores do not capture friction or users’ relative priorities.The author describes the resulting scores as approximations.Source: §IX · pp. 11–12
  • As a Linux microVM on macOS, SideKernel cannot provide some Seatbelt-based capabilities, including testing native macOS SwiftUI applications; other isolation primitives were out of scope.Seatbelt-based sandboxes might provide sufficient security depending on the use case and threat model.Source: §IX · p. 12

X. FUTURE WORK

The paper proposes future improvements to SideKernel, including more granular network controls, broader credential and agent support. Its conclusion describes SideKernel’s usability features alongside Docker Sandboxes and the more limited agent capabilities of Microsandbox, Shuru, and SmolVM.

X. FUTURE WORK

  • Future work includes replacing the NAT kill-switch with a network proxy for granular allowlisting and DNS observability, adding generic credential storage, and supporting more major agents.The planned agent integrations include Codex and Microsoft Copilot.Source: §X · p. 12

XI. CONCLUSION

  • SideKernel provides bidirectional clipboard use in Claude Code, runtime port forwarding, native Keychain authentication, automatic transfer of host Claude skills and agents, and frictionless external-file drops.The paper also describes personalized images as easing environment provisioning.Source: §XI · p. 12
  • Docker Sandboxes is another highly capable sandbox for the tested usability barriers, with DNS controls through a TUI, custom credential management, preinstalled major agents, and observability.Source: §XI · p. 12
  • Microsandbox, Shuru, and SmolVM follow SideKernel and Docker Sandboxes, with more limited AI coding agent capabilities.Source: §XI · p. 12
  • The author attributes the limited effort on local macOS coding-agent sandboxes to an industry focus on autonomous programmable SDK agents, leaving coding agents as an afterthought.The author notes that the industry is young and rapidly developing.Source: §XI · p. 12
  • The author says Docker released sbx on January 30, 2026, further supporting the claim that the market for local AI coding-agent sandboxes is young.Source: §XI · p. 12

APPENDIX A FULL TASK DEFINITIONS

The appendix specifies binary capability tests and reports survey results about sandbox use and barriers. Its survey tables describe different respondent groups, and some single-respondent free-text responses are omitted.

APPENDIX A FULL TASK DEFINITIONS

  • The appendix defines each task as a capability test with a binary outcome scored by the paper’s criteria.Table VI covers host–sandbox file sharing, and Table VII covers networking, ports, and localhost.Source: Appendix A · p. 13, Table VI · p. 13, Table VII · p. 13
  • The file-sharing task defines ease as an in-sandbox built-in mechanism without restarts or host commands, and security as requiring explicit user approval.Source: Appendix A · p. 13

T3 DNS CONNECTION URL LOGS

T5 PACKAGE INSTALLATION

APPENDIX B GOOGLE SURVEY RESULTS

  • Survey questions are reported for their relevant respondent groups, and free-text responses or options selected by only one respondent are omitted.The notes specify that some barrier percentages apply to current and former users, while others are limited to one subgroup.Source: Appendix B · pp. 14–15
  • Among 33 current or former sandbox users, reported barriers included setup from scratch and networking difficulties at 24.2% each, and file sharing difficulty at 21.2%.Source: Appendix B · p. 15
  • Among seven former users, Docker Sandbox was the most frequently reported prior tool at 42.9%, followed by full VMs at 28.6%.Source: Appendix B · p. 15
  • Among 35 non-users, 60.0% had never considered a sandbox, 31.4% were unaware of good options, and 11.4% had looked but found it too difficult.Source: Appendix B · p. 15
Loading 2610.02456v1…