这是另一篇有关人工智能代理安全的新论文： 《谷歌人工智能代理安全方法简介》 ，作者是 Santiago Díaz、Christoph Kern 和 Kara Olive。
（几天前，我写了另一篇最近的论文《保护 LLM 代理免受即时注入的设计模式》 。）
这篇谷歌论文自称是“我们打造的安全人工智能代理的理想框架”。读起来很有意思。
因为我收集了“AI代理”的定义，所以他们使用的定义如下：
人工智能系统旨在感知环境、做出决策并采取自主行动来实现用户定义的目标。
两大关键风险
这篇论文描述了部署这些系统所涉及的两个关键风险。我喜欢他们清晰简洁的框架：
需要战略重点关注的主要问题是恶意行为（非故意、有害或违反政策的行为）和敏感数据泄露（未经授权披露私人信息）。存在一个根本性的矛盾：代理人自主性和权力的增强（推动效用）与风险的增加直接相关。
这篇论文的措辞比上周那篇关于设计模式的论文温和一些。那篇论文明确强调：“一旦 LLM 代理获取了不受信任的输入，就必须对其进行约束，使其不可能触发任何后续操作。” 这篇谷歌论文则回避了这个问题，并进行了如下阐述：
安全隐患：这里的关键挑战是如何可靠地区分可信用户命令与潜在不可信上下文数据以及来自其他来源的输入（例如，电子邮件或网页中的内容）。如果无法做到这一点，就会引发注入攻击，隐藏在数据中的恶意指令可能会劫持代理。安全的代理必须仔细解析并分离这些输入流。
需要考虑的问题：
- 代理处理哪些类型的输入，它能否清楚地区分可信的用户输入和可能不受信任的上下文输入？
然后谈到系统指令：
安全隐患：一项关键的安全措施是在提示符中清晰地划分和分离这些不同的元素。在可信系统指令和潜在不可信的用户数据或外部内容之间保持明确的区分，对于缓解提示符注入攻击至关重要。
我的问题在于：这两个例子中唯一正确的答案是，明确的分离是不可能的！上述问题的表述方式暗示着不存在解决方案。
此后不久，他们确实承认了这一点（重点是我）：
此外，当前的LLM架构未能对提示的各个组成部分（尤其是系统和用户指令与外部不可信输入）进行严格的区分，这使得它们容易受到诸如提示注入之类的操纵。迭代规划（在“推理循环”中）的常见做法加剧了这种风险：每个循环都可能引入逻辑缺陷、偏离意图或被恶意数据劫持的机会，从而可能使问题更加复杂。因此，具有高度自主性的代理执行复杂的多步骤迭代规划会带来更高的风险，需要强大的安全控制。
这条关于记忆的注释非常好：
内存可能成为持续性攻击的载体。如果包含即时注入的恶意数据被处理并存储在内存中（例如，作为从恶意文档中总结出来的“事实”），它可能会影响代理在未来不相关的交互中的行为。
本节介绍了渲染代理输出所涉及的风险：
如果应用程序渲染代理输出时未进行基于内容类型的适当清理或转义，则可能会出现跨站脚本 (XSS) 等漏洞或数据泄露（例如，通过图像标签中恶意编写的 URL）。渲染组件的强大清理功能至关重要。
需要考虑的问题：[…]
- 在呈现代理生成的输出时应用了哪些清理和转义过程来防止执行漏洞（例如 XSS）？
- 如何验证呈现的代理输出（尤其是生成的 URL 或嵌入内容）以防止敏感数据泄露？
然后，本文进一步阐述了前面提到的两个关键风险，即恶意行为和敏感数据泄露。
流氓行为
这里他们给出了一个关于即时注入的 cromulent 定义：
恶意行为（非故意的、有害的或违反政策的代理行为）是人工智能代理的主要安全风险。
一个关键原因是即时注入：隐藏在处理数据（例如文件、电子邮件或网站）中的恶意指令可以欺骗代理的核心AI模型，劫持其规划或推理阶段。该模型将这些嵌入的数据误解为指令，从而利用用户的权限执行攻击者的命令。
此外，还存在误解用户命令可能导致意外操作的相关风险：
客服人员可能会误解含糊不清的指令或上下文。例如，“给 Mike 发邮件告知项目进展”这样的含糊不清的请求可能会导致客服人员选择错误的联系人，从而无意中泄露敏感信息。
敏感数据泄露
这是迄今为止我见过的最常见的即时注入风险形式。我在我的渗透攻击标签中对此进行了详细的描述。
实现敏感数据泄露的主要方法是数据泄露。这涉及诱骗代理，使敏感信息对攻击者可见。攻击者通常通过利用代理操作及其副作用（通常由提示注入驱动）来实现此目的。[…] 他们可能会诱骗代理检索敏感数据，然后通过诸如将数据嵌入代理被提示访问的 URL 中，或将机密信息隐藏在代码提交消息中等操作泄露数据。
代理安全的三大核心原则
本文的下一部分描述了 Google 针对代理安全的三个核心原则：
原则 1 是代理必须具有明确定义的人类控制者。
[…] 为了确保安全性和问责制，代理必须在明确的人工监督下运行。每个代理都必须拥有一组明确定义的控制人类用户。
该原则要求系统必须能够可靠地区分来自授权控制用户的指令与任何其他输入，尤其是代理处理的潜在不受信任的数据。对于被视为关键或不可逆的操作（例如删除大量数据、授权重大金融交易或更改安全设置），系统应在继续操作之前要求明确的人工确认，以确保用户始终处于知情状态。[…]
代表团队或团体行事的代理需要独特的身份和清晰的授权模型，以防止未经授权的跨用户数据访问或一个用户无意中触发影响另一个用户的操作。
这包括两个部分：跟踪哪个用户正在控制代理，以及为关键操作添加人工确认步骤。
原则二是代理人的权力必须有限制。
代理的权限（即其可执行的操作和可访问的资源）必须根据其预期用途及其控制用户的风险承受能力进行谨慎限制。例如，用于研究的代理不应拥有修改财务账户的权限。通用代理需要机制在运行时动态限制其权限，确保对于任何给定的查询，只有相关的权限处于活动状态（例如，当任务为创意写作时，禁止执行文件删除操作）。
这代表了一种我从未见过的更为复杂的代理权限方法。代理权限应该根据任务动态变化的想法固然引人入胜，但我很难想象它在实践中如何有效运作。我能想到的唯一实现方法是添加更多AI层，根据感知到的任务动态调整权限，而这在我看来本身就存在风险，因为即时注入攻击可能会影响这些决策。
原则3： Agent的行动和计划必须是可观察的。我很喜欢这个原则——重点是我自己的：
如果代理的操作完全不透明，我们就无法确保其忠实履行职责，也无法诊断问题。因此，代理的行为，以及在可行的情况下，其规划流程，必须可观察、可审计。[…]
有效的可观察性还意味着代理可执行操作的属性（例如，操作是只读还是状态更改操作，或者是否处理敏感数据）必须清晰地描述。这些元数据对于自动化安全机制和人工审核至关重要。最后，用户界面的设计应提升透明度，让用户深入了解代理的“思维过程”、其参考的数据源或其计划执行的操作，尤其是在执行复杂或高风险操作时。
是的，是的，是的。那些对我隐瞒其行为的LLM系统本质上令人沮丧——它们让我更难评估它们是否运行良好，也更难发现它们何时出错。这篇论文让我相信，也存在一个非常有力的安全论据：系统越不透明，我就越难发现它何时会失控，何时会受到快速注入攻击的破坏。
谷歌的混合纵深防御策略
所有这些都引出了我们对谷歌当前混合纵深防御策略的讨论。他们乐观地将其描述为“传统的确定性安全措施与动态的基于推理的防御措施”的结合。我喜欢确定性，但我仍然对“基于推理的防御措施”（即用非确定性人工智能模型解决安全问题）深表怀疑。
他们描述第 1 层的方式对我来说完全有意义：
第 1 层：传统的确定性措施（运行时策略执行）
当代理决定使用工具或执行操作（例如“发送电子邮件”或“购买商品”）时，该请求会被策略引擎拦截。引擎会根据预定义规则评估此请求，这些规则基于多种因素，例如操作的固有风险（是否不可逆？是否涉及金钱？）、当前上下文以及可能的先前操作链（代理最近是否处理过不受信任的数据？）。例如，一项策略可能会强制执行支出限额，例如自动阻止任何超过 500 美元的购买操作，或要求用户通过提示明确确认 100 至 500 美元之间的购买操作。另一项策略可能会阻止代理在刚刚处理过来自已知可疑来源的数据后向外部发送电子邮件，除非用户明确批准。
根据此评估，策略引擎确定结果：它可以允许该操作，如果它违反了关键策略则阻止它，或者要求用户确认。
我非常喜欢这个。要求用户确认所有操作很快就会导致“快速疲劳”，用户会直接点击“是”。这种方法比这更智能：策略引擎可以评估所涉及的风险，例如，如果操作不可逆或涉及的金额超过一定数额，并且只在这些情况下才需要确认。
我还喜欢这样的想法：“如果代理刚刚处理了来自已知可疑来源的数据，除非用户明确批准，否则策略可能会阻止代理向外部发送电子邮件”。这与CaMeL 论文中描述的数据流分析技术相符，该技术可以帮助识别某个操作是否正在处理可能受到即时注入攻击污染的数据。
第 2 层是我开始感到不舒服的地方：
第二层：基于推理的防御策略
为了补充确定性护栏并解决其在处理环境和新威胁方面的局限性，第二层利用基于推理的防御：使用人工智能模型本身来评估输入、输出或代理对潜在风险的内部推理的技术。
他们讨论了针对即时注入攻击示例的对抗性训练，试图教会模型识别和尊重分隔符，并提出专门的防护模型来帮助对潜在问题进行分类。
我明白这是纵深防御的一部分，但我仍然不明白无法提供保证的系统如何能成为这里的安全策略的有价值的补充。
他们至少承认这些局限性：
然而，这些策略是非确定性的，无法提供绝对的保证。模型仍然可能被新型攻击所欺骗，其故障模式也难以预测。这使得它们本身不足以应对需要绝对安全保障的场景，尤其是涉及关键或不可逆操作的场景。它们必须与确定性控制协同工作。
我对他们的第一层防御比他们在第二层采取的方法更感兴趣。
标签：人工智能代理、人工智能、 LLMS 、提示注入、安全、谷歌、生成人工智能、渗透攻击
原文： https://simonwillison.net/2025/Jun/15/ai-agent-security/#atom-everything