近年来，随着生成式人工智能技术快速演进，以及越来越多企业级应用场景不断涌现，生成式 AI 在企业中的采用速度呈爆发式增长。

然而，大语言模型（LLM）也可能意外生成有害结果、泄露敏感信息，甚至成为攻击者的攻击入口。随着技术不断发展，以及攻击者持续寻找新的系统突破方式，这些安全风险本身也在不断发生变化。

对于企业而言，由此可能带来的后果不仅包括负面舆情，还可能涉及合规风险、网络安全事件、法律责任，甚至集体诉讼。

为了跟进最新的大语言模型安全风险，开放全球应用安全项目（Open Worldwide Application Security Project，OWASP）更新了其 LLM 应用十大关键安全风险（Top 10 Most Critical Vulnerabilities of LLM Applications）。

值得注意的是，这是 OWASP 首次在专家针对 AI 安全风险类别进行投票评估的基础上，同时引入真实世界安全事件数据，对榜单进行综合排序。

关键风险点

在最新版榜单中，提示词注入（Prompt Injection）和敏感信息泄露（Sensitive Information Disclosure）仍然是最严重的两类安全威胁。

与此同时，过度代理权限（Excessive Agency）上升至第三位。这一变化反映了生成式 AI 应用正在从传统聊天机器人快速演进至智能体系统——这些系统不仅能够生成文本，还可以调用 API、执行代码并直接对外部系统采取操作。

此外，无界资源消耗（Unbounded Consumption）等问题的重要性明显上升，而随着输出过滤与清洗机制被更广泛采用，输出处理不当（Improper Output Handling）的排名则下降至榜单末位。

这些变化充分说明，生成式 AI 行业仍处于高速演进阶段。随着新技术不断进入市场，这份榜单未来很可能还会继续发生变化。

OWASP 表示，这份榜单同时融合了两类信息：一类来自实际攻击和防御这些系统的安全从业人员经验，另一类则来自现实世界中已经发生的安全事故记录，并通过交叉验证形成最终结果。

这份榜单的目的不仅是帮助开发者和企业了解潜在的安全风险，同时也希望提供相应的缓解与修复策略，从而改善 LLM 应用整体安全态势。

对于企业而言，这十大风险都值得重点关注，而安全建设可以从排名最高的风险开始逐项推进。

1. 提示词注入（Prompt Injection）

自 OWASP 于 2023 年初首次发布 LLM 十大安全风险以来，提示词注入始终位居榜首。

提示词注入是一种通过恶意构造输入内容，诱导大语言模型在不知情的情况下执行攻击者意图的攻击方式。

这种攻击既包括直接针对模型实施的“越狱（Jailbreaking）”，也包括通过操纵文件、网页等外部输入内容影响模型行为，最终可能导致数据外泄、社会工程攻击以及其他安全问题。

例如，攻击者可以设计特殊提示词，诱骗企业聊天机器人泄露原本无权访问的专有信息；也可以上传包含隐藏指令的文本、图像或音频文件，使应用按照攻击者预期的方式异常运行。

提示词注入还包括跨模态攻击，即攻击者通过不同数据模态操纵工具输出、中间推理过程或持久化记忆，从而达到恶意目的。

为了降低提示词注入风险，OWASP 建议采取以下措施：

• 在系统提示词（System Prompt）中明确限制模型的角色和能力边界。

• 对最敏感的操作引入“人在回路（Human-in-the-loop）”机制，通过额外的人工审批步骤检查是否存在未经授权的操作。

• 定义严格的输出结构（Output Schema），并使用可信的应用程序代码对模型的每一次响应进行验证。

• 对输入和输出中的文本、图像、音频以及结构化数据进行安全扫描，识别恶意或危险内容，并在敏感或未经授权的信息进入模型或返回给用户之前进行阻断。

• 将凭证信息以及能够改变系统状态的能力保留在应用程序代码层，而不是交由模型本身管理，并针对每项操作遵循最小权限原则。

2. 敏感信息泄露（Sensitive Information Disclosure）

敏感信息泄露也常被称为数据泄露（Data Leakage）。

这一风险指的是 LLM 在输出过程中泄露受保护数据、专有算法或其他机密信息，并可能进一步导致未经授权的数据访问、隐私侵犯以及其他安全事件。

敏感数据可能通过多种途径进入大语言模型。

例如，在模型最初的训练过程中，或者后续微调、Embedding（嵌入）过程中，都可能将敏感信息引入模型；用户也可能直接通过提示词向模型提交敏感数据。

一旦模型能够访问这些信息，就有可能被其他未经授权的用户间接获取。

主要防护措施包括：

• 在模型训练和推理过程中采用数据清洗、脱敏等机制，避免 LLM 直接访问敏感数据。

• 对用户输入内容设置过滤机制，防止用户上传敏感信息，或者主动识别并删除、屏蔽其中的机密数据。

• 当 LLM 在推理过程中需要访问外部数据源时，应实施严格的访问控制，并遵循最小权限原则。

3. 过度代理权限（Excessive Agency）

随着智能体系统越来越广泛地进入企业生产环境，过度代理权限已从上一版本榜单的第六位上升至第三位。

所谓过度代理权限，是指 LLM 被授予了过强的实际操作能力。

这一问题通常来源于三个方面：功能过度、权限过高以及监督机制不足。

OWASP 指出，当 LLM 出现幻觉，受到提示词注入攻击、恶意插件影响，遭遇设计不合理的提示词，或者仅仅因为模型本身性能较差时，都可能执行具有破坏性的操作。

AI 云安全厂商 Sysdig 高级网络安全战略专家 Crystal Morin 表示，无论从专家投票还是现实安全事件数据来看，过度代理权限在 OWASP 榜单中的快速上升，都说明业界对于 AI Agent 风险的担忧是有现实依据的。

Morin 表示：

“大语言模型已经从单纯生成文本，发展到能够利用真实权限、访问工具并直接执行操作，这意味着一旦出现问题，其影响范围也将显著扩大。OWASP 更新后的十大风险榜单建立在真实世界证据之上，企业可以利用这些信息，更有针对性地确定当前应用安全工作的优先级。”

Pentest-Tools.com 安全经理 Daniel Bechenea 表示，目前已经有足够多的企业开始让 AI Agent 使用生产环境凭证，因此相关问题也越来越频繁地出现在现实安全事故记录中。

Bechenea 举出了两个具有代表性的案例。

第一个案例发生在 2026 年 4 月。

当时，一个 Cursor 编程智能体正在为 PocketOS 执行预发布环境（Staging）任务，但在执行过程中遇到了凭证不匹配问题。

随后，该智能体越过原本任务范围，在一个与当前任务无关的文件中找到了一枚 Root 级 API Token，并使用这一高权限令牌删除了 Railway 上的一个 MCP Volume。

问题进一步恶化的原因在于，Railway 将 Volume 级备份存储在同一个 Volume 内。

因此，当数据卷被删除时，备份也随之一并被删除，而最终能够恢复的最新数据副本已经是三个月之前的版本。

另一起广受关注的事件中，一款 Replit Agent 删除了 SaaStr 的生产数据库。

当时系统已经明确进入代码冻结（Code Freeze）阶段，但该智能体仍执行了数据库删除操作，并在之后错误地声称数据已经无法恢复。

Bechenea 表示：

“这两个事件都没有攻击者参与。”

“它们共同的问题在于：所使用的凭证权限范围都明显大于任务本身实际需要，同时系统也没有针对破坏性、不可逆操作建立强制安全检查机制。”

“两个案例中其实都存在书面的安全约束规则，但这些规则最终都没有发挥作用。”

“这些事件再次提醒我们：写在 Prompt 里的规则，并不等同于真正的安全控制。”

Bechenea 建议，企业应该主动测试 AI Agent 能够通过已连接工具访问哪些资源，同时验证 Agent 在真正访问这些资源并准备执行敏感操作时，系统是否存在能够介入并阻止危险行为的安全机制。

针对过度代理权限，OWASP 建议：

• 将 LLM 可以调用的插件和工具数量，以及这些插件和工具能够实现的功能，限制在业务真正所需的最低范围内。

• 尽量避免向模型提供执行 Shell 命令、任意获取 URL 等开放式功能，应优先使用权限和能力更加细粒度的功能接口。

• 将 LLM、插件和工具能够访问系统的权限严格限制在最低必要水平。

• 持续跟踪用户授权状态和安全上下文，确保 AI 代表某个用户在下游系统执行操作时，始终在该用户的具体身份上下文中执行，并仅使用完成该操作所必需的最低权限。

4. 供应链漏洞（Supply Chain Vulnerabilities）

供应链漏洞在此前版本中排名第三。

这一类别主要涉及第三方组件、遭到投毒或已经过时的预训练模型，以及被篡改或污染的训练数据集等安全问题。

此次更新之后，该类别又重点纳入了 模型上下文协议服务器（Model Context Protocol Server，MCP Server）以及模型制品（Model Artifacts）相关风险。

随着开放获取的大语言模型不断普及，以及新的模型微调技术持续出现，AI 供应链风险也在进一步扩大，尤其是在企业从公共模型仓库或协作平台获取模型时。

这一类别还覆盖另一类问题：模型原始开发者没有对训练数据进行充分审查，从而可能引发隐私、软件许可证或版权方面的违规风险。

OWASP 表示，这类问题最终可能导致模型产生偏差性结果、引发安全事件，甚至造成系统故障。

主要防护措施包括：

• 对数据来源和供应商进行严格审查。

• 只使用信誉良好的插件，并确保插件已经按照企业自身的安全和业务要求完成测试；在使用外部模型或第三方供应商时，应采用模型签名和代码签名机制。

• 持续扫描环境中的未授权插件和过期组件，包括模型本身及其相关制品，并建立相应的补丁管理策略，对发现的问题及时进行修复。

• 在选择第三方模型时，应执行全面的 AI 红队测试和安全评估，在正式部署之前识别潜在漏洞、偏差以及可能存在的恶意功能。

5. 数据与模型投毒（Data and Model Poisoning）

数据与模型投毒是指攻击者操纵模型预训练数据，或者篡改模型微调、Embedding 过程中使用的数据，从而人为植入漏洞、后门或偏差，最终影响甚至控制模型行为。

例如，如果恶意攻击者或内部人员成功获得训练数据集的访问权限，就可以主动修改其中的数据，使模型输出错误指令或错误建议，从而损害企业利益，或者让攻击者从中获利。

主要防护措施包括：

• 验证训练数据的供应链，尤其是在使用外部来源数据时，应重点确认数据来源及完整性。

• 针对不同业务场景，考虑采用独立训练数据或不同微调方式构建不同模型，从而实现更加细粒度且准确的生成式 AI 输出。

• 确保模型运行环境具备充分的沙箱隔离能力，防止模型抓取本不应该访问的数据源。

• 对特定训练数据以及不同数据源类别执行严格审核或输入过滤，以控制伪造数据进入模型的数据规模。

6. 无界资源消耗（Unbounded Consumption）

这一类别此前被称为模型拒绝服务（Model Denial of Service）。

所谓无界资源消耗，是指攻击者通过某种方式使 LLM 消耗异常大量的计算、存储或其他资源，从而导致其他用户的服务质量下降，并可能进一步造成巨额资源成本。

OWASP 表示，随着 LLM 对资源的消耗越来越大、用户输入具有高度不可预测性，同时大量开发人员对于这类安全风险仍缺乏充分认识，这一问题正变得越来越重要。

例如，攻击者可以利用自动化工具，持续向企业聊天机器人提交大量高度复杂的查询请求。

每一个复杂查询都需要消耗大量推理时间和计算资源，同时也会直接产生费用。

这种攻击有时也被称为 “钱包拒绝服务（Denial of Wallet）”——攻击目标并不一定是彻底让系统宕机，而是通过大量消耗云计算或模型 API 资源，使受害企业产生高额费用。

无界资源消耗还包括模型窃取（Model Theft）。

攻击者可以向模型持续提出海量问题，通过大量输入输出结果逐步逆向推导原始模型能力，或者利用模型大规模生成合成数据，再使用这些数据训练新的模型。

主要防护措施包括：

• 实施输入验证和清洗机制，确保用户输入符合预先定义的边界，同时过滤恶意内容。

• 对单个请求或单个执行步骤设置资源使用上限，使包含复杂操作的请求受到约束；针对单个用户或 IP 地址实施 API 速率限制；或者限制系统响应 LLM 输出时可以排队执行的操作数量以及总操作数量。

• 持续监控资源使用情况，及时识别异常资源峰值或异常使用模式。

• 在系统设计阶段引入优雅降级（Graceful Degradation）能力，使系统在高负载情况下仍能够保持部分服务能力，而不是完全失效。

7. 错误信息（Misinformation）

LLM 有时会生成事实错误、不恰当或者不安全的内容。

Omdia 网络安全高级首席分析师 Rik Turner 表示，这类所谓的“幻觉（Hallucination）”问题，在企业使用 LLM 辅助安全分析人员开展工作时尤其危险。

Turner 表示：

“如果模型返回的是明显的胡言乱语，安全分析师能够很容易判断它有问题，那么分析师可以直接否定这一结果，并进一步帮助改进算法。”

“但如果模型产生的幻觉非常具有可信度，看起来几乎就像真的一样，又会怎样？”

当企业把 LLM 直接提供给公众使用时，例如部署客户服务聊天机器人，这类幻觉风险将更加突出。

一旦系统向用户提供危险、违法或者错误的信息，企业可能因此承担直接经济损失、声誉损害甚至法律风险。

同时，过度依赖（Overreliance）还会进一步放大错误信息带来的影响。

当用户对 LLM 生成内容过度信任，而没有进行充分验证时，一个看似合理但实际上错误的答案就可能直接转化为错误决策。

主要防护措施包括：

• 要求模型输出建立在权威信息源基础之上，并在实际采取行动之前验证其中的关键事实和结论。

• 引入审批流程以及系统级检查机制。

• 对模型生成的关键结论、相关证据以及最终结果进行记录，并针对对抗性场景持续开展测试。企业还应定期测试工作流程在面对误导性场景时的表现。

• 采用最小权限、沙箱隔离以及速率限制等安全机制，降低单次错误事件可能造成的影响范围。

8. 隐藏上下文暴露（Hidden Context Exposure）

隐藏上下文暴露是在此前“系统提示词泄露（System Prompt Leakage）”类别基础上的进一步扩展，将更广泛的隐藏上下文范围问题纳入其中。

系统提示词是预先提供给 LLM 的初始指令，用于指导模型后续对话和行为。

这些提示词中可能包含敏感指令、运行参数、安全控制规则、业务逻辑以及企业内部信息。

企业可能错误地认为系统提示词天然处于保密状态，但实际上这些内容存在被用户发现和提取的可能。

OWASP 指出，这一问题真正的核心并不是“攻击者可能获取系统提示词”。

更根本的问题在于，企业从一开始就不应该把敏感信息放进系统提示词中。

例如，有些企业会把 API Key、认证信息等敏感凭证直接写入 Prompt，这种做法本身就存在严重安全隐患。

开发人员应该始终假设：所有隐藏上下文都有可能被发现。

主要防护措施包括：

• 将 API Key、认证信息、数据库信息等敏感数据与系统提示词彻底分离，并存放在模型无法直接访问的独立系统中。

• 不要依赖系统提示词控制模型行为；例如针对有害内容的检测等安全控制，应在模型之外的独立系统中实现。

• 在 LLM 外部部署安全护栏（Guardrails），检查模型输出，确保模型行为符合预期。

• 将权限隔离、授权检查等关键安全控制独立于 LLM 实现，并使用确定性、可审计的机制执行这些控制。

• 如果一项工作流中包含多个任务，而不同任务需要不同级别的访问权限，应考虑使用多个独立 Agent，每个 Agent 仅配置完成自身任务所需的最低权限。

9. 向量与嵌入安全缺陷（Vector and Embedding Weaknesses）

企业通常会使用向量数据库和检索增强生成（Retrieval-Augmented Generation，RAG）系统增强 LLM 能力。

这类系统会在向 LLM 提交提示词之前，从企业内部数据存储中检索相关且最新的信息，并将其作为上下文提供给模型。

在这样的架构中，攻击者可能诱骗系统检索其原本无权访问的信息，也可能直接攻击这些数据源，通过数据投毒进一步影响模型，使模型输出错误信息。

OWASP 指出，向量与嵌入安全缺陷本质上是 RAG 类系统“检索基础层（Retrieval Substrate）”中的安全失败，而不是 LLM 或 Prompt 本身的问题。

Embedding 和向量存储构成了一个独立的攻击面。

OWASP 表示，与传统数据存储系统相比，这些新型基础设施通常缺少同等成熟的访问控制和审计能力，因此容易产生新的安全风险。

例如，在多租户环境中，如果向量数据库缺乏充分隔离，或者过滤规则设计不当，就可能向某个租户返回属于其他租户的文档，甚至返回超出当前用户授权范围的信息，最终导致数据泄露。

主要防护措施包括：

• 实施细粒度访问控制，并使用能够识别权限上下文的向量数据库和 Embedding 存储系统；同时对不同数据集实施严格分区，避免用户借助 LLM 间接获取本无权访问的信息。

• 建立完善的数据验证流程，只接收和处理来自可信、经过验证的数据源的信息。对于简历等用户提交内容，可以使用文本提取工具识别并标记隐藏文本。

• 对合并后的数据集进行全面审核和分类，避免不同数据源之间出现错误匹配，同时严格控制不同数据类别的访问权限。

10. 输出处理不当（Improper Output Handling）

输出处理不当是指 LLM 生成结果在被传递给其他下游组件和系统之前，没有得到充分验证、清洗和安全处理。

由于 LLM 的输出内容可能受到用户提示词输入影响，因此如果系统直接信任模型输出，本质上就相当于间接向用户开放了原本不应该直接访问的系统功能。

例如，如果 LLM 输出被直接传递给系统 Shell 或类似高权限执行功能，就可能最终导致远程代码执行（Remote Code Execution，RCE）。

此次 OWASP 更新还扩大了这一类别的范围，将 AI 编程助手大规模生成不安全代码的风险纳入其中。

主要防护措施包括：

• 将模型视为任何其他普通、不可信用户，采用零信任思路处理其输出，并在模型响应被提交给后端功能之前进行严格的输入验证。

• 遵循 OWASP ASVS（应用安全验证标准，Application Security Verification Standard）相关要求，确保输入验证、数据清洗机制得到有效实施，同时针对输出内容进行恰当编码，从而降低非预期代码执行风险。