AI Agent 框架将提示注入变成安全故障

Google News 本周提出了一个直截了当的安全观点：尽管多年来围绕提示注入构建了各种防御措施，但提示注入并非根本漏洞。更深层的故障存在于 AI Agent 框架中——它们会将不确定的模型输出转化为具有特权的操作。

这一差异改变了工程团队需要保护的对象。被操纵的聊天机器人可能只会输出无意义内容；被操纵的 Agent 却可能读取私密文件、调用 API、修改代码、发送消息，或污染共享记忆。

The Register 的表述挑战了一种常见假设。开发者往往将恶意文本视为漏洞，并把更强的提示词当作补救方案。更具决定性的问题是：模型接受这些文本后，周边系统允许它做什么。

这并不意味着提示注入无害。它仍然是通过直接请求或不受信任的外部内容影响模型的一种可靠方式。然而，只有当系统架构提供了权限、数据和可执行路径时，注入才会演变为实际的运营安全事件。

因此，正在形成的较量已经十分清晰。一方依赖模型在模糊语言中识别危险指令；另一方则假定这种识别终将失败，并限制任何受损模型能够造成的后果。

Google News 将 Agent 框架置于核心位置

关键变化在于：责任从模型行为转向系统架构。

提示注入通常被描述为模型安全问题。攻击者将指令嵌入提示词、文档、网站、电子邮件、图像或工具响应中，模型随后遵循这些指令，而非用户真正的请求。

这种描述准确，但并不完整。它指出了影响模型的方法，却没有识别导致实际损害的控制失效。不受信任的文本无法自行删除文件、调取客户记录或发布源代码。

Agent 框架提供了这些能力。它将模型连接到工具、凭据、记忆、数据库、浏览器、代码解释器和其他 Agent。它还可能决定模型能否在没有再次获得人工授权的情况下采取行动。

这种架构可能将一次错误理解转化为一连串副作用。被投毒的网页变成工具请求，工具请求变成数据库查询，检索到的材料随后出现在由同一 Agent 生成的对外消息中。

间接提示注入在这里尤其重要。攻击者不需要访问聊天界面，恶意指令可以潜伏在 Agent 执行日常任务时接触到的内容中。

研究型 Agent 可能在网页上遇到这些指令；编程助手可能在 issue 描述或代码仓库文件中发现它们；办公 Agent 则可能从电子邮件、日历邀请或共享文档中摄入这些内容。

在每一种情况下，模型都面临艰难的分类问题。它必须区分描述某条指令的文本与应当服从的文本；二者都会以自然语言 token 的形式进入模型的工作上下文。

OWASP 风险定义同时承认直接和间接注入。它还指出，影响在很大程度上取决于业务场景以及授予模型的自主行动能力。

最后这一条件的重要性远超初看时的印象。同一句恶意语句在两种部署中可能造成截然不同的结果：只读摘要工具或许只会生成一段被污染的文字，而高权限 Agent 则可能泄露机密信息。

Google News 作为发现这一争论的渠道颇有价值，但它并非根本权威。相关标题指向了更广泛的安全研究体系，该体系正越来越多地将 Agent 劫持视为一种架构性威胁。

NIST 将 Agent 劫持描述为一种间接提示注入，它会导致 Agent 执行非预期的有害操作。其劫持评估使用了模拟工作空间、旅行服务、消息系统和银行工具。

这些环境揭示了 Agent 安全与聊天机器人安全为何不同。模型并非只是在回答问题，而是在一个带有权限和现实后果的工作流中选择行动。

这种重新界定也让漏洞报告更为明确。“提示注入”描述了影响如何进入系统；一项有价值的安全发现还应说明由此造成的影响，例如未授权的数据访问或未经批准的代码执行。

传统安全团队早已做出类似区分。用户可控输入并不自动意味着安全事件；当软件将该输入传递给不安全的解释器，或跨越安全边界对其加以信任时，漏洞才会出现。

语言模型让这种类比变得更复杂，因为指令和数据共享一种灵活的表示形式。对于每一项自然语言任务，并不存在参数化数据库查询那样的通用等价物。这让模型周边的隔离控制变得更加重要。

因此，关键事件在概念上发生，但在运营上意义重大。安全工作正逐渐远离对完美指令过滤的承诺，转而采用即使模型做出错误决策后仍然有效的限制措施。

提示注入是触发因素，而非爆炸半径

被注入的指令会形成影响力，而框架决定这种影响力是否会演变为安全事件。

设想一个负责审查传入支持工单的 Agent。它需要访问工单文本、客户详细信息，以及可能的内部知识库；它还可能拥有退款或发送账户消息的工具。

攻击者在工单中嵌入隐藏指令，要求 Agent 调取另一名客户的记录，并将其写入回复。模型在自认为正在完成既定工作流的同时，遵循了这一指示。

在数据离开公司之前，必须发生多项失效。Agent 获得的访问范围必须超过当前工单所需；其工具层必须接受模型生成的参数；对外操作还必须在没有独立授权的情况下继续执行。

恶意文本开启了这条链路，但它并未制造过度权限、缺失的数据边界或不存在的审批关卡。这些决策来自应用程序和框架。

这一区别是 AI Agent 安全的核心。系统应假定模型判断会出错，尤其是在模型处理攻击者可控内容时。安全控制必须始终位于该判断循环之外。

仅靠工具 schema 无法解决问题。schema 可以要求有效的电子邮件地址或文档标识符，却无法判断模型是否有正当理由联系该地址或调取该文档。

格式正确的恶意操作仍然是恶意操作。框架需要将策略执行与用户身份、数据所有权、任务范围、来源以及当前授权状态绑定。

来源意味着记录信息来自何处，并在整个工作流中保留这一标签。来自未知网页的内容，不应仅仅因为某个 Agent 对其进行了摘要就获得可信状态。

在多 Agent 系统中，这条规则会变得更加困难。一个模型可能负责研究主题，另一个负责规划回复，第三个则执行工具操作。随着输出在它们之间传递，恶意指令也可能被转化。

接收 Agent 看到的可能是润色后的文字，却看不到影响这些文字的不受信任来源。如果框架丢弃了来源信息，通过另一个 Agent 对指令进行“洗白”就可能实际上提升其权限。

持久记忆则创造了另一条路径。攻击者可能诱使 Agent 存储有害规则、错误事实或被篡改的偏好。原始恶意内容消失后，后续会话仍可能检索到该条目。

构建个人知识库的团队也面临类似的信任问题。检索到的信息应保留其来源和访问上下文，尤其是在 Agent 可以基于它采取行动时。

记忆不应成为隐形控制平面。写入操作需要约束、审计记录，并清晰区分经用户批准的偏好与模型生成的观察结果。

浏览也带来了自身风险。网页可能包含可见指令、隐藏文本、元数据、图像内容，或是为模型而非人类设计的对抗性材料。Agent 处理这些内容，正是因为浏览是其预期功能。

Google 报告称，其正在监测公共网络中已知的间接注入模式。其网络威胁研究将这些模式列为优先事项，因为浏览 Agent 会经常消费攻击者可控的网页。

这造成了一种结构性权衡。Agent 的信息访问范围越广，它接触到的不受信任内容就越多；它获得的权限越大，一次错误理解的潜在影响也越大。

消除所有外部内容会让许多 Agent 失去价值；给予所有外部内容同等影响力则会使它们变得不安全。框架必须在保留实用性的同时，实施仅凭语言无法保证的边界。

这意味着要将规划与授权分离。模型可以提出操作建议、说明理由并准备参数；确定性的策略服务则应决定该操作是否被允许。

这一决定应考虑当前用户、请求的任务、目标资源、数据敏感性和内容来源。高影响操作应要求确认，并清晰展示将会发生什么。

确认内容不能完全由可能已受损的模型撰写。否则，攻击者既能影响拟议操作，也能影响向用户展示的说明。

可信的界面应根据经过验证的工具参数构建关键信息。它应明确目的地、受影响的记录、请求的权限，以及任何计划离开系统的数据。

这正是爆炸半径变得可衡量的方式。即使提示注入在语言层面得逞，攻击者仍会在每一个关键边界遇到独立控制。

其结果更接近成熟的应用安全，而非巧妙的提示词工程。最小权限、隔离、显式授权、输出验证、日志记录和事件响应仍然不可或缺。

为什么更强的系统提示词无法承担安全边界

提示词加固可以减少成功攻击，但残余失效使其不适合作为最终授权层。

系统提示词可以要求 Agent 忽略外部内容中的指令。它们可以将源材料标记为不受信任，并提醒模型只遵循用户目标。

这些措施值得采用。它们可以阻挡简单攻击、减少意外偏离，并迫使对手付出更多努力。它们还可以帮助模型解释可疑内容，而不是立即据此采取行动。

Google 研究人员在一个多智能体编程框架中测试了安全提示。其 多智能体研究 覆盖了超过 150 个单轮攻击场景和 32 个多轮攻击场景。

一套约 500 token 的安全强化提示将单轮失败率从 19.48% 降至 2.60%。多轮失败率则从 75% 降至 46.88%。

这些结果支持采用提示强化，同时也暴露了它的局限。当智能体能够执行代码、访问凭据或修改生产资源时，46.88% 的多轮失败率依然不可接受。

即便较低的单轮失败率，在大规模应用中也会带来实质风险。重复交互会给攻击者提供更多机会，而攻击者可以在观察模型行为后调整措辞。

该研究还发现，成功攻击正转向功能性包装。这类攻击将恶意意图隐藏在看似普通的智能体功能任务中。静态指令很难在不阻断合法工作的情况下拒绝它们。

这正是将安全边界置于模型内部的核心问题。模型必须解释一个开放式请求，同时预测该请求是否违反另一条开放式指令。

它并不像操作系统检查文件访问那样评估稳定的权限规则。它生成的是概率性响应，受到其上下文中每一个相关 token 的影响。

若仅将提示注入解释为“忽略先前指令”，就忽略了这种模糊性。有效攻击不一定会明确宣示冲突。它们可以提供虚假上下文、模仿可信工作流语言，或将意图拆分到多个步骤中。

一个审查代码的智能体可能会遇到看似描述必需测试的文本。该测试会悄悄下载或执行外部组件。开发工作流中的每一个单独步骤都可能显得合理。

浏览智能体可能会被告知，必须执行某项特定操作才能访问所请求的页面。办公助手则可能读取一份文件，其中声称公司政策要求为合规审查而转发内容。

模型并不独立知晓每个组织的真实政策。如果框架允许模型生成的声明来授权模型生成的操作，系统就会陷入循环。

过滤器也面临类似局限。检测器可以搜索已知短语，或估计文本是否看起来具有对抗性。攻击者可以改写指令、拆分载荷、将其隐藏在不同格式中，或使其看起来像普通数据。

屏蔽所有祈使句会破坏常见工作流。文件、电子邮件、代码注释和支持工单中都可能合法地包含指令。智能体通常需要理解这些指令，而不是将其采纳为自身目标。

微调可以提升抵抗力，但无法消除架构冲突。模型仍需解释不可信语言，而新的攻击模式可能落在其训练分布之外。

检索增强生成同样无法消除这一冲突。RAG 会检索外部材料并将其加入模型上下文。如果来源遭到污染，检索就可能恰好在攻击者指令看似相关时将其送达。

模型升级甚至可能以意料之外的方式改变风险。能力更强的模型或许能更好地识别攻击，但在攻击成功后，它也可能更有效地使用工具。

这就是为什么基准分数需要结合语境来看。在固定测试套件中拒绝大多数注入的模型，并不能证明已部署的智能体是安全的。真实系统包含自定义工具、权限、记忆和集成。

防御目标应是优雅失效。当模型错误分类内容时，周边系统应当控制后果、暴露攻击尝试，并保留供审查的证据。

只读智能体仍可能误导用户，因此输出质量很重要。不过，最严重的后果通常出现在框架将不确定的推理与无边界的权限结合时。

因此，安全提示应属于分层设计的一环。它是一项控制措施，而不是决定私人数据是否跨越边界、可执行代码是否到达工作站的控制措施。

AI 智能体安全取决于能力、上下文与同意

框架应将模型视为不可信的规划者，其提议必须经过可执行的检查。

第一项架构控制是能力最小化。智能体应只获得当前任务所需的工具，而不是用户或组织可用的所有集成。

日历摘要工具很少需要发送邮件的权限。研究助手不会天然需要 shell 访问权限。代码审查工具可能需要读取仓库，但不应拥有合并变更的权限。

静态的最小权限原则很有帮助，但针对任务的授权更好。某个工具可以仅为一次受限操作开放，并在该操作结束后消失。

凭据也应始终留在模型上下文之外。模型应通过代理请求操作，而不是直接处理可复用的密钥。日志应从提示和工具响应中隐去敏感 token。

第二项控制是上下文授权。传统访问检查通常回答用户是否可以访问某项资源。智能体系统还必须问：该访问是否支持用户当前的请求。

能够读取两个客户账户的用户，并不一定授权智能体将它们合并。拥有部署权限的开发者，也没有授权每个代码审查智能体进行部署。

意图无法从语言中被完美推断，但框架可以通过明确的任务声明缩小范围。它们可以将工具绑定到声明的目标、资源集合、时间窗口和允许的数据流。

第三项控制是对后果重大操作的同意。在向外部发送信息、花费资金、变更访问权限、删除数据或执行不可信代码之前，人工批准尤为重要。

同意必须具有实质意义。反复出现的模糊弹窗会训练用户在不检查的情况下批准。界面应明确指出具体操作，并突出其与原始任务的偏离。

低风险、可逆的操作可以采用较轻的控制。高风险或不可逆的操作需要更强的确认；在企业环境中，可能还需要第二位审批者。

第四项控制是隔离。代码执行应在沙箱中进行，并限制网络、文件系统和凭据访问。浏览器会话应将不可信页面与敏感应用状态隔离开来。

工具输出应被视为数据，而非自动可信的指令。框架应在将输出返回模型前，验证其大小、格式、目标位置和允许内容。

第五项控制是保留来源信息。每一份文档、消息、网页、记忆项和智能体响应都应携带其来源及信任分类。

当一个智能体总结不可信页面时，摘要也应保持不可信。转换不应抹去来源链路。下游策略引擎随后便可阻止低信任材料授权高影响操作。

第六项控制是提议与执行分离。规划器可以决定应发送一封电子邮件，但独立组件应验证收件人和附件。

这种分离可限制“混淆代理”攻击。混淆代理是指拥有合法权限的系统被操纵，利用该权限服务于他人的目的。

第七项控制是可观测性。团队需要记录，显示哪个来源影响了决策、哪个模型提出了操作、哪项策略允许了它，以及哪个工具执行了它。

没有这些记录，组织便无法重建一次智能体事件。常规应用日志可能记录 API 调用，却遗漏提示、检索内容、记忆状态和智能体之间的消息。

监控也应聚焦行为。警示信号包括异常的资源组合、重复的授权失败、新的外发目标、意外的记忆写入，或工具在其正常序列之外被使用。

第八项控制是在完整工作流中进行对抗测试。只测试基础模型，忽略了权限和副作用所在的框架。

NIST 的方法采用真实工具和任务，因为智能体安全具有上下文性。模型可能在普通聊天中抵御攻击，却在同一指令出现在看似可信的业务对象中时失败。

红队应在智能体消费的每一种来源中植入恶意内容。这包括网站、电子邮件、文档、代码仓库、问题跟踪器、工具元数据、搜索结果和共享记忆。

它们还应测试多轮和多智能体路径。一条被阻止的直接命令，可能在被中间智能体重新表述后成功，或被存储以供日后检索。

目标不是发布单一的提示注入成功率，而是识别哪些成功注入能够触及敏感数据、特权工具或不可逆操作。

这有助于更好地确定优先级。仅损坏临时草稿的高频注入值得关注。能够触及生产凭据的较罕见注入，则应优先采取更强控制。

OWASP 建议采用最小权限、外部内容隔离、人工批准、输出验证和对抗测试。这些措施体现了纵深防御模型，而非对单一检测器的信赖。

NIST 更广泛的攻击分类法同样强调，在识别攻击的同时管理后果。这种方法适合智能体系统，因为彻底预防仍然充满不确定性。

这些控制措施都不会让模型变得可信。它们让系统更少依赖模型的可信性，而这才是更站得住脚的工程目标。

Google News 读者接下来应关注什么

决定性证据将来自框架默认设置、可衡量的控制效果，以及透明的事件报告。

第一个信号是，主要框架是否将受限执行设为默认选项。可选的沙箱和权限控制有助于经验丰富的团队，但默认设置会塑造数千个普通部署。

应关注智能体平台如何处理工具授权、网络访问、文件系统写入和可复用凭据。一个先暴露广泛能力、后再说明如何强化的框架，保留了底层风险。

最强的默认设置是不自动授予任何敏感工具。开发者需要添加范围狭窄的能力，并了解每项权限的后果。

第二个信号是，评估是否衡量端到端影响。攻击拒绝率很有用，但它们无法揭示成功攻击是否触及机密数据或完成危险操作。

更好的评估会同时报告模型被攻破和系统被攻破的情况。它们会区分被操纵的回答与未经授权的读取、对外传输、代码执行或持久记忆变更。

它们还应公布重复尝试下的结果。一次成功、但在多次变体攻击后失败的防御，在面向互联网的服务中只能提供有限保护。

Google 的研究结果说明了这一需求。提示强化显著提高了抵抗力，但多轮攻击仍保留较高失败率。架构控制决定了这些残余失败意味着什么。

第三个信号是披露质量。AI 特有事件往往缺少传统漏洞管理中常见的材料。团队可能只收到一篇供应商博客文章，却没有标准标识符、受影响版本范围或明确的修复路径。

框架提供商应发布安全公告，说明完整的攻击链。用户需要知道所需的内容来源、模型行为、权限、工具、受影响版本，以及可用的缓解措施。

仅笼统声称模型获得了“额外安全防护”并不够。客户需要了解供应商究竟修改了模型、框架策略、权限系统、沙箱，还是用户审批流程。

漏洞赏金决策也应采用同样的标准。如果一份报告证明了提示注入，但没有产生实质影响，给出低严重性评级或许合理。但如果注入能够触及特权操作，将其斥为预期的模型行为，就回避了真正的问题。

Google News 将继续呈现提示注入演示，因为它们直观且易于复现。有些只是影响较小的越狱，而另一些则会暴露严重的框架失效。

读者应区分三个问题。攻击者是否影响了模型？这种影响之后获得了什么能力？哪项独立控制本应阻止随后的操作？

与其追问提示注入是否终于被彻底解决，这一顺序能带来更有用的风险评估。现有证据并不足以支持人们假定存在通用解决方案。

开发者应检查所有连接不可信内容与敏感工具的路径。企业采购方应要求具备任务范围限定的权限、来源追溯、沙箱、审批控制和可审计的执行记录。

知识工作者在连接电子邮件、文件、日历和工作场所系统之前，应先确认代理能够访问哪些内容。整合这些来源会迅速提升便利性，但潜在的影响范围也会同步扩大。

核心反转依然很简单：提示注入是触发因素，而框架提供了触达范围、权限与持久性。只处理触发因素，危险的机制本身并未改变。

下次看到 Google News 标题称又有代理被劫持时，不要只盯着恶意文字。应追问：是哪个工具执行了它们，是什么权限允许了它们，以及为何没有独立控制进行干预。

这正是代理构建者如今需要通过的考验：当模型被说服、被误导，或只是犯错时，系统能否依然保持安全？如果答案只依赖于更好的提示，框架本身仍然带着这个漏洞。