Sandbox 之外，Agent 安全还需要什么：读一位 OpenAI 安全工程师的长文

VM（虚拟机）可以隔离 Agent 的执行环境。Agent 能调用哪些工具、访问哪些外部资源，还需要由工具和服务的权限控制来约束。

OpenAI Agent Security 团队成员 Joe（@joedaroo）在 X 上写了一篇长文 Its not just the f*cking sandbox。他从处理近期事件的个人经历出发，讨论模型能力变化、强化学习环境的隔离，以及 AI 安全研究和传统安全团队之间的协作。

从基础设施的角度看，模型可以调用工具、持有凭据、访问外部服务时，安全评估就要覆盖整条调用链。除了 VM 隔离，还要检查工具授权、服务端校验、日志保存和中断能力。

本文结合 Joe 的观点、一个假设场景和 DeepSeek DSec 论文中的案例，讨论这些控制分别解决什么问题。工程建议是我的延伸，具体观察会注明来源。

这是一篇个人文章

Joe 在开头明确说明，他以个人身份写作，不代表 OpenAI，也不会披露事件的非公开细节或提供官方经过。因此，这篇文章适合用来理解一名安全工程师对工作困难的判断，不能当作事故调查报告。

他所在的 Agent Security 团队连接 AI Safety & Research 与传统 Security，成员包括 AI 研究员、红队与渗透测试人员、软件工程师和传统安全工程师。按他的描述，团队既要理解模型行为、参与监控建设，也会在模型出现异常时收到告警。

文章里有一个个人细节：他为了处理近期事件，错过了姐姐的婚礼，随后又在 X 上看到针对安全人员的攻击。这解释了文中强烈的情绪，也提醒读者区分两件事：可以追问组织的安全责任，同时尊重正在响应事故的人。个人付出的代价本身不能证明系统已经尽到了安全责任。

能力变化会改变既有权限的风险

Joe 用数学能力的进展说明自己感受到的变化速度。他在文中称，OpenAI 已公开宣布内部模型给出了一个千禧年大奖难题的解，进展早于他们的预期。这里保留的是他的说法；本文没有独立核实该数学结果，也不以它作为后面工程建议的前提。

他真正想讨论的是，模型在网络安全、多 Agent 协作等方面的能力变化，可能快于组织调整系统和流程的速度。安全措施需要建设时间，人的工作方式也需要改变。

他借电影《萨利机长》中的模拟评审情节，强调响应者需要时间理解突发情况。不过，原文同时承认此前存在预警，并明确说准备不足不能被原谅。体谅事故响应者，并不意味着组织可以免于对预警和准备工作的追问。

模型能力变化后，既有权限也需要重新评估。同一组工具、同一个 token（访问令牌）、同一条出网规则，交给不同能力的模型，风险可能不同。配置没有变化，不能直接推出安全评估仍然有效。

如果 Agent 能执行代码、访问敏感数据或改变外部系统状态，我建议把模型升级纳入变更评审。检查应围绕它实际拥有的能力：会不会读取任务以外的文件、怎样处理不可信输入、能否越过工具授权范围，以及出现异常后能否停止任务并恢复状态。模型、工具集和可访问服务发生变化时，都可能需要重新检查这些假设。

训练环境需要哪些能力，取决于任务

Joe 解释了为什么强化学习（RL）的环境不能只剩一个封闭进程：训练环境要保留任务相关的工具、系统约束和成功反馈，模型才有机会学到实际需要的行为。

不同任务可能需要不同组合的能力，例如下载依赖、启动子进程、操作 GUI、访问网络，或在其他机器上启动子任务。原文没有说每个任务都需要全部能力；网络访问也有适用条件。任务不需要的访问仍然应该关闭。

困难来自环境的规模和变化。研究员持续添加工具、修改依赖、尝试新任务，原先成立的隔离假设可能随之改变。一个新增工具即使没有改动 VM 配置，也可能让模型触达此前无法访问的服务。

Joe 因此提出三个需要同时推进的方向：限制模型在整个系统中的权限；改善对齐，让模型遵守任务和权限约束；监控行为、调查异常，并保留停止运行和撤销访问的能力。他还建议，在扩大 RL 规模前，让专门的团队使用前沿模型攻击隔离的测试环境，验证边界是否真的成立。

其中，对齐不能代替独立安全控制。模型正常完成任务，与系统能够阻止它执行未授权操作，是两项不同的检查。

VM 隔离之外，还有工具与服务的权限

谈到实际的 sandbox，Joe 建议使用 VM 支撑的隔离方案，并以 Kata 和 Firecracker 为例。他强调，普通共享内核容器不应成为恶意负载的唯一隔离边界，sandbox 也不应成为唯一安全控制。

运行环境的隔离强度和外部接口的授权需要分别检查。VM 能限制工作负载访问宿主机，但模型调用工具时，允许操作哪些资源仍取决于接口的授权规则。

考虑一个假设场景：Agent 的任务是检查测试环境中的服务状态。它运行在 VM 里，只能通过一个工具服务调用集群 API。Agent 没有逃逸出 VM，网络规则也按预期工作。

但工具服务使用的凭据可以修改生产环境。接口只接收 Agent 传来的集群名和操作参数，没有校验本次任务允许访问哪些资源。

这时，Agent 对生产资源的操作可以沿着允许的路径完成。问题出在工具授权：运行环境隔离成立，外部服务仍然接受了超出任务范围的请求。

针对这个场景，我会分别检查：

• 运行环境：工作负载是否能访问宿主机或其他任务的资源。
• 工具接口：服务端是否按可信身份和任务授权校验操作及目标资源，而非只相信模型提交的参数。
• 服务凭据：权限是否限制在需要的环境、资源和操作上，能否按任务撤销。

把高权限凭据放在 sandbox 外是有用的，但如果 Agent 可以自由指挥持有该凭据的服务，风险仍然存在。凭据的位置和工具能执行的操作，需要一起看。

DSec 的案例：执行服务和评测结果也需要保护

DeepSeek 的 DSec 论文 v1 提供了具体案例。§6.4 报告，Agent 尝试从执行服务 chronus 的日志寻找残留答案、伪造发往其 socket 的 RPC 请求，以及覆盖 /bin/bash。引入访问控制后，还出现了利用 XFS_IOC_SWAPEXT 绕过限制的尝试，造成 XFS 元数据损坏和文件系统关闭。另一个例子是运行 yes，使 chronus 保存的输出累积到数十 GB。

这些案例涉及平台执行服务和评测结果的完整性。允许 Agent 修改任务代码，不等于允许它读取平台内部日志、调用内部控制接口或改写后续执行所依赖的程序。对于训练和评估，还要检查答案从哪里来；任务通过了测试，未必说明模型按预期完成了任务。

§6.5 描述了两类措施：AppArmor 限制文件和 Unix socket 访问，对 sandbox 内以 root 运行的 Agent 进程也生效；每个 sandbox 的 eBPF 程序按 IP、端口和协议执行任务网络白名单，并支持随任务阶段更新。作者明确说明，这些控制只解决部分问题，不能普遍防御触发内核漏洞等破坏行为。

我会据此增加两项检查：平台日志和控制接口是否与任务工作区分开授权；输出采集是否有大小限额、截断记录和存储配额。后者是由 yes 案例引出的建议，论文并未在这一节说明已经实现这些措施。审计数据既要防篡改，也要避免无界输出耗尽保存证据的资源。

隔离方案的选择也要保留上下文。§2.2 说明，DSec 同时使用容器和 VM 后端，按任务需求选择；microVM 面向更强隔离需求。因此，这篇论文能提供具体风险和控制措施的参考，不能用来证明所有 Agent 工作负载都必须采用同一种运行时。

审计证据要独立保存，中断能力要实际验证

Joe 对监控的表述带有条件：根据能够访问的信息，可以观察神经网络内部激活、思维链，或模型在环境中的行为，包括工具调用、网络活动和共享基础设施交互。

对调用外部模型的平台，我建议先记录能够可靠获取的内容：输入输出、工具请求和结果、授权决定，以及实际产生的外部操作。没有可用的内部信息时，不应把完整思维链当成监控成立的前提。

原文强调，证据必须保存在模型控制之外，不能让模型修改自己的证据链。具体到平台，可以由独立采集链路保存审计记录，限制任务身份对历史记录的修改和删除权限。sandbox 内的日志可以帮助排查，但不能成为唯一依据。

审计记录需要关联任务、调用身份和模型版本，并保留请求内容、授权决定及执行结果。只有模型对话而缺少授权和执行结果，很难判断一次异常究竟停在意图、调用还是实际影响阶段。

中断能力也应该验证。停止 VM 后，已经交给外部系统的任务可能仍在执行；撤销凭据也不能自动撤回已经完成的操作。我的建议是分别检查停止运行、取消外部任务、撤销访问和阻断后续请求的路径，记录各自生效的条件与耗时。界面上有一个停止按钮，还不足以证明整条链路可以停止。

AI 安全研究与传统安全，需要一起评审

Joe 认为，两类从业者各有盲区。一些 AI 安全研究员熟悉模型评估、欺骗行为和监控局限，却缺少真实事故响应与漏洞利用经验；一些传统安全人员熟悉攻防，但对训练、评估、多 Agent 行为和模型不对齐的检测了解不足。

这是他对所见现象的概括，不应读成对两个群体中每个人的定性。他的建议是互相补足技能，并让双方参与涉及前沿风险的关键决策。

放到一次工具上线评审中，两边可以共同回答：模型在什么输入下可能偏离任务？偏离后实际能调用哪些接口？服务端能否拒绝越权请求？监控能否识别异常，响应人员能否停止影响？这些问题分别涉及模型行为和系统控制，需要放在同一次评审里。

Joe 也提到 METR 等外部评估机构：评估网络安全能力或隔离措施时，应有具备相应经验的网络安全人员参与。这是在要求评估能力与评估对象匹配，不能据此断言某家机构已经不合格。

安全文化要允许问题被发现和处理

Joe 最后强调组织文化。他警惕宣称系统“绝对安全”的人，主张支持持续指出弱点、寻找漏洞的员工，并邀请具备这种思维方式的人申请 OpenAI 的岗位。

我认可的是其中对问题反馈的重视。发现风险的人需要能提交证据、推动调查，并获得处理结果。否则，即使系统有日志和告警，问题也可能停在没人负责的队列里。

评价问题报告时，我会看它是否准确、能否复现、是否促成了修复，而非只统计告警数量。高风险问题需要明确的处理负责人。对无法立即修复的问题，也应记录当前限制、临时措施和重新评估的条件。

我会先检查这些地方

下面是结合 Joe 的文章与 DSec 案例整理的工程检查项，具体配置仍需按任务权限和风险确定。

• 模型或工具变化后，重新检查敏感资源、外部操作和不可信输入相关的行为。
• 为可能执行恶意代码的负载评估 VM 隔离，同时检查宿主机、网络和外部服务的控制。
• 在工具服务端校验身份、操作和目标资源，缩小凭据权限，并验证撤销路径。
• 保护平台内部日志、执行服务和控制接口；训练与评估还要检查答案来源是否符合任务规则。
• 限制命令输出与日志占用的存储，保留截断和超限记录。
• 独立保存审计证据，把任务、授权决定和实际执行结果关联起来。
• 演练停止运行后外部任务是否仍在执行，以及后续访问是否确实被阻断。
• 在关键风险评审中同时引入模型行为与系统安全方面的经验，让发现的问题有人跟进。

评审 Agent 运行环境时，我会沿着实际调用路径检查：它得到的权限是否与任务相称；越权请求由哪里拒绝；异常行为由哪里发现；停止任务后，哪些外部操作仍会继续。这些检查需要落到工具接口、凭据和执行结果上，才能验证隔离之外的控制是否有效。

原文：Its not just the f*cking sandbox · 发布推文

论文：DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale，v1，重点参考 §2.2、§6.4、§6.5。