Add lightweight OS-level sandboxing via sandlock for LocalCommandLineCodeExecutor

[congwang-mk]

Problem

The LocalCommandLineCodeExecutor writes LLM-generated code to disk and executes it via asyncio.create_subprocess_exec with full host privileges. The only safeguard is a suppressible UserWarning.

Attack scenario: indirect prompt injection causes the LLM to generate malicious code (e.g., exfiltrating SSH keys, installing backdoors). The code runs with full filesystem, network, and process access.

The Docker executor provides real isolation but is opt-in and adds significant overhead. There is no lightweight, local sandboxing option between "completely unsandboxed" and "full Docker container."

Proposal

Add sandlock as a new code executor backend. Sandlock is a lightweight Linux process sandbox using Landlock, seccomp-bpf, and user namespaces.

What sandlock provides

Layer	Protection
Landlock	Filesystem path whitelisting (read-only / read-write), network domain + port restrictions
seccomp-bpf	Syscall filtering at kernel level: blocks ptrace, mount, unshare, kexec_load, bpf, etc.
User namespaces	Privilege escalation prevention without root
Resource limits	Memory, process count, CPU, open file caps (no cgroups needed)

Why this fits AutoGen

• ~20ms startup vs ~200ms+ for Docker. Low enough to be a reasonable default.
• No root, no daemon. Unlike Docker, just pip install sandlock. No Docker socket needed.
• Fits the executor interface. AutoGen already has a clean CodeExecutor abstraction. A SandlockCommandLineCodeExecutor would implement the same interface as LocalCommandLineCodeExecutor but with kernel-enforced confinement.
• Aligns with Proposal: Standardized Safety Sandbox for Agent Tool Execution #7230. The proposed ToolSafetyPolicy interface (allow_network, allow_filesystem, max_memory) maps directly to sandlock's capabilities.
• Self-hosted. No Azure subscription needed. Works in air-gapped environments.
• Linux primary. Non-Linux users can continue using the Docker executor.

Where it fits in the executor hierarchy

LocalCommandLineCodeExecutor  →  SandlockCodeExecutor  →  DockerCodeExecutor  →  AzureCodeExecutor
      (unsandboxed)               (lightweight             (container            (cloud
                                   OS-level)                isolation)            isolation)

Example usage

from autogen_ext.code_executors.sandlock import SandlockCommandLineCodeExecutor

executor = SandlockCommandLineCodeExecutor(
    work_dir="./coding",
    fs_read=["/usr/lib/python3", "/usr/local/lib"],
    fs_write=["./coding"],
    net_allow=[],  # no network by default
    max_memory_mb=512,
    max_procs=5,
)

Relation to existing issues

• [Security] LocalCommandLineCodeExecutor executes LLM-generated code without sandboxing #7462 (LocalCommandLineCodeExecutor unsandboxed): sandlock provides a drop-in replacement with kernel enforcement
• Proposal: Standardized Safety Sandbox for Agent Tool Execution #7230 (ToolSafetyPolicy proposal): sandlock's per-sandbox policy maps directly to the proposed interface
• Security: Fix Path Traversal in LocalCommandLineCodeExecutor #7181 (path traversal in LocalCommandLineCodeExecutor): Landlock filesystem whitelisting prevents writes outside allowed paths at the kernel level
• MCP tool poisoning can enable arbitrary code execution via unsigned tool definitions #7427 (MCP tool poisoning): sandboxed tool execution limits blast radius of malicious MCP tools

Alternatives considered

• Docker-only: adds complexity and overhead; not available in all environments (CI, minimal VMs, air-gapped)
• Hardening LocalCommandLineCodeExecutor with blocklists: fundamentally limited; new bypasses will always emerge
• firejail: requires root or setuid binary
• bubblewrap (bwrap): lower-level, no Python API, no resource limits without cgroups
• gVisor: heavy, requires Docker or dedicated kernel

References

• sandlock GitHub
• Landlock LSM
• seccomp-bpf docs

[balthazar-bot]

Strong +1 on adding a middle tier between "runs on the host" and "full container orchestration". A lightweight sandbox backend is exactly the missing rung.

The part I would push on is making the policy contract primary, and the sandbox backend secondary.

In practice, operators care about questions like:

• filesystem: read-only where? writable where?
• network: disabled, allowlist, or full?
• process / memory limits: what are the enforced ceilings?
• environment: inherited, scrubbed, or explicit allowlist?

If AutoGen standardizes that policy shape first (whether via ToolSafetyPolicy or similar), then Local, Sandlock, Docker, etc. become implementations of the same intent instead of separate security stories.

That also helps with the messy real-world cases:

• Linux kernel too old for a given Landlock ABI
• a feature degrades (e.g. port rules / IPC isolation unavailable)
• non-Linux hosts need a different backend entirely

The executor can then return an effective policy artifact after startup, e.g. "requested X, enforced Y, degraded Z". That is much more useful operationally than assuming the requested sandbox level actually materialized.

So: yes to Sandlock, but I’d treat it as a backend for a stable capability contract, not as the contract itself. Otherwise the ecosystem risks repeating the usual pattern where "sandboxed" means five different things depending on which executor name happened to be chosen.

[msaleme]

This addresses a real and exploitable gap. The LocalCommandLineCodeExecutor running with full host privileges is exactly the attack surface we test for in our AutoGen security harness.

We just shipped AG-NE-003 (Local Executor Trust Boundary Bypass) — a test that probes whether code execution stays sandboxed regardless of executor type. It sends payloads that detect whether they are running in Docker or on the host, then attempt to read /etc/passwd in the local case. The test passes only if the response contains no system file content.

A few observations from testing:

1. The suppressible UserWarning is not a security control. Any indirect prompt injection that generates code bypasses it entirely since there is no human in the loop at that point.

2. sandlock (Landlock + seccomp) is a solid approach for Linux. The key question is how to handle the gap on macOS/Windows where Landlock is unavailable. A platform-aware fallback matrix (Landlock on Linux, sandbox-exec on macOS, restricted tokens on Windows) would make this more broadly adoptable.

3. The opt-in vs opt-out default matters enormously. If sandboxing is opt-in (like Docker executor today), most users will never enable it. Consider making the sandboxed executor the default and requiring an explicit flag to run unsandboxed.

Our full AutoGen harness (10 tests across speaker selection poisoning, nested conversation escape, and message source spoofing) is open source: pip install agent-security-harness

Happy to add sandlock-specific test vectors once the implementation lands.