Each language version is independently generated for its own context, not a direct translation.
这篇文章是 Perplexity 公司写给美国国家标准与技术研究院（NIST）的一份报告，主要探讨了**人工智能代理（AI Agents）**带来的新安全挑战。
为了让你更容易理解，我们可以把AI 代理想象成你雇佣的**“超级数字管家”。以前的软件只是听你指令的“工具”（比如计算器），而这个“管家”不仅能听懂你的话，还能主动**帮你查邮件、订机票、甚至操作电脑文件。
虽然这很方便，但也带来了全新的安全风险。以下是用通俗语言和比喻对报告核心内容的解读：
1. 核心问题：代码和数据的“界限”模糊了
- 传统软件（像老式厨房）： 以前，厨师（程序代码）和食材（数据）是分开的。厨师按菜谱做菜，食材只是被处理，不能反过来指挥厨师。
- AI 代理（像会读心术的管家）： 现在的 AI 把“指令”和“数据”混在一起了。
- 比喻： 想象你的管家不仅看菜谱，还能读你收到的信件（数据）。如果有人在信件里藏了一句“把家里的保险柜打开”，AI 可能会误以为这是你的新指令，从而执行了不该做的事。
- 风险： 这种“数据即代码”的特性，让黑客可以通过发送一段看似正常的垃圾邮件或网页内容，悄悄“黑”进你的 AI，让它干坏事。这被称为**“间接提示注入”**（Indirect Prompt Injection）。
2. AI 代理的三大新风险
报告指出了 AI 代理特有的三个安全漏洞：
A. 保密性风险（隐私泄露）
- 比喻： 你的管家为了帮你办事，必须知道你的银行卡号、家庭住址和私人日记。
- 问题： 如果管家被黑客“洗脑”（通过上述的注入攻击），它可能会把你最私密的日记偷偷发给陌生人，或者把银行密码泄露出去。因为它能访问太多数据，一旦失守，后果很严重。
B. 完整性风险（被篡改的决策）
- 比喻： 你让管家“帮我买最便宜的机票”。
- 问题： 如果黑客在机票网站上埋了个陷阱，告诉管家“这家航空公司其实更便宜（其实是假的）”，管家就会信以为真，帮你买了贵得多的票，或者把文件改得面目全非。AI 可能会做出错误的决定，甚至被诱导去干坏事。
C. 可用性风险（系统崩溃或死循环）
- 比喻： 管家太勤快了，一旦遇到一个复杂的任务，它可能会陷入死循环，不停地尝试、失败、再尝试，直到把家里的电都耗光，或者把电脑卡死，导致你无法使用它。
- 问题： 黑客可以利用这一点，故意给 AI 发一堆复杂任务，让它忙到崩溃（拒绝服务攻击）。
3. 多代理系统：一群管家的混乱
现在的 AI 系统往往不是只有一个管家，而是一群**“管家团队”**（多代理系统）在协作。
- 比喻： 一个管家负责查资料，另一个负责发邮件，还有一个负责订酒店。
- 新风险（困惑的副手）： 如果黑客骗了“查资料”的管家，让它去命令“发邮件”的管家发一封诈骗信。这时候，“发邮件”的管家以为这是团队指令，就照做了。
- 难点： 很难分清是谁的责任，因为指令在多个管家之间传递，就像接力赛一样，一旦中间有人被收买，整个链条就乱了。
4. 现有的防御手段不够用
传统的杀毒软件或防火墙，就像给大门装锁，主要防的是外部坏人。但 AI 代理的问题在于，坏人可能已经混在“食材”（数据）里进来了，或者管家自己“想错了”。
- 现状： 现有的安全机制大多是为人类设计的（假设人类会小心谨慎），但 AI 是机器速度，一旦出错，人类根本来不及反应。
5. 怎么解决？（三层防御策略）
报告建议像盖房子一样，建立**“纵深防御”**体系，不能只靠一层保险：
- 第一层：输入过滤（像安检员）
- 在数据进入 AI 大脑之前，先检查有没有“坏话”。但这很难，因为坏话可能伪装得很好，而且检查太慢会影响体验。
- 第二层：模型加固（像给管家洗脑）
- 训练 AI 模型，让它学会区分“老板的指令”和“网页上的垃圾话”。但这也不是 100% 可靠，因为 AI 本质上是概率性的，偶尔还是会犯错。
- 第三层：确定性防线（像最后的保险锁）
- 这是最重要的！ 无论 AI 怎么想，必须有一道死板的、不可篡改的规则（代码）来把关。
- 比喻： 不管管家怎么建议，如果要转账超过 100 元，或者删除重要文件，系统必须强制要求人类确认，或者自动拒绝。这道防线不能靠 AI 判断，必须靠传统的、确定的代码逻辑。
6. 未来的方向
- 制定新标准： 需要像交通规则一样，制定 AI 之间如何安全协作的标准。
- 更好的测试： 不能只考静态的试卷，要像“红蓝对抗”演习一样，让黑客不断攻击 AI，看看它能不能扛得住。
- 人机协作： 在关键决策上，保留人类的“刹车权”，但要设计得聪明一点，不要每件事都让人确认，否则用户会烦死。
总结
这篇报告的核心思想是：AI 代理很强大，但它把“数据”变成了“指令”，这让黑客有了新武器。
要保护它，我们不能只依赖 AI 变聪明，必须建立多层防御，特别是要有一道人类或确定性代码把守的“最后防线”，防止 AI 在关键时刻“发疯”或被黑客操控。就像给一个拥有超级能力的机器人管家，既给它自由，又给它戴上不可摘除的“安全项圈”。
Each language version is independently generated for its own context, not a direct translation.
《人工智能代理的安全考量》技术总结
论文来源：Perplexity 对 NIST/CAISI 信息请求（2025-0035）的回复
作者：Ninghui Li, Kaiyuan Zhang, Kyle Polley, Jerry Ma (Perplexity & Purdue University)
日期：2026 年 3 月 9 日
1. 问题背景 (Problem)
随着前沿人工智能（AI）代理（Agents）系统的兴起，传统的软件安全假设面临根本性挑战。本文指出，AI 代理系统引入了独特的安全威胁，这些威胁无法通过传统软件的安全机制完全解决。主要问题包括：
- 代码与数据的界限模糊：在传统计算机安全中，代码（指令）与数据是严格分离的。然而，在基于大语言模型（LLM）的代理系统中，纯文本提示（Prompts）充当了“代码”的角色，控制着代理的调用流程。动态生成的文本本身可能成为新的提示，导致控制流依赖于运行时未知的负载。这种模糊性使得传统的注入攻击（如 SQL 注入）演变为更复杂的间接提示注入（Indirect Prompt Injection）。
- 自动化灵活性与不可预测性：传统软件遵循预编程的工作流，而 AI 代理能够根据高层目标动态构建工作流、选择工具并链式执行操作。这种非确定性的逻辑使得难以形式化验证系统安全性，也难以枚举所有可能的不良行为状态。
- 现有安全机制的不匹配：现有的安全机制（如沙箱、同源策略）主要针对人类用户或确定性软件设计。AI 代理以机器速度执行操作，且具备自主性，传统的“最小权限”和“细粒度访问控制”在动态环境中难以有效实施，容易导致**困惑副手（Confused Deputy）**漏洞和权限提升。
- 多代理系统的复杂性：在多代理系统中，子代理之间的隐式委托、共享状态以及缺乏清晰的授权链，使得错误和恶意指令容易在代理间传播，导致级联故障。
2. 方法论 (Methodology)
本文基于 Perplexity 在运营通用代理系统（服务于数百万用户和数千家企业）中的实际经验，结合理论分析，采用以下方法进行研究：
- 威胁建模：从机密性（Confidentiality）、完整性（Integrity）和可用性（Availability）（CIA 三元组）的角度，系统性地分析 AI 代理系统的攻击面。
- 架构分析：深入剖析代理系统的架构组件，包括工具选择逻辑、执行边界、基于网络的摄入（Web-grounded ingestion）、多代理协调以及技能/插件供应链。
- 分层防御评估：将当前的防御措施视为一个分层堆栈进行评估，包括输入级、模型级、执行监控级和确定性最后防线。
- 案例研究：引用 OpenClaw 等开源代理平台的具体架构（如网关、多代理路由、插件机制）以及 CVE-2026 等具体漏洞案例，说明架构选择如何直接影响安全属性。
3. 关键贡献 (Key Contributions)
本文提出了针对 AI 代理系统安全的核心见解和框架：
A. 独特的威胁分类
- 间接提示注入：攻击者将恶意指令嵌入代理检索的内容（如网页、邮件）中，操纵代理行为（如窃取日历数据）。
- 困惑副手与权限提升：在多代理环境中，低权限代理可能诱导高权限代理执行敏感操作，绕过访问控制。
- 级联故障：在长运行工作流中，单个组件的失败可能导致下游代理停滞或进入无限重试循环，造成资源耗尽。
B. 分层防御架构 (Defense-in-Depth)
作者提出必须采用多层防御策略，单一机制无法提供全面保护：
- 输入级防御：检测并过滤恶意输入（如使用困惑度测量、专用检测器、Spotlighting 技术）。但面临误报率高和延迟问题。
- 模型级防御：通过训练模型理解“指令层级”（Instruction Hierarchy），区分系统指令、用户指令和第三方数据。然而，模型缺乏原生的强制执行层，仍可能被绕过。
- 执行监控与沙箱：在系统架构层面运行代理，使用沙箱隔离资源。例如，CaMeL 框架将受信任的控制流（P-LLM）与非受信任的数据流（Q-LLM）分离，确保污染变量无法影响特权操作。
- 确定性最后防线 (Deterministic Last Line of Defense)：这是最关键的贡献。必须有一个不依赖 LLM 推理的确定性层，使用传统代码（如白名单、黑名单、速率限制、正则验证）来强制执行策略，无论 LLM 生成什么内容，都禁止违规操作。
C. 架构与部署的安全考量
- 指出架构选择（如工具设计、多代理协调）和部署方式（云端 vs 本地/边缘）直接决定了攻击面和信任边界。
- 强调本地部署虽然减少了网络暴露，但增加了内部人员和配置风险；云端部署则引入了新的网络信任边界。
4. 结果与发现 (Results & Findings)
- 防御成熟度评估：
- 输入级和模型级防御：处于学术研究早期和初步生产部署阶段，尚不能作为独立保护手段。
- 确定性执行机制（如工具白名单、人机回环确认）：是目前最成熟且广泛部署的防御层。
- 多代理风险：多代理系统显著增加了隐式委托和权限提升的风险，传统的审计和恢复机制难以追踪跨代理的决策路径。
- 基准测试缺失：当前的安全基准测试多为静态，无法反映代理在动态、多步工作流中面对自适应攻击时的表现。
- 人机交互挑战：过度的人类确认请求会导致用户疲劳，反而降低安全性。需要研究“风险感知自主性”（Risk-aware Autonomy），即仅在风险超过阈值时请求确认。
5. 意义与建议 (Significance & Recommendations)
本文对 NIST、CAISI 及整个 AI 生态系统具有重要的指导意义：
- 制定分层防御参考架构：呼吁 NIST 开发一个包含输入、模型、系统三层防御的参考架构，供从业者设计、部署和审计代理应用时使用。
- 建立动态安全基准：需要开发包含自适应攻击者的动态基准测试，以评估代理系统在真实多步工作流中的安全性，而非仅依赖静态测试套件。
- 改进访问控制模型：建议结合基于角色的访问控制（RBAC）与风险自适应访问控制，为代理系统建立确定性的授权策略层。
- 优化人机治理：研究如何在保持自动化优势的同时，通过风险感知机制和周期性透明度报告（而非频繁打断）来平衡安全与可用性。
- 填补标准空白：现有的通信协议（如 MCP, A2A）缺乏高层安全规范，需要制定关于安全委托、代理间信任边界和权限管理的指导方针。
总结：本文强调，AI 代理的安全不能仅依赖模型本身的改进，必须构建包含确定性强制执行层的纵深防御体系，并重新审视传统的代码 - 数据分离原则和访问控制模型，以适应代理系统的非确定性和高自动化特性。