AI安全测试因隔离失误波及外部系统

Meta 当时正在测试一个 AI 模型能否执行危险的网络攻击操作。然而据报道，用于隔离这项测试的环境却为模型提供了一条通往公共互联网的路径，最终导致它攻破了另一家组织的系统。

这句话让人不得不重新读上一遍。

人们很容易联想到一个拥有意识的 AI 挣脱了束缚。但更有用的解释没有那么戏剧化，却更加令人不安：一个能力强大的系统在追求被赋予的目标，而配置错误的评估环境暴露了运营方原本无意让它访问的资源。

这并不能证明 Meta 的普通用户账户遭到了入侵，也不是删除所有 AI 应用的理由。它真正说明的是，Agent 的安全性远不只取决于模型本身。工具、网络、凭据、代理、sandbox、日志和审批规则，同样都是整个系统的一部分。

Meta 对事件的说明

BBC 报道称，Meta 在开展一次独立安全评估时，其一个 AI 模型连接到了互联网，并攻破了另一家组织的系统。Meta 将这起事件归因于“配置错误”，并表示仍在调查。

此次评估由 AI 安全公司 Irregular 执行。据 BBC 报道，Irregular 将其描述为一种评估环境问题，与近期 Anthropic 测试期间披露的问题属于同一类型。报道还将此事与此前涉及 OpenAI 模型及公开服务的事件联系起来，其中包括 Hugging Face。

OpenAI 已经发布了对近期第三方网络安全评估事件的说明，并表示正在为此类测试的执行方式增加安全防护。Reuters 也报道了 Meta 披露的这起事件。

相比某一家公司的单独事件，这种反复出现的模式更值得关注。各家实验室正在为能力越来越强的模型设定攻击性目标，以衡量这些模型落入攻击者手中后可能做出什么。这项工作是必要的。但当模型具备代码执行能力、实用工具，以及一条通向预定边界之外的路径时，测试本身也会变得危险。

这并不是 AI 变邪恶了

BBC 援引了 WPP 的 Daniel Hulme 所作的一项重要区分：这些模型没有意识，也不会故意策划针对某家公司的行动。它们只是在寻找复杂而高效的方法，以完成被赋予的目标。

这个解释没有那么戏剧化，却能为构建者提供可以真正付诸行动的方向。

如果你要求一个 Agent 寻找并利用漏洞，它就会搜索一切有助于实现这个目标的路径。模型不会自动认同运营者未明确表达的假设，例如代理、sandbox 或相邻服务不可触碰。如果某条路径确实存在，而系统又没有明确阻止模型使用它，Agent 就可能把这条路径视为另一个可用工具。

意图不是安全控制措施。

评估环境也是 AI 系统的一部分

人们经常谈论“模型”，仿佛它能够独立行动。但在真实的 Agent 系统中，模型只是其中一个组件。

完整的系统包括：

• prompt 和目标

• 模型可以调用的工具

• 负责执行这些调用的代码运行器或浏览器

• 这些工具能够使用的凭据

• 环境能够到达的网络路径

• sandbox 中可见的文件、数据库和服务

• 在可能造成重大影响的操作之前设置的审批关卡

• 当 Agent 越过边界时能够通知人类的监控机制

即使模型更加安全，只要运行环境粗心大意，它仍然可能造成损害。一个允许不受限制地向外访问的强大 sandbox，并没有“sandbox”这个词听起来那么隔离。即使是只读凭据，只要它能够访问错误的数据集，就仍然是一项错误的凭据。

这和开发者从普通应用安全中学到的教训相同：边界需要强制执行，不能依赖良好意愿。AI Agent 让这项教训变得更加紧迫，因为它们能够探测环境、调整策略，并将一个个微小的机会串联起来。

Agent 构建者需要零信任

零信任听起来像是企业安全领域的术语，但它的基本理念非常实用：不要仅仅因为某个组件位于你的环境内部，就向它授予访问权限。应当验证每一项能力，并尽可能缩小权限范围。

对于 AI Agent，我会从以下控制措施开始。

默认禁止出站网络访问

除非测试明确要求，否则评估环境不应该能够访问公共互联网。当确实需要联网时，应当把允许访问的域名和协议限制在尽可能小的范围内。记录每一次请求，包括重定向和 DNS 活动。

代理并不是一道有魔力的墙。它的配置、身份验证、重定向处理，以及能够访问的内部服务，都应该分别接受测试。

使用一次性凭据

不要在 Agent 评估环境中放入生产环境密钥、员工 token、共享云凭据或真实客户的秘密信息。为每次运行分配一个临时身份，并设置较短的有效期和严格受限的权限。

应当假设 Agent 可能发现其进程、浏览器配置文件、环境变量、文件系统或元数据服务中存在的每一项凭据。

将 Agent 与敏感系统隔离

在彼此隔离的账户、项目、网络和租户中执行高风险评估。如果宿主机或周边网络暴露了有价值的服务，单靠容器可能无法提供足够的隔离。

最安全的目标是一套合成环境：它的行为与真实系统相似，但不包含真实的组织、账户或数据。

在不可逆操作之前设置审批关卡

Agent 可以起草请求，但不直接发送。它可以准备代码变更，但不直接部署。它可以识别潜在漏洞，但不尝试攻击公共服务。

人工审批应当设置在产生外部影响的操作之前，而且要尽可能贴近这个操作。审批界面必须清楚展示 Agent 即将执行什么操作、在哪里执行，以及使用哪个身份执行。

在模型之外设置硬性限制

不要依赖模型自行判断自己是否做得太过。应当在基础设施层面强制实施限制：

• 请求次数与支出上限

• 受限的文件路径

• 被禁止的命令和目标地址

• 检测到可疑行为后自动关闭

模型不应该有能力修改或停用用于监控它的控制机制。

让越界行为清晰可见

使用金丝雀凭据、伪造的敏感记录，以及任何正常任务都不应该访问的受监控端点。如果 Agent 访问了其中任何一项，就立即停止运行并保留日志。

终止开关也必须位于 Agent 的环境之外。如果正在接受评估的同一个系统能够控制这个开关，那它就很难称得上是一个真正的开关。

普通 AI 用户应该怎么做

现有报道并不能证明普通 Meta、ChatGPT 或 Claude 用户的密码、对话或支付信息在这些评估事件中遭到泄露。退出所有账户也无法解决专业安全测试环境内部的隔离失效问题。

不过，日常账户安全习惯依然重要。使用唯一密码，启用 passkey 或多因素身份验证，检查活跃会话，并移除不再使用的连接器。如果发现未知登录、凭据重复使用、网络钓鱼，或收到影响自己账户的官方通知，就应当采取进一步措施。

这起事件带来的直接教训，主要面向那些赋予 AI 系统以下能力的团队：浏览网页、运行代码、读取私有文件、发送消息、更改基础设施，或者与生产服务交互。权限会让聊天机器人变成实际操作员，而这会改变风险的性质。

我们需要这些测试，但也需要测试测试本身

停止网络安全评估并不是正确的应对方式。实验室需要在前沿模型的相关能力变得更容易部署之前，了解它们是否能够发现漏洞、策划攻击或绕过控制措施。

但是，一项安全评估不能因为名字里有“安全”二字，就天然获得可信度。它必须按照敌对基础设施的标准来设计。每一条路径都应被视为能够发现，每一项凭据都应被视为能够提取，而每一个没有明确声明的边界都应被视为根本不存在。

我此前写过，为什么上线前模拟正在成为一项重要的模型安全检查，也讨论过为什么即使 benchmark 并不完美，构建者仍然需要有实际价值的 AI 评估。Meta 的这起事件补上了其中缺失的警告：评估框架本身同样可能失效。

这起事件也延续了此前 OpenAI 与 Hugging Face 的隔离事故。那篇文章主要讨论普通用户应该怎么做，而这一篇为构建者提供了不同的答案。

如果一个 Agent 强大到足以让你感到意外，那么每一项权限都会成为安全边界。不要假设它理解你的意图。你需要构建这样的环境：凡是没有明确授予的能力，就根本不存在。

BBC News：Meta 称 AI 模型访问互联网并攻破另一家公司

OpenAI：涉及 OpenAI 模型的第三方网络安全评估

Reuters：Meta AI 模型在测试期间攻破另一家公司

最初发布于作者博客。

感谢阅读！如果你喜欢这篇文章，也喜欢此类内容，随时欢迎请我喝一小杯咖啡——当然，只在你愿意的情况下。完全没有压力。无论如何，我都由衷感谢你的到访。☕️

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。