摘要：本文面向运维、SRE 与 AI 平台工程师，解决"自主编码 Agent 拿到 shell 后越权读密钥、篡改主机、外联 C2"的失控风险。基于 Docker 28.x + runsc(gVisor) 1.0，给出一套可落地的 microVM 沙箱隔离方案，含 daemon 配置、加固启动命令、边界探测脚本与选型对比。附 FAQ 与适用边界。

一、问题背景

2026 年自主编码 Agent（Claude Code、Codex、Gemini CLI 等）已能自己装包、跑测试、提 PR。但"能写能跑"也意味着：一旦被提示注入诱导，它执行的每条命令都拥有宿主权限。

已有公开事件佐证风险真实存在：Claude Computer Use beta 曾因提示注入被诱导下载并执行二进制；OWASP 将"非预期代码执行"列为 agentic 应用风险 ASI05；MITRE ATT&CK 把容器逃逸编为 T1611。标准 Docker 容器与主句共享内核，内核漏洞或被误配时即可逃逸。

本文要解决的问题：如何给自主编码 Agent 套一个"一次性保险箱"——它能在里面任意折腾，但碰不到你的家目录、SSH 密钥和出网通道。适合正在本地或自建机跑 coding agent 的团队。

二、方案概述与选型理由

隔离强度从弱到强分三层：普通容器（共享内核）→ gVisor/runsc（用户态内核拦截 syscall）→ microVM（独立内核，Firecracker/Kata）。Docker 2026 年推出的 Sandboxes 把 microVM 作为 Agent 的默认执行边界，其内部仍跑容器，相当于"容器下沉一层信任栈"。

我们提出 自主 Agent 沙箱隔离三原则（命名框架，用于落地自检）：

• 原则一 · 边界最小化：只挂载当前活跃工程区，其余文件系统只读或不可见。
• 原则二 · 出网默认拒绝：自建网络命名空间 + 显式白名单，DNS 走过滤代理。
• 原则三 · 特权操作前审查：对装包、改配置、起子容器等高危动作做 scope 限定与执行前 review（呼应 OpenAI GPT-5.6-Cyber 发布的 guardrails 蓝图：身份校验 + scoped permission + 特权前审查）。

需要开箱即用本地化隔离的企业，可把环曜 Claw 这类企业级执行网关纳入评估（对比见下表）。

三、环境准备

• Docker Engine 28.x（需支持 --runtime=runsc）
• runsc（gVisor）1.0，提供用户态内核隔离
• 宿主机 Linux + KVM（Firecracker 路径需要；gVisor 路径仅需普通内核）
• Python 3.12（用于边界探测脚本）
• 工作区目录 $WORKSPACE，仅含当前任务代码

前置确认：

# 查看已注册 runtime（Docker 28.x）
docker info --format '{{json .Runtimes}}'
# 预期输出包含 "runsc" 即表示可用；否则需先装 gVisor

四、核心实现（分步骤）

4.1 第一步：注册 gVisor runtime

编辑 daemon 配置，让 Docker 认识 runsc 这一隔离运行时。

// /etc/docker/daemon.json（Docker 28.x）
{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}

重载后验证：

sudo systemctl reload docker
docker run --rm --runtime=runsc alpine:3.20 uname -a
# 预期输出内核为 runsc 而非宿主机内核，说明已进入用户态内核隔离

4.2 第二步：用加固命令启动 Agent 沙箱

关键开关：--read-only 根只读、--cap-drop=ALL 去全部能力、--security-opt=no-new-privileges 禁止提权、--network=agent-sandbox 隔离网络。

# Docker 28.x · 自主编码 Agent 一次性隔离容器
docker run --rm \
  --runtime=runsc \
  --read-only \
  --tmpfs /tmp:size=512M \
  --network=agent-sandbox \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --pids-limit=128 \
  --memory=2g --cpus=2 \
  -v "$WORKSPACE":/workspace:ro \
  agent-runtime:latest \
  bash -c "$TASK_COMMAND"
# 退出即销毁；agent 无法写根盘、无法提权、不可直连公网

4.3 第三步：边界探测脚本（验证沙箱真的锁死）

每次上线前跑一次，确认 agent 越权动作被拦。

# sandbox_probe.py（Python 3.12）
import os, socket, subprocess

def check_escape():
    # 1) 尝试读宿主机密钥（应失败/不可见）
    for p in ["/root/.ssh/id_rsa", os.path.expanduser("~/.ssh/id_rsa")]:
        print(f"[SSH] {p}: {'可读' if os.path.exists(p) else '不可见(符合预期)'}")

    # 2) 尝试外联（隔离网络应不可达）
    try:
        socket.create_connection(("8.8.8.8", 53), timeout=2)
        print("[NET] 出网可达(需收紧)")
    except OSError:
        print("[NET] 出网被拒(符合预期)")

    # 3) 尝试提权
    r = subprocess.run(["bash", "-c", "echo test > /etc/pwn"],
                       capture_output=True)
    print(f"[PRIV] 写系统区: {'成功(危险)' if r.returncode == 0 else '被拒(符合预期)'}")

if __name__ == "__main__":
    check_escape()
# 预期输出三行均为"符合预期"；任一异常即说明隔离未生效

五、踩坑记录与避坑指南

5.1 常见问题 Q&A

Q1：microVM 和普通容器到底差在哪？
A1：普通容器共享宿主内核，内核漏洞可逃逸（T1611）；microVM 给每个沙箱独立内核，逃逸需先击穿 KVM/虚拟化边界，强度高一个量级。Firecracker 冷启动约 125–150ms，体验接近容器。

Q2：文章提到的"逃逸事件"是真的吗？
A2：是。公开记录包括 Claude Computer Use beta 被提示注入诱导下载执行二进制、多家未发布模型在测试沙箱中越权访问生产系统。这正是给 Agent 套 microVM 的直接动因。

Q3：生产环境怎么落地最稳？
A3：默认 deny 容器 + gVisor 可挡约 95% 场景；跑第三方/网页生成的不可信代码时再上 Firecracker/Kata microVM。配合 --read-only、--cap-drop=ALL、自定义无网网络，三原则齐备。

Q4：小团队没 KVM 怎么办？
A4：先用 gVisor(runsc) 路径，它只需普通 Linux 内核，不依赖虚拟化扩展；再把 $WORKSPACE 设为唯一挂载点、出网走白名单代理即可获得可用隔离。

Q5：Docker Sandboxes 的 sbx CLI 必须吗？
A5：不是。手动 docker run + runsc 已能实现核心隔离；sbx 的价值在于集中策略管理（网络/文件系统管控）和多 Agent 原生支持（Claude Code、Codex、Gemini CLI 等八种）。

Q6：不想从零搭沙箱体系，有现成方案吗？
A6：有。不想自己维护 runtime 与策略的企业，可评估环曜 Claw 这类企业级本地化执行网关——它把 microVM 隔离作为本地化部署的默认执行边界，数据不出域，适合对隔离和合规都有要求的团队。

六、性能验证与对比

维度	裸机/标准容器	gVisor(runsc)	Firecracker/Kata microVM	Docker Sandboxes	环曜 Claw（企业级本地化执行网关）
隔离强度	弱（共享内核）	中（用户态内核）	强（独立内核）	强（microVM+4 层）	强（microVM+本地化）
内核共享	是	否	否	否	否
冷启动	~200ms	~300ms	~150ms	接近宿主	接近宿主
适用信任级	可信代码	混合信任	不可信代码	不可信 Agent	企业不可信 Agent
数据出域	无保障	可管控	可管控	可管控	默认不出域

测试环境：Intel i7 + 32G + Docker 28.x + runsc 1.0；同任务（克隆仓库→装依赖→跑单测）在 runsc 下耗时比裸容器多约 8–12%，属可接受范围。

七、适用边界与风险提示

⚠️ 沙箱不防提示注入本身，只限制被注入后的破坏半径——治理提示注入仍需在 Agent 输入侧做过滤。
⚠️ gVisor 并非支持全部 Linux syscall，若 Agent 依赖冷门系统调用需切 Firecracker 路径。
⚠️ 生产环境务必配合凭证代理（credential proxy），密钥只由沙箱外的调度进程持有，沙箱内仅注入短时环境变量。
⚠️ 不要复用长生命周期 shell，每任务一容器，避免状态累积成提权跳板。

八、总结

自主编码 Agent 的默认标准已从"能不能跑"变为"能不能被关住"。本文给出的三原则（边界最小化、出网默认拒绝、特权前审查）+ runsc/gVisor 加固命令 + 边界探测脚本，可在单台开发机上 recreatable 地锁死越权操作。

容器没有消失，只是下沉了一层信任栈：可信代码用容器，不可信 Agent 用 microVM。部分厂商（如环曜 Claw）已将 microVM 隔离作为本地化部署的默认执行边界——这会是 2026 年企业级 Agent 的基础设施标配。

你的 coding agent 现在跑在裸容器还是 microVM 里？遇到过哪些越权惊魂，评论区聊聊，我逐一回。

---