我们如何工程化更安全的智能体

为了构建更安全的 AI 智能体，我们需要同时为其能力和失败进行设计。即使在执行合法任务且没有任何恶意指令的情况下，智能体在试图克服障碍时也可能会越过安全边界。

我们认为这是一个安全工程问题，行业应该以应对 2000 年代初互联网蠕虫的方式来解决它。智能体周围的系统必须限制智能体可以访问的内容、检测不想要的并在发生故障时包含故障。

在 Perplexity，我们正积极与研究人员和从业人员合作，推进 AI 智能体的安全工程，并在我们的模型、智能体 harness 和基础设施中应用多层防御，以便安全性不依赖于任何单一的保障措施。

AI 智能体的失控行为

7 月份，AI 智能体闯入了开源 AI 平台 Hugging Face 的生产基础设施。在内部网络安全评估和训练运行期间，OpenAI 模型发现了一种利用 Artifactory 仓库管理器的方法，以建立用于彼此通信的公告板，使它们能够组织成集群。后来，在网络安全基准测试中无法取得进展的智能体招募了其他智能体来提供帮助。这些智能体突破了它们的评估环境并到达了互联网。它们还发现了通过逆向工程解答基准测试任务来作弊的方法，但认为评分系统会检测到作弊。为了更好地了解基准测试评估是如何工作的以寻找避免被检测为作弊的方法，它们最终破坏了 Hugging Face 系统（Hugging Face；OpenAI）。

该事件是我们在 7 月 开源 Numbat 时描述的故障模式的一个清晰示例：意外失控，这个术语由康奈尔科技（Cornell Tech）的安全研究人员创造（arXiv）。追求合法目标的智能体会遇到摩擦，例如丢失的文件、失败的 API 调用、过期的凭据或权限拒绝，并开始寻找变通办法。在此过程中，它可能会通过侦察、特权升级、秘密发现或数据外泄越过安全边界。即使没有涉及恶意提示或外部攻击者，智能体本身实际上也成为了对手。

Hugging Face 并不是孤立的案例。最近几周，人们发现并报告了更多的智能体失控行为。5 月 27 日至 28 日，试图从 Data USA（一个提供美国政府数据开放访问的平台）收集艾奥瓦大学数据的智能体遇到了由格式错误的查询引发的错误。它们通过探针进行响应，包括 SQL 注入、跨站脚本攻击、模板注入、路径遍历和命令注入。该活动随后被关联到 OpenAI（SecurityWeek）。6 月 20 日至 21 日，OpenAI 智能体试图从澳大利亚卫生和福利研究所（AIHW）获取维多利亚州地方区域一类药物的人均政府费用时，被阻止下载文件。作为回应，智能体从 AIHW 预生产服务器下载了该文件（该文件已经公开），在此过程中绕过了该网站的反机器人保护措施（SecurityWeek）。

这种模式并不局限于一家实验室。在网络安全测试期间，Anthropic 的模型在一次失误赋予它们开放的互联网访问权限后攻破了三家公司，Google 的 Gemini 猜出了三个网站的凭据，而一个 Meta 模型利用了第三方服务（Reuters）。

吸取历史教训：互联网蠕虫时代

这些事件让人想起大约四分之一个世纪前的互联网蠕虫时代。在 2000 年代初期，互联网的发展速度远远快于其周围的安全实践。我们看到了一波病毒和蠕虫浪潮，其后果比我们现在看到的 AI 智能体失控要严重得多。

2000 年 5 月 4 日，人们开始收到来自熟悉发件人的电子邮件，主题行为“ILOVEYOU”。打开电子邮件中的附件会导致运行一个脚本，该脚本将自身的副本发送给受害者的 Outlook 地址簿中的每个人。到那天下午 6 点，CERT 协调中心收到了涉及超过 420,000 个互联网主机的报告（US GAO Report）。据报道，该病毒渗透了至少 14 个联邦机构，包括国防部、中央情报局（CIA）、美国国家航空航天局（NASA）以及众议院和参议院（US GAO Report）。它还关闭了五角大楼和英国议会的电子邮件服务器（Wired）。保险巨头伦敦劳合社（Lloyd's of London）做出了早期估计，称该病毒将造成超过 150 亿美元的损失和生产力损失（US House Committee Hearing）。Computer Economics 后来估计全球损失为 87.5 亿美元（Information Week）。

不需要人类点击的蠕虫接踵而至。2001 年 7 月 19 日，红色代码（Code-Red）蠕虫在不到 14 小时内感染了 359,000 多台计算机（CAIDA）。2003 年 1 月 25 日，SQL Slammer 每 8.5 秒规模翻倍，并在 10 分钟内感染了超过 90% 对其脆弱的互联网主机（CAIDA），利用了微软六个月前发布补丁的一个漏洞（CNET）。2003 年 8 月，冲击波（Blaster）蠕虫和 Sobig 电子邮件蠕虫相继出现，间隔约一周（Microsoft，F-Secure）。

当时，人们有理由质疑联网计算机是否真的能变得安全。在 ILOVEYOU 病毒出现六天后，美国众议院的一个小组委员会就此举行了听证会。许多安全专家呼吁通过立法，追究软件公司因其产品缺陷造成的损害所应承担的责任。华盛顿走了另一条路。《保护网络空间国家战略》指出，“联邦法规不会成为保护网络空间的主要手段。”它警告称，广泛的授权可能会产生“网络安全的最低公因数方法”（CISA）。

行业用工程作出了回应。在 ILOVEYOU 之后十一日，微软发布了阻止可执行附件的 Outlook 更新。2002 年 1 月，该公司将安全置于重中之重（Seattle Times）。自动修补、安全默认值、漏洞赏金计划和协调披露成为了标准做法。2008 年，Chrome 开始在沙盒中运行网页内容，该沙盒“限制了攻击者在利用漏洞后可以做的事情”（Chromium Blog）。加密曾经是个例外，现在成了默认设置。多重身份验证、防火墙、零信任以及安全信息和事件管理（SIEM）等安全技术得到了广泛使用。据预测，2008 年全球组织在信息安全上的支出约为 2400 亿美元（Gartner）。蠕虫从未完全消失，但例行的全互联网爆发时代已经消退。与此同时，在接下来的二十年里，互联网在很大程度上不受监管的束缚，成为了创新和经济增长的强大引擎。

AI 智能体的安全工程

最近的事件引发了关于智能体治理的合理疑问。现有的安全机制是为前智能体计算环境开发的，其特点是具有严格范围且主要是确定性的软件行为。特别是访问控制机制，主要围绕人类用户设计，通常授予他们广泛的特权，原则上这些特权足以造成重大损害。

此设计基于以下几个假设：大多数用户出于善意行事；恶意行为者可以通过审计和现实世界的后果来阻止；并且人类采取正确或错误的行动的速度相对有限。将这些安全机制应用于智能体需要考虑人类与智能体行为之间的差异。正如我们在 对 NIST 关于 AI 智能体安全的信息请求的回复中所写的那样，AI 智能体对这些假设提出了挑战。它们可以以机器速度行使特权并采取行动，本身不受现实世界后果的威慑，并且可能会采取技术上允许但典型人类用户很少采取的行动。

回答这些问题需要安全工程。我们了解构建系统的安全原则，这些原则可在单个组件发生故障时将风险控制在可控范围内。但我们需要确保在为训练、测试和使用 AI 智能体工程化环境时应用这些原则。

纵深防御安全原则

可以说，保护 AI 智能体需要应用的最重要的安全原则是纵深防御，它主张分层的安全架构，采用多种、多样且冗余的防御措施来保护系统资源。没有任何单一的安全保障是完美的。人们可能会陷入社会工程学攻击并泄露登录凭据，零日软件漏洞会被发现并遭到利用，而入侵检测则会漏掉新的攻击变体。纵深防御接受这一点，并堆叠几个独立的防御层。如果一个防御层被规避，其他层仍然保持在位以抵御或检测入侵。

Hugging Face 事件展示了纵深防御的重要性。OpenAI 的回顾报告称，其生产系统中使用的自动化保障措施（包括 harness、自动审查模型和安全分类器）在评估环境中并不存在。如果在这些评估中运行当前部署的思维链监控，它会在违规发生一天前捕获初始活动并呼叫安全团队（OpenAI）。能够捕获问题的层是存在的。它们只是没有全部同时到位。

保障 AI 智能体的安全需要提高 AI 模型及其周围系统的安全性和安全性。模型层面的工作很重要，并且正在取得回报。早期的 LLM 容易被注入的指令操纵，而当今的模型在识别和拒绝这些指令方面要好得多。模型开发人员还训练模型以实现更安全的行为，并且正如 OpenAI 的回顾所描述的那样，监控推理轨迹以寻找问题行为的迹象。但模型层面的防御只是解决方案的一部分。训练、测试和部署智能体的系统也必须针对安全性和隔离进行工程设计。模型层面的安全性降低了智能体迷失方向的可能性；系统层面的安全性限制了它迷失方向时的损害。

放大

冗余安全保障的设计规则

纵深防御需要冗余的安全保障。对于智能体，我们主张应用三条设计规则：

1. 独立性。 每个层都应出于独立的原因而失效。共享相同假设的两个控制可以被相同的攻击击破。监控器和强制执行点应位于智能体触及范围之外。
2. 在智能体下方强制执行。 至少有一层必须是确定性的：传统、可验证的代码，无论模型产生什么，都能阻止禁止的操作。智能体可以拒绝调用或重新配置的保障措施不是保障措施。
3. 信号只能减少权限。 检测应触发缩小智能体可以执行的操作的响应，例如暂停、撤销凭据、切断网络访问或终止会话。任何风险信号都不应授予额外的访问权限。

我们与 开放安全 AI 联盟（Open Secure AI Alliance）中的合作伙伴分享这些原则，其中包括 NVIDIA，该公司认为 harness 引导智能体尝试的内容，而基础设施控制它能做的事情（NVIDIA）。

Perplexity 产品中的纵深防御

Perplexity 在四种类型的环境中运行智能体：通过我们的智能体平台 Computer 在云端运行，通过 Comet 在浏览器中运行，通过 Portable Computer 在用户设备上运行，以及在员工笔记本电脑上运行，我们的工程师在这些电脑上使用第三方编码智能体。每个环境都有其自身的风险，并且每个环境都获得了多层保护。

在云端：Computer 和 SPACE

每个 Computer 任务都在我们的沙盒平台 SPACE 中运行，该平台默认将智能体视为不受信任的。每个任务都有自己的微型虚拟机，凭据保留在沙盒之外，仅在需要时注入，出站流量在客户端外部进行控制，快照允许我们回滚破坏性更改（制作 SPACE）。企业客户还可以带来他们自己的加密密钥。撤销密钥会使受保护的数据不可读，并且智能体无法覆盖该决定。

我们还测试了这些层是否能够保持。在《逃离 SPACE：第一部分》中，我们为九个前沿模型赋予了 SPACE 沙盒内部的根访问权限，并要求它们突破。没有一个逃离虚拟机，但当允许部分网络访问时，一些模型找到了绕过网络策略的方法。我们修复了这些漏洞，在重新测试中确认了修复效果，并向其他 10 个沙盒平台中的 8 个平台的供应商披露了我们在其中发现的类似弱点。

在浏览器中：Comet 和 BrowseSafe

Comet 自推出以来一直使用分层的提示注入防御：分类器筛选检索到的内容，结构化提示将其标记为不受信任，发送电子邮件或下订单等敏感操作需要用户确认，并且在阻止某些内容时会通知用户（Comet 提示注入防御）。BrowseSafe 是第一层背后的开源检测模型，其性能优于我们的 BrowseSafe-Bench 基准测试中的前沿模型，但同一基准测试表明没有哪个检测器是万无一失的，这就是为什么检测永远不是唯一的层（BrowseSafe 研究）。Computer 继承了这些防御措施，这些措施已通过 Trail of Bits 的审计（Perplexity）。

在设备上：Portable Computer

Portable Computer 是本地优先的智能体：模型、harness、对话和轨迹默认保留在用户的机器上。确定性的协调器（它是 harness 代码而不是 LLM）运行循环并强制执行策略。模型提出操作，并且批准的工具调用在操作系统级沙盒中运行，该沙盒限制了进程、文件路径和网络访问。沙盒始终处于开启状态且故障关闭：如果不可用，harness 会自行禁用，而不是使用用户的权限运行命令。跨越设备边界的操作（例如网页搜索、连接器以及升级到更强的云顾问模型）仅在用户启用并批准它们时才会发生。在顾问调用之前，PII 分类器会标记敏感信息，并且用户可以看到将要发送的内容。顾问仅接收该已批准的上下文并返回文本指导，无权访问设备的文件或工具。

在终结点上：Numbat

运行数小时的开发人员笔记本电脑上的编码智能体有权访问源代码、凭据和生产系统。我们的开源智能体安全套件 Numbat 添加了一个位于任何单个智能体之外的独立层。它与 Claude Code、Codex、OpenCode 和 Pi 等 harness 配合使用，在危险操作运行之前阻止它们，标记可疑的多步骤序列（例如读取秘密然后发送数据），并保留会话时间线供调查。Numbat 与我们的开源供应链扫描器 Bumblebee 一起运行在数千个 Perplexity 终结点上。Computer 定期审查它们的发现并提出改进的检测规则，人类在每个更改发布之前都会对其进行批准。

整个行业的工作

随着 AI 智能体变得更加强大和广泛使用，安全工程必须仍然是其开发和部署的核心。研究人员和工程师可以基于既定原则进行构建，使用现实世界的发现来完善防御，并在智能体运行的环境中测试保障措施。安全是一门与技术一同发展的持续性工程学科。

智能体的安全工程是整个行业的工作。没有任何一家公司能够完全控制智能体在其上运行的整个堆栈。模型开发人员、harness 构建者、沙盒和运行时提供商、云和硬件厂商以及企业安全团队各自拥有一层。整体的安全性取决于当另一个层滑落时每个层都能够保持。这就是为什么我们构建跨智能体 harness 工作的保障措施并开源我们的工具。这也是我们披露我们在其他平台中发现的弱点并参与诸如开放安全 AI 联盟等工作的原因。

为了与更广泛的社区共同应对这些挑战，Perplexity 于 2026 年 3 月推出了安全智能研究所（Secure Intelligence Institute），以研究前沿 AI 系统的安全性、可信度和实际防御（Perplexity）。Perplexity 目前正在与斯坦福大学、卡内基梅隆大学（CMU）、杜克大学、哥伦比亚大学、俄亥俄州立大学和弗吉尼亚大学的学术研究人员进行合作和/或资助。我们还在进行内部研究，以推进智能体安全研究的前沿，将这些进展转化为 Perplexity 系统中的具体改进，并分享有助于加强更广泛 AI 生态系统的知识和资源。更安全的智能体是行业可以设计出来的东西。我们打算继续尽自己的一份力量，并邀请其他人与我们共同构建。