Building Lightweight Sandboxes for Local AI Coding Agents with gVisor

When local AI coding agents write and execute code, that code may run with the same permissions as the agent, creating potential security risks. Developer cr-sbarbouche shared an open-source project called agvisor on Reddit, aiming to find a balance between "blindly trusting generated code" and "managing heavy Firecracker VM clusters."

Why Do We Need AI Code Sandboxes?

AI coding agents (such as LLM-based code generation tools) typically need to execute generated code to verify logic or complete tasks. If this code runs directly on the host machine, malicious or erroneous code generation could compromise the entire system. The traditional solution is to use virtual machines (like Firecracker) for isolation, but this comes with high management costs. agvisor takes a middle path: implementing lightweight sandboxes based on Docker and gVisor (runsc), which provides strong isolation while avoiding the complexity of virtual machines.

gVisor (runsc) is a user-space kernel sandboxing technology open-sourced by Google. Traditional containers (like Docker) share the Linux kernel with the host machine—processes inside the container interact directly with the host kernel through system calls, and a kernel vulnerability could break isolation. gVisor implements a Linux system call interface-compatible kernel (Sentry) in user space; system calls from container processes are intercepted and handled by this user-space kernel, with only a small number of necessary operations forwarded to the host kernel, significantly reducing the attack surface. runsc is the OCI-compliant runtime provided by gVisor that can be called directly by Docker. Compared to lightweight VMs like Firecracker, gVisor starts faster and has lower resource overhead, though system call compatibility and performance are somewhat compromised. It's suitable for scenarios that require isolation without wanting to bear VM management costs.

Core Features of agvisor

agvisor is a Python wrapper library that sandboxes code execution through Docker calling gVisor. It supports the following features:

• Resource limits: Configurable CPU, memory, PID, and disk quotas to prevent resource exhaustion.
• Automatic cleanup: Automatically destroys sandboxes via maximum lifetime and inactivity timeouts, reducing leftovers.
• Persistent workspaces: Workspace data is preserved after sandbox restarts, facilitating continuous tasks.
• Remote execution: Supports local Docker and remote execution via SSH, adapting to different deployment environments.
• Optional desktop environment: Provides a GNOME desktop with a browser, accessible via RDP, allowing developers to observe agent interactions with a real desktop.
• Model-agnostic: Works with any coding agent that can execute commands, without binding to a specific model.

Usage example is concise and clear:

from agvisor import Limits
from agvisor.sandbox import create_sandbox

with create_sandbox(
    limits=Limits(cpus=1, memory="512m"),
    lifetime=3600
) as sb:
    r = sb.exec("python3 -c 'print(1+1)'")
    print(r.stdout)

Known Limitations and Security Considerations

The author candidly lists the current version's limitations, which are crucial for evaluating adoption:

• Platform dependencies: Requires Linux, Docker, and gVisor; macOS users need to run through a Linux VM.
• Unrestricted network: By default, network access within the sandbox is unrestricted, including access to cloud metadata endpoints, which could become an attack vector.
• Missing storage quotas: Persistent workspaces do not yet implement storage quotas and could be abused.
• No built-in authentication: Lacks multi-tenant security boundaries, unsuitable for hostile multi-tenant scenarios.

The author emphasizes that the current version (0.1.x) is an early alpha, built by a single person and unaudited, and is not recommended for hostile multi-tenant workloads.

Cloud metadata endpoints (such as AWS's 169.254.169.254, GCP's metadata.google.internal) are internal HTTP services provided by cloud providers for programs within instances to query their own configuration and temporary credentials. These endpoints are typically accessible from within the instance without authentication, so once an attacker can execute code on the host (for example, through a sandbox escape without network restrictions or directly exploiting network access within the sandbox), they could read instance role credentials, then move laterally or access cloud resources. This is also a common target for SSRF (Server-Side Request Forgery) type vulnerabilities. For sandbox solutions, access to link-local addresses and metadata domains should be restricted by default, or protected through mandatory token mechanisms like IMDSv2. agvisor's current unrestricted network means users need to block such endpoints themselves through firewall rules or network policies.

Community Feedback and Future Directions

The author seeks feedback on Reddit, with particular focus on the security model. His questions include: How do people currently sandbox local AI coding agents? What security vulnerabilities have been overlooked? Is a live desktop with a browser really needed, or is headless execution sufficient?

This openness is commendable. For sandboxing AI coding agents, network restrictions and storage quotas are obvious improvement points. Additionally, authentication and isolation in multi-tenant scenarios require more mature solutions. agvisor provides a lightweight starting point for individual developers and small teams, but risks should be carefully evaluated before use in production environments.

The project is open-sourced on GitHub and can be installed via pip install agvisor. If you're looking for a simple sandboxing solution to run AI-generated code, give it a try—but be sure to do so in an isolated environment.

One-line Summary

agvisor uses Docker and gVisor to provide a lightweight code execution sandbox for AI coding agents.

Paragraph Summary

agvisor is an open-source Python library designed to provide an isolated environment for generated code executed by local AI coding agents. It uses Docker to invoke the gVisor (runsc) runtime, striking a compromise between "directly trusting generated code" and "managing heavy Firecracker VM clusters." The project supports CPU, memory, PID, and disk quotas, features automatic cleanup, persistent workspaces, SSH remote execution, and optional GNOME desktop with RDP access, and is not bound to any specific model. The author also candidly acknowledges that the current 0.1.x version is an early alpha with security limitations including unrestricted network (including cloud metadata endpoints), no storage quotas, and no built-in authentication, and is not recommended for hostile multi-tenant scenarios. The author is soliciting community feedback on Reddit regarding the security model and the necessity of a live desktop.