OWASP 大模型应用十大安全风险解析：治理要点
OWASP 大模型应用十大安全风险是面向 LLM 应用的关键漏洞清单，覆盖提示词注入与不安全的输出处理，帮助团队评估敏感数据、权限边界和治理检查。
什么是 OWASP 大模型应用十大安全风险？
OWASP 大模型应用十大安全风险是面向 LLM 应用中常见关键漏洞的风险清单，用于帮助团队优先识别影响较大、较普遍且可能被利用的安全问题。它关注的不只是模型本身，还包括输入、输出、数据、组件、权限和应用集成链路中的风险。
这类 Top Ten 清单更适合作为安全意识和治理起点，而不是完整的安全检查清单。团队可以用它建立风险优先级，但仍需要结合自身业务场景、数据类型、系统架构和合规要求，继续做威胁建模与安全评估。
要点： OWASP 大模型应用十大安全风险可以帮助团队快速聚焦 LLM 应用中的高优先级问题，但不能替代完整的安全设计、测试、监控和访问控制体系。
先从五个风险面理解大模型应用安全
从工程治理角度看，LLM 安全风险可以先按输入、输出、数据、组件和权限五个风险面理解。这样比单独记忆风险名称更容易落到系统设计和检查动作上。
| 风险面 | 典型问题 | 对应关注点 |
|---|---|---|
| 输入侧 | 用户输入或外部内容诱导模型偏离预期行为 | 提示词注入、系统指令边界、外部内容可信度 |
| 输出侧 | 系统把模型输出直接当作可信结果使用 | 不安全的输出处理、展示前校验、执行前确认 |
| 数据侧 | 敏感数据进入训练、推理或日志链路后被暴露 | 敏感信息泄露、数据最小化、访问权限 |
| 组件侧 | 模型、依赖、插件、外部工具或集成链路存在缺陷 | 供应链漏洞、不安全插件设计 |
| 权限侧 | 模型或 Agent 拥有过大的操作范围 | 过多自主权、越权操作、细粒度访问控制 |
提示词注入和不安全的输出处理，分别代表输入侧与输出侧的核心问题。前者关注模型是否会被输入内容诱导，后者关注应用是否把模型生成内容当作确定、可信、可执行的结果。
敏感信息泄露、不安全插件设计和过多自主权，则会把风险从对话层扩展到业务系统层。一旦模型可以访问数据、调用工具或触发业务操作，权限边界和数据边界就必须被明确设计。
常见风险项速览：先从关键条目入手
下面从治理视角梳理常见风险项。这里的重点不是替代正式清单定义，而是帮助团队把风险名称转化为可检查的系统边界、数据规则和工程动作。
| 风险项 | 核心问题 | 常见关注点 | 治理提示 |
|---|---|---|---|
| 提示词注入 | 输入内容影响模型行为，使模型偏离预期约束 | 用户输入、网页内容、文档内容、间接指令 | 区分系统指令与外部内容，降低不可信输入对关键操作的影响 |
| 不安全的输出处理 | 应用直接信任模型输出并展示、传递或执行 | 输出校验、内容过滤、下游系统调用 | 对输出做验证、转义、审批或人工确认，避免直接执行 |
| 训练数据中毒 | 训练或调优数据被污染，影响模型行为和回答质量 | 数据来源、数据清洗、数据可信度 | 建立数据来源审查和质量控制机制 |
| 模型拒绝服务 | 模型服务可用性受到资源消耗或异常请求影响 | 请求规模、资源占用、服务稳定性 | 对调用频率、输入规模和资源使用设置边界 |
| 供应链漏洞 | 模型、依赖组件、外部工具或集成链路存在安全问题 | 第三方组件、模型来源、依赖更新 | 管理组件来源、版本和集成路径，减少未知依赖风险 |
| 敏感信息泄露 | 敏感数据在训练、推理、日志或输出中被暴露 | 个人信息、业务机密、凭据、内部数据 | 数据分类、最小化使用、权限隔离和日志治理并行推进 |
| 不安全的插件设计 | 插件或工具调用把模型风险扩展到外部系统 | API 调用、业务操作、参数校验 | 限制插件能力，对高风险操作增加校验与确认 |
| 过多的自主权 | 模型或 Agent 拥有过大的决策和执行范围 | 自动执行、越权操作、错误操作 | 明确权限边界、调用范围和人工介入条件 |
这类风险清单的价值在于建立优先级框架。实际落地时，团队还需要结合应用是否接触敏感数据、是否连接业务系统、是否具备工具调用能力，以及是否允许自动执行操作来判断风险等级。
提示词注入和不安全输出处理有什么区别？
提示词注入和不安全的输出处理经常同时出现，但二者关注的风险入口不同。提示词注入偏向输入侧，关注模型如何被诱导；不安全输出处理偏向输出侧，关注系统如何使用模型结果。
| 对比维度 | 提示词注入 | 不安全的输出处理 |
|---|---|---|
| 风险入口 | 用户输入、外部文档、网页内容或其他可被模型读取的信息 | 模型生成的文本、结构化结果或工具调用参数 |
| 影响对象 | 模型行为、回答方向、系统指令边界 | 应用展示层、业务系统、数据库、外部 API 或自动化流程 |
| 典型问题 | 输入诱导模型忽略原有约束或执行非预期任务 | 应用把模型输出当作可信内容直接执行或传递 |
| 防护重点 | 输入来源识别、指令隔离、上下文边界管理 | 输出校验、转义、审批、执行前确认 |
一个简单的判断方法是：如果问题发生在模型接收信息时，通常更接近提示词注入；如果问题发生在系统使用模型结果时，通常更接近不安全的输出处理。许多真实应用会同时面临两类风险，因此需要输入侧和输出侧一起治理。
数据与模型层风险如何影响大模型应用？
数据与模型层风险会影响模型回答质量、业务判断、数据安全和服务稳定性。对于接入企业知识库、用户数据或内部工具的 LLM 应用，这类风险尤其需要提前评估。
训练数据中毒会影响模型行为和回答质量
训练数据中毒关注的是数据源和训练过程的可信度。如果训练或调优数据中混入恶意、错误或不符合业务要求的内容，模型可能在后续回答中表现出偏差、错误判断或不符合预期的行为。
治理时不应只关注模型上线后的表现，也要关注数据进入模型生命周期之前的来源、清洗、审核和变更管理。对于高风险业务场景，数据质量控制本身就是安全治理的一部分。
模型拒绝服务会影响可用性和稳定性
模型拒绝服务关注的是应用可用性。LLM 调用通常涉及计算资源、上下文长度、并发请求和外部服务依赖。如果缺少边界控制，异常请求或资源消耗可能影响服务稳定性。
团队可以从调用频率、输入长度、任务复杂度、资源监控和异常流量识别等方面建立基本防线。这里的重点不是单纯限制用户，而是让服务在异常情况下仍能保持可控。
敏感数据使用需要先评估风险与收益
在模型和推理中使用敏感数据时，团队需要先评估风险与收益。敏感数据可能出现在用户输入、业务上下文、检索结果、日志记录、模型输出或工具调用参数中。只要链路上存在不必要暴露，就可能扩大风险面。
可执行的治理方向包括：
- 对数据进行分类，明确哪些数据可以进入 LLM 应用链路；
- 遵循最小化原则，只提供完成任务所需的数据；
- 对不同用户、角色和工具设置不同访问范围；
- 检查日志、缓存和调试信息中是否包含敏感内容；
- 对输出中的敏感信息暴露风险进行检测和处理。
供应链、插件和自主权带来的工程化安全挑战
当 LLM 应用从简单问答发展为可调用工具、访问数据库、连接业务系统的应用时，风险会从模型交互扩展到完整工程链路。供应链、插件和自主权就是这类工程化风险的集中体现。
供应链漏洞来自更长的集成链路
供应链漏洞可能出现在模型、依赖组件、外部工具、插件、API 服务或部署链路中。LLM 应用通常依赖多个组件协同工作，任何一个环节的缺陷都可能影响整体安全。
因此，团队需要知道应用依赖了哪些模型、组件和工具，也需要知道这些依赖如何更新、由谁维护、能访问哪些数据，以及出现异常时如何隔离。
不安全插件设计会放大外部系统风险
插件或工具调用让 LLM 能够连接外部系统，例如查询数据、调用接口、生成操作参数或触发业务流程。如果插件缺少参数校验、权限限制或操作确认，模型输出中的错误就可能转化为真实业务风险。
插件治理的重点不是禁止工具调用，而是让工具调用具备清晰边界：哪些工具可以调用、哪些用户可以调用、哪些参数需要校验、哪些操作必须人工确认。
过多自主权会增加不可控执行风险
过多自主权关注的是模型或 Agent 是否拥有超出必要范围的决策和执行能力。当系统允许模型自动选择工具、连续执行任务或直接影响业务状态时，错误操作、越权操作和不可控执行的风险都会上升。
更稳妥的做法是将自主权分层：低风险操作可以自动化，高风险操作需要审批或人工确认；查询类能力和写入类能力应分开授权；执行权限不应默认继承用户或系统的全部权限。
身份验证、授权和细粒度访问控制怎么做？
生成式 AI 应用需要可靠的身份验证和授权机制，并通过细粒度访问控制管理不同用户、角色、数据和工具之间的边界。尤其在 LLM 应用接触敏感数据或外部业务系统时，权限控制不能只停留在应用入口。
要点： 访问控制机制不应只依赖 LLM 应用程序逻辑本身。模型可以参与理解和生成，但关键权限判断应由独立、可靠的身份验证和授权机制承担。
访问控制检查清单
| 检查项 | 需要确认的问题 |
|---|---|
| 身份 | 用户、服务账号和自动化代理是否有明确身份标识？ |
| 角色 | 不同角色是否对应不同数据范围和操作范围？ |
| 权限 | 查询、写入、调用工具、执行操作是否分别授权？ |
| 数据范围 | 敏感数据是否按最小必要原则提供给模型或工具？ |
| 工具权限 | 插件和外部 API 是否限制可调用范围和参数范围？ |
| 输出使用 | 模型输出进入下游系统前是否经过校验或确认？ |
| 日志链路 | 输入、输出、检索结果和调用参数是否可能记录敏感数据？ |
| 变更管理 | 模型、插件、依赖和权限策略变更是否可追踪？ |
细粒度访问控制的核心目标，是让 LLM 应用在完成任务时只获得必要的数据和能力。对于连接内部系统的应用，应特别关注用户权限、工具权限和数据权限是否一致，避免模型成为绕过权限边界的中间层。
团队落地时可以从哪些检查项开始？
团队可以把 OWASP 大模型应用十大安全风险作为风险识别起点，建立持续评估流程，而不是把它当作一次性合规任务。下面的清单适合用于需求评审、架构设计、上线前检查和周期性复盘。
风险识别
- 是否识别了应用涉及的输入、输出、数据、组件和权限风险面？
- 是否明确哪些风险项与当前业务场景最相关？
- 是否将 Top Ten 清单作为起点，而不是唯一安全依据？
敏感数据治理
- 敏感数据是否进入训练、推理、检索、日志或调试链路？
- 使用敏感数据前是否评估了风险与收益？
- 是否执行数据分类、最小化使用和访问权限隔离？
身份验证与授权
- 用户和服务账号是否经过可靠身份验证？
- 是否为不同角色设置了细粒度访问权限？
- 关键访问控制是否独立于 LLM 应用程序逻辑？
输出处理与工具调用
- 模型输出是否会被直接展示、执行或传递给下游系统？
- 高风险输出是否有校验、转义、审批或人工确认机制？
- 插件、API 和外部工具是否有明确调用范围和参数限制？
供应链与自主执行
- 模型、依赖组件、插件和外部服务来源是否可管理？
- 组件更新、权限变更和集成变更是否可追踪？
- Agent 或自动化流程是否存在过多自主权？
- 高风险操作是否设置了人工确认或回滚机制？
对于大模型应用治理来说，最重要的是把风险清单转化为系统边界、权限策略、数据规则和工程流程。只有当这些控制点落实到应用生命周期中，OWASP 大模型应用十大安全风险才真正发挥治理价值。
原文链接：https://www.qianwenai.com/discover/owasp-llm-top-10-security-risks
