AI安全风险TOP 10: OWASP GenAI LLM TOP 10 2026 中文民间翻译

2026版的LLM TOP 10发表至今已经一个半月了，主包上个月联系过官方的中文翻译组，lead表示：'did not receive the go ahead for the translation commit'，结果过了大半个月还没有在官网看到中文译本，正好我最近打算以最新的LLM TOP 10为脉络，写个LLM安全新手入门文章，想着反正自己也要看还不如直接把AI翻译下来的东西整理一下发出去，就有了这篇文章，具体的入门文章可能等到月底会发。

译者说明

本文为 OWASP GenAI LLM Top 10 2026 的非官方中文翻译整理，原版 PDF 可从 OWASP 官方页面获取，本文翻译主要参考官方 GitHub 仓库中的 2026 发布版 Markdown 源文件。

原项目采用 CC BY-SA 4.0 许可发布，允许在保留署名并遵循相同许可的前提下复制、传播和改编。本文由 AI 辅助翻译并人工整理，如有歧义或错误，请以英文原文为准。

另外，附录 A（Related Framework Mappings）主要用于不同安全框架之间的术语与条目映射。为避免翻译造成术语对应关系和信息损失，其中的映射表内容保留英文原文，仅翻译表格之外的说明性文字。

项目负责人来信

不要再试图构建一个永远不会被骗的模型。应该构建模型周围的系统，使得当模型被骗时——而它终究会被骗——不会有任何重要的东西因此出问题。这种安全姿态贯穿了这里的全部十项风险。今年，我们第一次能够向你展示证据，而不是要求你仅凭信任接受这一点。

此前这个榜单的每一个版本，都是建立在专业判断之上的。数百名从业者参与评估，判断哪些风险最重要。这一投票至今仍然是榜单的骨架，而且它本就应该如此。今年，我们做了一件这个项目以前从未做过的事：用真实发生过的问题记录来检验投票结果。我们汇总了来自公开漏洞数据库和一个 AI 危害数据库的 7,714 起真实事件，并构建了分类器对这些事件进行读取和归类，其中有 6,639 起包含足够的信息，可以被划分到相应类别。然后我们提出了一个非常直接的问题：从业者所担心的风险，是否与真实事件记录所反映的情况一致？

答案是否定的——至少并不总是一致，而这正是出人意料之处。投票结果与数据在一些具体而且有意义的地方出现了分歧，而这些分歧带给我们的启示，比它们一致的地方更多。

提示词注入是最明显的例子。从业者将它排在第一位。但如果只按照原始事件记录对各类别排序，它甚至会跌出前十。这种差距体现的是一种防御效应。团队会投入大量精力对抗提示词注入，因此真正形成清晰漏洞利用并最终进入公开数据库的事件反而更少。于是，公开事件数量低估了这一风险，而成熟团队实际上已经投入了真实的成本来持续抵御它。只要模型会读取不受信任的输入，这个攻击面就存在——换句话说，它无处不在。因此，提示词注入仍然排在第一位。既然这个攻击面无法彻底关闭，就应该按照“总有一天它会被用于攻击你”的前提来设计系统。

错误信息则恰好相反，而且这是我希望你放慢速度认真阅读的一项风险。投票者把它排在了接近末尾的位置，而事件记录却把它排在了接近顶部的位置。这是所有分歧中最值得警惕的一类：投票认为风险较低，而证据显示风险较高。最终榜单仍将错误信息放在中间位置：投票被赋予了更高权重，但事件证据把它向上推了一些。这里真正重要的正是这种分歧。当模型以流畅而自信的方式输出内容，并据此驱动某项决策或工具调用时，一个错误答案就会转化为一个错误行动，而事件记录显示，这类失败发生的频率比投票结果所假设的更高。

社区投票占总权重的四分之三，事件数据占剩余的四分之一。我们有意让投票占据较高权重。这份榜单是社区共识的产物，一年中带有噪声的数据，不应该推翻真正从事这项工作的人员所形成的判断。四分之一的权重已经足以在“认知与证据之间差距很大”时，让某项风险上移或下移一个层级；但又不足以让不完善的数据独自重写整个榜单。Top 10 中每一个最终排名，都是由这种平衡决定的。

2026 Top 10 的变化

从 2025 版到最终 2026 版 OWASP GenAI/LLM Top 10 的排名变化。不同颜色分别表示排名保持不变、上升、优先级下降，或条目被重命名/重新划定范围。

今年的排名变化幅度比过去几年更大，而这些变化正对应了前面所说的“认知与证据之间的差距”。过度代理权（Excessive Agency）上升到第三位，这是整个榜单中影响最大的排名变化，因为投票结果和事件记录都表明，智能体式部署正是现实损害集中发生的地方。无界消耗（Unbounded Consumption）上升了四位，这是因为从业者现在对资源耗尽和成本耗尽风险的重视程度，高于它此前排名所体现出的程度。输出处理不当（Improper Output Handling）下降幅度最大，从第五位降至第十位。提示词注入（Prompt Injection）依靠社区投票的高排名，以及其背后的防御效应，继续保持第一。敏感信息泄露（Sensitive Information Disclosure）保持第二位，这是榜单顶部唯一一个认知与证据高度一致的地方，也是我们信心最高的一项。此前的 System Prompt Leakage（系统提示词泄露）现在更名为 Hidden Context Exposure（隐藏上下文暴露），以更广泛地描述同一种问题：本应处于不可触及范围内的信息，却被错误地当作可以安全信任和隐藏的内容。

还有几个条目的范围也得到了扩展。我们将更新、更明确的风险纳入那些本就应该涵盖它们的现有条目中，而不是为了这些风险单独建立过于狭窄的新类别，因为那只会让整个榜单变得碎片化，却不会带来实际收益。提示词注入现在涵盖跨模态攻击，例如将指令隐藏在图像或音轨中的攻击。供应链（Supply Chain）现在涵盖这样一种信任失效：被推广使用的模型制品，实际上并不是它所声称的那个东西。数据与模型投毒（Data and Model Poisoning）现在吸收了针对微调过程的破坏。输出处理不当现在也覆盖了 AI 助手大规模生成不安全代码所带来的风险。这些风险背后的事件一直都是真实存在的。现在，它们终于被归入了真正应该归属的位置。

还有一条边界正变得一年比一年重要。当模型只是你应用中的一个组件时，这份榜单负责覆盖相关风险。一旦模型变成了一个行动主体——能够调用工具、在会话之间保留记忆，并在下游触发实际后果——相关风险就进入了 OWASP Agentic Top 10 的范围。我们阅读过的许多事件，实际上都正好位于这条边界上。这里的每一个条目，描述的是“模型作为应用组件”时的失效。当你的模型开始自主行动时，就应该把这份榜单与 Agentic Top 10 配合使用，因为这两份榜单都无法单独覆盖完整的风险范围。

展望未来

你现在就可以信任这份榜单，并据此采取行动。它将那些负责攻击和防御这些系统的从业者所形成的专业判断，与现实中已经发生过的问题记录结合在了一起，并让二者相互检验。这种现实依据，是此前的版本只能承诺、而无法真正提供的东西。对这十项风险全部采取措施，从排名最前的风险开始，并按照“总有一天模型会被用来对付你”的前提去构建针对每一项风险的防御。这样做，你所覆盖的既包括这个领域最担心的风险，也包括它已经真正遭受过损害的风险。

和它所涵盖的技术一样，这份榜单也是社区共同协作的产物。开发者、数据科学家和安全从业者共同塑造了它，他们贡献了自己的专业判断，而在今年，也贡献了真实的事件记录。我们感谢每一位参与其中、提出争论，并推动我们用证据去检验既有认知的人。我们希望这份榜单能够帮助你保护自己正在构建的系统。

Steve Wilson

项目负责人，OWASP Top 10 for LLM Applications

LinkedIn: https://www.linkedin.com/in/wilsonsd/

Rock Lambros

联合负责人，OWASP Top 10 for LLM Applications

LinkedIn: https://www.linkedin.com/in/rocklambros

LLM Top 10 概览

攻击面被可视化为靶心。位于外围的入侵途径经由放大机制汇聚，最终产生三种核心影响。注：并非所有 LLM04 攻击都呈向内渗透之势，部分攻击可直接造成影响。

LLM01:2026 提示词注入(Prompt Injection)

描述

当输入到大型语言模型（LLM）的内容——无论是用户直接输入、检索到的内容、工具输出、图像、音频或视频内容、中间推理，还是持久化记忆——以应用开发者未预期的方式改变模型行为时，就会出现提示词注入漏洞。LLM 在架构上并不区分“指令”和“数据”（二者都是同一序列中的词元），因此不存在一种可以直接对应于参数化查询的解决方案（NCSC, 2025）。输入不必是人类可读的，不必直接来自用户，也不必在渲染后的界面中可见，就能影响模型。

提示词注入漏洞存在于模型处理输入的方式中，也存在于这些输入迫使模型错误地向系统其他部分传递数据或指令的过程中。部署时的三项特性会进一步加剧这一问题。第一，上下文窗口混合：模型将系统提示词、用户输入、检索到的文档、工具输出、对话历史和记忆视为同一个词元序列，其中没有强制执行的信任边界。第二，记忆持久化：一旦注入内容被写入长期记忆、RAG 语料库、向量存储或托管记忆服务，之后每个从该存储读取内容的会话都会受到污染。第三，智能体执行：当模型输出驱动工具调用时（文件系统、Shell、电子邮件、云 API、MCP 服务器、子智能体），影响范围就会从聊天界面扩展到智能体工具所能触及的一切；而工具输出又会重新进入上下文窗口，从而产生链式效应或自我复制效应。

可以沿三个维度剖析提示词注入的构成。投递入口指它如何到达模型（直接输入、检索内容、工具输出、工具连接通道或持久化记忆）。传播行为指它如何跨越时间和边界传播（单次攻击、多步骤攻击链、通过记忆或 RAG 跨会话传播，或在智能体之间自我复制）。编码方式指恶意指令如何以词元或像素的形式表示（纯文本、Base64 或其他混淆方式、不可见 Unicode、多模态或隐写术、低资源语言）。在选择适用的缓解措施之前，沿这些维度拆解场景是一项有用的威胁建模步骤。

成功的提示词注入所造成的严重程度和影响性质，取决于模型所处的业务环境，以及系统架构赋予模型的行动能力。提示词注入可能导致的后果包括但不限于：

• 泄露敏感信息、系统提示词内容、检索到的私有文档或基础设施细节。
• 操纵模型输出，使其生成带有偏见、有害或由攻击者指定的内容，并被下游系统或用户据此采取行动。
• 未经授权地调用智能体原本有权限调用的工具；如果智能体能够访问 Shell、文件系统或云 API，后果可能升级为任意命令执行和破坏性操作。
• 通过图像 URL 通道、渲染输出中的隐藏 Unicode 字符，或隐蔽的工具日志侧信道窃取数据。
• 通过记忆或 RAG 语料库投毒，跨会话持续控制智能体行为。

注：提示词注入不同于 LLM02:2026 敏感信息泄露，后者关注模型通过输出泄露了什么，包括推理通道的内容；也不同于 LLM03:2026 过度代理权，后者关注模型输出触发特权操作所产生的后果。本条目关注输入边界本身。模型输出在到达下游组件之前的清理和验证，则由 LLM10:2026 输出处理不当涵盖。

提示词注入的类型

直接提示词注入

用户，或能够使用用户访问路径的攻击者，提供输入，以非预期的方式改变模型行为。直接注入可以是有意的（恶意用户构造越狱提示词），也可以是无意的（合法用户粘贴的内容恰好包含相互冲突的指令；或者用户依赖一个 LLM 提供帮助，却无意中针对另一个无关的下游 LLM 优化了自己的输入，如场景 #3 所示）。

越狱是提示词注入的一个子集，攻击者的目标是让模型违反其安全协议。应用层防护有助于限制越狱的影响，但要有效预防，仍需持续更新模型训练和安全机制。

间接提示词注入

模型摄入来自外部来源的内容（网页、文档、电子邮件、工具响应、检索到的 RAG 片段、图像、MCP 服务器的输出、数据库行或 Issue 标题），其中包含起到提示词注入作用的数据。这些指令并非由用户提供，用户也没有看到它们。投递入口的信任属性决定了哪些防御措施在实践中可行：

• 不可信入口。 公共网页、未知发件人的电子邮件、搜索结果。防御方必须将来自这些来源的任何内容视为可疑内容。大多数提示词注入研究都集中在这一类入口上。
• 半可信入口。 公共缺陷跟踪系统中的 Issue 标题、软件包的 README 和变更日志、第三方 API 响应：这些是用户选择检索、但并非由用户编写的内容。用户信任平台，却不一定信任每个贡献者。
• 可信入口。 开发者自己的代码仓库、数据库、内部文档和邮件。开发者可能没有意识到攻击者已经在这些位置放入了内容；攻击者可能利用了某个无关的上游途径，例如公开的缺陷报告表单。

它们具有共同的结构：攻击者不需要直接攻陷后端。他们只需将文本放在开发者的 LLM 会读取的位置，随后，以开发者权限运行的 LLM 就会代为完成操作。仅关注聊天界面的防御会完全遗漏这种情况。

间接提示词注入越来越多地将用户自己的 LLM 实例变成攻击用户自身后端的武器。其模式是：攻击者通过低权限通道（公开表单、客户工单、社区拉取请求），向用户信任的位置提交文本，然后等待用户连接了 MCP 的智能体或开发助手在使用用户的高权限凭证时读取这段文本。执行特权操作的是智能体，而不是攻击者（参见常见风险示例 #3；场景 #9 介绍了针对生产环境的概念验证）。

常见风险示例

1. 通过直接提示词输入覆盖指令：用户消息覆盖系统提示词中的角色和能力限制，使模型在预期范围之外披露信息、生成内容或采取行动。有意输入和无意输入都属于这种情况。
2. 通过检索内容进行间接注入：攻击者的指令夹带在 RAG 片段、网页、文档或电子邮件中，并在内容进入上下文窗口时被执行（例如 EmailGPT；INCIBE-CERT, 2024）。
3. 可信入口中的间接注入：植入低权限但受信任通道（Issue 跟踪系统、反馈表单、支持工单）的文本，使用户的 LLM 使用自身的高权限凭证采取行动，窃取代码仓库、导出数据库或修改 IDE 配置；这些都是攻击者无法直接执行的操作（Invariant Labs, 2025; General Analysis, 2025; Rehberger, 2025a）。
4. 多模态与隐写注入：图像、音频或视频中低于人类感知阈值的扰动被编码器提取出来（Clusmann et al., 2025；参见场景 #6）。
5. 不可见字符注入与数据外传：标签区块字符、变体选择符和零宽 Unicode 字符在看似无害的文本中携带指令或外传字节。2024 年 8 月针对 M365 Copilot 的 ASCII 走私概念验证窃取了一个 Slack 多因素认证（MFA）验证码（Rehberger, 2024）。
6. 跨会话记忆与 RAG 语料库投毒：持久化记忆或 RAG 语料库中的一条受污染记录，会影响今后每个读取它的会话（W. Zou et al., 2025；参见场景 #4）。
7. 将微调接口用作梯度预言机（“fun-tuning”）：攻击者从供应商的微调 API 读取逐样本损失值，以优化攻击载荷（对 Gemini 的攻击成功率从 65% 提升至 82%），从而将类似白盒的优化方法用于闭源权重模型（Labunets et al., 2025）。
8. 多语言、编码或低资源语言载荷：低资源语言和混合语言输入会提高攻击成功率，并绕过未针对这种方案训练的分类器；Base64、ROT13 或表情符号编码则能绕过从未接触过这些编码的过滤器（Hackett et al., 2025）。

预防与缓解策略

提示词注入是当前生成式 AI 的内在问题：LLM 在架构上不区分指令与数据，其行为又具有随机性，因此目前不存在可靠的预防机制；这一立场与 NIST（2025）、NCSC（2025）以及 Debenedetti et al.（2025）一致。因此，防御应从架构入手，而非依赖拦截。设计外围系统时，应明确假定模型的指令边界最终会被绕过，并限制模型获准执行的操作，以及其输出获准触及的范围，使成功的注入不会转化为成功的漏洞利用。

有记录的大多数高影响提示词注入事件之所以后果严重，是因为注入发生在这样的系统中：其工具、权限范围或输出渲染能力，允许被操纵的模型以用户的权限级别替攻击者行动（参见场景 #7 至 #9）。这就是本条目与 LLM03:2026 过度代理权在实际运行中的关系：提示词注入是输入侧的失陷，而过多的功能、权限或自主性，则让这种失陷产生了聊天窗口之外的后果。Simon Willison 的“致命三要素”（lethal trifecta，2025）将同样的结构性判断表述为一项部署前检查：如果智能体能够同时访问私有数据、摄入不可信内容并与外部通信，就具备了造成高影响利用的条件；去掉其中任意一项，就能消除这一组合条件。

应将以下控制措施作为纵深防御共同使用，因为没有任何单项控制足够有效。其中一些措施可以降低注入成功率，但预计会在面对自适应攻击者时逐渐失效。另一些措施则在注入成功之后限制影响范围；面对能够探测系统的攻击者，能够继续发挥作用的是这类措施。对于智能体部署，最小权限和能力预算控制（#4、#8）是关键支柱；LLM03:2026 对行动能力一侧的问题进行了完整讨论。

1. 在系统提示词中约束模型的角色与能力。 使用明确声明的允许和禁止规则（“仅协助处理 X，不得访问 Y，不得将输出转发至外部地址”），而非开放式授权。这只能提供部分控制：推断出提示词的攻击者可以绕过它（Nasr et al., 2025），因此应将其与 #4 中的权限控制配合使用。
2. 定义严格的输出模式，并在可信的应用代码中验证每一条响应，在任何下游系统据此行动之前完成验证；应采用结构验证，而不是再调用一次 LLM。这样能够发现格式违规，却无法发现语义操纵：符合模式的响应仍可能携带恶意 SQL 查询，或按数据外传需求构造的邮件正文。
3. 在每一种模态的边界处实施过滤（文本、图像、音频、结构化数据），而不只是过滤文本。 运行针对各模态的分类器，对图像进行 OCR，对音频进行转录，然后对提取出的内容应用文本过滤。语义过滤器可以被改写或编码绕过，低资源语言和混合语言输入也会降低其准确率（Hackett et al., 2025）。
4. 由应用代码而非模型掌管凭证和状态变更能力，并按每项操作授予最小权限。 将特权调用路由至确定性策略引擎，由该引擎在执行时重新验证意图与参数。NIST AI 100-2 E2025 以及 CISA 与“五眼联盟”联合发布的运营技术（OT）指南（CISA et al., 2025），都将这种确定性的中介控制视为采购的基线要求。为“方便”而授予的宽泛权限，以及多智能体之间的逐级调用，会在下游重新引入风险。
5. 在每个内容摄入和渲染边界，移除标签区块字符（U+E0000 至 E007F）、变体选择符（U+FE00 至 FE0F）以及零宽字符（U+200B、U+200C、U+200D、U+2060）。 这些字符在正常渲染时不可见，可用于夹带指令或数据外传字节（参见常见风险示例 #5）；基于变体选择符的变种（Rehberger, 2025c）能够以不可见的方式夹带任意字节。移除这些字符并不能阻止可见文本载荷，也不能阻止未来出现的其他隐写类别。
6. 通过结构上独立、且标注来源的通道传递外部内容，使模型能够区分数据与指令（S. Chen et al., 2025; Microsoft Research, 2025）。这只能在非自适应测试中降低攻击成功率：了解标记方案的攻击者可以模仿它，而 StruQ 已在自适应攻击下被绕过（Nasr et al., 2025）。
7. 在执行任何特权操作、不可逆操作或对外可见的操作之前，要求人工明确确认，并向审核者展示待执行操作的准确渲染结果，而不是摘要。不可见字符走私可能导致展示的操作与实际执行的操作不一致（#5）；大量审批带来的疲劳也会削弱审核者的判断力。
8. 以“二要素规则”（Rule of Two）作为底线，对智能体能力进行预算分配（Meta AI, 2025）。将同时具备以下能力视为高风险：（A）接触不可信输入，（B）访问敏感数据，以及（C）改变状态或与外部通信。任何具备 [A,B,C] 的智能体都需要逐项操作获得人工批准，而 [A,B] 或 [A,C] 配置则需要明确开展剩余风险评估（参见场景 #8）。NIST AI 100-2 E2025 以及 CISA、FBI、NSA 和 ACSC 的 OT 指南（CISA et al., 2025）都认可这一规则，但该规则没有涉及自主行动的深度（Noma Security, 2025）。
9. 将智能体记忆写入视为特权操作。 记录引发写入的提示词，对写入内容进行分类，以识别其中的指令或角色修改内容；在含有指令的记忆被跨会话持久化之前，要求获得批准。2025 年 2 月的一个 Gemini 概念验证（Rehberger, 2025b）通过延迟工具调用污染了记忆（MITRE, n.d.）。事实性条目与指令之间的界限可能逐渐模糊，而增量写入可能绕过逐次写入分类。
10. 固定每个 MCP 服务器和第三方工具包的版本，对其进行签名与验证，审计工具描述中的隐藏指令，并监控工具组合。 将它们视为软件供应链攻击面：第三方工具包由 LLM04:2026 供应链涵盖，MCP 服务器和工具注册表则由 ASI04 智能体供应链漏洞涵盖（参见场景 #9）。固定版本无法阻止已经随该固定版本发布的载荷，也无法阻止不改变版本号的工具描述投毒。
11. 使用已经读过已部署防御方案的自适应攻击者进行测试，不接受仅基于静态攻击得出的攻击成功率结论。 使用 AgentDojo（Debenedetti et al., 2024）和 JailbreakBench（Chao et al., 2024）建立基线，然后在向测试人员公开完整防御规范的前提下开展红队测试。Nasr et al.（2025）发现，对于近期提出的 12 种防御中的大多数，静态攻击成功率接近零，而自适应攻击成功率超过 90%（另见 LLMail-Inject，Microsoft Security Response Center, 2025）。

攻击场景示例

场景 #1：直接注入

攻击者通过提示词要求客服聊天机器人忽略其准则、查询私有数据存储并发送电子邮件，从而导致未经授权的访问和权限提升。

构成分析：（a）用户直接输入；（b）单次攻击；（c）纯文本。

场景 #2：通过检索到的网页内容进行间接注入

用户要求助手总结一个包含隐藏指令的网页。模型插入一张 Markdown 图像，其 URL 会将私密对话外传至攻击者控制的域名。用户只能看到渲染后的图像，始终看不到那条指令。

构成分析：（a）检索到的网页内容（间接）；（b）单次攻击，通过图像 URL 外传数据；（c）隐藏在页面源码中的纯文本。

场景 #3：无意注入

一份职位描述 PDF 中嵌入了一条 AI 检测指令。求职者在不知情的情况下使用 LLM，根据这份职位描述优化简历；模型将该指令呈现出来，招聘系统因此对候选人作出标记。这是一起双方均无恶意的提示词注入。

构成分析：（a）间接输入（文档／PDF）；（b）单次攻击；（c）纯文本。

场景 #4：RAG 知识库投毒

攻击者向应用检索所使用的语料库提交投毒文档。匹配的查询返回被修改的内容，其中的指令随即改变输出。面对包含数百万篇文本的知识库，仅五篇投毒文档就曾达到约 90% 的攻击成功率（W. Zou et al., 2025）。

构成分析：（a）检索内容（RAG 语料库）；（b）跨会话／跨用户；（c）纯文本。

场景 #5：载荷拆分

攻击者将恶意指令拆分到简历的多个字段中（页眉、正文、附件），使逐字段分类器看来没有任何单个字段具有恶意。LLM 在评估时将这些片段重新组合，其推荐结果因此受到操纵。

构成分析：（a）拆分在多个字段中的用户直接输入；（b）单次攻击，在评估时重新组合；（c）被拆分的纯文本。

场景 #6：多模态隐写注入

攻击者以低于人类视觉感知阈值的方式，将一条指令嵌入图像。多模态模型的视觉编码器提取出载荷，模型行为发生变化，随后生成有害输出或发起未经授权的工具调用。研究者已经在肿瘤影像场景中，针对四个前沿视觉语言模型演示了这种攻击（Clusmann et al., 2025）；也通过结合视觉扰动与文本引导，针对通用模型演示了这种攻击（R. Chen et al., 2025）。

构成分析：（a）图像输入（间接／多模态）；（b）单次攻击；（c）隐写／像素级编码。

场景 #7：文档承载的零点击智能体数据外传

一封精心构造的电子邮件，在无需用户交互的情况下，触发由 LLM 驱动的生产力助手外传组织数据。Aim Security 针对 Microsoft 365 Copilot 演示了这种攻击（Reddy & Gujral, 2025），同时绕过了已部署的提示词注入分类器和链接遮蔽过滤器。

构成分析：（a）电子邮件／文档（间接）；（b）单次攻击，伴随工具调用；（c）纯文本，配合不可见 Unicode 数据外传通道。

场景 #8：智能体执行破坏性命令

2025 年 7 月的两起事件展示了不同途径造成的同类影响。在 AWS 回滚相关提交之前，一名攻击者向 Amazon Q 的 VS Code 扩展仓库提交了一个破坏性的系统提示词，不过提交的代码因语法错误而未能执行（Amazon Web Services, 2025a）。另一起独立事件中，运行时注入导致 Amazon Q 执行了任意代码（Amazon Web Services, 2025b）。拥有 Shell、文件系统或云 API 访问权限的智能体，会将注入放大为影响宿主的安全事件。

构成分析：（a）供应链／遭篡改的系统提示词，或运行时间接注入；（b）跨会话持续生效，或伴随 Shell 工具执行的单次攻击；（c）纯文本。

场景 #9：通过 MCP 对可信后端进行间接注入

攻击者在低权限通道中植入文本（公开的 GitHub Issue、支持工单或恶意 npm 包），而开发者的 LLM 使用高权限凭证读取这些内容。Invariant Labs（2025）通过投毒的 GitHub Issue 窃取了私有代码仓库；General Analysis（2025）通过 Cursor 的 Supabase MCP 服务器导出了生产数据库，该服务器以 service_role 角色运行并绕过行级安全控制；恶意的 postmark-mcp 包（Koi Security, 2025; Toulas, 2025）则将估计涉及 300 家组织的电子邮件密送给攻击者。

构成分析：（a）可信入口中的间接注入（MCP 通道：Issue、工单、npm 包）；（b）多步骤工具调用链；（c）纯文本。

LLM02:2026 敏感信息泄露(Sensitive Information Disclosure)

描述

当集成了 LLM 的系统通过数据主体、数据控制者或系统所有者未授权的通道，暴露机密数据、受监管数据、受特权保护的数据或专有数据时，就会发生敏感信息泄露。这些通道并不限于最终回答：工具调用参数、推理轨迹、检索到的文本块、多模态输出、日志、遥测数据、嵌入向量，以及可观测的推理特征（耗时、词元长度、对数概率、置信度、缓存命中行为），都是泄露面。应将它们分别视为输出，并应用相同的分类和脱敏规则。

泄露可能发生在 LLM 生命周期的四个阶段：

1. 训练阶段。 模型、微调模型或 LoRA 适配器记住了语料库内容，随后逐字或以可恢复的形式复现这些内容。记忆程度随模型容量、数据重复程度和上下文长度呈对数线性关系变化。面向狭窄任务的适配器会高保真地记住罕见样本，形成一个有别于基础模型的定向提取攻击面。
2. 推理阶段。 模型泄露当前上下文中的内容（系统提示词、RAG 文本块、文件、工具输出、记忆或另一个会话的数据），通常是因为摘要、翻译或提取操作呈现了超出请求范围的内容，其中也包括在视觉上已被遮盖的文本片段。
3. 处理流水线阶段。 微调、蒸馏、合成数据生成、梯度、SDK 和可观测性机制，将敏感数据转移到衍生产物中。
4. 观测阶段。 对手无需收到内容本身，就能根据外部可测量的特征（TLS 加密下的词元长度、延迟、对数概率、置信度、缓存命中信号）推断事实。

受保护的信息包括个人身份信息（PII）、受保护健康信息（PHI）、财务数据、凭证、API 密钥、商业秘密、模型权重、受特权保护的通信、涉密或受出口管制的材料，以及生物特征和基因组标识信息。大多数事件由两类结构性失效引发。第一，上游过度共享：未限定访问范围的网盘、遗留权限和知识库将敏感数据提供给 RAG，模型随后按设计检索这些数据。需要修复的是数据访问面，而非模型（DSGAI01）。第二，持久性：一旦数据影响了权重、嵌入向量或适配器，即使删除源数据，相关信息仍然可以被提取，这给履行 GDPR 第 17 条和 CCPA 第 1798.105 节规定的删除义务带来困难。开放权重部署不能依赖速率限制，因为提取、成员推断和反演可以离线运行，且速率不受限制。

严重程度应取决于接收方能够获知什么，而非泄露内容是否看起来像自然语言。适用的法规与标准框架包括《欧盟人工智能法案》（欧盟第 2024/1689 号条例，高风险相关义务自 2026 年 8 月起适用）、GDPR、HIPAA、CCPA/CPRA、ISO/IEC 42001 和 NIST AI 600-1。本条目讨论作为应用组件的 LLM。当它作为自主行动者运行时（跨会话记忆、工具选择、多步骤数据外传），由此放大的风险由 ASI 涵盖，更深入的控制措施则见 DSGAI。

常见风险示例

1. 训练数据记忆与提取。 2023 年 11 月的“poem”发散攻击，以约 200 美元的成本，诱使 gpt-3.5-turbo 输出了超过 10,000 个不重复的已记忆样本（Nasr et al., 2023）。供应商的补丁已多次被绕过。与同等规模的基础模型相比，微调模型及其 LoRA 适配器中的数据更容易被提取，形成一个有别于基础模型的定向提取攻击面。《纽约时报》诉 OpenAI 案和 Getty 诉 Stability AI 案的诉讼证据中，都包含逐字或原样复现的示例；其中 Getty 案的核心是水印复现。
2. 推理阶段的上下文与输出泄露。 2023 年 3 月，ChatGPT 的 Redis 缺陷暴露了 1.2% 的 Plus 订阅用户的支付相关个人身份信息。2025 年，由于缺少 noindex 指令，超过 4,500 个共享对话被 Google 编入索引。存储临床数据嵌入向量的向量存储属于 HIPAA 审计控制的适用范围，但大多数团队尚未将这些控制落实到实际运行中；检索层的授权机制也普遍实施不足。应将推理轨迹和工具参数视为输出，而非调试遗留物。轨迹通道还使通过强制输出推理轨迹来提取模型成为可能。正则表达式和黑名单过滤器会被跨语言、Base64 和十六进制编码绕过。如果策略禁止某种综合推断结果，那么即使各个来源单独使用时都被允许，将它们聚合起来（预算 + 招聘 + 尽职调查 → 某个待收购目标）也构成泄露。
3. 嵌入向量与表征泄露。 现代反演方法能够从泄露或导出的向量中重建明文，因此，“仅包含嵌入向量”的备份泄露也属于源文档泄露。余弦相似度不会遵守访问控制列表（ACL）。必须在检索之前完成授权，因为生成后的过滤无法撤回已经提供给模型的文本块。相关机制由 LLM09:2026 和 DSGAI13 涵盖。本条目关注其监管后果。
4. 多模态泄露。 视觉模型通过 OCR 从截图、通知和 PDF 元数据中读取凭证与个人身份信息。生成模型会复现水印和可识别的人脸（Getty／Stable Diffusion 水印案是典型案例）。跨模态转换（将文本渲染为图像、通过 OCR 将图像转换为文本）可以绕过仅覆盖单一模态的数据防泄露（DLP）措施。
5. 推理阶段的侧信道。 SPV-MIA 将针对微调目标模型的成员推断 AUC 提升至 0.9（Fu et al., 2024），足以就某个具名个人作出监管意义上的泄露认定。Whisper Leak（McDonald & Bar Or, 2025）通过加密流量对 28 个生产模型的对话主题进行分类，精确率—召回率曲线下面积（AUPRC）超过 98%。Weiss et al.（2024）通过词元长度重建了 29% 的响应内容，并推断出 55% 的响应的主题。Wu et al.（2025）演示了多租户推理服务中由 KV 缓存共享导致的提示词泄露。Dong et al.（2025）从中间层反演出一段长达 4,112 个词元的医疗提示词，按词元匹配计算的 F1 值为 0.8688。Carlini et al.（2024）通过 logit 偏置通道恢复了一个生产模型的投影层。
6. 训练流水线泄露。 恶意服务器实施的梯度反演（Boenisch et al., 2021）、蒸馏，以及合成数据中的信息延续，会将样本转移到衍生模型中。针对受差分隐私（DP）保护模型的迭代查询攻击，会不断改进由 LLM 生成的查询，并锁定置信度突增的位置，以重新识别个人。因此，固定 ε 的差分隐私是必要条件，但如果没有速率限制、查询模式检测和每用户预算，仍然不足以提供保护。
7. 平台与生态系统泄露。 可观测性平台（Langfuse、LangSmith、Datadog LLM Observability）默认记录完整的提示词、补全文本、文本块和轨迹。两个具有代表性的事件是：2025 年 1 月，DeepSeek 的 ClickHouse 暴露了超过一百万行日志和 API 密钥（Wiz, 2025）；以及 Check Point 在 2026 年披露的 ChatGPT 数据外传问题，其中攻击利用代码执行运行时内隐藏的出站通道，仅凭一条精心构造的提示词，就将运行时变成了一个静默的 DNS 通道，而用户可见的回答仍然保持无害（Check Point Research, 2026）。

预防与缓解策略

缓解措施遵循 DSGAI 的分层结构，提供逐级实施的路径。

第 1 层：基础措施（所有部署）

1. 治理语料库：开展来源追溯、分类和去重，去重范围覆盖近似重复内容、音译形式和不同格式的变体。在摄入时清除个人身份信息。去重能够减少记忆，但不能消除记忆。
2. 最小化上下文：仅向外部提供商发送任务所需字段。除非针对具体模板有充分理由，否则禁用自动上下文（customer_360、追加完整记录）。
3. 先授权、后检索：在索引查询内部实施文档级和文本块级授权，而不是在检索之后的应用层实施。对于高敏感度工作负载，按租户隔离索引。
4. 系统提示词安全规范：绝不在系统提示词中存储秘密、凭证或受监管数据。
5. 使用分类器进行清理，而非仅依赖正则表达式：结合模式匹配、命名实体识别（NER）和经过训练的分类器，因为正则表达式无法有效处理编码后的输出和跨语言输出。
6. 在敏感端点上，按用户和会话设置查询预算，以干扰枚举和成员探测。
7. 运行安全规范：在应用性能监控（APM）系统摄入日志和轨迹之前，限制其访问并进行清理；对传输中和静态存储的数据进行加密；通过技术手段强制落实“不用于训练／不保留”，而非仅依赖政策文本。

第 2 层：加固措施（受监管／高敏感度场景）

1. 根据敏感度和基数校准采用差分隐私的随机梯度下降（DP-SGD），并监测过拟合，将其作为记忆程度的替代指标。配合检测措施使用，因为固定预算的保护效果会在自适应查询下减弱。
2. 保护向量存储：实施加密、独立于文档 ACL 的访问控制列表、受限制的导出 API、最小范围的 k 近邻检索（k-NN），以及嵌入空间探测检测。
3. 在生产端点上，对对数概率、置信度和解释信息的提供设置访问限制。
4. 将推理轨迹作为正式输出进行分类和脱敏。绝不将原始轨迹记录到访问不受限制的可观测性系统中。
5. 侧信道防御：对流式输出进行随机填充和词元批量发送；为高敏感度租户分配专用前缀缓存以实施隔离；在租户共用基础设施时，对 KV 缓存进行分区。
6. 对结构化标识符使用保留格式加密，严格区分内部与外部路由，并在外部路径上实施字段允许列表。
7. 将能够识别 AI 相关活动的审计日志接入安全信息与事件管理（SIEM）系统，持续开展 DLP 和 AI 安全态势管理（AI-SPM），并建立有文档记录的数据域清单、强制实施关联策略，防止单独获准使用的数据源组合出被禁止的结论。

第 3 层：高级措施（受监管、涉密、重点攻击目标场景）

1. 当威胁模型足以证明功能效用和延迟方面的代价合理时，采用机密计算（Intel TDX、AMD SEV-SNP、AWS Nitro Enclaves），或新兴的隐私保护推理方法（AloePri 协变混淆框架，Lin et al., 2026）。
2. 对原始数据、嵌入向量、检查点和适配器实施可验证的删除，并在执行机器遗忘后，通过提取和成员推断探测验证删除效果。
3. 将信息泄露红队测试设为发布门槛：覆盖提取、成员推断、嵌入向量反演、内部状态反演、侧信道，以及 LoRA 数据可提取性；进行定量测量，并与 MITRE ATLAS 对齐。
4. 使用提取工具审计合成数据。通过探测检测、速率限制和水印抵御蒸馏。为聚合分析设置预算。
5. 演练信息泄露事件响应预案：按数据类别以及受影响的数据主体或会话确定影响范围，然后评估并履行相关法规框架下适用的数据泄露和严重事件通报义务（例如 GDPR、HIPAA 和《欧盟人工智能法案》第 73 条）。随后开展机器遗忘、重新训练或撤下模型，清理向量和缓存，通知供应商，并审计持久化记忆。

攻击场景示例

场景 #1

发散提示词使生产模型大规模输出已记忆的个人身份信息、URL 和仍然有效的凭证，触发 GDPR 第 33 条规定的通报义务。

场景 #2

共享推理状态中的缺陷，将一名用户用于生成医疗信函的提示词泄露到另一名用户的推理轨迹中。适用 HIPAA 的 60 天通报要求。

场景 #3

扩展思考轨迹被原样记录到共享的 APM 项目中，使检索到的个人身份信息暴露给数百名工程师，而回答本身仍然经过了脱敏。

场景 #4

提示词注入使客服机器人输出其系统提示词，以及嵌入其中的供应商 API 密钥。

场景 #5

共享的法律 RAG 索引跨越了律所边界，将一名客户受特权保护的策略综合进另一名客户的回答中，构成律师—客户保密特权放弃事件。

场景 #6

一份泄露的“仅包含嵌入向量”的向量备份，在经过反演后被重新认定为源文档泄露，72 小时通报倒计时重新开始。

场景 #7

Whisper Leak 对加密流式传输进行主题推断，无需解密即可识别哪些用户正在查询医疗、法律或政治主题。

场景 #8

针对临床微调模型的成员推断，无需提取任何记录，就能以较高的 AUC 识别训练集中的患者，构成依照 HIPAA 需要报告的认定。

场景 #9

一份 PDF 在未经修改的文本上方渲染了黑色矩形遮盖层，模型却对隐藏在该遮盖层下方的个人身份信息进行了总结。

场景 #10

注入的“诊断检查”使代码运行时将电子表格内容编码进 DNS 查询中，而用户可见的统计摘要仍然保持无害。

LLM03:2026 过度代理权(Excessive Agency)

描述

基于 LLM 的系统通常会由开发者赋予一定程度的行动能力：通过工具（不同供应商也将其称为扩展、插件或技能）调用函数或与其他系统交互，以响应提示词并执行操作。LLM 智能体还可以根据输入提示词或先前的 LLM 输出，动态选择要调用的工具。基于智能体的系统通常会反复调用 LLM，并使用前几次调用的输出，为后续调用提供依据和指引。

过度代理权是指这样一种漏洞：无论是什么原因导致 LLM 行为失常，当 LLM 产生非预期、含糊不清或受到操纵的输出时，系统都可能据此执行造成损害的操作。常见的触发因素包括：

• 设计不佳的无害提示词导致的幻觉／编造，或者仅仅是模型性能不佳或未正确对齐所导致的幻觉／编造；
• 来自恶意用户、先前调用的恶意或已被攻陷工具，或（在多智能体／协作系统中）恶意或已被攻陷的协作智能体的直接／间接提示词注入。

过度代理权的根本原因通常包括以下一项或多项：

• 功能过多；
• 权限过大；
• 自主性过高。

过度代理权可能对机密性、完整性和可用性造成广泛影响，具体取决于基于 LLM 的应用能够与哪些系统交互。在智能体系统中，过度代理权可能表现为 ASI02：工具滥用与利用、ASI03：身份与权限滥用，以及 ASI08：级联失效。

注：过度代理权不同于输出处理不当，后者关注的是对 LLM 输出审查不足的问题。对模型输入和输出进行清理，并不是治理过度代理权的根本控制措施；输入清理由 LLM01:2026 提示词注入涵盖，输出清理由 LLM10:2026 输出处理不当涵盖。

常见风险示例

1. 功能过多

LLM 智能体可以访问的工具中，包含系统预期运行所不需要的功能。例如，开发者需要赋予 LLM 智能体从存储库读取文档的能力，但所选用的第三方工具同时还具备修改和删除文档的能力。

2. 功能过多

某个工具可能在开发阶段被试用，随后因有更好的替代方案而被弃用，但原工具仍然可供 LLM 智能体调用。

3. 功能过多

具有开放式功能的 LLM 工具，未能妥善过滤输入指令中超出应用预期运行所需范围的命令。例如，一个用于运行特定 Shell 命令的工具，未能有效阻止其他 Shell 命令的执行。

4. 权限过大

LLM 工具在下游系统中拥有应用预期运行所不需要的权限。例如，一个本用于读取数据的工具，使用某个身份连接数据库服务器，而该身份不仅拥有 SELECT 权限，还拥有 UPDATE、INSERT 和 DELETE 权限。

5. 权限过大

一个设计上应在单个用户上下文中执行操作的 LLM 工具，却使用通用的高权限身份访问下游系统。例如，一个用于读取当前用户文档存储的工具，使用能够访问所有用户文件的特权账户连接文档存储库。

6. 自主性过高

基于 LLM 的应用或工具未能对高影响操作进行独立验证和审批。例如，一个能够删除用户文档的工具，在未获得用户任何确认的情况下就执行删除操作。

预防与缓解策略

以下措施可以防止过度代理权：

1. 最小化工具数量

将 LLM 智能体获准调用的工具限制在最低必要范围内。例如，如果基于 LLM 的系统不需要获取 URL 内容的能力，就不应向 LLM 智能体提供此类工具。

2. 最小化工具功能

将 LLM 工具实现的功能限制在最低必要范围内。例如，一个访问用户邮箱以总结邮件的工具，可能只需要读取邮件的能力，因此不应包含删除或发送邮件等其他功能。

3. 避免开放式工具

尽可能避免使用开放式工具（例如运行 Shell 命令、获取 URL 内容等），改用功能粒度更细的工具。例如，基于 LLM 的应用可能需要将某些输出写入文件。如果使用能够运行 Shell 函数的工具来实现这一功能，非预期操作的可能范围就会非常大（任何其他 Shell 命令都可能被执行）。更安全的替代方案是构建一个专用的文件写入工具，仅实现这一特定功能。工具应为所有输入参数定义严格的模式，并在使用前验证其内容。

4. 最小化工具权限

将 LLM 工具在其他系统中获得的权限限制在最低必要范围内，以限制非预期操作的影响范围。例如，一个使用产品数据库为客户提供购买建议的 LLM 智能体，可能只需要对“products”表的读取权限。它不应能够访问其他表，也不应能够插入、更新或删除记录。应通过为 LLM 工具连接数据库时使用的身份设置适当的数据库权限，来强制落实这些限制。

5. 在用户上下文中执行工具

跟踪用户的授权和安全范围，确保代表用户执行的操作，在下游系统中以该特定用户的上下文执行，并且仅使用最低必要权限。例如，一个读取用户代码仓库的 LLM 工具，应要求用户通过 OAuth 进行身份验证，并仅授予最低必要的权限范围。在委托或多智能体工作流中，应在链式工具调用或智能体调用之间保留原始用户上下文和授权范围，而非仅依赖发起调用的智能体或服务身份所拥有的权限。

6. 要求用户批准

采用人在回路中的控制机制，要求在执行高影响操作之前获得人工批准。这可以在下游系统中实现（位于 LLM 应用范围之外），也可以在 LLM 工具本身内部实现。例如，一个代表用户创建并发布社交媒体内容的 LLM 应用，应在实现“发布”操作的工具中加入用户审批流程。

7. 完全中介

在程序逻辑中实现授权，而不是依赖 LLM 判断某项操作是否被允许。落实完全中介原则，确保向下游系统发出的所有请求，都由工具、位于工具与下游系统之间的独立执行前策略决策点，或下游系统本身，依据安全策略进行验证。这类策略有助于处理智能体的某项操作虽然名义上被允许，但在具体上下文中并不安全的情况。分级执行策略（审计、警告、阻止、升级处理）允许后果较轻或容易撤销的操作自动获批，同时将后果严重或不可逆的操作转交人工审核。例如，客服聊天机器人可以自动将退款处理为店铺余额（可以收回），而向外部付款之类的不可逆操作则转交人工批准。

以下措施无法防止过度代理权，但可以限制所造成的损害程度：

8. 监控工具使用

记录并监控 LLM 工具和下游系统的活动，以识别何处正在发生非预期操作，并作出相应响应。

9. 速率限制

围绕工具调用设置阈值，并实施熔断机制：当超过阈值时，停止调用、限制速率，或升级至人工审核。简单的阈值可以基于调用次数，而感知上下文的阈值则可以基于工具某个输入参数的累计值。

攻击场景示例

场景 #1：遭劫持的邮件助手

一个基于 LLM 的个人助手应用通过工具获得了访问个人邮箱的权限，以总结收到的邮件内容。要实现这一功能，工具需要具备读取邮件的能力，但系统开发者所选择的工具同时也包含发送邮件的功能。该应用还存在间接提示词注入漏洞：一封恶意构造的来信诱使 LLM 指示智能体扫描用户收件箱中的敏感信息，并将其转发至攻击者的邮箱地址。可以通过以下方式避免这种情况：

• 使用仅实现邮件读取能力的工具，消除过多的功能；
• 通过仅具有只读权限范围的 OAuth 会话向用户的邮件服务进行身份验证，消除过大的权限；以及／或者
• 要求用户对 LLM 工具起草的每一封邮件进行人工审核，并亲自点击“发送”，消除过高的自主性。

或者，也可以在邮件发送接口上实施速率限制，以减轻所造成的损害。

LLM04:2026 供应链(Suplly Chain)

描述

LLM 供应链容易受到漏洞影响，这些漏洞会破坏训练数据、模型、适配器、转换流水线和部署平台的完整性，导致输出偏差、安全事件或系统故障。传统软件漏洞主要涉及代码缺陷和依赖项，而在机器学习中，风险还延伸到第三方预训练模型、数据集和模型制品；这些对象可能通过篡改、投毒或恶意制品替换受到操纵。

创建 LLM 是一项专业工作，依赖第三方模型、数据集，以及使用 LoRA（低秩适配）等参数高效微调（PEFT）技术构建、并在 Hugging Face 等平台上共享的可复用适配器。如今，模型制品、来源证明，以及转换／合并工作流都已成为供应链中的主要攻击面，而端侧 LLM 又进一步扩大了这一范围。

本条目涵盖的部分风险也在 LLM05:2026 数据与模型投毒中进行了讨论。本条目重点关注这些风险的供应链层面。智能体应用特有的供应链风险，包括 MCP 服务器和工具注册表，由《OWASP 智能体应用十大风险》中的 ASI04 智能体供应链漏洞涵盖（OWASP GenAI Security Project, 2026）；MITRE ATLAS 则将相应的对手技术归入 AML.T0010 AI 供应链入侵（MITRE, n.d.）。

常见风险示例

1. 存在漏洞或已过时的第三方组件与模型

攻击者可以利用过时或已弃用的组件，包括软件包、模型服务框架和模型本身，攻陷 LLM 应用。这与 A06:2021 易受攻击和过时的组件类似，但当组件用于模型开发、微调或推理时，风险会进一步增加。LLM 编程助手还带来了一种新的变体：它们会大规模幻觉出看似合理却并不存在的软件包名称（Spracklen et al., 2025），攻击者则提前注册这些名称（称为“slopsquatting”，即利用 AI 幻觉包名进行抢注），使未经核验的 AI 推荐依赖项最终指向恶意代码。

2. 许可证风险

AI 开发涉及多种软件和数据集许可证，它们对使用、分发和商业化提出不同要求。如果管理不当，就会带来法律与合规风险。

3. 存在漏洞或遭到篡改的预训练模型

模型制品难以被全面检查，仅靠静态分析无法确认其行为安全性。预训练模型可能包含通过投毒数据集或直接篡改引入的隐藏偏差或后门。弃用 Python pickle 等不安全的序列化格式，可以降低但不能消除这种风险；这类格式在加载时可能执行任意代码。后门可以直接嵌入模型的计算图中，并在 ONNX 等被广泛认为安全的格式中持续存在；此外，精心构造的模型文件还可以利用该格式原生解析器中的内存损坏缺陷，llama.cpp 的 GGUF 解析过程中的堆溢出漏洞（CVE-2024-23496）就展示了这一点（Cisco Talos, 2024）。

4. 薄弱的来源证明与未签名的模型制品

已发布的模型缺乏有力的来源保证：模型卡记录了模型信息，却不能证明其来源；而已被攻陷的供应商账户或仿冒账户，可以借受信任的名称发布恶意模型。如果模型、适配器、数据集、微调检查点和转换输出未经过签名，也未固定哈希值，攻击者就可以在传输、存储，或自动化流水线将制品接纳到可信环境的晋级边界处，替换或悄然修改这些制品。当流水线通过可变引用（例如 latest 标签）而非不可变摘要来解析制品时，风险尤其突出。

5. 存在漏洞的适配器，以及遭到入侵的转换、合并和量化工作流

LoRA 适配器使微调变得模块化且高效，但恶意适配器可能破坏预训练基础模型的完整性；无论是在协作式模型合并环境中，还是在将适配器下载并应用于已部署模型的推理平台上，都存在这一风险。模型转换和合并服务可以在格式转换过程中引入恶意改动，从而绕过审查控制。量化也是一种相关的转换风险：攻击者可以精心构造模型权重，使全精度模型在评估时表现正常，而量化后的制品却展现出攻击者指定的行为（Egashira et al., 2025）。因此，对全精度模型的安全保证不能直接延伸到实际部署的量化制品。

6. 端侧 LLM 供应链漏洞

随设备交付的 LLM 将遭到入侵的制造流程、设备操作系统或固件漏洞的利用，以及包含篡改模型的重新打包应用纳入攻击面，使设备完整性和固件信任成为 LLM 供应链的一部分。

7. 不明确的条款与条件及数据隐私政策

模型运营方不明确的条款与条件（T&Cs）和数据隐私政策，可能导致敏感应用数据被用于模型训练，并在之后泄露；模型供应商提供的材料也可能带来版权风险。

预防与缓解策略

1. 仔细审查数据来源和供应商，包括其条款与条件及隐私政策，并且仅使用可信供应商。定期审查和审计供应商的安全状况与访问权限；当其安全态势或条款与条件发生变化时，重新进行评估。
2. 采用 OWASP 十大风险中 A06:2021 易受攻击和过时的组件所列的缓解措施：漏洞扫描、漏洞管理，以及确保应用使用仍在维护的组件、API 和底层模型版本的补丁策略。对能够访问敏感数据的开发环境实施相同控制；在采用 AI 推荐的依赖项之前，核验它们确实存在，且正是所需的软件包。
3. 在选择第三方模型时开展 AI 红队测试和评估，重点围绕范围内的使用场景；并在生产环境中持续开展相关工作，在 MLOps 和 LLM 流水线中进行异常检测与对抗鲁棒性测试，以发现篡改和投毒。
4. 使用软件物料清单（SBOM）维护一份保持最新且经过签名的组件清单，并通过 AI 物料清单（AIBOM）和机器学习软件物料清单（ML SBOM），将其扩展到模型、适配器和数据集；评估 OWASP CycloneDX ML-BOM（OWASP CycloneDX, n.d.）和 OWASP AIBOM 项目（OWASP GenAI Security Project, 2025）等方案。在同一份清单中跟踪许可证，并定期审计，以确保合规性和透明度。
5. 仅使用来自可验证来源的模型，并通过第三方完整性检查、签名和文件哈希，弥补来源证明薄弱的问题。由透明度日志支持的加密模型签名（例如 OpenSSF Model Signing 项目和 Sigstore）可将模型制品与签名者身份绑定（Open Source Security Foundation, 2025）。模型训练无法保证实现可复现构建；安全 AI 联盟（CoSAI）提供了机器学习制品签名的成熟度模型（OASIS Open, 2025）。签名证明的是完整性和来源，而非安全性（来自已被攻陷的供应商，或受信任但实际具有恶意的供应商的模型，即使签名有效，也仍可能包含后门）。因此，应将签名与不可变制品引用、来源策略、基于策略的发布门禁（例如 SLSA）（Open Source Security Foundation, n.d.）、行为评估，以及对上游模型完整性的持续验证结合使用。同样，对外部提供的代码也应使用代码签名。
6. 严格监控和审计协作式模型开发环境，并将模型转换与合并服务视为高风险的制品晋级节点。
7. 对部署在边缘设备上的模型进行加密并实施完整性检查，使用供应商的证明 API 防范遭到篡改的应用和模型，并拒绝无法识别的固件和不可信的设备状态。

攻击场景示例

场景 #1：遭到入侵的软件包与模型服务框架

一个遭到入侵的依赖项进入模型开发或推理环境。2022 年 12 月的 PyTorch 供应链攻击就是一例：PyPI 注册表中的恶意 torchtriton 包遮蔽了合法的 PyTorch-nightly 依赖项，并外传数据（PyTorch Foundation, 2022）。模型服务栈也属于同一攻击面：ShadowRay 攻击在真实环境中利用了存在争议的 CVE-2023-48022（生产环境 Ray 服务器上无需身份验证即可访问的仪表板），后来进一步升级为跨暴露集群自我传播的僵尸网络（Lumelsky & Elbaz, 2025）；而在 Ollama 中，CVE-2024-37032 允许攻击者通过从注册表拉取的恶意模型清单实现远程代码执行（Wiz, 2024）。

场景 #2：将篡改后的模型发布到模型中心

攻击者使用看似可信的名称发布遭到篡改的模型。PoisonGPT 概念验证展示了这种情况：一个参数经过精准修改的模型能够传播虚假信息，同时逃过标准基准评估的检测（Huynh & Hardouin, 2023）。同样的信任缺口还涉及：攻击者通过微调移除热门模型的安全功能，同时保留其在无害任务上的性能（Zhan et al., 2023）；任何未经验证就部署的预训练模型；以及共享的 AI 即服务平台——研究人员曾通过恶意模型逃逸推理容器，进而访问其他客户的模型和数据（Tamari & Tzadik, 2024）。

场景 #3：供应商的 LoRA 适配器遭到篡改

攻击者渗透一家第三方供应商，并悄悄修改某个 LoRA 适配器；随后，该适配器通过模型合并工作流被合并到已部署的 LLM 中。一旦完成合并，该适配器就会成为进入系统的隐蔽入口。

场景 #4：遭劫持的模型转换或合并服务

攻击者通过模型合并或格式转换服务发动攻击，篡改公开可用的模型并注入恶意行为。HiddenLayer 关于劫持 Hugging Face 上 Safetensors 转换机器人的研究展示了这一点（HiddenLayer, 2024）。

场景 #5：模型命名空间复用

某个组织从公共模型中心部署模型时，仅通过 Author/ModelName 标识符引用该模型。原作者删除或转移账户，使该命名空间被释放；攻击者随后重新注册相同名称，并在原路径下发布恶意模型。仅按名称解析模型的流水线和托管模型目录随后就会拉取攻击者的模型，导致远程代码执行（Saraf & Balassiano, 2025）。

场景 #6：绕过扫描器、安全加载器和安全格式

某个组织通过恶意软件扫描器和一个文档声称能够防止代码执行的加载器选项，对第三方模型进行准入检查。攻击者绕过了这两道防线。损坏的或经压缩封装的 pickle 数据流，会在扫描器到达损坏字节之前执行其载荷；在 Hugging Face 上发现的 nullifAI 模型就是如此（Zanki, 2025）。模型扫描器和安全加载器标志都曾出现获得 CVE 编号的绕过漏洞，例如 PickleScan 零日漏洞（Cohen, 2025），以及启用 weights_only 的 torch.load 中的漏洞（CVE-2025-32434）（GitHub Security Advisories, 2025）。ONNX 等“安全”格式的计算图中，类似 ShadowLogic 的后门（Wickens et al., 2024）不会附带可供序列化扫描器标记的可执行代码。应将扫描器和安全加载器标志视为纵深防御的一层，而非安全保证，并结合来源验证，以及已修补的加载器和解析器共同使用。

场景 #7：模型制品构建流水线遭到入侵

攻击者通过恶意构建工作流依赖项、被盗的制品注册表凭证或缓存投毒，攻陷某个组织用于微调和发布模型的 CI/CD 流水线。Ultralytics 攻击就是一例：攻击者通过 GitHub Actions 缓存注入，将一个旗舰 AI 库植入木马的版本发布到 PyPI（Python Package Index, 2024），其中甚至包括一个同样遭到篡改的“修复”版本。这与 xz-utils 后门和 Codecov 入侵等经典事件中的构建时替换属于同类问题。由于植入后门的制品由组织自身的发布基础设施构建并签名，因此它可以通过下游来源检查、内部证明，以及仅标记外部来源组件的供应链扫描器。

场景 #8：遭逆向工程的移动应用

攻击者对移动应用进行逆向工程，将端侧模型替换为一个会把用户引向诈骗网站的篡改版本，并通过社会工程手段分发重新打包后的应用。

LLM05:2026 数据与模型投毒(Data and Model Poisoning)

描述

数据与模型投毒描述了一类攻击和失效：对手（或不安全的处理流程）操纵数据或模型制品，将有害行为、偏差或可被利用的弱点植入 AI 系统。在现代生成式 AI 环境中，投毒并不限于传统意义上的“训练数据”。它可能发生在数据被摄入、转换、检索或复用的任何环节，包括预训练、微调、嵌入向量创建、检索增强（RAG）和模型分发。最终得到的 AI 系统可能表面上仍能正常运行，但其行为会损害信任、安全性与信息安全。

当预训练、微调或嵌入数据遭到篡改，以引入漏洞、后门或偏差时，就会发生数据投毒。这可能是有意为之（恶意投毒），也可能是无意造成的（数据管理不当、来源受到污染）。这种操纵会破坏模型完整性。模型会学到错误的模式、内化恶意关联，或被训练成表现出错误行为。其后果包括有害输出、能力受损和可靠性下降。

核心思想是：投毒针对的是模型的“学习过程”，而非某个单独的运行时缺陷。典型的软件漏洞可以通过修复代码来打补丁，而应对投毒可能需要重新验证数据、重新训练、更换模型或重新设计流水线；这些措施成本高昂，也会对实际运行造成干扰。

投毒可能发生在 LLM 生命周期的多个阶段：

• 预训练： 恶意构造或受到污染的语料库，使模型吸收有害模式、不安全指令或有偏差的表征。
• 微调： 受到操纵的数据集引入特定领域的失效模式或隐藏触发器。
• 嵌入与向量化： 投毒针对存储的向量，影响检索到的内容，导致回答被定向引导，或产生隐蔽的错误信息。
• 迁移学习／模型复用： 遭到入侵的源模型将其受损状态传递给下游系统。
• 持续学习流水线： 缺乏充分验证的自动化摄入，使攻击者能够逐步塑造模型行为。

随着组织越来越依赖外部数据集、RAG 流水线、共享模型仓库和智能体工作流，数据投毒攻击面也随之扩大。通过共享仓库分发的模型，可能因捆绑的非权重制品而携带风险，包括恶意反序列化（例如 pickle 文件），以及聊天模板、分词器配置、LoRA/PEFT 适配器和量化制品遭到篡改；上述任何一种都可能在加载时执行有害代码或改变模型行为。这类后门可能在平时完全不影响模型行为，直到某个触发器使其发生变化，从而让模型有机会成为潜伏智能体。

在智能体部署中，投毒风险还延伸到工具集成、持久化记忆存储，以及基于人类反馈的强化学习（RLHF）反馈循环。《OWASP 智能体应用十大风险》对这些攻击面进行了深入讨论。

本条目涵盖持久化数据或模型行为受到的持久性破坏。推理时通过检索内容传入的提示词指令，由 LLM01:2026 提示词注入涵盖；利用嵌入空间几何特性的攻击，则由 LLM09:2026 向量与嵌入弱点涵盖。

常见风险示例

1. 训练与微调数据投毒： 攻击者向数据集中注入带有偏见或恶意的内容。一种定向变体会刻意削弱模型的拒绝行为，同时保持其总体准确率，使标准评估无法发现这种退化。
2. 金融模型数据投毒： 攻击者向欺诈检测模型注入错误标注的交易数据，将欺诈交易标记为合法交易。模型因此学会忽略真实威胁，使欺诈行为能够绕过检测，并破坏人们对 AI 驱动的金融系统的信任。
3. 开源数据集供应链投毒： 攻击者向广泛使用的数据集贡献恶意数据。插入共享数据集的触发短语，可能传播到大量基于该数据集进行微调的下游模型中，一旦后门被发现，就会迫使相关方进行成本高昂的重新训练。
4. 少量、高影响的后门投毒： 无论数据集规模如何，仅 250 篇投毒文档就能破坏参数规模从 6 亿到 130 亿的模型（Souly et al., 2025）。经过策略性设计的少量操纵，已足以造成显著影响。
5. AI 推荐／记忆投毒： 攻击者在网页内容中嵌入隐藏指令，在不被发现的情况下操纵 AI 的记忆或推荐结果，展示了基于智能体的系统和持久化记忆中的风险。
6. RAG 知识库投毒： 对每个目标查询，仅注入一段经过优化的投毒文本，就能压过检索语料库中的准确内容；而且，在面对改写、基于指令的预防措施和基于检测的防御时，该攻击仍保持较高的成功率（Zhang et al., 2025）。
7. 智能体／多系统投毒： 多智能体工作流中的投毒输入，会影响整个 AI 驱动生态系统中的行为和数据访问，而不仅仅影响单个模型。
8. 医疗模型投毒： 对医疗训练数据进行极少量投毒，就能在通过标准评估的同时显著改变模型输出，在安全关键领域产生不安全的建议。
9. 供应链中的恶意 AI 模型： 攻击者通过公共仓库分发嵌有后门的受损模型。下载这些模型的组织会在不知情的情况下引入隐藏触发器，或遭遇系统入侵。

预防与缓解策略

1. 使用 SBOM/ML-BOM（例如 CycloneDX）跟踪数据集和模型的来源及演变关系，强制实施签名和验证，并在整个生命周期的各个阶段持续验证数据完整性。
2. 对所有传入数据建立严格的验证机制，审查第三方供应商，并将输出与可信来源进行比较，以尽早发现偏差或对抗性操纵。
3. 通过强制落实信任边界、过滤检索内容、对来源进行评分，以及将系统指令与外部数据隔离，保护 RAG 系统。
4. 使用沙箱和严格的隔离控制，限制模型与未经验证的数据、工具或外部系统交互。
5. 在训练、嵌入和推理流水线中应用基于统计和 AI 的异常检测，并依据已定义的阈值，监测训练损失、输出和行为中的漂移或异常，以发现随时间显现的细微投毒影响。
6. 使用经过精心筛选的领域专用数据集进行微调，以减少接触不可信数据的机会，并降低跨领域污染风险。
7. 落实最小权限访问、网络分段和严格的数据访问控制，防止未经授权的数据注入。
8. 使用数据版本控制工具（例如 DVC）跟踪数据集变更、维护版本历史，并在发现投毒时支持回滚和取证分析。
9. 通过验证传入数据、要求人工监督，以及实施速率限制，管控自动化重新训练和反馈循环，防范利用被操纵的偏好信号逐步实施投毒。
10. 持续使用对抗性输入和基于触发器的提示词，对模型开展红队测试，以发现隐藏后门。不要假定安全对齐能够清除后门。每轮对齐完成后，都必须开展专门的触发器探测（Hubinger et al., 2024）。
11. 实施结合验证层的依据锚定技术，确保检索到的内容在影响输出之前已经过验证。
12. 将推理制品，包括聊天模板、分词器配置、LoRA/PEFT 适配器和量化制品，视为与安全相关的代码。在部署前强制实施签名、哈希验证、差异检查和静态分析。

攻击场景示例

场景 #1

攻击者向内部知识库插入经过操纵的文档。投毒文档的内容出现在回答中，导致错误建议、业务决策受到操纵，或声誉受损。

场景 #2

攻击者在 AI 工具会进行摘要处理的网页中嵌入隐藏指令。当这些指令被摄入 RAG 或记忆系统时，它们会使模型偏向推荐特定产品，从而实现经济利益操纵，并使人们失去对 AI 输出的信任。

场景 #3

攻击者向自动化重新训练的反馈循环提交精心构造的输入。这不需要访问基础设施，只需具备普通用户界面的访问权限。结果是模型缓慢漂移，逐渐出现准确率下降、带有偏见的输出或不安全的建议。

场景 #4

恶意内部人员向训练数据集注入错误标注的交易数据。模型无法检测到欺诈，导致财务损失、合规违规，以及违反监管要求。

场景 #5

攻击者将投毒后的预训练权重上传到公共仓库。标准安全训练无法清除嵌入的后门（Hubinger et al., 2024）。组织因此面临大规模系统入侵、数据泄露或定向操纵。

场景 #6

攻击者修改模型的聊天模板（例如 GGUF 包或分词器配置中的聊天模板），加入由触发器激活的条件指令。模型通过公共模型中心重新分发，在无害输入下表现正常。在 18 个模型和 4 种推理运行时上进行的验证显示：在触发条件下，事实准确率从 90% 降至 15%，URL 输出的成功率超过 80%（Fogel et al., 2026）。

场景 #7

开发者使用不安全的序列化方式（例如 pickle）加载第三方模型。嵌入的恶意代码在加载过程中执行，使攻击者能够攻陷宿主、进行横向移动，并入侵基础设施。

场景 #8

在共享 AI 环境中，一个租户向共享嵌入或记忆层注入对抗性数据，影响其他租户的回答，造成跨租户污染和隐私风险。

场景 #9

攻击者跨多个会话，向 AI 智能体的持久化记忆注入恶意指令。智能体开始优先采用攻击者控制的逻辑，导致工作流受到长期操纵，并使攻击效果隐蔽地持续存在。

LLM06:2026 无界消耗(Unbounded Consumption)

描述

当 LLM 应用允许过量且不受控制的推理活动时，就会出现无界消耗。攻击者可以借此破坏服务可用性、造成难以承受的财务成本，或通过克隆模型窃取知识产权。这些行为都利用了同一类漏洞：缺乏对资源消耗方式的充分控制。

LLM 对计算资源的高需求，尤其是在云环境和按词元付费的环境中，使其天然容易受到资源滥用和未经授权使用的影响。这种威胁的一个显著特征是成本不对称。无论是通过精心构造的提示词、窃取的凭证，还是受到操纵的工作流，攻击者都能以几乎可以忽略不计的自身成本，触发成本高得不成比例的计算。

以下趋势进一步加剧了这一风险：扩展思考和推理模型日益普及，其输出预算较大或约束不足；多模态模型显著增加单次请求的计算成本；智能体架构和工具使用协议（例如 MCP）将单个请求放大为级联的下游操作；共享推理基础设施则引入了新的供应链攻击面。仅靠传统的请求速率限制已不足以应对。有效防御需要感知词元用量的成本控制、硬性支出上限、智能体级熔断机制，以及持续的成本归因监控。

常见风险示例

1. 变长输入洪泛与输出激增

攻击者可以利用处理效率上的弱点，向 LLM 提交大量长度各异的输入，使其过载。这可能耗尽资源，并使系统失去响应，从而严重影响服务可用性。这也包括通过微调投毒引发的输出激增：仅一个恶意训练样本，就能破坏模型的序列结束行为，使每次请求的输出都达到最大长度（Gao et al., 2024）。

2. 钱包拒绝服务（DoW）

攻击者通过发起大量操作，利用云端 AI 服务按使用量收费的模式，给服务提供方造成难以承受的财务负担，甚至使其面临破产风险。

3. 大上下文滥用

反复发送接近上限的请求、不断累积上下文，以及应用侧重新分块，会消耗不成比例的计算和内存资源。许多 API 会直接拒绝超出上下文窗口的输入，因此，持续存在的风险来自那些刚好保持在限制以内、却不断抬高单次请求成本的请求。

4. 推理循环与思考词元耗尽

攻击者构造简短、看似无害的提示词，迫使扩展思考模型陷入长时间运行或无法终止的推理循环，在绕过输入大小过滤器的同时，消耗巨量的思考词元预算，最终导致资源耗尽（Li et al., 2025）。由于这些提示词体量很小且看起来合法，标准输入验证无法提供保护。

5. 针对资源过度消耗进行优化的对抗性输入

攻击者使用优化技术构造输入，使计算成本最大化。这不同于简单要求模型执行资源密集型任务，其中包括海绵样本（Shumailov et al., 2020）和对抗性视觉扰动。它涵盖使用基于梯度和无梯度的技术，对对抗性输入进行优化。与推理循环攻击不同，这类攻击需要在输入空间中进行显式优化，而不只是设计提示词。

6. 多模态输入与输出

多模态模型会将图像、音频和视频转换为大量词元，因此，单个请求的成本可能显著高于可比的纯文本请求。具体的额外开销会随模型、提供商、分辨率、媒体时长和预处理流水线而变化。

7. 模型提取与蒸馏窃取

攻击者使用精心构造的输入查询模型 API，收集足够多的输出，以复制模型的部分能力，或微调出一个功能等效的模型。暴露 logits 和对数概率会显著加快提取过程（Carlini et al., 2024）。通过时序信息或对共享基础设施的观测，以侧信道方式提取模型权重或架构的风险，由 LLM02:2026 敏感信息泄露涵盖。

8. 智能体与工具交互导致模型资源泛滥消耗

攻击者可以发布工具，迫使基于 LLM 的应用陷入递归或无限的工具调用循环，从而过度消耗 LLM 资源。这可能使看似合法的工具操作造成财务负担，或损害服务质量。当一次工具调用扩展为数量庞大的后续操作时，LLM 可能需要管理由单个任务衍生出的数百次调用，导致词元过度消耗。

9. 推理基础设施漏洞利用

攻击者针对 LLM 服务框架（vLLM、TensorRT-LLM、SGLang、Triton、Ollama）中的漏洞，通过不安全的反序列化缺陷、特殊词元注入，以及注入的聊天模板，使服务崩溃或耗尽模型资源。

预防与缓解策略

1. 速率限制与输入大小验证

实施速率限制和用户配额，限制单一来源实体在给定时间内能够发出的请求数量。不要仅以每秒请求数为限，还应对每分钟词元数、每日词元数和单次请求的估算成本设置限制。使用请求执行前的词元估算，在推理开始之前拒绝不符合要求的请求。这也包括验证输入，确保其不超过合理的大小限制。

2. 硬性支出上限

按 API 密钥、用户、团队和云账户，设置不可覆盖的预算上限。这些上限必须是超过后即停止推理的强制执行机制，而不是可能被快速累积的工作负载甩在后面的告警阈值。支出上限还应考虑不同模态和工具协议之间的成本差异。

3. 资源分配管理

动态监控和管理资源分配，防止任何单个用户或请求消耗过多资源。

4. 沙箱技术

限制 LLM 对网络资源、内部服务和 API 的访问。约束应用能够访问的范围，可以限制攻击者将提取出的模型信息或数据外传至外部目的地的能力。

5. 平稳降级

将系统设计为能够在高负载下平稳降级，保留部分功能，而非完全失效。

6. 限制排队操作并实现稳健扩缩容

限制排队操作数量和操作总数，同时结合动态扩缩容与负载均衡，应对不断变化的需求，并确保系统性能保持稳定。

7. 扫描对抗性扰动

扫描模型输入，尤其是大型视觉语言模型（LVLM）的视觉输入，查找可能导致模型资源过度消耗的对抗性扰动迹象。

8. 检测资源密集型工具交互

监控智能体与工具之间的交互，识别特定会话是否似乎正在引发没有明确终止状态的递归操作或资源密集型操作。建立正常工具行为的基线，以检测特定工具是否偏离标准的词元消耗模式。

9. 智能体熔断机制

对所有智能体执行过程强制设置步骤数限制、递归深度限制、时间限制和单次运行成本上限。使用状态哈希检测递归循环。

10. 推理基础设施加固

保持模型服务框架为最新版本。禁用不安全的反序列化，限制特殊词元透传，并在所有推理端点上强制实施身份验证。

攻击场景示例

场景 #1：不受控制的输入大小

攻击者向处理文本数据的 LLM 应用提交异常庞大的输入，导致过高的内存使用量和 CPU 负载，可能使系统崩溃，或显著拖慢服务。

场景 #2：重复请求

攻击者向 LLM API 发送大量请求，造成计算资源过度消耗，使合法用户无法使用服务。

场景 #3：资源密集型查询

攻击者构造特定输入，旨在触发 LLM 中计算成本最高的处理过程，导致 GPU 被长时间占用，并可能使系统失效。

场景 #4：钱包拒绝服务（DoW）

攻击者制造过量操作，利用云端 AI 服务按使用量付费的模式，使服务提供方承担难以承受的成本。

场景 #5：功能性模型复制

攻击者使用 LLM 的 API 生成合成训练数据，并微调另一个模型，构建出功能等效的模型，从而绕过传统模型提取方法的局限。

场景 #6：LVLM 图像输入中的扰动

攻击者构造对抗性图像输入，其中包含经过优化的扰动，使 LVLM 在输出时过度消耗词元（Gao et al., 2025）。

场景 #7：多轮工具调用循环与工具调用扇出

攻击者可以发布恶意工具（例如通过开源仓库中的 Claude Skill），指示智能体执行递归循环任务，或需要大量工具调用的任务。开发者将该工具集成到智能体中后，就可能引发过量词元消耗和服务不稳定。

场景 #8：智能体会话中不断增长的 LLM 上下文

攻击者或无恶意的用户保持一个智能体会话持续开启，逐步注入内容，使每次推理都重新处理全部累积上下文。随着上下文增长，单轮成本从第一轮约 0.001 美元，上升到第 100 轮约 0.50 美元。由于每个请求单独来看都在预算以内，因此没有任何单个请求触发速率限制，但大量并发或长期存续会话的累计成本却可达到数百美元。

LLM07:2026 错误信息(Misinformation)

描述

当 LLM 或基于 LLM 的应用生成不正确、不完整、缺乏依据或具有误导性的信息，而这些信息看起来足够可信，能够影响人的决策、自动化工作流或智能体行动时，就会出现错误信息问题。核心风险在于：错误的输出被信任，并被据此采取行动。

在现代系统中，模型输出会驱动工具调用、生成代码、推断系统状态、授权操作，并协调多个智能体。这使错误信息成为一种系统级失效，可能导致财务损失、安全事件、人身安全风险或运行中断。

在智能体系统中，错误信息通常表现为不正确的状态、推理或证据；这些内容被下游组件使用，直接导致非预期操作。

错误信息可能源于幻觉、不完整或过时的上下文、薄弱的事实依据、含糊的提示词、带有偏差或受到破坏的数据、具有误导性的摘要，或未经验证的工具输出。攻击者也可以蓄意诱发错误信息。如果根本原因是提示词注入、投毒或供应链入侵，应分别参考相应的风险条目。不安全生成代码的执行和处理，由 LLM10:2026 输出处理不当涵盖；将模型幻觉出的软件包名称注册为供应链攻击途径，则由 LLM04:2026 供应链涵盖。本条目关注由此产生的失效模式：错误的表述驱动了有害决策或操作。

过度依赖仍然是一个关键因素。人和系统经常将流畅、自信或结构清晰的输出视为权威。在智能体架构中，这种过度依赖往往已经嵌入系统设计之中。

常见风险示例

1. 缺乏依据或错误的决策支持：不正确或缺乏依据的信息影响商业、法律、医疗、财务或运营决策。
2. 工作流中的错误状态推断：LLM 推断某个条件已经满足，而实际上并未满足，从而触发非预期操作。
3. 错误或虚构的代码与依赖项：模型给出错误的代码建议，或引用并不存在的、由模型幻觉产生的软件包（Spracklen et al., 2025）。
4. 误导性摘要与关键遗漏：摘要遗漏关键约束、例外情况、时间戳或风险。
5. 对抗性诱发的错误信息：攻击者构造输入，导致模型作出错误断言或遗漏关键事实。
6. 跨智能体的错误信息传播：错误输出在多个智能体和工作流之间传播。
7. 伪造或错误归属的证据：虚构或受到操纵的内容被呈现为权威证据。

预防与缓解策略

1. 行动前为断言提供依据：要求输出以权威且最新的来源为依据。
2. 实施“断言—核验—行动”模式：将生成与执行分离，并在行动前验证断言。
3. 验证工具调用：执行前检查参数、授权、前置条件和当前状态。
4. 使用验证信号，而非仅依赖置信度：纳入事实依据检查和一致性检查。
5. 对高影响操作强制实施运行时验证：引入审批工作流和系统检查。
6. 检测并防止遗漏导致的失效：要求使用包含必填字段的结构化输出。
7. 限制影响范围：实施最小权限、沙箱和速率限制。
8. 监控并测试错误信息问题：记录断言、证据和结果，并测试对抗性场景。
9. 校准人和系统的信任：区分已验证的事实与假设。
10. 对抗性评估与持续测试：定期使用误导性场景测试工作流。

攻击场景示例

场景 #1：推荐幻觉产生的依赖项

编程助手推荐一个看似合理却并不存在的软件包，而攻击者已提前注册了这一幻觉包名，因此，信任该建议的开发者会安装攻击者控制的代码（Spracklen et al., 2025）。

场景 #2：智能体作出错误的政策判断

客服智能体误读政策，批准了一笔违反条款的退款，造成财务损失。

场景 #3：安全关键摘要中的遗漏

一份临床摘要遗漏了某种药物的禁忌证，而临床医生依据这一不完整的建议采取了行动。

场景 #4：对抗性诱发的错误推理

攻击者在支持论坛中植入错误的修复步骤，故障排查智能体检索到这些步骤后，将其作为可信建议转述。

场景 #5：错误告警触发自动响应

安全智能体将正常流量误判为入侵，并自动封锁一个生产网络网段，导致服务中断。

场景 #6：跨智能体信任失效

检索智能体将一名客户报告为已通过身份验证，但实际上该客户并未通过验证；下游支付智能体信任这一状态，并发放资金。

场景 #7：虚构任务完成状态

智能体报告每夜数据库备份已完成，但备份实际上从未运行；由于不存在备份，之后的恢复操作失败。

LLM08:2026 隐藏上下文暴露(Hidden Context Exposure)

描述

隐藏上下文暴露是指，未经授权地提取、推断或重建放置在模型上下文中、隐藏且不面向用户的系统指令或运行上下文。当这些隐藏上下文包含或揭示秘密、策略逻辑、工具、信任边界、工作流判定条件、专有行为，或其他能够实质性增强攻击者能力的敏感实现细节时，这种暴露就具有安全意义。

在 LLM 应用中，隐藏上下文通常包括系统提示词、开发者指令、检索到的策略文本（来自 RAG 知识库、配置存储或用户画像服务）、应用向模型开放的工具和函数的模式定义，以及应用组装进模型上下文窗口的其他规则、指令和材料。它们的共同点是：这些隐藏上下文原本不打算向最终用户展示，但模型能够访问。

从业者在设计系统时，应假定隐藏上下文可以被发现，上下文中的任何内容都不应被视为秘密。应用开发者应确保隐藏上下文的披露几乎不会或完全不会造成直接的安全影响。不应在其中嵌入凭证、连接字符串和令牌等敏感数据，也不应仅依赖隐藏上下文，将其作为授权、权限分离、策略执行或内容过滤的安全边界。

严重程度取决于隐藏上下文中放置了什么，以及应用如何依赖这些内容。问题的严重程度可以从信息级（没有秘密、没有与安全相关的逻辑，也不依赖其保密性），到中危（内部规则、过滤条件、角色描述或工作流逻辑能够实质性地帮助攻击者，但不控制关键决策），再到高危（嵌入凭证或令牌，或者依赖隐藏上下文的保密性来实施授权或内容策略），以及严重级（披露可通过攻击链导致所连接系统中的远程代码执行、大范围数据外传或权限提升）。

隐藏上下文暴露本身会引入风险，同时也经常放大相邻类别中的风险：

• 披露的规则或逻辑使更有针对性的提示词注入成为可能（LLM01:2026）。
• 嵌入的凭证构成敏感信息泄露（LLM02:2026）。
• 暴露的工具权限和模式定义扩大了过度代理权的攻击面（LLM03:2026）。
• 泄露的输出格式规则可能助长输出处理不当问题（LLM10:2026）。

总之，LLM08 涵盖的基础风险是：LLM 隐藏的控制上下文遭到暴露、推断或重建，并因此实质性地增强攻击者的能力。LLM08 不涵盖：

• 受监管的用户数据或训练数据的泄露（LLM02 敏感信息泄露）。
• 智能体机制对这一风险的放大，例如持久化记忆、智能体间通道、工具配置持久化，以及多步骤智能体入侵（由《OWASP 智能体应用十大风险》涵盖）。
• 集成 LLM 的系统所继承的通用应用安全问题，例如服务端日志泄露、客户端打包资源检查，以及基础设施层侧信道。

常见风险示例

1. 敏感功能、工具和函数模式定义暴露

应用的系统提示词或隐藏上下文可能揭示原本应当保密的敏感信息或功能。这些内容可能包括敏感的系统架构、可用工具和函数、API 密钥、数据库凭证或用户令牌。虽然暴露这些内容很可能造成损害，但真正的风险在于：一开始就将敏感凭证放进了隐藏上下文。

2. 行为控制逻辑暴露

应用上下文包含应当保密的内部决策过程信息。这些信息使攻击者能够深入了解应用的工作方式，并可能据此利用应用中的弱点或绕过控制措施。

3. 对安全与拒绝机制进行逆向分析

系统提示词可以定义模型应在什么条件下拒绝请求或过滤内容。当这些指令通过系统提示词泄露而暴露时，攻击者就能看到控制拒绝行为的规则。普通用户可能只能看到“抱歉，我无法这样做”之类的回答，而泄露会揭示导致这一决策的底层触发因素、条件和例外情况。这使攻击者能够构造输入，刻意避开已知的拒绝模式，或利用执行上的漏洞，从而提高获得原本受限回答的可能性。

4. 权限与用户角色披露

指令上下文可能包含与授权和权限有关的指令或信息。例如，通过面向内部的 MCP 服务器提供的工具描述，可能指出用户必须具有开发者角色才能使用该工具，或者具有某种角色的用户能够访问一组文档，以进行 RAG 搜索。这类信息的披露可能引来其他形式的探测，包括有针对性的对话和提示词注入（LLM01:2026），并可能进一步揭示其他敏感信息（LLM02:2026）。

5. 输出结构与格式规则暴露

系统提示词经常定义回答应如何组织，包括 JSON 模式、模板或验证约束等必需格式。当这些指令暴露时，攻击者就能了解输出如何构建，以及下游系统依赖哪些假设。攻击者可以利用这些知识，生成符合预期格式、却嵌有非预期值或经过操纵的值的响应，从而可能导致错误解析或非预期的系统行为。

预防与缓解策略

1. 不要将敏感数据放入隐藏上下文

不要将凭证、秘密或对安全至关重要的配置直接嵌入系统提示词或隐藏上下文。应假定 LLM 能够访问的所有上下文，也可能被用户获取。应将这类信息移至模型无法直接访问的外部系统，并避免让模型自行处理敏感数据。

2. 使用确定性方法和防护机制进行验证与行为控制

由于 LLM 可能受到提示词注入等攻击，不应依赖隐藏上下文作为控制模型行为的主要机制。对模型进行专门微调或进一步训练，可能降低披露风险，但无法提供稳定的保证，而且可能产生其他非预期后果。应通过模型之外的独立、确定性系统，强制落实关键行为要求。例如，有害内容的检测和预防应由外部防护措施处理，而不是依靠嵌入隐藏上下文中的指令。

3. 独立于 LLM 实施授权与访问控制

权限分离、授权边界检查等关键控制措施，不得通过系统提示词或其他机制交由 LLM 执行。这些控制应以确定性且可审计的方式强制落实，而 LLM 并不适合提供这类保证。如果任务需要不同级别的访问权限，应按授权上下文将它们分离，并仅向每个任务授予其所需的权限。

攻击场景示例

场景 #1：通过系统提示词泄露凭证

某个 LLM 的系统提示词中包含一组凭证，用于访问已向其开放的某个工具。系统提示词泄露给攻击者后，攻击者便能够将这些凭证用于其他目的。

场景 #2：通过上下文提取获取工具模式定义

攻击者通过对话探测，提取出包含工具列表和参数模式定义的隐藏上下文，并利用这些信息构造输入，引导应用发起特定的工具调用。没有凭证被披露，也没有策略被明显绕过，但攻击者现在拥有了后续提示词注入尝试的具体目标，以及串联下游操作所需的侦察信息。

场景 #3：通过防护规则披露绕过限制

某个 LLM 的系统提示词禁止生成冒犯性内容、生成外部链接以及执行代码。攻击者提取出该系统提示词，并利用披露的限制条件构造提示词注入攻击，绕过这些限制。

LLM09:2026 向量与嵌入弱点(Vector and Embedding Weaknesses)

描述

对于任何将文本、图像、代码或音频转换为数值表示，并通过相似性搜索决定模型能看到什么的 LLM 应用，向量与嵌入弱点都会带来安全风险。检索增强生成（RAG）是最常见的例子，但基于向量的智能体记忆、语义缓存和去重流水线也依赖相同的机制。只要相似性搜索位于数据源与提示词之间，嵌入层就成为应用信任边界的一部分。

这些弱点不同于提示词注入。它们利用的是嵌入空间的几何特性和相似性搜索的机制，而不是模型遵循指令的行为。许多攻击即使在检索内容完全不含恶意指令的情况下也能成功。一种有用的理解方式是：投毒使系统出错，反演使系统泄密，干扰使系统沉默，访问控制失效则使系统不加区分地处理数据。

本条目涵盖依赖嵌入层才能成功的攻击。通过检索内容进行的间接提示词注入，由 LLM01:2026 提示词注入涵盖；训练阶段对嵌入模型进行的投毒，由 LLM05:2026 数据与模型投毒涵盖；向量存储库中的序列化缺陷，由 LLM04:2026 供应链涵盖；不依赖嵌入空间几何特性的智能体记忆攻击，则由 ASI06:2026 记忆与上下文投毒（《OWASP 智能体应用十大风险》）涵盖。不使用向量的检索系统（仅使用 BM25、由 LLM 原生进行树结构导航）仍然存在非几何层面的风险，但不具有 LLM09 所描述的攻击面。

常见风险示例

1. 通过共享相似性搜索造成跨租户泄露

在多租户部署中，相似性搜索经常先在整个索引上运行，然后才在应用层实施访问控制。攻击者可以使用精心构造的查询探测索引，并根据结果数量、分数分布和响应时间，推断其他租户文档是否存在、涉及什么主题，以及大致数量，而无需看到文档本身。即使每份文档都已正确标记，每次 API 调用也都经过身份验证，这种攻击仍然可以成功，因为访问控制决策发生在嵌入空间搜索完成之后。向量数据库软件中的传统身份验证缺陷，例如 CVE-2025-64513（Milvus，通过伪造 sourceID 请求头绕过身份验证，CVSS 9.3）和 CVE-2025-69286（RAGFlow，可预测的令牌派生方式使账户接管成为可能，CVSS 9.3），不属于本条目的范围，但会加剧几何层面的风险：由于泄露的向量存储可以通过反演恢复为源文档（风险 #2），向量数据库中的身份验证缺陷，会比文档数据库或键值存储中的同类缺陷造成更严重的后果。

2. 嵌入反演

存储的嵌入向量可以被反演，以恢复源文本。已有报告中的恢复效果，从恢复句子嵌入中约 50–70% 的词语，到使用 Vec2Text 方法对 32 个词元的短输入实现 92% 的精确重建不等（Morris et al., 2023）；Vec2Text 需要针对每个编码器训练一个反演模型。ZSInvert（C. Zhang et al., 2025）和 Zero2Text（Kim et al., 2026）则以零样本方式运行，无需针对特定编码器进行训练，可用于跨领域和黑盒场景，并且在存储时加入差分隐私噪声的情况下仍然有效。在实际运维中，向量数据库备份、发送给第三方服务的嵌入向量，以及因云存储配置错误而暴露的嵌入向量，都应被视为等同于底层文档的泄露。在 GDPR 等法规框架下，是否需要通报泄露取决于数据主体面临的风险；由于现代嵌入向量可以被反演，这种风险是真实存在的。

3. 检索阶段数据投毒

能够通过公开数据抓取流水线、文件上传、合作伙伴数据馈送或遭到入侵的内部来源向语料库写入内容的攻击者，可以构造嵌入向量落在目标查询附近的内容。当用户提交该查询时，攻击者的内容就会被检索出来，并作为可信上下文提供给 LLM。已发表的攻击方法表明，即使面对包含数百万条内容的语料库和黑盒系统，仅用少量投毒文档也能稳定实现较高的成功率。攻击成功需要同时满足两个条件：投毒内容必须被检索到（几何层面），并且必须能够引导回答（生成层面）。防御者可以在任一层面介入。MITRE ATLAS 将这类攻击归为持久化战术下的 AML.T0070（RAG 投毒）。训练阶段对嵌入模型本身进行的投毒属于 LLM05:2026。

4. 检索干扰

攻击者可以通过插入一份“阻断文档”，使 RAG 系统无法正常提供服务。这类内容经过专门设计，会针对特定查询被检索出来，并使 LLM 拒绝回答或声称缺乏信息。与投毒不同，阻断文档不携带恶意指令。它利用检索机制和 LLM 的安全行为。无需访问目标嵌入模型或 LLM，仅通过黑盒优化生成一份阻断文档，就足以实施攻击。这是一种针对检索层的可用性攻击。

5. 通过相似性搜索进行成员推断

攻击者想知道的是某份特定文档（医疗记录、法律诉讼文件、人力资源投诉）是否存在于索引中，而非文档写了什么。如果应用向客户端返回原始相似度分数或距离，索引就会成为直接的成员判定预言机，整个过程无需 LLM 参与。如果应用仅返回生成的回答，攻击者仍然可以通过提交文档片段或经过扰动的查询，并分析响应来推断成员关系。即使内容仍受到保护，成员关系信息本身也可能是敏感信息。

6. 语义缓存与去重投毒

语义缓存和近似重复检测使用余弦相似度阈值，判断两段内容是否“相同”。如果攻击者能够构造出相似度恰好高于或低于该阈值的内容，就可以污染缓存条目，使所有语义等价的查询都收到攻击者的文本；利用投毒内容的近似重复版本绕过去重；或者迫使系统将合法的新内容误判为重复内容并悄然丢弃。Wu et al.（2026）在 AWS、Azure 和阿里云部署中端到端地展示了语义缓存投毒。Z. Zhang et al.（2026）展示了黑盒键碰撞攻击：在无法访问目标编码器的情况下，使用替代嵌入模型构造分处阈值两侧的向量。这三种失效模式都依赖嵌入空间的几何特性，文档级控制措施无法察觉它们。

7. 多模态嵌入投毒

CLIP 和 ColPali 等跨模态编码器将图像、音频、代码和文本映射到同一个向量空间。能够提交非文本内容的攻击者，可以构造一张图像，使其嵌入向量靠近某个敏感文本查询。当用户提交该查询时，这张图像就会被检索出来，作为可信上下文。MM-PoisonRAG（Ha et al., 2025）和 Poisoned-MRAG（Liu et al., 2025）展示了针对多模态 RAG 流水线的局部和全局投毒。“One Pic is All it Takes”（《一张图就足够》）表明，仅一张图像就足以实施针对性和通用性 VD-RAG 投毒。在人工审核者看来，这张图像平平无奇；由于载荷并非文本，基于文本的内容扫描也无法发现它。

预防与缓解策略

1. 权限与访问控制

在索引查询内部强制限定租户范围，而不是将其作为检索后的过滤步骤，并在服务端进行验证。客户端提供的范围只是建议，不是控制措施。将嵌入和相似性搜索端点作为正式 API 实施身份验证，并按租户设置速率限制。对于高敏感度工作负载，为每个租户或信任区域使用物理隔离的索引。在文本块层面实施访问控制：一份大部分内容公开的文档，也可能包含一个机密段落。

2. 数据验证、来源认证与来源追踪

在生成嵌入向量之前对内容进行规范化：在提取阶段去除零宽字符、白底白字文本和 Unicode 同形异义字符。为每个嵌入向量跟踪来源信息（来源、摄入时间、信任层级、流水线版本），以便使受到入侵影响的批次失效并对其进行审计。对于来自外部、即将进入敏感索引的内容，实施人工审核。审查嵌入模型本身。带有后门的编码器会破坏所有摄入内容的几何表示。

3. 按信任层级隔离数据

不同信任级别的内容（外部网页数据、内部机密文档、合作伙伴数据），在没有强隔离的情况下不得共享索引。索引级隔离优于共享索引上的分类标签，因为它消除了这类配置错误路径。

4. 摄入与检索阶段的异常检测

标记那些与大量常见查询异常接近的新向量，这是检索劫持投毒的特征。关注返回过多高相似度匹配结果的查询、嵌入端点上的异常请求量（可能是基于查询的反演攻击的前兆），以及摄入后增长速度超出预期的向量簇。不要向客户端返回原始相似度分数；在检索排序层引入噪声和多样化机制；对可能被当作预言机反复查询的端点实施速率限制。交叉编码器重排序可以提高攻击成本，但不能替代来源追踪和摄入控制。现代攻击会同时针对检索与排序。

5. 存储生命周期控制

当源文档被删除时，在限定时间内删除其嵌入向量，并通过对账审计验证。将向量数据库备份视为与源文档具有相同的敏感等级。对静态存储的嵌入向量进行加密，并将密钥与应用层分开管理。更换嵌入模型时，应重新为整个语料库生成嵌入向量，而不是混用新旧向量。异构嵌入会在相似性行为上产生可被利用的缺口。将嵌入 API 密钥作为秘密保护。密钥泄露后，攻击者就能查询你实际使用的那个编码器。

6. 监控、日志记录与事件响应

保留不可篡改的检索活动日志（租户范围、查询、返回的 ID、相似度分数）。监控租户过滤器绕过尝试、跨租户检索异常，以及嵌入 API 的异常消耗。更新事件响应预案，在依据 GDPR 第 33 条及类似法规开展泄露评估和通报时，将“仅泄露嵌入向量”的事件按源数据泄露处理。

攻击场景示例

场景 #1：针对公共数据摄入流水线的嵌入相似性攻击

一家公司的 RAG 系统定期抓取公开文档和论坛帖子。攻击者发布经过专门设计的帖子，使其嵌入向量落在某些特定内部查询附近，例如“我们第三季度的营收预测是多少”。当员工提出这个问题时，攻击者的内容就会被检索出来，并提供给 LLM。同样的文本直接粘贴到聊天中不会产生效果。攻击之所以有效，完全是因为攻击者能够在嵌入空间中，将内容放置在目标查询附近。

场景 #2：共享向量索引中的跨租户推断

一个多租户 SaaS 产品使用单个共享向量索引，并在应用层实施租户过滤。租户 A 提交探测查询。在应用过滤器之前，相似性搜索会遍历所有嵌入向量，包括租户 B 的向量。A 始终看不到 B 的文档，但响应时间差异、结果数量和分数分布差异，会揭示 B 的内容是否存在及其大致主题。经过多次查询，A 构建出一份有用的 B 租户数据分布图。这一类别中的真实事件包括 CVE-2025-69286（RAGFlow）：在这个广泛部署的开源 RAG 引擎中，可预测的令牌生成方式使跨账户入侵成为可能。

场景 #3：从泄露的向量存储中进行嵌入反演

一次云配置错误暴露了生产向量数据库的备份。底层文档是包含个人身份信息（PII）的客户对话日志，它们被单独加密，并未暴露，因此该事件最初被归类为低严重程度：“泄露的只是嵌入向量”。攻击者对窃取的嵌入向量实施零样本反演攻击，在无法访问原始编码器的情况下，重建出相当一部分源内容，其中包括个人身份信息。该事件被重新认定为等同于源文档泄露，并重新评估通报义务。“仅泄露嵌入向量”并不是一种可据此免责的分类。

LLM10:2026 输出处理不当(Improper Output Handling)

描述

输出处理不当，特指大型语言模型生成的输出在传递给下游其他组件和系统之前，未经过充分的验证、清理和处理。由于 LLM 生成的内容可以受到提示词输入的控制，这种行为类似于向用户间接开放额外功能的访问权限。

输出处理不当关注的是模型输出在传递给下游之前未得到安全处理的问题，而 LLM07:2026 错误信息关注的是不正确或具有误导性的输出。模型输入的验证与清理由 LLM01:2026 提示词注入涵盖。

成功利用输出处理不当漏洞，可能导致 Web 浏览器中的跨站脚本攻击（XSS）和跨站请求伪造（CSRF），以及后端系统中的服务端请求伪造（SSRF）、权限提升或远程代码执行。

以下条件可能扩大该漏洞的影响：

• 向 LLM 授予过大的应用权限，使权限提升或远程代码执行成为可能。
• 容易受到间接提示词注入攻击，使攻击者可能获得对目标用户环境的特权访问。
• 来自第三方工具的输入未经验证。
• 缺少针对具体上下文的输出编码（例如 HTML、JavaScript、SQL）。
• 对 LLM 输出的监控和日志记录不足。
• 缺少针对 LLM 使用的速率限制或异常检测。
• 终端、日志或 IDE 等输出接收端在渲染模型输出时，未消除 ANSI 转义序列等控制字符的作用。
• 客户端渲染器（浏览器、聊天界面、IDE、终端）自动获取模型输出中引用的外部资源（例如 Markdown 图像、链接预览、iframe），使攻击者能够通过出站请求外传上下文数据。

常见风险示例

1. LLM 输出被直接传入系统 Shell 或 exec、eval 等类似函数，导致远程代码执行。
2. LLM 生成 JavaScript 或 Markdown 并返回给用户，随后浏览器解释执行这些代码，导致 XSS。
3. LLM 生成的 SQL 查询未经适当参数化就被执行，导致 SQL 注入。
4. LLM 输出在未经适当清理的情况下被用于构造文件路径，可能导致路径遍历漏洞。
5. LLM 生成的内容在未经适当转义的情况下被用于电子邮件模板，可能导致钓鱼攻击。
6. 包含 ANSI 转义序列或其他控制字符的 LLM 输出，被写入会解释这些字符的终端、日志查看器或 IDE 窗格，从而使视觉欺骗、剪贴板劫持（例如 OSC 52），或对已知终端模拟器漏洞的利用成为可能（Rehberger, 2024b）。
7. 聊天界面自动渲染模型输出中引用的 Markdown 图像或链接预览，使能够控制部分模型上下文的攻击者，可以通过图像 URL 的主机名或查询字符串外传对话数据（Rehberger, 2024a）。

预防与缓解策略

1. 像对待其他任何用户一样对待模型，采用零信任方法，并对模型传入后端函数的响应实施适当的输入验证。
2. 遵循 OWASP ASVS（应用安全验证标准）指南，确保有效的输入验证与清理（OWASP, n.d.）。
3. 对返回给用户的模型输出进行编码，以降低 JavaScript 或 Markdown 引发非预期代码执行的风险。OWASP ASVS 提供了有关输出编码的详细指导。
4. 根据 LLM 输出的使用位置，实施感知上下文的输出编码（例如，对网页内容使用 HTML 编码，对浏览器脚本上下文使用 JavaScript 编码）。
5. 对所有涉及 LLM 输出的数据库操作，使用参数化查询或预处理语句。
6. 采用严格的内容安全策略（CSP），降低 LLM 生成内容引发 XSS 攻击的风险。
7. 实施日志记录和监控系统，检测 LLM 输出中可能表明存在漏洞利用尝试的异常模式。
8. 在将模型输出写入终端、日志文件或其他会解释其内容的接收端之前，清理其中的控制字符（ANSI 转义序列、BEL、OSC、退格、回车）和其他不可打印字节。如果必须保留这些内容，应将其编码为可见形式。
9. 在客户端渲染器（聊天界面、IDE、邮件客户端、移动应用）中，防止模型输出触发向攻击者控制端点的自动出站请求。默认禁用 Markdown 图像、链接预览、iframe 及类似元素的自动渲染。如果必须渲染，应将资源获取限制在明确列出的允许来源范围内，或者通过能够移除携带数据的查询参数的服务端获取器代理这些请求。

攻击场景示例

场景 #1

某个应用使用 LLM 工具为聊天机器人功能生成响应。该工具还提供若干管理功能，供另一个具有特权的 LLM 访问。通用 LLM 在未进行适当输出验证的情况下，将响应直接传递给该工具，导致工具因维护而关闭。

场景 #2

用户使用由 LLM 驱动的网站摘要工具，为一篇文章生成简明摘要。该网站包含提示词注入，指示 LLM 从网站或用户对话中获取敏感内容。随后，LLM 可以对敏感数据进行编码，并在未经任何输出验证或过滤的情况下，将其发送到攻击者控制的服务器。

场景 #3

某个 LLM 允许用户通过类似聊天的功能，为后端数据库构造 SQL 查询。用户要求生成删除所有数据库表的查询。如果未对 LLM 构造的查询进行审查，所有数据库表就会被删除。

场景 #4

一个 Web 应用使用 LLM 根据用户的文本提示词生成内容，却不对输出进行清理。攻击者可以提交精心构造的提示词，使 LLM 返回未经清理的 JavaScript 载荷，当其在受害者的浏览器中渲染时，就会导致 XSS。对模型输出的验证和编码不足，使这一攻击得以发生。

场景 #5

某个 LLM 被用于为营销活动生成动态电子邮件模板。攻击者操纵 LLM，使其在邮件内容中加入恶意 JavaScript。如果应用未对 LLM 输出进行适当清理，就可能对使用存在漏洞的邮件客户端查看邮件的收件人造成 XSS 攻击。

场景 #6

某个应用未经人工审核或安全测试，就自动编译并部署 LLM 生成的代码。由于输出被直接信任，并在未经验证的情况下执行，不安全的代码进入生产环境并遭到利用。

附录：Top 10 与 OWASP AISVS 1.0 的映射

目的

OWASP LLM 应用 Top 10 是一份风险认知文档：它列出了最关键的十类失效风险，并从原则层面解释了如何预防和缓解每一类风险。OWASP AI Security & Privacy Verification Standard（AISVS，AI 安全与隐私验证标准）则是一项验证标准：它将 AI 安全拆解为可测试的要求（“验证……”），并为每项要求分配从 L1（基础）到 L3（高级）的保障等级。

二者相互补充。本附录将它们连接起来，使已经阅读某个 Top 10 风险条目的团队，可以直接进一步查看用于防御该风险的具体、可审计控制措施。对于每一项风险，本附录回答一个问题：

“针对这项风险，我应该验证哪些 AISVS 要求，才能确认已经采取了相应的防御措施？”

映射版本： OWASP LLM 应用 Top 10 2026 → OWASP AISVS 1.0。

如何阅读本附录

覆盖矩阵（Coverage Matrix）以一览表的形式展示全部十项风险与 AISVS 十二个控制章节之间的对应关系。可以利用该矩阵查看某项风险主要集中在哪些方面，以及哪些章节承担了最主要的防御作用；随后，再阅读 AISVS 1.0 中这些章节的完整内容，以确定适用于你的系统的具体 Verify that…（“验证……”）要求。

这些映射提供的是方向性指导，而不是合规对应表：某个被标记的章节能够帮助防御相应风险，但通常无法单独“解决”该风险；同时，一个章节也可能与此处未标记的其他风险相关。

图例：● 主要防御（该章节是防御此项风险的主要防线）· ○ 辅助防御（能够提供防御作用，但并非核心）。

AISVS 1.0 控制章节

覆盖矩阵

说明与注意事项

• 方向性指导，而非认证依据。 某个章节之所以被标记为与某项风险相关，是因为验证该章节中的控制措施能够帮助防御这项风险。要完整覆盖一项风险，通常需要来自多个章节的控制措施，以及 AISVS 无法编码进去的、针对具体系统的设计决策。
• 映射到章节，而非单项要求。 该矩阵的映射粒度为章节级别（C1 至 C12）。在每一个被标记的章节中，具体适用哪些 Verify that…（“验证……”）要求，以及相应采用何种保障等级（从 L1 基础到 L3 高级），取决于你的具体系统；应查阅 AISVS 1.0 中相应章节的正文。
• 智能体化带来的风险放大。 2026 版中的多个条目指出，相应风险在智能体和多智能体系统中会被进一步放大。在这些情况下，AISVS C9（编排与智能体安全）和 C10（MCP 安全）包含本附录所映射的相关防御措施；但对于智能体特有的威胁，OWASP Top 10 for Agentic Applications 仍然是主要参考资料。
• 持续演进的映射。 这两份文档都会持续演进。本附录映射的是 Top 10 2026 与 AISVS 1.0；当其中任何一份文档发布新版本时，都应重新审视这份映射。

附录 A：相关框架映射

本附录汇总了 OWASP 大语言模型应用 Top 10（2026）十项风险与九个外部安全框架及分类体系之间的映射关系。它取代了各风险条目中原有的“相关框架与分类体系（Related Frameworks and Taxonomies）”部分，将这些内容集中整理为一份固定版本的参考资料。

如何阅读本附录

覆盖矩阵（Coverage Matrix）用于直观展示每项风险分别与哪些框架存在映射关系。后续的按框架分类部分（By-Framework Sections）则给出了具体的元素映射，以及这些映射适用的原因。 映射采用各框架较为宏观的分类层级，例如战术（tactics）、支柱/弱点（pillars/weaknesses）、风险类别（risk categories）和控制域（control domains）。 所有元素均取自框架来源与版本（Framework Sources & Versions）中列出的固定框架版本。每个单元格都会列出主要映射，以及最相关的辅助映射。

​

图例：
● 主要映射——属于该风险的核心防御措施或核心描述。
○ 辅助映射——与该风险相关并起到一定作用，但并非核心。
— 无适用映射。

覆盖矩阵

OWASP Top 10 for Agentic Applications (ASI) — 2026 (于 2025-12-09 发布)

本部分内容从 2026 版各风险条目中原样迁移至此，用于将每项 LLM 风险映射到 OWASP Top 10 for Agentic Applications（ASI）中的相应风险。

OWASP GenAI Data Security 2026 (DSGAI) — v1.0 (2026-03-17)

每一行将一项 LLM Top 10 风险映射到 OWASP GenAI Data Security 2026（DSGAI）的风险类别。其中，主要元素表示与其最接近的数据安全风险类别，辅助元素则表示与其最相关的相邻数据风险。

MITRE ATLAS — content v2026.06 (format-version 6.0.0)

每一行表示一项 OWASP LLM 风险与 MITRE ATLAS 攻击者战术（AML.TAxxxx）之间的映射，即利用该风险的攻击在攻击过程中会涉及哪些战术。主要战术表示攻击者的核心目标，辅助战术表示实现这一目标所涉及的支撑步骤。

MITRE ATT&CK — v19.1

每一行将一项 OWASP LLM 风险映射到攻击者利用该风险时所涉及的 MITRE ATT&CK v19.1 Enterprise 战术（TA ID）。其中，主要战术表示该风险对应的核心攻击目标，辅助战术表示与之相关的其他攻击阶段。

MITRE CWE（Common Weakness Enumeration，通用缺陷枚举）— 4.20

每项 OWASP LLM Top 10 2026 风险都会映射到能够描述其根本原因的 CWE 弱点。其中，主要 CWE 表示定义该风险的核心弱点，辅助 CWE 表示最主要的促成性失效模式。

NIST AI 600-1（Generative AI Profile）— v1.0（2024 年 7 月）

每一行将一项 OWASP LLM 风险映射到其所涉及的 NIST AI 600-1 Generative AI Profile 风险类别。其中，主要类别表示该风险的核心风险，辅助类别表示其次要方面。

NIST AI RMF (AI 100-1) — v1.0 (2023)

每一行将一项 OWASP LLM 风险映射到 NIST AI RMF（AI 100-1）中与其结果最直接相关的类别。其中，“主要（primary）”表示二者几乎直接对应，“辅助（supporting）”表示部分对应或治理层面的关联。

CSA AI Controls Matrix (AICM) — v1.1 (2026-06-22)

每一行将一项 OWASP LLM 风险映射到能够应对该风险的 CSA AI Controls Matrix v1.1 控制域。其中，主要控制域承担核心控制作用，辅助控制域则用于提供纵深防御。

OWASP AIVSS（AI Vulnerability Scoring System，AI 漏洞评分系统）— v0.8

每一行列出了某项 LLM Top 10 风险可能导致或促成的 OWASP AIVSS Agentic AI Core Security Risks。其中，主要映射表示该风险能够最直接促成的智能体风险，辅助映射表示次要路径；AIVSS 随后会对这些智能体风险的严重程度进行评分。

框架来源与版本

附录 B: LLM应用架构与威胁建模

LLM 应用架构与威胁模型，OWASP LLM 应用十大风险（2026）

参考文献

针对 OWASP LLM 应用十大安全风险（2026版）的参考资料，按风险条目分类并采用 APA-7 格式编排。若某来源被多个条目引用，则在每个条目下均完整列出，并附注 [also cited in ...]。

LLM01: 提示词注入(Prompt Injection)

• Amazon Web Services. (2025a, July). AWS-2025-015: Amazon Q VS Code extension supply-chain incident [Security bulletin]. https://aws.amazon.com/security/security-bulletins/AWS-2025-015/
• Amazon Web Services. (2025b, July). AWS-2025-019: Amazon Q runtime injection [Security bulletin]. https://aws.amazon.com/security/security-bulletins/AWS-2025-019/
• Chao, P., Debenedetti, E., Robey, A., Andriushchenko, M., Croce, F., Sehwag, V., Dobriban, E., Flammarion, N., Pappas, G. J., Tramèr, F., Hassani, H., & Wong, E. (2024). JailbreakBench: An open robustness benchmark for jailbreaking large language models. arXiv. https://arxiv.org/abs/2404.01318
• Chen, R., Cui, S., Huang, X., Pan, C., Huang, V. S.-J., Zhang, Q., Ouyang, X., Zhang, Z., Wang, H., & Huang, M. (2025). JPS: Jailbreak multimodal large language models with collaborative visual perturbation and textual steering. In Proceedings of the 33rd ACM International Conference on Multimedia (MM '25). Association for Computing Machinery. https://dl.acm.org/doi/10.1145/3746027.3754561
• Chen, S., Piet, J., Sitawarin, C., & Wagner, D. (2025). StruQ: Defending against prompt injection with structured queries. In Proceedings of the 34th USENIX Security Symposium (USENIX Security 25). USENIX Association. https://www.usenix.org/system/files/usenixsecurity25-chen-sizhe.pdf
• Clusmann, J., Ferber, D., Wiest, I. C., Schneider, C. V., Brinker, T. J., Foersch, S., Truhn, D., & Kather, J. N. (2025). Prompt injection attacks on vision language models in oncology. Nature Communications, 16, Article 1239. https://www.nature.com/articles/s41467-024-55631-x
• Cybersecurity and Infrastructure Security Agency, Federal Bureau of Investigation, National Security Agency, & Australian Cyber Security Centre. (2025, December). Principles for the secure integration of AI in operational technology. https://www.cisa.gov/sites/default/files/2025-12/joint-guidance-principles-for-the-secure-integration-of-artificial-intelligence-in-operational-technology-508c.pdf
• Debenedetti, E., Shumailov, I., Fan, T., Hayes, J., Carlini, N., Fabian, D., Kern, C., Shi, C., Terzis, A., & Tramèr, F. (2025). Defeating prompt injections by design. arXiv. https://arxiv.org/abs/2503.18813
• Debenedetti, E., Zhang, J., Balunović, M., Beurer-Kellner, L., Fischer, M., & Tramèr, F. (2024). AgentDojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents. arXiv. https://arxiv.org/abs/2406.13352
• General Analysis. (2025, July). Supabase MCP can leak your entire SQL database [Blog post]. https://generalanalysis.com/blog/supabase-mcp-blog
• Greshake, K. (2023). Inject my PDF: Prompt injection for your resume [Blog post]. https://kai-greshake.de/posts/inject-my-pdf
• Greshake, K., Abdelnabi, S., Mishra, S., Endres, C., Holz, T., & Fritz, M. (2023). Not what you've signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection. arXiv. https://arxiv.org/abs/2302.12173
• Hackett, W., Birch, L., Trawicki, S., Suri, N., & Garraghan, P. (2025). Bypassing LLM guardrails: An empirical analysis of evasion attacks against prompt injection and jailbreak detection systems. arXiv. https://arxiv.org/abs/2504.11168
• INCIBE-CERT. (2024). CVE-2024-5184: EmailGPT [Vulnerability advisory]. https://www.incibe.es/en/incibe-cert/early-warning/vulnerabilities/cve-2024-5184
• Invariant Labs. (2025, May). GitHub MCP server vulnerability [Blog post]. https://invariantlabs.ai/blog/mcp-github-vulnerability
• Koi Security. (2025, September). Postmark-MCP npm malicious backdoor: Email theft [Blog post]. https://www.koi.ai/blog/postmark-mcp-npm-malicious-backdoor-email-theft
• Labunets, A., Pandya, N. V., Hooda, A., Fu, X., & Fernandes, E. (2025). Fun-tuning: Characterizing the vulnerability of proprietary LLMs to optimization-based prompt injection attacks via the fine-tuning interface. arXiv. https://arxiv.org/abs/2501.09798
• Meta AI. (2025, October 31). Agents rule of two: A practical approach to AI agent security [Blog post]. https://ai.meta.com/blog/practical-ai-agent-security/ [also cited in LLM03]
• Microsoft Research. (2025). Defending against indirect prompt injection attacks with spotlighting. https://www.microsoft.com/en-us/research/publication/defending-against-indirect-prompt-injection-attacks-with-spotlighting/
• Microsoft Security Response Center. (2025, March). Announcing the winners of the Adaptive Prompt Injection Challenge — LLMail-Inject [Blog post]. https://www.microsoft.com/en-us/msrc/blog/2025/03/announcing-the-winners-of-the-adaptive-prompt-injection-challenge-llmail-inject/
• MITRE. (n.d.). AI agent context poisoning: Memory (AML.T0080.000) [ATLAS technique]. MITRE ATLAS. Retrieved July 11, 2026, from https://atlas.mitre.org/techniques/AML.T0080.000
• Nasr, M., Carlini, N., Sitawarin, C., Schulhoff, S. V., Hayes, J., Ilie, M., Pluto, J., Song, S., Chaudhari, H., Shumailov, I., Thakurta, A., Xiao, K. Y., Terzis, A., & Tramèr, F. (2025). The attacker moves second: Stronger adaptive attacks bypass defenses against LLM jailbreaks and prompt injections. arXiv. https://arxiv.org/abs/2510.09023
• National Cyber Security Centre. (2025, December). Prompt injection is not SQL injection [Blog post]. https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
• National Institute of Standards and Technology. (2025). Adversarial machine learning: A taxonomy and terminology of attacks and mitigations (NIST AI 100-2e2025). https://csrc.nist.gov/pubs/ai/100/2/e2025/final
• National Institute of Standards and Technology. (n.d.). CVE-2025-32711 detail. National Vulnerability Database. Retrieved July 11, 2026, from https://nvd.nist.gov/vuln/detail/CVE-2025-32711
• Noma Security. (2025). Why the Rule of Two can't protect your agents [Blog post]. https://noma.security/blog/mcp-servers-agentic-risk-and-the-framework-that-protects-it/
• OWASP GenAI Security Project. (2025). OWASP Top 10 for LLM Applications — LLM01:2025 Prompt injection. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
• Reddy, P., & Gujral, A. S. (2025). EchoLeak: The first real-world zero-click prompt injection exploit in a production LLM system. arXiv. https://arxiv.org/abs/2509.10540
• Rehberger, J. (2024, August). M365 Copilot prompt injection, tool invocation and data exfil using ASCII smuggling [Blog post]. Embrace The Red. https://embracethered.com/blog/posts/2024/m365-copilot-prompt-injection-tool-invocation-and-data-exfil-using-ascii-smuggling/
• Rehberger, J. (2025a, August). GitHub Copilot: Remote code execution via prompt injection (CVE-2025-53773) [Blog post]. Embrace The Red. https://embracethered.com/blog/posts/2025/github-copilot-remote-code-execution-via-prompt-injection/ [also cited in LLM10]
• Rehberger, J. (2025b, February). Hacking Gemini's memory with prompt injection and delayed tool invocation [Blog post]. Embrace The Red. https://embracethered.com/blog/posts/2025/google-gemini-memory-persistence-prompt-injection/
• Rehberger, J. (2025c). Sneaky bits & ASCII smuggler updates [Blog post]. Embrace The Red. https://embracethered.com/blog/posts/2025/sneaky-bits-and-ascii-smuggler/
• Toulas, B. (2025, September 25). Unofficial Postmark MCP npm package silently stole users' emails. BleepingComputer. https://www.bleepingcomputer.com/news/security/unofficial-postmark-mcp-npm-silently-stole-users-emails/
• Willison, S. (2025, June 16). The lethal trifecta for AI agents: Private data, untrusted content, and external communication [Blog post]. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
• Zou, A., Wang, Z., Carlini, N., Nasr, M., Kolter, J. Z., & Fredrikson, M. (2023). Universal and transferable adversarial attacks on aligned language models. arXiv. https://arxiv.org/abs/2307.15043
• Zou, W., Geng, R., Wang, B., & Jia, J. (2025). PoisonedRAG: Knowledge corruption attacks to retrieval-augmented generation of large language models. In Proceedings of the 34th USENIX Security Symposium (USENIX Security 25). USENIX Association. https://www.usenix.org/system/files/usenixsecurity25-zou-poisonedrag.pdf [also cited in LLM07, LLM09]

LLM02: 敏感信息泄露(Sensitive Information Disclosure)

• BeyondScale. (2026, May). Vector database security: RAG compliance & monitoring. https://beyondscale.tech/blog/vector-database-security-rag-compliance-monitoring
• Boenisch, F., Dziedzic, A., Schuster, R., Shamsabadi, A. S., Shumailov, I., & Papernot, N. (2021). When the curious abandon honesty: Federated learning is not private. arXiv. https://arxiv.org/abs/2112.02918
• Carlini, N., Paleka, D., Dvijotham, K. D., Steinke, T., Hayase, J., Cooper, A. F., Lee, K., Jagielski, M., Nasr, M., Conmy, A., Yona, I., Wallace, E., Rolnick, D., & Tramèr, F. (2024). Stealing part of a production language model. arXiv. https://arxiv.org/abs/2403.06634 [also cited in LLM06]
• Check Point Research. (2026, February). ChatGPT data leakage via a hidden outbound runtime channel. https://research.checkpoint.com/2026/chatgpt-data-leakage-via-a-hidden-outbound-channel-in-the-code-execution-runtime
• Dong, T., Meng, Y., Li, S., Chen, G., Liu, Z., & Zhu, H. (2025). Depth gives a false sense of privacy: LLM internal states inversion. arXiv. https://arxiv.org/abs/2507.16372
• Fu, W., Wang, H., Gao, C., Liu, G., Li, Y., & Jiang, T. (2024). Membership inference attacks against fine-tuned large language models via self-prompt calibration [Conference poster]. Neural Information Processing Systems (NeurIPS 2024). https://neurips.cc/virtual/2024/poster/95327
• The Guardian. (2026, April 1). Anthropic Claude Code source leak. https://www.theguardian.com/technology/2026/apr/01/anthropic-claudes-code-leaks-ai
• InstaTunnel. (2026, February). Differential privacy reversal via LLM feedback. https://instatunnel.my/blog/differential-privacy-reversal-via-llm-feedback-the-silent-killer-of-data-anonymization
• Jiang, C., Pan, X., Hong, G., Bao, C., Chen, Y., & Yang, M. (2024). Feedback-guided extraction of knowledge base from retrieval-augmented LLM applications. arXiv. https://arxiv.org/abs/2411.14110
• Lakshmanan, R. (2026, March 26). Claude extension flaw enabled zero-click XSS prompt injection via any website. The Hacker News. https://thehackernews.com/2026/03/claude-extension-flaw-enabled-zero.html
• Lin, Y., Zhang, Q., Ruan, W., Zhang, D., Hong, J., Wu, Y., Xia, H., Mao, Y., & Zhong, S. (2026). Towards privacy-preserving LLM inference via covariant obfuscation (Technical report). arXiv. https://arxiv.org/abs/2603.01499
• McDonald, G., & Bar Or, J. (2025). Whisper Leak: A side-channel attack on large language models. arXiv. https://arxiv.org/abs/2511.03675
• Nasr, M., Carlini, N., Hayase, J., Jagielski, M., Cooper, A. F., Ippolito, D., Choquette-Choo, C. A., Wallace, E., Tramèr, F., & Lee, K. (2023). Scalable extraction of training data from (production) language models. arXiv. https://arxiv.org/abs/2311.17035
• OWASP GenAI Security Project. (2026). OWASP GenAI data security 2026 (Version 1.0). https://genai.owasp.org/
• Panda, A., Choquette-Choo, C. A., Zhang, Z., Yang, Y., & Mittal, P. (2024). Teach LLMs to phish: Stealing private information from language models. arXiv. https://arxiv.org/abs/2403.00871
• Unit 42. (2026, March). Gemini Live in Chrome hijacking (CVE-2026-0628). Palo Alto Networks. https://unit42.paloaltonetworks.com/gemini-live-in-chrome-hijacking
• Weiss, R., Ayzenshteyn, D., Amit, G., & Mirsky, Y. (2024). What was your prompt? A remote keylogging attack on AI assistants. arXiv. https://arxiv.org/abs/2403.09751
• Wiz. (2025, January). Wiz Research uncovers exposed DeepSeek database leak. https://www.wiz.io/blog/wiz-research-uncovers-exposed-deepseek-database-leak
• Wu, G., Zhang, Z., Zhang, Y., Wang, W., Niu, J., Wu, Y., & Zhang, Y. (2025). I know what you asked: Prompt leakage via KV-cache sharing in multi-tenant LLM serving [Conference paper]. Network and Distributed System Security Symposium (NDSS 2025). https://www.ndss-symposium.org/ndss-paper/i-know-what-you-asked-prompt-leakage-via-kv-cache-sharing-in-multi-tenant-llm-serving/

LLM03: 过度代理权(Excessive Agency)

• Bort, J. (2026, February 23). A Meta AI security researcher said an OpenClaw agent ran amok on her inbox. TechCrunch. https://techcrunch.com/2026/02/23/a-meta-ai-security-researcher-said-an-openclaw-agent-ran-amok-on-her-inbox/
• Ferreira, B. (2026, March 7). Claude Code deletes developers' production setup, including its database and snapshots — 2.5 years of records were nuked in an instant. Tom's Hardware. https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-code-deletes-developers-production-setup-including-its-database-and-snapshots-2-5-years-of-records-were-nuked-in-an-instant
• Kovacs, E. (2026, April 1). Google addresses Vertex security issues after researchers weaponize AI agents. SecurityWeek. https://www.securityweek.com/google-addresses-vertex-security-issues-after-researchers-weaponize-ai-agent/
• Kundel, D. (2024, October 10). Rogue agents: Stop AI from misusing your APIs. Twilio. https://www.twilio.com/en-us/blog/rogue-ai-agents-secure-your-apis
• Lucas, J. (2024, December 16). Sandboxing agentic AI workflows with WebAssembly. NVIDIA Developer Blog. https://developer.nvidia.com/blog/sandboxing-agentic-ai-workflows-with-webassembly/
• Meta AI. (2025, October 31). Agents rule of two: A practical approach to AI agent security [Blog post]. https://ai.meta.com/blog/practical-ai-agent-security/ [also cited in LLM01]
• NVIDIA. (n.d.). NeMo-Guardrails: Interface guidelines. GitHub. https://github.com/NVIDIA/NeMo-Guardrails/blob/main/docs/security/guidelines.md
• Rehberger, J. (2023, May 28). ChatGPT plugin exploit explained: From prompt injection to accessing private data. Embrace The Red. https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./

LLM04: 供应链(Supply Chain)

• Cisco Talos. (2024). llama.cpp GGUF library gguf_fread_str heap-based buffer overflow vulnerability (TALOS-2024-1913). https://talosintelligence.com/vulnerability_reports/TALOS-2024-1913
• Cohen, D. (2025, December 2). PyTorch users at risk: Unveiling 3 zero-day PickleScan vulnerabilities. JFrog. https://jfrog.com/blog/unveiling-3-zero-day-vulnerabilities-in-picklescan/
• Egashira, K., Staab, R., Vero, M., He, J., & Vechev, M. (2025). Mind the gap: A practical attack on GGUF quantization (arXiv:2505.23786). arXiv. https://arxiv.org/abs/2505.23786
• GitHub Security Advisories. (2025, April 17). PyTorch torch.load weights_only bypass (CVE-2025-32434, GHSA-53q9-r3pm-6pq6). https://github.com/pytorch/pytorch/security/advisories/GHSA-53q9-r3pm-6pq6
• HiddenLayer. (2024, February 21). Hijacking Safetensors conversion on Hugging Face. https://hiddenlayer.com/research/silent-sabotage/
• Huynh, D., & Hardouin, J. (2023, July 9). PoisonGPT: How we hid a lobotomized LLM on Hugging Face to spread fake news. Mithril Security. https://blog.mithrilsecurity.io/poisongpt-how-we-hid-a-lobotomized-llm-on-hugging-face-to-spread-fake-news
• Lumelsky, A., & Elbaz, G. (2025, November 18). ShadowRay 2.0: Attackers turn AI against itself in global campaign that hijacks AI into self-propagating botnet. Oligo Security. https://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet
• MITRE. (n.d.). AI supply chain compromise (AML.T0010). MITRE ATLAS. Retrieved July 11, 2026, from https://atlas.mitre.org/techniques/AML.T0010
• OASIS Open. (2025, November 18). Coalition for Secure AI releases two actionable frameworks for AI model signing and incident response. https://www.oasis-open.org/2025/11/18/coalition-for-secure-ai-releases-two-actionable-frameworks-for-ai-model-signing-and-incident-response/
• Open Source Security Foundation. (2025, April 4). Launch of Model Signing v1.0: OpenSSF AI/ML Working Group secures the machine learning supply chain. https://openssf.org/blog/2025/04/04/launch-of-model-signing-v1-0-openssf-ai-ml-working-group-secures-the-machine-learning-supply-chain/
• Open Source Security Foundation. (n.d.). Supply-chain Levels for Software Artifacts (SLSA). Retrieved July 11, 2026, from https://slsa.dev/
• OWASP CycloneDX. (n.d.). Machine learning bill of materials (AI/ML-BOM). Retrieved July 11, 2026, from https://cyclonedx.org/capabilities/mlbom/ [also cited in LLM05]
• OWASP GenAI Security Project. (2025, December 18). Evolving AI transparency: The journey of the AIBOM Generator and its new home at OWASP. https://genai.owasp.org/2025/12/18/evolving-ai-transparency-the-journey-of-the-aibom-generator-and-its-new-home-at-owasp/
• OWASP GenAI Security Project. (2026). OWASP Top 10 for Agentic Applications (2026). https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
• Python Package Index. (2024, December 11). Supply-chain attack analysis: Ultralytics. PyPI Blog. https://blog.pypi.org/posts/2024-12-11-ultralytics-attack-analysis/
• PyTorch Foundation. (2022, December 31). Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022. https://pytorch.org/blog/compromised-nightly-dependency/
• Saraf, I., & Balassiano, O. (2025, September 3). Model namespace reuse: An AI supply-chain attack exploiting model name trust. Unit 42, Palo Alto Networks. https://unit42.paloaltonetworks.com/model-namespace-reuse/
• Spracklen, J., Wijewickrama, R., Sakib, A. H. M. N., Maiti, A., Viswanath, B., & Jadliwala, M. (2025). We have a package for you! A comprehensive analysis of package hallucinations by code generating LLMs. In Proceedings of the 34th USENIX Security Symposium (USENIX Security 25). USENIX Association. https://www.usenix.org/system/files/usenixsecurity25-spracklen.pdf [also cited in LLM07]
• Tamari, S., & Tzadik, S. (2024, April 4). Wiz Research finds architecture risks that may compromise AI-as-a-Service providers. Wiz. https://www.wiz.io/blog/wiz-and-hugging-face-address-risks-to-ai-infrastructure
• Wickens, E., Schulz, K., & Bonner, T. (2024, October 10). ShadowLogic: Persistent no-code backdoors in AI computational graphs. HiddenLayer. https://hiddenlayer.com/innovation-hub/shadowlogic/
• Wiz. (2024). Probllama: Ollama remote code execution vulnerability (CVE-2024-37032). https://www.wiz.io/blog/probllama-ollama-vulnerability-cve-2024-37032
• Zanki, K. (2025, February 6). Malicious ML models discovered on Hugging Face platform (nullifAI). ReversingLabs. https://www.reversinglabs.com/blog/rl-identifies-malware-ml-model-hosted-on-hugging-face
• Zhan, Q., Fang, R., Bindu, R., Gupta, A., Hashimoto, T., & Kang, D. (2023). Removing RLHF protections in GPT-4 via fine-tuning (arXiv:2311.05553). arXiv. https://arxiv.org/abs/2311.05553

LLM05: 数据与模型投毒(Data and Model Poisoning)

• OWASP CycloneDX. (n.d.). Machine learning bill of materials (AI/ML-BOM). Retrieved July 11, 2026, from https://cyclonedx.org/capabilities/mlbom/ [also cited in LLM04]
• DVC. (n.d.). DVC: Data version control [Documentation]. https://dvc.org/doc
• F5. (2025). Data and model poisoning [OWASP Top 10 for LLM applications guide (2025)]. https://my.f5.com/manage/s/article/K000149782
• Fogel, A., Hofman, O., Cohen, E., & Vainshtein, R. (2026). Inference-time backdoors via chat templates: From LLM supply chains to agentic system compromise (arXiv:2602.04653). arXiv. https://arxiv.org/abs/2602.04653
• GitHub. (2026, March 26). Giskard Agents have server-side template injection via ChatWorkflow.chat() using non-sandboxed Jinja2 Environment (GHSA-frv4-x25r-588m). GitHub Advisory Database. https://github.com/advisories/GHSA-frv4-x25r-588m
• Hubinger, E., Denison, C., Mu, J., Lambert, M., Tong, M., MacDiarmid, M., Lanham, T., Ziegler, D. M., Maxwell, T., Cheng, N., Jermyn, A., Askell, A., Radhakrishnan, A., Anil, C., Duvenaud, D., Ganguli, D., Barez, F., Clark, J., Ndousse, K., … Perez, E. (2024). Sleeper agents: Training deceptive LLMs that persist through safety training (arXiv:2401.05566). arXiv. https://arxiv.org/abs/2401.05566
• JFrog Security Research. (n.d.). GGUF-SSTI. https://research.jfrog.com/model-threats/gguf-ssti/
• MITRE. (n.d.). MITRE ATLAS: Adversarial threat landscape for artificial-intelligence systems. https://atlas.mitre.org
• National Institute of Standards and Technology. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). https://www.nist.gov/itl/ai-risk-management-framework
• Souly, A., Rando, J., Chapman, E., Davies, X., Hasircioglu, B., Shereen, E., Mougan, C., Mavroudis, V., Jones, E., Hicks, C., Carlini, N., Gal, Y., & Kirk, R. (2025). Poisoning attacks on LLMs require a near-constant number of poison samples (arXiv:2510.07192). arXiv. https://arxiv.org/abs/2510.07192
• Zhang, B., Chen, Y., Liu, Z., Nie, L., Li, T., Liu, Z., & Fang, M. (2025). Practical poisoning attacks against retrieval-augmented generation (arXiv:2504.03957). arXiv. https://arxiv.org/abs/2504.03957

LLM06: 无界消耗(Unbounded Consumption)

• Akkus, A. (2024, December 27). You wouldn't download an AI: Extracting AI models from mobile apps. Altay's Blog. https://altayakkus.substack.com/p/you-wouldnt-download-an-ai
• Anthropic. (n.d.). Vision [Build with Claude documentation]. Retrieved July 11, 2026, from https://docs.anthropic.com/en/docs/build-with-claude/vision
• Awan, A. A. (2023, March 24). How watermarking can help mitigate the potential risks of LLMs? KDnuggets. https://www.kdnuggets.com/2023/03/watermarking-help-mitigate-potential-risks-llms.html
• Carlini, N., Paleka, D., Dvijotham, K. D., Steinke, T., Hayase, J., Cooper, A. F., Lee, K., Jagielski, M., Nasr, M., Conmy, A., Yona, I., Wallace, E., Rolnick, D., & Tramèr, F. (2024). Stealing part of a production language model (arXiv:2403.06634). arXiv. https://arxiv.org/abs/2403.06634 [also cited in LLM02]
• DeepLearning.AI. (2023, March 15). Runaway LLaMA: How Meta's LLaMA NLP model leaked. The Batch. https://www.deeplearning.ai/the-batch/how-metas-llama-nlp-model-leaked/
• Dong, B., Feng, H., & Wang, Q. (2026). Clawdrain: Exploiting tool-calling chains for stealthy token exhaustion in OpenClaw agents (arXiv:2603.00902). arXiv. https://arxiv.org/abs/2603.00902
• Gao, H., Zhang, Y., Zhou, Z., Jiang, L., Meng, F., Xiao, Y., Sun, L., Wang, K., Liu, Y., & Feng, J. (2025). Resource consumption red-teaming for large vision-language models (arXiv:2507.18053). arXiv. https://arxiv.org/abs/2507.18053
• Gao, K., Pang, T., Du, C., Yang, Y., Xia, S.-T., & Lin, M. (2024). Denial-of-service poisoning attacks against large language models (arXiv:2410.10760). arXiv. https://arxiv.org/abs/2410.10760
• Jiang, W., Li, H., Xu, G., Zhang, T., & Lu, R. (2024). A comprehensive defense framework against model extraction attacks. IEEE Transactions on Dependable and Secure Computing, 21(2), 685–700. https://ieeexplore.ieee.org/document/10080996
• Li, Y., Wang, J., Zhu, H., Lin, J., Chang, S., & Guo, M. (2025). ThinkTrap: Denial-of-service attacks against black-box LLM services via infinite thinking (arXiv:2512.07086). arXiv. https://arxiv.org/abs/2512.07086
• moohax, & monoxgas. (2023, March 31). Proof Pudding (CVE-2019-20634) (AVID-2023-V009). AI Vulnerability Database. https://avidml.org/database/avid-2023-v009/
• Nevo, S., Lahav, D., Karpur, A., Bar-On, Y., Bradley, H. A., & Alstott, J. (2024). Securing AI model weights: Preventing theft and misuse of frontier models (RR-A2849-1). RAND Corporation. https://www.rand.org/content/dam/rand/pubs/research_reports/RRA2800/RRA2849-1/RAND_RRA2849-1.pdf
• Radosevich, B., & Halloran, J. (2025). MCP safety audit: LLMs with the Model Context Protocol allow major security exploits (arXiv:2504.03767). arXiv. https://arxiv.org/abs/2504.03767
• Sev, C. (2023, August 30). Security update: Incident involving unauthorized admin access. Sourcegraph. https://about.sourcegraph.com/blog/security-update-august-2023
• Shumailov, I., Zhao, Y., Bates, D., Papernot, N., Mullins, R., & Anderson, R. (2020). Sponge examples: Energy-latency attacks on neural networks (arXiv:2006.03463). arXiv. https://arxiv.org/abs/2006.03463
• Taori, R., Gulrajani, I., Zhang, T., Dubois, Y., Li, X., Guestrin, C., Liang, P., & Hashimoto, T. B. (2023, March 13). Alpaca: A strong, replicable instruction-following model. Stanford Center for Research on Foundation Models. https://crfm.stanford.edu/2023/03/13/alpaca.html

LLM07: 错误信息(Misinformation)

• National Institute of Standards and Technology. (2024). Artificial intelligence risk management framework: Generative artificial intelligence profile (NIST AI 600-1). U.S. Department of Commerce. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
• OpenAI. (2025, September 5). Why language models hallucinate. https://openai.com/index/why-language-models-hallucinate/
• OWASP Gen AI Security Project. (2025). LLM09:2025 Misinformation. https://genai.owasp.org/llmrisk/llm092025-misinformation/
• Spracklen, J., Wijewickrama, R., Sakib, A. H. M. N., Maiti, A., Viswanath, B., & Jadliwala, M. (2025). We have a package for you! A comprehensive analysis of package hallucinations by code generating LLMs. In Proceedings of the 34th USENIX Security Symposium (USENIX Security 25). USENIX Association. https://www.usenix.org/system/files/usenixsecurity25-spracklen.pdf [also cited in LLM04]
• Zou, W., Geng, R., Wang, B., & Jia, J. (2025). PoisonedRAG: Knowledge corruption attacks to retrieval-augmented generation of large language models. In Proceedings of the 34th USENIX Security Symposium (USENIX Security 25). USENIX Association. https://www.usenix.org/system/files/usenixsecurity25-zou-poisonedrag.pdf [also cited in LLM01, LLM09]

LLM08: 隐藏上下文暴露(Hidden Context Exposure)

• Cao, B., Li, C., Cao, Y., Ge, Y., Wang, T., & Chen, J. (2025). You can't steal nothing: Mitigating prompt leakages in LLMs via system vectors. arXiv. https://arxiv.org/abs/2509.21884
• Das, B. C., Amini, M. H., & Wu, Y. (2025). System prompt extraction attacks and defenses in large language models. arXiv. https://arxiv.org/abs/2505.23817
• Goffin, J. (2025, July). Proof of concept: Dangers of system prompt leakage. Resk. https://resk.fr/pdf/resk-enterprise-ai-security-guide.pdf
• Hui, B., Yuan, H., Gong, N., Burlina, P., & Cao, Y. (2024). PLeak: Prompt leaking attacks against large language model applications. arXiv. https://arxiv.org/abs/2405.06823
• jujumilk3. (2025). Leaked system prompts [GitHub repository]. GitHub. https://github.com/jujumilk3/leaked-system-prompts
• LeakHub. (n.d.). LeakHub [Website]. Retrieved July 11, 2026, from https://leakhub.ai/
• Li, Z., Guo, J., & Cai, H. (2025). System prompt poisoning: Persistent attacks on large language models beyond user injection. arXiv. https://arxiv.org/abs/2505.06493
• Nie, Y., Wang, Z., Yu, Y., Wu, X., Zhao, X., Guo, W., & Song, D. (2024). LeakAgent: RL-based red-teaming agent for LLM privacy leakage. arXiv. https://arxiv.org/abs/2412.05734
• Zheng, X., Wu, Y., Huang, H., Li, Y., Ma, X., Li, B., Jiang, Y.-G., & Wang, C. (2026). Just ask: Curious code agents reveal system prompts in frontier LLMs. arXiv. https://doi.org/10.48550/arXiv.2601.21233

LLM09: 向量与嵌入弱点(Vector and Embedding Weaknesses)

• Chaudhari, H., Severi, G., Abascal, J., Suri, A., Jagielski, M., Choquette-Choo, C. A., Nasr, M., Nita-Rotaru, C., & Oprea, A. (2024). Phantom: General backdoor attacks on retrieval augmented language generation (arXiv:2405.20485). arXiv. https://arxiv.org/abs/2405.20485
• Chen, Y., Xu, Q., & Bjerva, J. (2025). ALGEN: Few-shot inversion attacks on textual embeddings via cross-model alignment and generation. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). Association for Computational Linguistics. https://aclanthology.org/2025.acl-long.1185/
• Chen, Z., Xiang, Z., Xiao, C., Song, D., & Li, B. (2024). AgentPoison: Red-teaming LLM agents via poisoning memory or knowledge bases (arXiv:2407.12784). arXiv. https://arxiv.org/abs/2407.12784
• Ha, H., Zhan, Q., Kim, J., Bralios, D., Sanniboina, S., Peng, N., Chang, K.-W., Kang, D., & Ji, H. (2025). MM-PoisonRAG: Disrupting multimodal RAG with local and global poisoning attacks (arXiv:2502.17832). arXiv. https://arxiv.org/abs/2502.17832
• Kim, D., Kang, D., Lee, K., Baek, H., & Kang, B. B. (2026). Zero2Text: Zero-training cross-domain inversion attacks on textual embeddings (arXiv:2602.01757). arXiv. https://arxiv.org/abs/2602.01757
• Li, H., Xu, M., & Song, Y. (2023). Sentence embedding leaks more information than you expect: Generative embedding inversion attack to recover the whole sentence (arXiv:2305.03010). arXiv. https://arxiv.org/abs/2305.03010
• Liu, Y., Yuan, Z., Tie, G., Shi, J., Zhou, P., Sun, L., & Gong, N. Z. (2025). Poisoned-MRAG: Knowledge poisoning attacks to multimodal retrieval augmented generation (arXiv:2503.06254). arXiv. https://arxiv.org/abs/2503.06254
• MITRE. (n.d.). RAG poisoning (AML.T0070) [Technique]. MITRE ATLAS. https://atlas.mitre.org/techniques/AML.T0070
• Morris, J. X., Kuleshov, V., Shmatikov, V., & Rush, A. M. (2023). Text embeddings reveal (almost) as much as text (arXiv:2310.06816). arXiv. https://arxiv.org/abs/2310.06816
• Shafran, A., Schuster, R., & Shmatikov, V. (2025). Machine against the RAG: Jamming retrieval-augmented generation with blocker documents. In 34th USENIX Security Symposium (USENIX Security 25). USENIX Association. https://www.usenix.org/conference/usenixsecurity25/presentation/shafran
• Shereen, E., Ristea, D., McFadden, S., Hasircioglu, B., Mavroudis, V., & Hicks, C. (2025). One pic is all it takes: Poisoning visual document retrieval augmented generation with a single image (arXiv:2504.02132). arXiv. https://arxiv.org/abs/2504.02132
• Song, C., & Raghunathan, A. (2020). Information leakage in embedding models (arXiv:2004.00053). arXiv. https://arxiv.org/abs/2004.00053
• Tan, X., Luan, H., Luo, M., Sun, X., Chen, P., & Dai, J. (2025). RevPRAG: Revealing poisoning attacks in retrieval-augmented generation through LLM activation analysis. In Findings of the Association for Computational Linguistics: EMNLP 2025. Association for Computational Linguistics. https://aclanthology.org/2025.findings-emnlp.698/
• Wang, F., Wan, X., Sun, R., Chen, J., & Arık, S. Ö. (2024). Astute RAG: Overcoming imperfect retrieval augmentation and knowledge conflicts for large language models (arXiv:2410.07176). arXiv. https://arxiv.org/abs/2410.07176
• Wu, G., Wang, T., Zhang, Y., Zhang, Z., Niu, J., Wu, Y., & Zhang, Y. (2026). When cache poisoning meets LLM systems: Semantic cache poisoning and its countermeasures. In Proceedings of the 2026 Network and Distributed System Security Symposium (NDSS). Internet Society. https://www.ndss-symposium.org/ndss-paper/when-cache-poisoning-meets-llm-systems-semantic-cache-poisoning-and-its-countermeasures/
• Xue, J., Zheng, M., Hu, Y., Liu, F., Chen, X., & Lou, Q. (2024). BadRAG: Identifying vulnerabilities in retrieval augmented generation of large language models (arXiv:2406.00083). arXiv. https://arxiv.org/abs/2406.00083
• Zhang, C., Morris, J. X., & Shmatikov, V. (2025). Universal zero-shot embedding inversion (arXiv:2504.00147). arXiv. https://arxiv.org/abs/2504.00147
• Zhang, Z., Liu, Z., Xie, Y., Huang, Q., & She, D. (2026). From similarity to vulnerability: Key collision attack on LLM semantic caching (arXiv:2601.23088). arXiv. https://arxiv.org/abs/2601.23088
• Zou, W., Geng, R., Wang, B., & Jia, J. (2025). PoisonedRAG: Knowledge corruption attacks to retrieval-augmented generation of large language models. In Proceedings of the 34th USENIX Security Symposium (USENIX Security 25). USENIX Association. https://www.usenix.org/system/files/usenixsecurity25-zou-poisonedrag.pdf [also cited in LLM01, LLM07]

LLM10: 输出处理不当(Improper Output Handling)

• diskordia. (2025, July 24). Inside CVE-2025-32711 (EchoLeak): Prompt injection meets AI exfiltration. Hack The Box. https://www.hackthebox.com/blog/cve-2025-32711-echoleak-copilot-vulnerability
• Klondike, G. (2023, June 6). Threat modeling LLM applications. AI Village. https://aivillage.org/blog/threat-modeling-llm/
• The MITRE Corporation. (2026). CWE-116: Improper encoding or escaping of output (Common Weakness Enumeration List Version 4.20). https://cwe.mitre.org/data/definitions/116.html
• OWASP. (2026). C7: Model behavior, output control and safety assurance (AI Security Verification Standard Version 1.0). https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C07-Model-Behavior.md
• OWASP. (n.d.). V5: Validation, sanitization and encoding (Application Security Verification Standard 4.0). Retrieved July 11, 2026, from https://owasp-aasvs4.readthedocs.io/en/latest/V5.html#validation-sanitization-and-encoding
• Porat, Y. (2025, December 25). All I want for Christmas is your secrets: LangGrinch hits LangChain Core (CVE-2025-68664). Cyata. https://cyata.ai/blog/langgrinch-langchain-core-cve-2025-68664/
• PortSwigger. (n.d.). Lab: Exploiting insecure output handling in LLMs. Web Security Academy. Retrieved July 11, 2026, from https://portswigger.net/web-security/llm-attacks/lab-exploiting-insecure-output-handling-in-llms
• Rehberger, J. [wunderwuzzi]. (2024a, June 14). GitHub Copilot Chat: From prompt injection to data exfiltration. Embrace The Red. https://embracethered.com/blog/posts/2024/github-copilot-chat-prompt-injection-data-exfiltration/
• Rehberger, J. [wunderwuzzi]. (2024b, December 6). Terminal DiLLMa: LLM-powered apps can hijack your terminal via prompt injection. Embrace The Red. https://embracethered.com/blog/posts/2024/terminal-dillmas-prompt-injection-ansi-sequences/
• Rehberger, J. [wunderwuzzi]. (2025, August 12). GitHub Copilot: Remote code execution via prompt injection (CVE-2025-53773). Embrace The Red. https://embracethered.com/blog/posts/2025/github-copilot-remote-code-execution-via-prompt-injection/ [also cited in LLM01]
• Willison, S. (n.d.). Markdown exfiltration [Tag archive]. Simon Willison's Weblog. Retrieved July 11, 2026, from https://simonwillison.net/tags/markdown-exfiltration/