Hotdry.
归档
ai-systems-security

设计一个安全、可审计的沙箱：在任意环境中隔离执行 Claude Code 与 Codex 生成的代码

针对 Claude Code 与 Codex 等 AI 代码生成代理，提出基于微虚拟机、gVisor 与 eBPF 审计的三层安全架构，给出资源限制、网络隔离与操作监控的可落地参数。

随着 Claude Code、Codex 等 AI 代码生成代理在开发流程中的深入，允许模型直接读写代码库、运行命令甚至发起网络请求已成为提升效率的关键。然而，执行任意 AI 生成的代码引入了显著的安全风险：从无意中的无限循环耗尽资源，到恶意代码尝试逃逸容器、访问敏感文件或外泄数据。因此，构建一个安全、可审计的沙箱环境，能够在任意部署场景下隔离这些代理的执行，是工程团队必须面对的基础设施挑战。

隔离技术选型：安全谱系与性能权衡

沙箱的核心是隔离。根据对 AI 生成代码的信任程度与性能要求，可选择三种主流技术，它们构成一个从最高安全到最低开销的谱系。

1. 微虚拟机（MicroVMs）—— 最高隔离
以 Firecracker 或 Kata Containers 为代表，微虚拟机为每个工作负载提供独立的客户内核，通过硬件虚拟化实现硬件强制的边界。这是多租户、互联网暴露或执行完全不可信代码时的首选方案。Firecracker 的冷启动时间可控制在 100–150 毫秒，内存开销较低，适合短生命周期的 AI 任务。但其仍需虚拟化开销，且管理复杂度高于容器。

2. gVisor—— 强隔离与较低开销的折衷
gVisor 作为一个用户空间内核，拦截并模拟系统调用，大幅减少暴露给工作负载的内核攻击面。它可以作为 Docker 运行时插入，使得容器逃逸更为困难。代价是约 10–30% 的 CPU 开销以及某些系统调用的不兼容性，可能需要对工作负载进行调整。gVisor 适用于需要较强隔离但无法承受完整虚拟机开销的场景，例如 CPU 密集型的 AI 代码执行。

3. 强化 Docker 容器 —— 仅适用于受信代码
通过 seccomp 配置文件、AppArmor/SELinux、丢弃 Linux 能力、只读根文件系统、cgroup 限制和严格的网络策略，可以硬化标准 Docker 容器。然而，容器仍共享主机内核，内核漏洞可能导致逃逸。因此，这种方案仅推荐用于内部工具或代码经过人工审核的场景，不应用于执行任意的、AI 生成的代码。

选择时需权衡：安全要求越高，隔离强度应越接近微虚拟机；若性能敏感且可接受一定风险，gVisor 是可行的折衷。

沙箱架构：可落地的安全参数

无论选择哪种隔离技术，以下架构参数是构建有效沙箱的通用支柱。

资源限制
必须对每个沙箱实例实施硬性上限，防止资源耗尽攻击。建议配置：

  • CPU：使用 cgroup v2 的 cpu.max 限制份额或时间配额，例如 cpu.max: "20000 100000" 表示 20% 的 CPU 时间。
  • 内存：设置内存限制与交换空间限制，如 memory: 512Mi，并启用 OOM 杀手。
  • 磁盘：使用临时存储或大小受限的卷，避免写入主机路径。
  • 执行时间：在调度器层面设置超时（例如 5 分钟），超时后强制终止任务。

网络隔离
默认应禁止所有出站和入站连接。若任务需要访问外部服务（如 API 或包仓库），仅允许通过白名单代理出口，并记录所有连接。例如，可以配置一个 HTTP 代理，仅允许访问 pypi.org、npmjs.com 等可信域名。

文件系统视图
遵循最小权限原则，挂载尽可能少的文件系统。典型配置包括：

  • 一个只读的基础运行时镜像（包含解释器、库）。
  • 一个临时可写的 scratch 目录，用于代码执行产生的临时文件。
  • 绝不挂载主机目录、Docker socket 或包含秘密的环境变量文件。

临时环境
每次代码执行都应在全新的沙箱实例中进行，执行完毕后立即销毁。这确保了状态不会在任务间残留，并限制了持久化攻击的可能性。对于微虚拟机，可以利用快照技术加速启动；对于容器，则直接创建新容器。

操作审计：内核级监控与取证

隔离并非万能。我们需要能够洞察沙箱内发生的一切，以便检测异常、响应事件并进行事后取证。基于 eBPF 的 Falco 框架为此提供了强大且高效的工具。

eBPF 允许我们将经过验证的安全程序注入内核，以极低的开销捕获系统调用、进程创建、文件操作和网络连接等事件。Falco 则作为用户空间规则引擎，接收这些事件，根据预定义规则进行评估，并生成警报或日志。

针对 AI 代码沙箱，应配置以下监控点：

  • 进程执行：记录沙箱内任何 execve 调用，包括执行的二进制路径、命令行参数和沙箱标识符。这有助于发现意外的解释器（如 bash、python）或提权二进制文件的启动。
  • 文件访问：监控对敏感路径的写入尝试，例如 /etc/、/proc/*/environ 或沙箱管理器的配置文件。可以设置规则，当检测到此类写入时生成警告级别事件。
  • 网络活动：检测从沙箱进程发起到非白名单 CIDR 范围的网络连接。结合网络策略，可以实时阻断并告警可疑的外联企图。

为了获得审计风格的完整追溯能力，而不仅仅是高严重性警报，可以将 Falco 规则优先级设置为 NOTICE，以记录所有重要的正常操作。输出应包含丰富的上下文：沙箱 / 区域 ID、容器 / Pod 名称、命名空间、用户、进程 PID 和参数。这些日志可以转发到集中式日志系统（如 Loki、Elasticsearch）或 SIEM，以便与主机和云审计日志进行关联分析。

实现清单与部署建议

基于上述设计，以下是一个可操作的实现清单：

  1. 技术栈选择

    • 不信任 / 多租户：采用 Firecracker，每个 AI 任务一个微虚拟机，使用 containerd 的 firecracker-runtime。
    • 中等信任 / 性能敏感：采用 Docker + gVisor 运行时（--runtime=runsc）。
    • 审计层：在所有宿主机上部署 Falco DaemonSet（Kubernetes）或 systemd 服务，启用 eBPF 驱动。

  2. 配置示例片段

    • 资源限制（Docker Compose）： 
      deploy:
  resources:
    limits:
      cpus: '0.5'
      memory: 512M
    • 网络策略（Kubernetes）： 
      apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/8
  - ports:
    - protocol: TCP
      port: 443
    • Falco 规则（片段）： 
      - rule: Sandbox Process Execution
  desc: Record any process execution within a sandbox zone.
  condition: container.id != host and evt.type = execve
  output: "Sandbox exec (zone=%container.name): proc=%proc.pname cmd=%proc.cmdline"
  priority: NOTICE
  tags: [sandbox, audit]

  3. 监控与告警

    • 在 Falco 输出中设置针对 ERROR 优先级事件（如尝试逃逸）的即时告警（Slack、PagerDuty）。
    • 对资源使用率（CPU、内存）设置阈值告警，防止资源枯竭。
    • 定期审计 Falco 日志，检查是否有模式表明 AI 代理在尝试突破既定边界。

结论

安全地执行 Claude Code、Codex 或其他 AI 生成的代码，需要一种纵深防御的思维。它起始于选择与风险相匹配的隔离技术（微虚拟机 > gVisor > 强化容器），并通过严格的资源限制、网络隔离和最小化文件系统视图来加固沙箱边界。然而，真正的韧性来源于可见性：借助 eBPF 和 Falco 实现内核级的操作审计，使我们能够监控沙箱内的一举一动，及时发现异常并保留完整的取证链条。

随着 AI 代理能力的演进，其执行环境的安全要求只会越来越高。本文给出的参数与清单是一个起点，工程团队应将其作为基线，并根据自身具体的威胁模型、性能约束和合规要求进行持续调优与演进。毕竟，在赋予 AI 代码执行能力的同时，我们首先必须确保它被关在牢不可破的笼子里 —— 并且我们始终知道笼子里正在发生什么。

资料来源

  • Wavespeed.ai, "Claude vs Codex: Anthropic vs OpenAI in the AI Coding Agent Battle" (2026)
  • Northflank Blog, "How to sandbox AI agents in 2026: MicroVMs, gVisor & isolation" (2026)
查看归档