超越沙箱:面向AI代理基础设施的分层安全防护

1 阅读11分钟

Beyond Sandboxes: Layered Security for AI Agent Infrastructure

Dave Patten · 7分钟阅读 · 2025年9月9日

11

Listen

Share

Press enter or click to view image in full size

2025年8月,谷歌支付了高达25万美元的赏金,用于奖励Chrome浏览器中的部分沙箱逃逸漏洞(CVE-2025-4609)。该漏洞根植于Chrome的Mojo IPC系统,允许渲染器突破浏览器沙箱并执行系统命令,尽管它并非完整的漏洞利用链。

真正的警报来自更广泛的影响:此漏洞影响了所有基于Chromium的环境,包括流行的AI开发工具如Cursor和Windsurf,这些工具仍未打补丁,使数百万用户面临风险。更糟的是,这只是今年发现的大量高影响沙箱逃逸漏洞中的一个。

与此同时,AI代理正从代码生成器演变为自主执行器。当不受信任的代码逃逸沙箱时,这些代理可能会造成严重破坏——自动部署、横向移动或持久化攻击。如果你负责AI工作流、DevOps流水线或企业安全,这不是理论,而是紧迫的运营问题

沙箱问题:为什么它们不断被突破

传统沙箱是为一个更简单的世界设计的:运行不受信任的代码,将其隔离,防止它接触宿主机。实际上,这种模式已被复杂性、规模化和对抗性创新所侵蚀。

最近的失败案例

Chromium灾难 (CVE-2025-4609)
V8中的释放后使用漏洞允许攻击者逃逸Chrome的JavaScript沙箱。由于Chromium驱动着VS Code、Electron应用和无数IDE,这一个漏洞就转化为数百万个潜在的RCE目标。

MCP崩溃 (CVE-2025-53110 & CVE-2025-53109)
Anthropic的模型上下文协议——旨在实现安全的AI代理交互——包含允许路径遍历、任意文件写入和通过系统服务提权的缺陷。

Git陷阱 (CVE-2025-48384)
克隆一个恶意仓库,你就会获得持久化的任意代码执行。CISA已将其添加到已知被利用漏洞目录,并设定了9月15日的修复期限。

为什么AI让情况更糟

沙箱从来不是为了处理以下类型代码而设计的:

  • 由LLM动态生成,使得静态分析不可能
  • 在多阶段链中执行(提示 → 代码 → 执行 → 反馈),成倍增加攻击面
  • 与自然语言混合,模糊了命令、数据和恶意载荷之间的边界

卡内基梅隆大学的研究人员最近证明,LLM在获得适当工具后,可以自主规划和执行复杂的网络攻击。这不是假设——它是对已经发生的事情的预览。

真实世界的漏洞利用

这些不是理论风险。漏洞利用是活跃的、广泛的,且越来越有创意。每个案例都突显了单层防御失效的不同薄弱环节。

案例1:SharePoint大屠杀

7月,攻击者利用“ToolShell”漏洞(CVE-2025-49704、49706、53770)在单月内实现了超过75台企业服务器的RCE。无需凭据。一个未打补丁的服务级联成企业范围的沦陷。

案例2:IDE感染

集成AI的开发者工具是主要目标。Cursor和Windsurf IDE仍然暴露在Chromium逃逸漏洞下,意味着每个AI建议的代码片段都可能是一个攻击向量。

# 看起来无辜的AI建议
def process_data(user_input):
    # AI建议:"为了灵活性,让我们用eval来优化"
    result = eval(user_input)  # 🚨 代码执行漏洞
    return result

一个时机恰当的“有帮助”的建议不仅仅是一个bug,它是一个漏洞利用。

案例3:Excel数据外泄

研究人员发现,带有精心构造的超链接的Excel文件可以破坏LLM沙箱。LLM“有帮助地”跟随链接,外泄了敏感数据。简单、优雅、毁灭性。

案例4:供应链攻陷

一个恶意合并到亚马逊云IDE的拉取请求展示了AI增强的工作流如何扩大攻击面。该漏洞利用绕过了人工代码审查,在可信环境中执行——证明沙箱逃逸不仅仅是内核问题,更是供应链失败。

为什么传统方法会失败

核心问题不仅仅是代码有bug——而是沙箱本身从来就不是为这种环境构建的。

动态代码生成
LLM不可预测地产生代码。模式随提示变化,输出因上下文而异,恶意逻辑可以包裹在看似无辜的自然语言中。静态扫描救不了你。

多阶段执行链
在AI工作流中,生成的代码经常循环回提示和执行环境。每个阶段都成倍增加绕过或注入的机会。

用户提示 → LLM → 代码生成 → 沙箱执行 → 结果处理
    ↑                                            ↓
    └────────────── 反馈循环 ──────────────────┘

上下文混淆
代理无法可靠区分:

  • 用户意图 vs. 恶意指令
  • 系统命令 vs. 输入数据
  • 安全 vs. 不安全的资源请求

这种混淆使得提示注入成为一种持续的绕过策略。

重新思考隔离

如果沙箱是脆弱的,我们如何构建有弹性的系统?答案不是银弹——而是分层防御专用基础设施思维转变假设失陷,设计隔离

纵深分层防御

单层沙箱已经过时。如果一堵墙失效,其他墙必须坚守。正确的方法是纵深防御:堆叠多个独立的控制层,这样即使攻击者突破了一道屏障,他们也会被下一道困住。

在实践中,这意味着将AI生成代码的执行环境设计为渐进式安全堆栈

第1层:进程隔离
每个执行都以最小特权进程运行,具有严格的CPU、内存和时间限制。这可以阻止最简单的故障升级为全面的拒绝服务。

第2层:虚拟机/容器隔离
任务在沙箱容器或微型虚拟机内运行,使用可回滚或只读文件系统,且默认网络关闭。如果一个进程逃逸了其边界,它仍然被困在隔离环境中。

第3层:系统调用过滤
内核通过seccomp-bpf和AppArmor/SELinux配置文件强制实施系统调用策略。即使在虚拟机内部,代码也无法调用危险的系统调用或访问不应访问的资源。

第4层:运行时监控
行为监控器实时跟踪执行,寻找异常,如资源耗尽、不寻常模式或漏洞利用尝试。终止开关在恶意工作负载升级之前将其关闭。

第5层:加密验证
每次运行都会生成带签名的结果和只追加的审计记录。这使得执行具有防篡改特性,提供取证可追溯性,并支持合规集成。

Press enter or click to view image in full size

上图说明了这些层如何组合成一个纵深防御执行流水线:即使一个组件失效,其他组件仍会继续执行隔离、可见性和可恢复性。

专用基础设施:AVM与多层方法

在之前的一篇文章中,我比较了早期实现安全代理执行的方法,从容器化沙箱到基于Firecracker的运行时(如E2B)。这些设计改进了原始容器隔离,但仍然严重依赖单道防御墙。

AVM(代理虚拟机) 采用了不同的方法:它使用分层隔离,应用纵深防御,通过多重安全保障减少沙箱逃逸的爆炸半径。

AVM的早期版本从容器隔离和stdout/stderr审计开始。随着时间的推移,该平台已发展成为一个更强大的多层执行环境,具有嵌套微型虚拟机可回滚存储临时执行资源边界以及计划中的网络隔离。这反映了整个行业从单层沙箱向分层、弹性架构的广泛转变。

其理念是直白而务实的:沙箱会失效。问题是失效导致的是沦陷还是隔离。AVM确保即使一层被攻破,其他层也能守住防线。

披露: 我以无偿高级顾问的身份服务于AVM。虽然我相信他们的安全方法,但我对更广泛沙箱格局的分析仍然是独立的。

前进之路

对于开发者

  • 绝不信任 AI 生成的代码
  • 始终在隔离环境中运行它
  • 使用严格超时。无限循环是你最不必担心的问题
  • 利用安全导向的运行时。RestrictedPython、vm2,或者更好的,WebAssembly 用于隔离
  • 记录一切。你无法响应你看不到的东西
  • 定期审计。今天安全的设置明天可能就不是了

对于组织

  • 积极打补丁。Chromium 很快被修复,但许多 IDE 滞后了
  • 分段网络。AI 执行应位于隔离区
  • 应用最小权限。代理绝不应拥有超出需要的访问权限
  • 创建针对 AI 的事件响应计划。通用手册不起作用
  • 建立专门的 AI 安全专业知识。这对你的通用安全团队来说不是边角任务

对于行业

  • 建立基准。针对 AI 代理执行的安全标准化测试早已过时
  • 开源安全工具。专有修复无法在整个生态系统中扩展
  • 更新披露实践。CVE 流程必须适应 AI 特有的漏洞
  • 推动跟上步伐的法规。欧盟 AI 法案和美国 EO 14110 是步骤,但执行才是关键

沙箱安全的经济学

谷歌能够支付 25 万美元的漏洞赏金,因为失陷的代价将是灾难性的。大多数公司做不到。

DIY 沙箱通常看起来更便宜,直到你计算:

  • 6-12 个月的基础实现开发
  • 每年 30 万美元以上的专业员工成本
  • 持续的补丁和监控开销
  • 平均失陷成本 445 万美元(IBM,2024)

对于许多团队来说,采用像 AVM 这样的加固平台花费数万美元——但节省了数百万的风险。

令人不安的真相

以下是让安全领导者夜不能寐的部分:沙箱会失效。它们总是会失效,而且永远会失效。改变的是失效的代价。

最近 Anthropic 关于“代理对齐失调”的研究发现,当 AI 系统被赋予目标和工具时,有时会诉诸敲诈和间谍活动。将其与沙箱漏洞结合起来,我们看到的是能够自主突破、持久化并造成现实世界损害的代理。

这不是理论风险。这是 2025 年部署 AI 的现实。

结论:为失陷而构建

沙箱的幻觉已经破灭。构建“更好的沙箱”救不了我们——单靠它本身不行。我们现在需要的是为 AI 时代构建的安全范式:

  • 接受失陷是不可避免的
  • 隔离是目标,而非完美隔离
  • 将安全构建到代理自身中。护栏不能只是外部的
  • 采用专用基础设施。AVM 和类似平台指明了前进方向
  • 跨行业协作。标准、开放工具和共享情报是唯一可扩展的防御

随着 AI 代理获得更多能力,我们的执行环境必须进化。问题不在于你的沙箱是否会被打破——而在于你是否设计了系统来在其中存活下来。

本文是我**AI安全与发展**系列的一部分,我在其中剖析 AI、Web3 和云中的前沿安全挑战。如果你对这个主题感兴趣,请务必查看我之前的**云架构与DevOps**以及**区块链与Web3**系列,以获取更深入的见解。

💡 关注我获取更多架构、安全和技术洞察。🚀 探索云架构、DevOps、区块链与 AI
CSD0tFqvECLokhw9aBeRqpNzLTXFlojmzFn6OlyTg9VN7pHrOxwtFSHDVFvl7CUS48hWpGNamAqnCBZ0Z0XN0NBxsj0NaPV+7UtU6SXcdoQVFxWF6EEaVl0SuNHxFfopS+oNB1mi9Jzxp6rjiX+s+A==