3.1 OWASP 大语言模型十大风险解析
开放式 Web 应用安全项目（OWASP）发布的 LLM Top 10 是业界常用的 LLM 应用安全风险清单之一。
版本说明：本节基于 OWASP Top 10 for LLM Applications 2025 进行解读；后续版本请以 OWASP 官方页面为准（见附录 C-38）。
3.1.1 OWASP 与 LLM Top 10 背景
OWASP 是非营利安全社区组织，长期维护 Web 安全、API 安全与 AI 安全相关实践。 LLM Top 10 的价值在于：把”模型风险”转译成”应用系统风险”，便于工程团队落地治理。
十大风险不是孤立清单，而是一个系统的攻击链
阅读下面的十个风险项时，重要的是理解它们之间的相互关联，而非将其视为独立的检查清单。在真实的安全事件中，多个风险往往协同作用：
提示注入（LLM01） 是众多攻击的”突破口”，它可能导致系统提示泄露（LLM07）、过度自主权的触发（LLM06）、甚至恶意工具调用
敏感信息泄露（LLM02） 常常是提示注入成功后的”后果”，攻击者获得控制权后第一步就是套出隐私数据
供应链风险（LLM03） 和 数据投毒（LLM04） 虽然风险概率较低，但一旦发生就会”污染源头”，影响所有下游应用
输出处理不当（LLM05） 和 过度自主权（LLM06） 联手，使得恶意的 LLM 输出能直接化为破坏性操作
向量与嵌入弱点（LLM08） 和 错误信息（LLM09） 在 RAG 系统中形成”垃圾进，垃圾出”的恶性循环
实际的安全架构设计需要从这个全景视角出发，构建多层防御来割断这些风险链条。具体的防御策略将在 第4-7章 逐一讲述。
2025 版风险条目（官方页面）
LLM01
提示注入
Prompt Injection
LLM02
敏感信息泄露
Sensitive Information Disclosure
LLM03
供应链风险
Supply Chain
LLM04
数据与模型投毒
Data and Model Poisoning
LLM05
输出处理不当
Improper Output Handling
LLM06
过度自主权
Excessive Agency
LLM07
系统提示泄露
System Prompt Leakage
LLM08
向量与嵌入弱点
Vector and Embedding Weaknesses
LLM09
错误信息
Misinformation
LLM10
无边界消耗
Unbounded Consumption
与早期版本相比，部分条目在命名上更强调“应用层可控风险”，读者应关注风险内核，不要只记忆编号。
3.1.2 LLM01：提示注入
为什么提示注入排在首位？
提示注入是 LLM 应用的"根本性"威胁。不同于传统 Web 应用的 SQL 注入需要"发现可注入点"，LLM 的交互接口本身就是接收指令的地方，这意味着任何与用户通信的接口都潜在可被利用。一旦提示注入成功，攻击者获得了对模型执行流的控制权，进而可以：
泄露系统提示、训练数据、或模型架构信息（导致后续的 LLM07 和 LLM02）
诱导模型调用有害工具或执行越权操作（导致 LLM06）
污染知识库或返回的信息（导致 LLM09）
因此，提示注入防御是整个安全体系的基座。
风险描述：攻击者通过恶意指令影响模型执行路径，绕过系统规则。
典型场景：直接注入、间接注入、工具返回注入。
防护思路
提示注入防护的核心思路是"分层隔离"——在架构上将"系统规则（不信任用户可改写）"与"用户数据（明确标记其来源）"分离。这样，即使用户输入包含恶意指令，模型也能通过"来源标记"识别出这不是系统约束，而是用户提供的信息。同时，对于从外部系统（如网页、文档）返回的内容，更应该建立特殊的检测与沙箱化处理。
防护重点
指令层与数据层分离：系统提示明确标记"用户数据边界"，使模型理解哪些是约束、哪些是输入
外部内容来源标记与降权：对来自 RAG、Web 搜索等外部渠道的内容降低权重，防止污染指令
工具调用前置策略校验：在模型调用工具前，用独立的分类器或规则引擎进行意图验证
核心控制与审计要求
核心控制：部署独立的安全网关（分类器）与严格的输入输出分离架构。
审计证据：提示注入回归测试报告（ASR < 2%）、带
confidence字段的网关拦截日志。
3.1.3 LLM02：敏感信息泄露
与 LLM01 的关系：从"破口"到"后果"
如果说提示注入是攻击者的"破口"，那么敏感信息泄露就是最常见的"后果"。攻击者获得控制权后，首先想到的就是套出隐私数据、系统秘密或其他用户信息。与此同时，即使没有成功的注入攻击，模型在正常运行中也可能因为：
训练数据记忆泄露
上下文与日志处理不当
多租户隔离缺陷
而无意中向用户暴露敏感信息。因此，敏感信息泄露防护是两层的：一是通过提示注入防御减少被"套取"的风险，二是通过输出侧的脱敏和 DLP 措施防止"无意泄露"。
风险描述：模型输出或上下文处理过程泄露隐私、密钥、系统细节或跨租户数据。
泄露路径：训练记忆泄露、上下文回显、日志误采集、系统提示泄露。
防护思路
敏感信息泄露防护需要"双向夹击"：一是在输入侧，通过脱敏和 PII 检测防止敏感数据被无意中送入 LLM；二是在输出侧，通过 DLP 和脱敏规则防止 LLM 的输出包含机密信息。在多租户场景下，还需要在存储、索引和日志层面进行严格的隔离，确保一个用户的信息不会"串"到另一个用户的上下文。关键是建立"最小信息原则"——只向 LLM 提供完成当前任务所需的最少敏感数据。
防护重点
输入输出双向脱敏：清洁入站数据，审计出站内容，防止泄露
多租户隔离与最小留存：存储中用户数据物理隔离，日志中敏感内容加密存储和自动清理
敏感字段检测与审计告警：自动识别 PII、密钥等特定字段，触发审计和隔离处理
核心控制与审计要求
核心控制：部署数据防泄漏（DLP）探针扫描双向流量，关键接口禁止返回裸数据。
审计证据：静态代码扫描（无硬编码凭证）报告、DLP 检测规则库清单及高敏脱敏（Redaction）拦截日志。
3.1.4 LLM03：供应链风险
风险链的"上游"威胁
前面的 LLM01 和 LLM02 都是"运行时"风险，而供应链风险来自更前面的阶段——在模型和应用还未上线时，污染就已经开始植入。供应链风险的特点是"广泛性和隐蔽性"：一个被污染的预训练模型或数据集可以影响数千个下游应用，而且很难在事后被发现。因此，供应链安全应该放在整个安全体系的最前端，从"源头把关"而非"事后补救"。
风险描述：模型、数据集、依赖库、插件、镜像、推理服务任一环节被污染都可影响系统。
防护思路
供应链安全的核心是"源头认证"和"全链路追踪"。在持续集成流水线中，从模型拉取、依赖下载到容器镜像构建，每一步都应该有校验机制——通过签名验证确保来源真实，通过 SBOM（软件物料清单）追踪每个依赖的版本和漏洞状态。此外，当发现供应链污染时，必须能快速识别受影响的下游应用并进行紧急响应。
防护重点
来源可追溯（签名/校验）：使用 Sigstore、TUF 等工具验证模型和依赖的真实性
依赖锁定与漏洞扫描：在构建时锁定依赖版本，定期扫描已知漏洞（CVE）
SBOM 与变更审计：为每个部署生成 SBOM，记录完整的变更链条便于事后追溯
核心控制与审计要求
核心控制：在 CI/CD 流水线强制阻断高危漏洞依赖，仅从受信任私有仓拉取模型组件。
审计证据：带有供应链漏洞（CVE）扫描记录的 SBOM 文件、镜像签名校验记录。
3.1.5 LLM04：数据与模型投毒
"污染源头"的深层威胁
如果说 LLM03 是防止外来污染源（第三方模型、依赖），那么 LLM04 则是防止内部污染——攻击者可能通过污染你自己的训练数据、微调数据或 RAG 知识库来长期改变系统行为。这种攻击的可怕之处在于：
潜伏性强：植入的"后门"或偏差可能在数周甚至数月后才被发现
难以根治：需要重新清洗数据和重新训练，成本极高
难以追溯：如果数据来自众多外部贡献者或网络爬取，找到污染源头困难重重
因此，数据投毒防护的关键是事前验证和事中监控，而不是事后救补。
风险描述：攻击者污染训练/微调/检索数据或模型工件，诱导系统长期偏离预期行为。
防护思路
数据投毒防护的难点在于"隐蔽性"——有害样本往往看起来无害，需要通过统计异常检测或行为基线比对来识别。因此，防护策略应该分为"事前"和"事中"两层：事前通过严格的数据来源审核和清洗减少污染概率，事中通过模型行为监控和 A/B 对比发现变异。一旦发现投毒，需要能快速回滚到已知安全的模型版本。
防护重点
数据摄入白名单与分级审核：建立受信任的数据来源清单，对新增数据进行内容和来源审核
异常样本检测与回滚机制：使用统计异常检测识别可疑样本，部署快速回滚流程
模型版本基线与行为回归测试：维护历史版本，定期运行回归测试套件验证模型输出分布的稳定性
核心控制与审计要求
核心控制：对训练数据及 RAG 知识库入库实施严格清洗、隔离和溯源机制。
审计证据：数据清洗规则文档、包含来源（Provenance）标签的数据集索引快照。
3.1.6 LLM05：输出处理不当
从"LLM 控制权"到"系统破坏权"的桥梁
前面的 LLM01-LLM04 涉及的是对"LLM 模型本身"的控制或污染，而 LLM05 则是这个控制权的"终端化"——即使 LLM 的输出不直接是有害的，但如果这个输出被下游系统当作"代码"或"命令"来执行，就会化为现实的破坏。特别是在 Agent 和工具调用场景中，LLM 的输出直接变成了：
数据库查询语句（SQL 注入）
系统命令（命令执行）
文件路径（路径遍历）
API 调用参数（二阶注入）
这意味着 LLM 的防御不能只关注"LLM 层"，还必须在下游系统建立强制的"参数化"和"白名单"执行方式，这是传统 Web 应用安全的基本原则，在 LLM 时代更加重要。
风险描述：将 LLM 输出直接用于 SQL、Shell、模板渲染或 API 参数，触发传统安全漏洞。
防护思路
这是一个经典的"信任边界漏洞"——LLM 的输出被下游系统当作"代码"而非"数据"。防护这个风险的核心原则是传统 Web 安全中的参数化，即使 LLM 输出看起来"合理"，也不应该直接拼接成命令。对于高危操作（如数据库修改、文件删除、外部 API 调用），还应该加入人在回路（HITL）的二次确认，确保模型生成的操作确实符合用户意图。
防护重点
输出永不直连执行面：所有 LLM 输出都经过参数化处理，永不直接进入 SQL 引擎、Shell 或模板渲染
参数化调用与 schema 校验：使用白名单限制可用的工具和参数范围，生成的参数必须通过 schema 验证
高危操作二次确认：修改、删除等破坏性操作需要用户明确的、脱离上下文的确认
核心控制与审计要求
核心控制：在 LLM 输出与系统执行组件之间构建强制数据断层（参数化校验），高危指令实施 HITL 拦截。
审计证据：编排层沙箱执行日志、越界参数被拒（Reject）告警记录。
3.1.7 LLM06：过度自主权
权限失控的加速器
LLM05 谈的是"技术层面的安全漏洞"，但 LLM06 则是"权限层面的滥用"。随着 Agent 技术的普及，LLM 被赋予了越来越多的"能力"——调用外部 API、访问数据库、发送邮件、修改文件等。这些能力本身无关安全，但问题在于：
权限矩阵爆炸：100 个工具的排列组合可以产生极高的风险组合
人工审查失效：无法逐一审查每个潜在的权限链
缺乏运行时约束：给 LLM 的权限往往是静态的、"要么全有，要么全无"
因此，LLM06 的防护不仅需要权限设计的精细化（RBAC），更需要运行时的动态收敛——在每个请求时刻，根据上下文和意图，动态地限制 LLM 当前可用的权限。这与传统应用的"连接时拿到所有权限"的设计思路完全不同。
风险描述：智能体被授予过多权限后，可能执行越权调用、批量外发或破坏性操作。
防护思路
过度自主权问题根本上源于"给与"和"使用"的不对称——权限设计时是"长期、静态、宽泛的"，但执行时应该是"当前、动态、最小化的"。在 Agent 架构中，需要从多个维度进行权限约束：
功能维度：定义每个 Agent 的能力范围（调用哪些工具）
参数维度：限制工具参数的有效范围（只能操作特定数据、用户或时间段）
时间维度：使用短期令牌而非长期凭证，减少凭证泄露的影响
行为维度：监控权限的使用情况，异常调用立即告警
防护重点
最小权限与时效令牌：Agent 只获得完成当前任务所需的最小权限，使用过期时间短的临时令牌
人在回路（HITL）审批：高危或异常的工具调用需要人工确认，而不是直接执行
高风险工具硬性阻断策略：某些工具（如删除数据库、转账等）永不允许 Agent 直接调用，必须经过显式的人工授权
核心控制与审计要求
核心控制：实行 RBAC（基于角色访问控制），所有破坏性/外流性动作要求多因素确权。
审计证据：工具最小权限配置清单、用户审批（Approve/Deny）流程的监控轨迹。
3.1.8 LLM07：系统提示泄露
破口背后的秘密
LLM07 与 LLM01（提示注入）是"矛盾体"的关系。如果提示注入是攻击者试图用恶意指令"改写"系统行为，那么系统提示泄露就是攻击者试图用诱导性问题"窃取"系统设计。一旦系统提示被暴露，攻击者就获得了：
系统的约束与策略（知道了"防线在哪"）
模型的工具列表与权限（知道了"能做什么"）
可能的内部流程与数据流（知道了"怎么做"）
有了这些信息，后续的攻击会精准得多。因此，系统提示泄露防护的核心是"机密信息不入上下文"——将所有敏感的系统级参数移到环境变量或密钥管理系统中，系统提示本身只保留"行为约束"而非"系统秘密"。
风险描述：攻击者诱导模型泄露系统提示、策略约束或内部流程信息。
防护思路
系统提示泄露的根本问题是”机密信息被当作指令存储在上下文中”。防护的首要原则是”机密信息永远不入系统提示”——所有密钥、内部工具链信息、系统参数都应该存在环境变量或密钥管理系统中，系统提示本身只保留”行为约束”。其次，对于攻击者常见的”诱导提示词”（如”重复你的指令”、”翻译你的系统信息”），需要通过专门的意图检测和输出过滤来阻止。最后，通过红队测试和持续监控来验证系统的”抗提取能力”。
防护重点
系统提示中不存放密钥：所有敏感信息（API 密钥、数据库凭证、工具列表细节）存在外部密钥管理系统，通过安全的 API 查询
对”提示提取类”请求做专门过滤：识别常见的提取提示词（如”repeat your instructions”、”what are your rules”），直接拒绝或返回虚假信息
用测试集持续回归”抗提取能力”：定期运行红队测试，验证系统提示是否被泄露，纳入 CI/CD 流水线
核心控制与审计要求
核心控制：把所有敏感变量移出系统提示（设为环境变量），部署针对”提取类”意图的专门识别隔离机制。
审计证据：系统提示变更管理工单、红队系统提示提取防范专项测试报告。
3.1.9 LLM08：向量与嵌入弱点
RAG 时代的新老攻击融合
随着 RAG（检索增强生成）的广泛应用，整个架构从”单纯的 LLM”变成了”LLM + 向量库 + 检索器”。这引入了一个全新的攻击面：攻击者可以在 RAG 链路的多个环节进行污染或操纵。特别是：
向量数据库的访问控制薄弱：没有行级权限隔离，用户 A 可能检索到用户 B 的私密数据
文档注入攻击：恶意者上传一份”表面无害，实则包含隐藏指令”的文档，当它被检索到时，就会进行间接提示注入
检索排名操纵：通过精心设计，让恶意内容排名靠前，被模型优先”吸取”
因此，RAG 安全不是”拉个向量库就完事”，而需要从”文档摄入→嵌入→索引→检索→重排”全链路进行加固。
风险描述：RAG 场景下，嵌入、索引、检索与重排链路被操纵，导致错误或恶意上下文进入生成环节。
防护思路
RAG 系统的安全性取决于其最薄弱的环节。从文档上传到最终生成的整条链路都需要加固：
文档摄入阶段需要内容审核和注入检测，防止恶意文档植入
嵌入和索引阶段需要确保数据的机密性和完整性
检索阶段需要行级权限隔离，防止跨用户数据泄露
重排阶段需要评估检索结果的可信度，防止恶意内容排名靠前
防护重点
向量库访问控制与加密：对向量数据库实施细粒度（行级）的访问控制，确保用户只能检索其权限范围内的数据；数据加密存储
检索结果可信度评估：对检索到的文档进行相关性和可信度评分，低于阈值的结果不进入 LLM 上下文
文档摄入阶段注入扫描：上传的文档经过内容检查和提示注入检测，确保不包含恶意指令
核心控制与审计要求
核心控制：给向量数据库加持身份验证及行级（Row-level）访问控制，确保用户仅能检索自己有权查阅的语料块。
审计证据：向量数据库访问隔离策略文档、RAG 命中分数的监控分布告警指标。
3.1.10 LLM09：错误信息
"有理有据"的谎言
与前面几个风险不同，LLM09 不是"被攻击"或"被污染"导致的，而是 LLM 的"本质属性"——大语言模型在学习过程中必然会学到"虚假的、过时的、或片面的"信息，有时甚至会"凭空编造"听起来很真实的内容。这对金融建议、医疗信息、法律意见等高敏场景构成直接威胁。关键是：
虚假内容可能被用户全盘接受，因为 LLM 说得条理清晰、甚至"引经据典"
多轮对话放大问题：前一轮的错误会成为下一轮的"背景知识"，错误逐轮扩大
跨链接损伤：一个错的 RAG 检索结果会污染后续的推理
防护 LLM09 的核心思路是**"验证而非信任"**——通过引用溯源、事实性评测、高敏场景的人工复核等手段来补偿 LLM 本身的缺陷。
风险描述：模型输出错误但看似可信的信息，在高敏场景可能造成现实损害。
防护思路
错误信息风险的本质是"LLM 的内在限制"，无法通过架构设计完全消除。防护重点应该在"检测和补偿"：
通过 RAG 强制模型引用具体来源，用户可验证信息的真实性
在金融、医疗、法律等高敏场景，部署事实性验证和人工复核
教导用户理解 LLM 的局限性，对输出保持适度的怀疑态度
防护重点
引用来源与事实核验：强制 LLM 附加检索来源链接，对于关键事实进行自动事实性检验（如金融数据对比、医学文献查证）
高风险域强制人工复核：医疗诊断、法律意见、投资建议等高风险内容必须经过人工审查
不确定性提示与拒答策略：当模型的置信度低于阈值时，主动告知用户"我不确定"或直接拒答，而非编造看似合理的答案
核心控制与审计要求
核心控制：通过检索增强（RAG）强制模型附加出处来源链接，降低置信度阈值主动触发拒答。
审计证据：生成事实性（Factual Correctness）及幻觉率的评测基线打分报告。
3.1.11 LLM10：无边界消耗
"肉体"上的拒绝服务
如果说前面的风险都涉及"控制权"或"信息"的争夺，那么 LLM10 则是最"原始"的方式——直接消耗资源，让服务瘫痪或成本爆炸。LLM 的推理成本高、延迟长的特性使得这个风险特别突出：
Token 洪泛：攻击者可以用几百万个 Token 的请求快速耗尽预算
长上下文压力：现代 LLM 支持 100K-1M Token 的上下文，而成本通常与 Token 数线性相关
复杂推理链：故意构造需要多步推理和多轮工具调用的请求
与传统的 DDoS 不同，LLM 的消耗是"合法的"请求，很难在网络层拦截。防护 LLM10 需要在应用层设置多重的"熔断"和"配额"机制，而不是仅依赖基础设施的防护。
风险描述：攻击者通过高并发、长上下文和高复杂度请求消耗预算与算力。
防护思路
无边界消耗风险的防护需要在多个维度设置"熔断"和"配额"：
在用户维度，限制单个用户的日/月消耗量
在请求维度，限制单个请求的 Token 数、推理步数、工具调用次数
在全局维度，设置总体的成本上限和服务降级策略
关键是"主动设限而非被动超支"——通过提前监控和告警，在成本失控前就采取行动。
防护重点
速率限制与并发配额：对单个用户/IP 实施请求速率限制，防止高并发冲击；对全局 API 设置并发上限
Token/步骤/工具调用上限：每个请求的 Token 数上限，每个 Agent 的推理步数上限，工具调用频率上限
预算告警与自动熔断：实时监控成本消耗，超过阈值时触发告警和自动降级（如降低返回文本长度、停止工具调用等）
核心控制与审计要求
核心控制：在 API 网关实施并发与基于 Token 使用量的细粒度用量熔断机制。
审计证据：API 访问限流（Rate Limit）配置清单、触发阈值（Budget Limit）带来的自动下线告警工单。
3.1.12 OWASP 与 NIST 框架的映射
OWASP LLM Top 10 侧重于应用层的具体风险项，而 NIST AI RMF 提供了更宽泛的管理框架。两个框架可以互补使用，以下为主要映射关系：
LLM01 提示注入
恶意指令通过输入影响模型行为
安全性（Secure）、韧性（Resilient）
LLM02 敏感信息泄露
输出或上下文暴露隐私和密钥
隐私增强、安全性
LLM03 供应链风险
模型/依赖/数据被污染
安全性（保护资产）、可问责性
LLM04 数据与模型投毒
训练数据被污染或植入后门
安全性、有效性与可靠性
LLM05 输出处理不当
LLM 输出直接用于代码/命令执行
安全性、有效性与可靠性
LLM06 过度自主权
智能体权限过大导致越权操作
安全性、可问责性
LLM07 系统提示泄露
攻击者诱导泄露系统提示和内部信息
透明性（受控范围内）、安全性
LLM08 向量与嵌入弱点
RAG 链路被操纵注入错误上下文
安全性、有效性与可靠性
LLM09 错误信息
模型输出虚假但可信的信息
有效性与可靠性、可解释性
LLM10 无边界消耗
高并发/长上下文请求耗尽资源
安全性（DoS 防护）
使用建议
在 战略层，使用 NIST AI RMF 的八项特征指导全面的安全管理体系建设
在 战术层，参考 OWASP LLM Top 10 的具体风险项和控制措施进行日常防御
在 映射层，通过上表关联两个框架，确保 OWASP 的控制项与 NIST 特征对齐
在 审计层，制定既涵盖 OWASP 具体控制点，又体现 NIST 管理特征的评估标准
生产环境中可参考 OWASP LLM Top 10，设计可测试的安全控制项，并纳入日常工程评审与上线流程。
3.1.13 Agent 系统中的 OWASP 风险特化
随着智能体（Agent）和工具调用（Tool Calling）能力的普及，OWASP LLM Top 10 中的某些风险项在 Agent 环境中呈现出新的、更严重的表现形式。以下是 Agent 系统特有的风险强化：
LLM01：提示注入（Agent 强化版）
直接注入：用户提示中的恶意指令
间接注入：工具返回的被污染内容（如网页、文档）
工具链注入：通过精心构造工具参数序列，诱导多个工具协同执行恶意操作
Agent 特有风险：智能体的迭代执行特性意味着单次注入可能通过自反馈循环扩大影响范围
LLM05：输出处理不当（Agent 强化版）
传统风险：LLM 输出直接用于 SQL/Shell 执行
Agent 强化：LLM 生成的工具调用参数直接被执行，工具返回值再次进入 LLM，形成“输出→输入→再输出”的反馈链
关键控制：在 Agent 编排层实施参数白名单、工具调用前置验证、返回值沙箱化处理
LLM06：过度自主权（Agent 强化版）
权限膨胀问题：随着可调用工具数量增加，权限矩阵组合呈指数增长，人工审查变得不可行
Agent 特有防御：采用基于角色的权限模板（RBAC）、动态权限缩减、最小权限执行窗口等方案（详见 7.1.7 节）
工具链权限审计：不仅审计单个工具调用，还要追踪“工具 A 的输出成为工具 B 的输入”时的权限传递
LLM03：供应链风险（Agent 强化版）
插件与连接器风险：Agent 生态中的 MCP Server、OpenAPI 连接器、自定义工具等需要供应链完整性保证
Agent 特有防御：在插件发布和消费流程中实施 SLSA 框架（构建完整性）+ Sigstore 无密钥签名（发布者身份验证）+ Rekor 透明日志（审计追踪）
参考资源：见 8.6.5 Agent 插件的供应链完整性保证
对应 Agent 应用的优先级调整
在 Agent 安全部署中，风险优先级应有所调整：
极高
LLM01（提示注入）+ LLM06（过度自主权）
Agent 的“决策→执行”流程天然放大了这两类风险
高
LLM05（输出处理）+ LLM03（供应链）
工具参数直接执行，供应链中的恶意工具影响范围大
中高
LLM02（敏感泄露）+ LLM08（向量弱点）
Agent 访问多种数据源，信息流转风险增加
中
其他风险项
与单体 LLM 应用风险等级相近
最后更新于