​​

想到 2025 年将是LLM智能体之年，而现状却令人不寒而栗…LLMs对越狱攻击的防御依然脆弱得可笑。诚然，DeepSeek 几周前发布时在 AI 界掀起巨浪，我也承认它确实强大得惊人。但这位 X 平台用户仅用简单的提示词注入就轻易生成了冰毒配方。

​​X 用户利用 DeepSeek 生成冰毒配方（来源：X.com）

现在想象一下，将这些相同的LLMs接入我们日常使用的医疗工具、法律系统和金融服务中。

我是不是忘了提，目前有超过半数——确切地说是 53%——正在构建 AI 代理的公司甚至没有对模型进行微调？说实话，这不能全怪他们——有效微调的成本高得惊人。然而，这意味着这些LLMs中的任何漏洞都将延续到你使用的代理上。所以，当你的“药物研究 AI”突然决定兼职制毒时，可别太惊讶。

玩笑归玩笑，LLMs的安全问题不仅是个难题——它正演变成一场日益严重的危机。为防止 AI 末日的到来，我们需要强有力的标准来指导这些 AI 系统的开发、测试和部署，以确保LLM的安全

诸如欧盟 AI 法案和 NIST AI RMF 等努力已在这一领域取得进展（我在LLM安全文章中详细讨论过这些内容），但都不及 2025 年 OWASP Top 10 LLM那样全面且专注于LLM。

2025 年的 OWASP Top 10 LLM是什么？

《2025 年 OWASP LLM应用十大安全风险》列出了构建安全LLM应用时面临的十大最关键风险与漏洞及缓解策略。这是开发者、科学家和安全专家协作的成果。这些指南覆盖了全生命周期：开发、部署与监控。

​​

没错，它不仅仅停留在测试你开发中的LLM应用。DeepSeek 可能对其模型进行了广泛测试，但这并未阻止它在公开发布后变成“制毒师”……因此监控至关重要，不过这一点我们稍后再详述。

OWASP 是什么？

如果你刚接触软件安全领域，可能在想：OWASP 是谁？我们为何要信任他们？

OWASP（开放全球应用安全项目）是一个非营利组织，以发布开源项目而闻名，如针对 API、物联网及现在LLMs（大型语言模型）的 OWASP 十大清单。这些清单汇集了全球安全专家的广泛协作成果，并确保其发现和工具对所有人免费开放。所以，请相信我，你可以信赖它们。

2025 年有哪些新变化？

OWASP 十大安全风险清单LLM最初发布于 2023 年，但随着LLM应用程序的迅速普及和采用，新的风险和漏洞不断显现。今年的最新更新是迄今为止最全面、最能反映当前安全形势的版本。

​​

以下是新内容：

• 过度自主权：随着 2025 年成为“LLM代理之年”，许多应用被赋予了前所未有的自主权级别。这一转变使得今年的风险清单中不得不大幅扩展关于过度代理风险的内容。
• RAG 漏洞：此外，由于 53%的公司选择不对模型进行微调，而是依赖 RAG 和代理管道，与向量及嵌入弱点相关的漏洞已跻身十大风险之列。
• 系统提示风险：我们还发现系统提示泄露已成为一个令人担忧的问题，许多LLM开发者在系统提示中暴露内容的边界上如履薄冰。
• 无界消耗（？）：最终，企业广泛采用LLMs及其引发的资源管理挑战激增，导致资源管理问题急剧上升，被 OWASP 恰如其分地称为“无界消耗”（有点令人困惑，你不觉得吗）。

恭喜你坚持到这里，因为接下来的部分至关重要。我将通过真实案例逐一解析 2025 年 OWASP Top 10 LLM风险，确保你完全理解所面临的挑战（不过下一节可能更为关键，因为我会系统性地讲解如何缓解这些风险）。

OWASP 2025 年十大安全风险LLM：完整榜单

1. 提示注入（LLM01:2025）

如果你曾探索过LLM安全领域，很可能遇到过提示注入攻击。这类攻击是最常见的LLM攻击类型，针对的是输入层——即你输入到LLM应用中的内容。它们既包括人类可理解的提示（例如，“我祖母快不行了…”这类请求），也包括无意义的输入（例如像“76dh3&^d”这样的随机标记），这些输入可能导致模型产生不良甚至有害的行为——无论是有意还是无意。

​​

“奶奶”提示注入

提示注入分为两种类型：直接和间接。直接提示注入发生在输入直接导致模型失效（失效指其行为不符合预期）时，而间接注入则发生在模型处理如文件或网站等外部资源导致失效的情况下。

例如：

• 直接注入：攻击者诱骗聊天机器人违反规则，以获取私人信息并发送未经授权的电子邮件。
• 间接注入：用户请求 AI 总结一个网页，但页面中隐藏的指令使 AI 链接到恶意网站并泄露私人对话。

​​

人类可理解与不可理解的注入对比

提示注入这一术语常与越狱互换使用，两者均通过利用模型在输入层面的漏洞来绕过安全防护。

你可以采取一些措施来帮助防止提示注入。这些缓解策略包括：

• 约束模型行为：提供严格的角色指令，强制遵循任务要求，并忽略任何试图修改指令的行为。
• 验证预期输出：明确输出要求，并通过确定性代码检查验证格式。（可利用防护栏实现…更多内容见后续章节）

2. 敏感信息泄露（LLM02:2025）

泄露敏感信息的风险令人恐惧，这也解释了为何 OWASP 在 2024 年榜单中将此风险从第六位提升四位。为了让LLM应用和 AI 助手提供更佳协助，它们需要更多访问你的数据——健康记录、财务细节、公司机密。

无论是通过训练数据集、RAG 知识库、数据库访问，还是用户直接输入信息（比如开发者们在代码库上使用 ChatGPT），敏感数据有多种途径进入 AI 系统。防止敏感数据进入对于避免其泄露至关重要。

​​

简单的数据泄露示例

可以理解，LLMs在某些场景下可能需要访问敏感数据。然而，在此类情况下，确保不泄露任何个人信息是绝对必要的。泄露可能通过多种方式发生，例如越狱、跨会话泄露（即数据在不同用户间泄露）等。

以下是数据泄露可能发生的一些示例：

定向提示注入攻击：攻击者精心构造输入以绕过过滤器，从模型中提取敏感信息。

数据泄露通过训练数据：敏感信息无意中被包含在训练数据中，导致潜在的泄露风险。

可以想象，敏感信息泄露可能带来灾难性后果。比如因无意间泄露加密密钥而导致数十亿比特币价值的损失。幸运的是，有一些缓解措施可以采用：

• 集成数据清理技术：在训练前对敏感内容进行脱敏处理，确保个人数据不被包含在模型中。
• 强健的输入验证：实施严格的输入验证机制，以检测有害或敏感数据，防止系统遭受破坏。（再次强调，这属于防护栏范畴）
• 强健的输出验证：实施严格的输出验证以防止数据泄露（…同时设置防护栏）

3. 供应链（LLM03:2025）

如果你在想“LLM供应链到底是什么？”，你并不孤单。OWASP 将其描述为构建LLM应用程序所用的所有外部组件——包括训练数据集、LoRA 适配器（用于微调）和预训练模型等。

这些资源极大地加速了开发进程并降低了使用门槛，但由于它们由外部开发，也带来了自身风险。例如，预训练模型可能包含隐藏的偏见、后门，甚至是可能危害应用程序的恶意代码。

以下是更多供应链攻击示例：

• 易受攻击的 Python 库：攻击者利用被篡改的 Python 库，例如从 PyPi 包注册表中下载的含有恶意软件的 PyTorch 依赖项。
• 直接篡改：攻击者修改并发布带有恶意参数的模型，绕过安全检查

这些漏洞在被利用之前往往难以察觉，因此尤为危险。一个看似可靠的预训练模型若被植入了后门触发器，可能在攻击者知晓的特定输入激活隐藏漏洞前表现正常，随后导致模型失效。

无论是你的LLM每次都生成相同的回复，还是出现不恰当的内容，最小化这些风险至关重要，这意味着需要持续检查和跟踪你的组件和来源：

• 模型完整性：使用来自已验证来源的模型，并实施如签名和文件哈希等完整性检查。
• 组件追踪：维护一份签名的软件物料清单(SBOM)以追踪组件及其漏洞。

4. 数据投毒（LLM04:2025）

数据投毒发生在攻击者操纵预训练、微调或嵌入过程中使用的数据时。这会引入漏洞、偏见或后门，降低模型性能并产生有害或有偏见的输出。

虽然这一风险在微调阶段更为突出，但如果攻击者未经授权访问知识库并决定污染检索数据集，它同样可能影响 RAG 系统。

数据投毒可通过多种方式展开：

偏见训练数据：攻击者向训练数据中注入带有偏见的样本，使输出结果歪曲以传播错误信息。

毒性数据包含：微调过程中引入有毒或有害数据，导致模型生成带有偏见或冒犯性的回应。

与缓解供应链风险类似，防止数据投毒没有捷径——你必须彻底审查所有数据集和知识库，确保它们安全且干净。相信我，你不会希望你的LLM因为错误的原因（如政治观点）登上头条。

以下是几种实现方法：

• 追踪数据来源：使用如 OWASP CycloneDX 等工具验证开发过程中数据的合法性及转换过程。
• 严格审查数据供应商：对数据提供者进行严格验证，并对照可信来源检查输出，以检测投毒行为。

5. 不当输出处理（LLM05:2025）

不当输出处理发生在LLM生成的输出在传递给其他系统或组件之前未得到适当验证或清理的情况下。听起来不太严重，对吧？错了。

不当的输出处理会严重影响系统，尤其是当下游组件（如访问 API 和数据库的工具）使用LLM生成的输出时。例如，Text2SQL 系统中的一次错误幻觉可能将 DELETE FROM users WHERE ID =123 变为 DELETE FROM user —瞬间，你的整个数据库就被清空了。

以下是更多攻击示例：

• 特权功能滥用：LLM将未经验证的输出传递给管理扩展，致使该扩展执行了非预期的维护命令。
• 敏感数据泄露：由LLM驱动的摘要工具处理了一个含有隐藏提示的恶意网站，导致其将敏感用户数据发送至攻击者控制的服务器。

…以及一些确保正确处理输出的方法。

• 上下文感知编码：根据具体使用场景对输出进行编码（例如，网页内容采用 HTML 编码，数据库查询使用 SQL 转义）。
• 输出净化：在将LLM响应传递给后端函数或外部系统前，进行验证与净化处理。

6. 过度代理（LLM06:2025）

与不当输出处理相关的是过度代理问题，这对具备工具访问能力以影响现实世界的代理型LLM应用而言是一个主要关切点。

过度代理可分解为三个领域：功能过剩、权限过剩及自主性过剩。作为开发者，我们有责任确保不为这些代理配备超出其预期用途的工具、权限或自主权。否则，可能会发生以下情况：

• 收件箱利用：拥有发送消息权限的助手被诱骗将敏感邮件转发给攻击者。
• 不必要的 Shell 访问：一个具有文件写入功能的扩展允许执行任意命令，导致非预期且有害的操作。

与不当输出处理（侧重于在调用其他工具前验证和清理LLM输出）不同，过度代理关注的是这些代理直接使用和管理工具的行为。

为减少过度代理行为，你可以采取以下措施：

• 限制功能与权限：使用范围狭窄的扩展并强制执行最小访问权限。
• 要求用户确认：对发送消息或执行命令等高影响操作实施人工审批。

7. 系统提示泄露（LLM07:2025）

系统提示泄漏发生在提示中包含的敏感信息被暴露时，导致诸如揭示内部规则、过滤标准或敏感功能等风险。

​​

示例攻击包括：

• 凭证暴露：攻击者提取包含凭证的系统提示，从而获得对外部工具的未授权访问。
• 指令绕过：攻击者利用提示注入覆盖系统提示限制，从而启用攻击性内容或远程代码执行。

最佳实践是将系统提示视为指导模型输出的简单指令，而非敏感数据的存储库。然而，当必须包含敏感信息时，加密和访问控制等保护措施至关重要。

以下是几种防止提示泄露的策略：

• 分离敏感数据：将凭证和密钥等敏感信息保留在系统提示之外。
• 实施防护栏：使用独立系统执行安全控制，并根据预期验证模型输出。

8. 向量与嵌入缺陷（LLM08:2025）

采用 RAG 管道的系统尤其容易因向量和嵌入的生成、存储或检索方式存在缺陷而受到攻击。攻击者可利用这些弱点注入有害内容、操纵输出或访问敏感信息。

例如：

• 未经授权的访问与数据泄露：配置错误的向量数据库允许对嵌入数据进行未授权访问，导致个人或专有信息等敏感数据暴露。
• 嵌入反转攻击：攻击者利用漏洞逆向工程嵌入向量，恢复原始数据，破坏机密性。

保护向量存储库需采取强有力的安全措施，包括访问控制、定期审计及嵌入流程验证：

• 权限与访问控制：在向量数据库中实施严格的逻辑和访问分区，并为用户提供细粒度的访问控制。
• 数据验证与来源认证：定期审核并验证所有数据源，仅接受来自可信、已验证提供商的数据。

9. 错误信息（LLM09:2025）

即便在LLMs领域取得进展，错误信息仍是一个重大问题。它常表现为LLMs生成看似可信实则虚假的内容，这通常源于幻觉——即模型训练数据空白导致的捏造输出。系统偏见及用户的过度依赖进一步放大了这些风险。

错误信息可能造成严重损害，不仅影响品牌声誉，还会导致现实世界的危害。例如：

• 恶意软件包利用：攻击者发布名称常被编码助手误认为常用包的恶意软件包，导致开发者无意中集成有害代码。
• 错误医疗诊断：由于准确性检查不足，医疗聊天机器人提供错误信息，对患者造成伤害并使公司面临诉讼风险。

为应对错误信息，LLMs需要更加可靠，用户在将其整合到关键决策前应始终验证输出结果。以下是几项缓解策略：

• RAG：通过在生成响应时从可信外部来源检索已验证数据，提升可靠性。
• 交叉验证与监督：鼓励用户通过外部来源验证输出结果，并对关键信息实施人工事实核查。

10. 无限制消耗（LLM10:2025）

列表末尾是无限制消耗现象，当某LLM的资源使用失控时，会导致性能下降、服务中断或意外成本。

虽然此问题更多涉及系统整体安全而非特定于LLM的安全，但导致资源无限消耗的攻击包括：

• 输入规模失控：攻击者提交过大的输入，消耗内存与 CPU 资源，可能导致系统崩溃。
• 重复请求攻击：攻击者发送大量 API 请求，耗尽系统资源，使合法用户无法获得服务。

随着LLMs在公众和商业环境中的广泛应用，适当的速率限制、监控和资源管理对于确保系统在高负载下仍保持可扩展性和高效性至关重要。为防止无限制的资源消耗，应实施以下策略：

• 速率限制与节流：限制请求速率并对资源密集型操作设置超时，以防止系统过载。
• 资源分配管理：动态监控和管理资源，防止任何单一用户或请求过度消耗资源。

风险缓解策略

希望到目前为止，您已成为LLM安全与防护领域的专家。我们已经全面梳理了 2025 年 OWASP Top 10 LLM风险，详细说明了恶意攻击如何利用LLM风险，并针对每一项提供了缓解策略。

然而，问题依然存在：尽管我们已经实施了所有这些安全机制，如何确保我们的LLM是安全可靠的？答案是，你需要一个系统化的测试框架。记住，从一开始我就告诉过你，你需要在开发和生产环境中都进行测试。

开发中的风险缓解

为了系统地测试开发中的LLM是否存在漏洞，你需要为每种风险准备一个全面的数据集。若想对LLM的安全性有信心，庞大的数据集至关重要。这些数据集不仅要涵盖广泛的攻击类型，攻击本身也需高效——既要有广度也要有深度。

你需要不断迭代你的LLM，直到它能通过评估数据集中的所有攻击。原因很简单：你的数据集可能无法覆盖所有可能的攻击，如果你的LLM连测试集中的攻击都无法抵御，你就得问：现实世界中还可能存在哪些其他漏洞？

对你来说幸运的是，过去一年里，我一直在攻击各种LLM应用——代理、RAG 系统、简单的LLMs——应有尽有。我们开发了一条流水线来帮助尽快保护你的LLM，甚至为此构建了一个支持平台。

​​

Confident AI 红队平台

Confident AI 让您能够自动生成攻击并利用研究支持的策略增强它们，使其更加有效。只需一键点击，您就能生成所需数量的攻击。该平台还允许您在一个中心位置跟踪进度，帮助您加速测试流程。若需更强的安全性，只需生成更多攻击并通过评估即可。

生产环境中的风险缓解

生产环境中风险缓解的第一步是监控——持续不断的监控。你需要追踪用户输入的每一个数据点，并依据你所关注的一套全面安全指标，评估LLM生成的每一个响应。监控范围应涵盖一切——从各组件基于不同输入的功能表现，到实时掌握整个LLM应用架构的全局可视性。

​​

Confident AI 可观测性功能

但仅靠监控是不够的。当然，你会了解发生了什么，但你实际上并没有采取任何措施来保护你的LLM应用程序。这就是为什么在生产环境中风险缓解的第二部分更为重要：你需要防护栏。防护栏是简单的二元指标，设置在用户输入到达你的LLM应用程序之前的输入层级，以及LLM的响应到达用户之前的输出层级。它们确保有害攻击不会触及你的应用程序，同时防止有害响应流向用户。这一点至关重要，因为即使你的LLM偶尔会失败（没有系统是 100%完美的），添加这些防护栏也能显著降低失败的风险。

Confident AI 还提供了一个全面的监控/可观测性平台和集成的防护栏 API，让您能在一个地方追踪所有情况。我们还会自动标记生产环境中任何失败的响应——无论是安全漏洞还是不可接受的回复——以便您可以在开发环境中继续测试这些失败响应，并进行必要的改进。

结论

LLM应用正变得越来越强大。这固然令人振奋，但也伴随着风险。我们虽极力推崇LLMs，但也坚信必须负责任地使用。OWASP 2025 年十大LLM风险清单是理解LLMs潜在风险及应对措施的绝佳起点。

不过，这仅是指导原则。若想真正高枕无忧，您需要一套系统化测试方案，覆盖LLM应用的开发与生产环境。幸运的是，有我们为您护航。过去一年我们持续构建、测试与迭代，确保您能轻松加固LLMs并对其安全性充满信心。