您的浏览器禁用了JavaScript(一种计算机语言,用以实现您与网页的交互),请解除该禁用,或者联系我们。 [CSA GCR]:智能体数据注入 - 发现报告

智能体数据注入

医药生物 2026-07-24 CSA GCR 杨静🍦
报告封面

代理数据注入:一种超越提示注入的新型攻击类别 如何被损坏的元数据绕过现有代理防御 2026-07-17 © 2026 云安全联盟。保留部分权利。 您可以下载、存储、展示、查看、打印、重新分发和链接到此文档的原始、未修改版本,前提是必须保持对云安全联盟的署名,并且所有商标和版权声明都保持完整。 本文件不得修改或更改。根据美国版权法中的合理使用条款,您可以引用文件的部分内容,但须注明出处为云安全联盟。 核心要点 首尔国立大学、伊利诺伊大学厄巴纳-香槟分校和Largosoft的研究人员已识别出代理数据注入(ADI),这是一种独特的间接提示注入类别,它破坏AI代理隐式信任的事实数据——例如UI元素标识符、评论作者元数据和工具调用记录——而不是嵌入直接指令[1][2]。 ADI通过利用大型语言模型如何以概率方式而非严格语法规则来解析结构标记而工作;研究人员称之为概率分隔符注入的技术,该技术使用转义引号、花括号以及类似字符,使模型相信虚构的数据边界是合法的[2]。 该研究团队展示了针对六个前沿模型的攻击实例——OpenAI的GPT-5.2和GPT-5-mini、Anthropic的Claude Opus 4.5和Sonnet 4.5,以及Google的Gemini 3 Pro和Flash——并针对现实世界中部署的代理,包括Chrome中的Claude、Google的Antigravity、Nanobrowser、Claude Code、OpenAI的Codex和Google的Gemini CLI [1][2]。 针对结构化数据攻击的成功率在约31%到43%之间,针对非结构化网页内容的成功率从三分之一到100%不等;ADI在针对为阻止提示注入而专门构建的防御措施时,仍保留了高达50%的有效性,而同样的防御措施几乎消除了基于指令的经典攻击[1][2]。 潜在弱点在于架构层面:当前的代理框架在元数据和上下文记录层面未能将可信数据与不可信数据隔离,这意味着即使代理经过加固以抵御直接提示注入攻击,也仍然存在风险,直到它们采用来源追踪或严格的数据流隔离[2]。 背景 根据CSA的评估,自从AI代理开始将其运行环境作为一部分来消费不受信任的内容——网页、电子邮件、拉取请求、工具输出——以来,间接提示注入一直是AI代理安全风险的主要表现形式。过去两年中形成的防御姿态假设攻击者的目标是向该内容中走私一条指令:一条告诉代理的隐藏指令 为窃取数据、转移资金或执行指令。防护栏模型、输入净化和指令层级训练都是为了检测并消除这种特定模式,而CSA自身关于保护基于LLM系统的指南则强调授权边界和验证层是针对此类攻击的主要控制措施[5]。 2026年7月6日,由首尔国立大学、伊利诺伊大学厄巴纳-香槟分校和Largosoft安全公司团队披露的“代理数据注入”(Agent Data Injection,简称ADI),完全针对代理操作的不同层级[1][2]。ADI并非要求代理执行其不应执行的操作,而是污染代理用来决定其当前正在做什么的依据事实。一个在网页中导航的代理依赖于该网页HTML中嵌入的标识符来识别哪个按钮是“立即购买”,哪个是“加入购物车”。一个审查代码请求的代理依赖于关于评论作者是谁以及先前工具调用实际返回了什么的元数据。所有这些元数据都不包含明确的指令,因此指令层级防御没有可操作的信号。在报道此次披露的Hacker News上,简洁地总结了这种区别:攻击在“提示注入防御正在查找的下一层”起作用[1]。 根据CSA的评估,这代表着行业在思考代理信任边界方面的一次重大转变。它表明过去两年的防御性投资——尽管规模庞大——仅解决了二维问题的一个维度。一个代理可能完全能够抵抗来自不可信内容的指令,但仍可能因其被欺骗关于自身位置、点击内容或与谁交谈而被操纵去做错误的事情。 安全分析 核心机制:概率分隔符注入 研究人员的核心技术贡献在于识别为何智能体从一开始就如此容易受到元数据损坏的影响。传统软件通过确定性规则解析结构化数据——JSON字段、HTML属性、API响应等:引号字符要么关闭字符串,要么不关闭,基于严格的语法。相比之下,大型语言模型将这些相同的结构读作文本,并以概率方式推断其边界,权衡分隔符“看起来像什么”与周围上下文,而不是强制执行精确的语法[2]。该论文将这种漏洞称为概率分隔符注入:攻击者将类似于合法结构标记的字符嵌入字段中——例如转义引号、视觉上相似的Unicode引号变体,或模板语法中使用的美元符号等。 代理期望接收的是原始数据。模型以概率方式读取时,会错误地判断存在新的字段或记录边界,而实际上并不存在,并将虚构的内容吸收进来,仿佛它是代理可信上下文中合法的一部分。 这很重要,因为它破坏了基于“可信/不可信边界由周围的应用程序代码正确执行”这一假设而构建的防御机制。如果漏洞仅存在于模型遵循嵌入指令的意愿中,那么移除或标记不可信字段中的祈使句式语言就能弥补这一缺陷。因为漏洞存在于模型对结构本身的感知方式中,攻击者无需编写任何看似命令的内容——一个伪造的发送者名称、一个重复的按钮标识符,或一个虚构的验证记录,都能在不包含任何守卫模型会标记为可疑的文本的情况下达成相同目标。 已证明的攻击向量 该研究团队针对生产代理系统验证了三种混凝土攻击模式,这些模式围绕代理从何处获取元数据以及这些元数据如何决定其下一步行动而组织。 该研究首先针对通过论文所标记的“元素ID注入”技术的网络浏览代理。许多网络代理通过页面可访问性树或DOM结构中嵌入的数字或序列标识符来识别可点击元素。通过在页面中植入一个伪造的产品评论或评论,该页面重用了与“立即购买”或“确认支付”元素相关联的真实且当前有效的按钮标识符——攻击者可以导致代理点击错误的目标,同时代理还认为它正在完成用户的原始请求。该技术已在Chrome中的Claude、Google的Antigravity以及开源的Nanobrowser项目[1][2]中进行了演示。 第二和第三个向量通过论文所称的“源注入”和“工具调用与响应注入”来针对编码代理。在源注入中,攻击者伪造GitHub评论的 apparent authorship元数据,使编码代理相信指令或命令来自受信任的仓库维护者,而非匿名或低权限账户,诱使代理执行其原本会持更严格审查的命令。在工具调用与响应注入中,攻击者伪造先前工具执行的记录——例如伪造的测试通过或安全扫描结果——使pull请求看似已通过其从未实际经历的验证步骤,让恶意代码得以绕过自动化或半自动化审查。这两种变体均已在Claude Code、OpenAI的Codex和Google的Gemini CLI [1][2]上得到验证。 量化威胁 研究团队在孤立的模型测试和完整的代理-闭环场景中测量了攻击成功率(ASR)。在结构化的JSON格式数据上,基准ASR范围从31.3%(Gemini 3 Pro)到43.3%(Gemini 3 Flash),GPT-5.2为41.8%,GPT-5-mini为40.3%,Claude Opus 4.5为34.3%,Claude Sonnet 4.5为37.3%[2]。针对非结构化的网页DOM数据,成功率范围要广泛得多,从大约三分之一到高达100%,具体取决于特定页面的结构和目标模型[1][2]。该漏洞在所有测试的供应商和模型系列中的一致性表明,ADI并非任何单个公司训练方法的产物,而是当前代理消费上下文的结构性后果。这些发现源自一个研究团队的研究;研究人员已公开发布其基准套件以供独立重复验证,但尚未被独立团队重现,下方的数据应被视为当前最佳证据,而非业界的既定共识。 其中一项在操作层面具有重要意义的研究发现涉及对现有防御措施的有效性。针对一系列具有代表性的缓解措施,该论文报告了以下代理级别的攻击成功率,并与49.1%的无防御基准线进行了对比。 输入防护栏——作为对抗常规提示注入攻击最常用的防御手段之一——对对抗自动化数据注入(ADI)无效,并且在一种配置下表现甚至略差于完全不设防。这一发现支持了这样的解释:ADI并非一个已解决问题的简单升级版,而是一个当前商业和开源防御系统未能设计用来弥补的漏洞。只有架构控制——即严格追踪受信源与不受信源之间的数据流,以及采用随机而非顺序的资源标识符——才能显著降低攻击成功率。而完全有效的严格数据流追踪配置则带来了显著的效用成本:代理任务完成率降至基准性能的36.5%,相比之下,在没有部署任何防御措施的情况下,基准效用为86.5%[2]。其中一个已部署的系统——OpenAI的ChatGPT Atlas浏览器——在设计上已具备部分防护功能:它使用难以猜测的随机生成的标识符来识别页面元素,而非简单的顺序计数器,这种随机标识符方法在研究人员对六种测试模型的基准测试中,将攻击成功率从49.1%降低至28.7%[1][2]。研究人员并未单独测量已部署Atlas产品本身的攻击成功率;关键在于,Atlas现有的工程选择恰好匹配了其基准测试验证为有效的防御类别。 信息披露与供应商回应 研究团队在发布前向Anthropic、OpenAI、谷歌以及Nanobrowser项目报告了研究结果。Anthropic、OpenAI和谷歌均确认了研究结果的准确性;截至发布时,尚未有供应商报告已发货或计划的修复方案,Nanobrowser也未对披露做出回应[1][2]。研究人员发布了他们的基准套件和攻击代码,以支持供应商测试和进一步的研究社区研究[1]。 建议 立即行动 在生产中运营代理系统的组织——特别是具有提交、合并或部署权限的网页浏览代理和编码助手——应清点这些代理视作权威的元数据来源:元素标识符、评论或提交作者字段,以及工具调用或测试结果记录。任何信任UI元素顺序或可预测标识符的代理都应被标记为近期整改优先事项,因为研究表明这种模式是直接且可被可靠利用的。安全团队还应审查其当前的提示注入 防御措施——尤其是输入和输出护栏模型——针对元数据损坏攻击进行了验证,因为现有证据表明,仅针对指令注入进行验证会带来一种虚假的覆盖感。 短期缓解措施 在代理框架支持的情况下,组织应从顺序的或人类可预测的资源及元素标识符转向随机化、不可猜测的标识符,遵循已至少在一个生产浏览器代理中降低ADI(假设为自动化数据集成)有效性的模式。对于具有合并或执行权限的编码代理,工具调用和响应记录——测试结果、安全扫描结果、审核批准——应与实际执行事件进行密码学绑定,而不是在代理的上下文中表示为可自由重写的文本,以便无法在真实的工具调用下游插入伪造的“测试通过”记录。代理沙箱化和双LLM(大型语言模型)架构,即将特权规划模型与处理不可信内容的低权限模型分离,在研究中产生了有意义(尽管不完整)的减少效果,并为尚无法支持完整数据溯源跟踪的代理提供了一种合理的过渡架构。 战略考量 该研究的核心结论——当前代理并未在元数据和上下文记录层面将可信数据与不可信数据隔离——指向的是一个更广泛的结构性需求,而非一个可修补的缺陷。完整数据流追踪在测试中彻底消除了攻击,但将任务完成效用降低至无防御基线86.5%的36.5%,使任务成功率减半,这对许多生产部署而言将是不容接受的效用成本,尽管风险容忍度较低的组织可能会认为这种权衡是合理的[2]。当前唯一完全有效的防御措施与当前实际可部署方案之间的这一差距,应指导组织如何排序其代理安全投资:安全与工程领导层不应将提示注入防御视为足够的覆盖范围来管理代理风险,而应将数据溯源——即区分代理上下文中每一部分数据实际来源的能力,并阻止代理将未验证数据视为已验证数据——视为下一个需要成熟的控制类别,在组织已用于构建代理授权和沙箱控制的时间线上同步推进。 CSA资源对齐 CSA的代理式AI红队指南[3]是最直接相关的先前CSA出版物。其代理式AI漏洞类别分类法已将代理上下文操控和知识库污染列为与指令式提示注入并列的独立威胁类别,其关于测试代理信任边界的指导与本研究笔记描述的元数据破坏向量紧密对应;使用该指南