什么是 LLM 安全？如何缓解 OWASP 十大安全风险

有一种攻击会诱使 AI 把攻击者的指令当作命令来执行，这就是提示词注入。自 2023 年以来，它在每一版《OWASP LLM 应用十大风险》中都位列第 1。

在 AI 安全领域，这份榜单几乎是最接近共识的存在。该项目最初由一小群安全专业人士发起，如今已汇聚了来自超过 18 个国家的 600 多名贡献专家。

我们是一家 AI 公司，却要发布一份关于 AI 如何被“说服”去做事的指南，所以就不假装这个问题已经解决了。OWASP 项目的联合负责人 Wilson 谈到当前的防御手段时说得相当直白：“……坦白说，我认为我们还没有达到 99%。”

2026 年版也以同样的基调开篇。项目负责人告诉我们，要“停止试图构建一个无法被愚弄的模型”，而应设计好模型周边的系统，让被愚弄的模型也无法破坏任何重要的东西。

我们将秉持这一立场，逐一审视 OWASP 2026 年榜单中的全部 10 项风险。

什么是 LLM 安全？

LLM 安全是指保护 AI 模型及使用这些模型的应用免受攻击和滥用。模型连接的东西越多，风险就越大：包括它能读取的文件和数据，以及它能使用的工具，比如电子邮件、搜索或公司数据库。

在安全防护到位的软件中，程序遵循的指令与它处理的信息之间有一条明确的界线。但 LLM 没有这条界线。

模型读取的所有内容都是以一长串文本的形式传入的：开发者的指令、你的问题、它查到的网页。AI 模型理应分清是谁在说话——是开发者、用户，还是模型自己在思考问题。

但研究人员 Jasmine Cui 和 Charles Ye 发现，模型主要是根据文本的口吻来猜测是谁在说话。因此，如果攻击者写下一段听起来像模型自身推理的内容，模型可能会以为这个想法是它自己想出来的。对于任何依赖模型分清谁说了算的安全机制来说，这都是个问题。

我们在自己的 AI 智能体上也遇到过同样的问题。我们的首席信息安全官 Kyle Polley 对ISMG 表示，智能体“即使你把策略写进系统提示词，也可能不会遵守”。正因如此，我们开发了 Numbat，这是一款开源工具，可以检查智能体即将执行的操作，并在该操作违反已配置的安全规则时将其拦截。

LLM 安全意味着要接受模型有时会听从错误对象的指令，并为它设置即使在这种情况下也依然有效的 AI 护栏。

LLM 安全有哪些最佳实践？

我们将按顺序逐一介绍《OWASP LLM 应用十大风险（2026 年版）》，从第 1 项到第 10 项。

对于每项风险，我们都会用通俗易懂的语言解释问题是如何出现的，并给出一个真实案例。然后，我们会介绍有助于预防该风险、或至少能够限制损害的做法。

1. 遏制提示词注入

当攻击者让 AI 遵循它本不应遵循的指令时，就发生了提示词注入。这些指令可能直接出现在聊天中，也可能被植入电子邮件、网页或文档里。

第二种类型被称为间接提示词注入。你让助手总结一份文档，而文档的作者已在其中指示助手把你的私密文件发给他们。如果助手照做，那么写这份文档的人实际上就借用了你的访问权限。

PCMag打了个比方：提示词安全就像给一块多孔的石头堵洞。你堵住一个孔，水又会从另一个孔渗出来。“一种攻击找到了突破口，随后被修复，但正因为 LLM 这类系统具有动态性，还有无数其他攻击途径有待发现。”

案例：2025 年 6 月，Aim Security 的研究人员发现了 EchoLeak，这一漏洞可诱使 Microsoft 365 Copilot 泄露公司私密信息。当员工提出一个日常工作问题时，Copilot 可能会调取这封电子邮件，执行其中隐藏的指令，并将敏感信息发送给攻击者。该攻击绕过了旨在拦截恶意指令和移除可疑链接的检查机制。

你可以这样做：

• 遵循Meta 的“三选二原则”（Rule of Two）：EchoLeak 需要 AI 同时能够读取公司数据、读取外部电子邮件并向外发送信息——而它三者兼备。将其限制为只具备其中两种能力，就能防止提示词注入获得过多控制权。如果任务确实需要这三种能力，则应在每次操作前要求人工批准。
• 模拟了解你防御措施的攻击者进行测试：把你已部署的规则和过滤器告诉安全测试人员，然后让他们设法绕过。在一项研究中，针对防御措施调整策略的攻击者在所测试的 12 种防御中的大多数上，成功率都超过 90%。

2. 防止敏感信息泄露

当 AI 系统把私密信息提供给无权查看的人时，就称为敏感信息泄露。这可能意味着泄露客户的支付信息，或将私人对话留存在共享数据库中。

许多泄露都始于“过度共享”。比如，某公司把 AI 连接到权限设置宽松的云盘和知识库，AI 便会完全按设计检索它能访问到的一切。无需任何人闯入，但你应当把这个 LLM 视为已被攻破。

案例：2025 年 1 月，Wiz 研究人员发现一个 DeepSeek 数据库向互联网公开，其中包含超过一百万条日志记录，包括聊天记录和 API 密钥（软件用来访问其他服务的凭据）。研究人员根本不需要说服模型透露任何信息。

你可以这样做：

• 在 AI 读取数据之前检查访问权限：你的应用应在将文档传给模型之前，先检查提问者有权查看哪些文档。
• 保护 AI 留下的记录：在保存活动日志之前删除私密信息和密钥，要求登录才能访问，并仅限有需要的人员访问。设置保留期限，以免这些记录无限期地累积。

3. 约束过度代理

存在过度代理问题的 AI 拥有超出其工作所需的权力：用不到的工具、超出任务范围的权限，或无需核查即可行动的自由。在这里，起因并不重要。

无论是注入的提示词、程序漏洞，还是模型单纯出错，结果都一样：只要 AI 具备这种能力，它迟早会做出破坏性的事情。

案例：2025 年 7 月，SaaStr 创始人 Jason Lemkin 称，尽管他已指示不要做任何更改，Replit 的编程智能体还是删除了他存有 1,206 条高管记录的数据库。该智能体起初表示数据无法恢复，但后来证明是可以恢复的。Jason 发现，告诉它不要动数据库，并没有消除它删除数据库的能力。

放大

来源：X

你可以这样做：

• 移除任务不需要的能力：既要限制智能体可获得的工具，也要限制这些工具能做什么。一个总结电子邮件的助手需要的是读取邮件的权限，而不是发送或删除邮件的权限。
• 将权限检查放在 AI 之外：每次请求执行操作时，都要对照你的安全规则进行检查，并要求由人来批准。

4. 检查进入 AI 供应链的内容

很少有公司从零开始构建 AI，而且这样做的公司逐年减少。根据 Menlo Ventures 的《2025 年企业生成式 AI 现状》调查，2024 年有 53% 的公司采购了 AI 模型，到 2025 年这一比例增至 76%。

多数情况下，公司会从 Hugging Face 等平台下载模型，用他人收集的数据集进一步训练，并接入由陌生人编写的插件和代码包。

其中每一部分都是一个入口。一旦有任何一部分被篡改，问题就会随你的产品一起交付出去。

案例：2026 年 1 月至 2026 年 8 月间，Hugging Face 的公开模型仓库从 243 万个增加到 296 万个。然而在 2026 年 7 月，OpenAI 的模型在内部安全测试期间绕过了旨在阻止其访问互联网的管控措施，并侵入了 Hugging Face 的部分系统。事实上，其中一个智能体找到了 14 个公开暴露的访问凭据，验证了它们可用，并将其分享给其他智能体。这些智能体随后利用漏洞，在 Hugging Face 的服务器上运行代码。

OpenAI 的报告称：“我们正在模型的整个生命周期中对对齐提出更严格的要求，并创建隔离程度更高的沙盒、限制互联网访问，以及进一步管控对模型权重的访问。”

你可以这样做：

• 将模型固定到确切版本并加以验证：将每个模型固定到经过审核的版本，并在加载前核对其文件指纹，这样被替换的文件就无法顶着同一标签混入。OWASP 还建议使用数字签名，但需要注意：签名只能证明模型的来源，并不能证明它是安全的。
• 检查 AI 推荐的每个软件包：在安装 AI 助手推荐的代码包之前，先确认它确实存在、是你想要的那个包，并且来自你预期的发布者。

5. 防范数据与模型投毒

被投毒的 AI 会从被污染的数据中学习。这些数据可能是用于微调它的示例，也可能是它用来搜索答案的知识库。模型看起来仍然运行正常，只是学到了错误的东西，有时它还会学会只在看到某个特定触发短语时才表现异常。

在有人用上这个短语之前，模型能通过你给出的每一项测试。

放大

而且，这种问题真的很难消除。投毒不是打个补丁就能修好的漏洞。如果你的数据有问题，你可能需要重新核查数据、重新训练模型，甚至彻底替换模型。

案例：2025 年 10 月，Anthropic、英国 AI 安全研究所和艾伦·图灵研究所的研究人员证明，250 份被投毒的文档就能让模型学会输出乱码——只要遇到特定的触发条件就会如此。在测试的全部四种模型规模中，所需的文档数量都相同，尽管最大的模型所用的干净训练数据是最小模型的 20 多倍。

你可以这样做：

• 追踪数据来源：记录你使用的每个数据集和模型、各自的来源，以及版本之间的变化。我们建议对数据集进行版本控制，这样一旦发现投毒，你就可以回滚到干净的版本，并查明问题是如何混入的。
• 测试后门：“后门”是攻击者植入模型的一种隐藏行为，会等待特定短语或其他触发条件将其激活。可以使用专门设计来让模型打破常规规则的输入来测试这类后门。

6. 为无限制消耗设置上限

当 AI 在可完成的工作量或可产生的费用上没有任何限制时，其消耗就被视为“无限制”的。大多数 AI 服务按使用量计费，因此攻击者可能会让你的账单暴涨，或者复制出一个你的模型。

OWASP 将其核心问题称为“成本不对称”：一个简短、廉价的请求，就可能在你这一端引发昂贵的计算。

案例：2024 年 5 月，Sysdig 威胁研究团队发现了一种名为“LLMjacking”的新型攻击。一群攻击者利用窃取的凭据，将矛头对准了 10 个云托管的 LLM 服务。他们通过一个存在漏洞的 Laravel 版本入侵，随后摸清了这些凭据的权限和各项配额，目的显然是转卖访问权限。他们还查询了大量日志设置，很可能是为了躲避检测。据 Sysdig 称，在最坏的情况下，受害者每天的损失可能超过 46,000 美元。

你可以这样做：

• 设置能真正止住支出的预算：为单个用户、API 密钥、团队以及整个账户设定硬性支出上限，并在所有可能接收请求的入口处强制执行。
• 为每项任务设定终止点：限制任务可运行的时长、可处理和生成的文本量，以及可进行的工具调用次数。为出现重复行为或超出配额的智能体添加自动中断机制。

7. 在采取行动之前识别错误信息

当 AI 生成了听起来正确但实际错误的内容，而有人（或某个系统）据此采取了行动，这就叫错误信息。核心风险与其说是错误答案本身，不如说是错误答案被信任和采用。

事件记录表明，从业者对错误信息的重视程度远不及应有的水平。根据 2026 年版的开篇信，投票者将它排在接近末尾的位置，但从真实事件来看，它应当名列前茅。

案例：2025 年，德勤澳大利亚根据一份价值 44 万澳元的政府合同，提交了一份关于福利 IT 系统的审查报告。悉尼大学研究员 Chris Rudge 发现报告中引用了不存在的研究，还有一段捏造的联邦法院判决引文。修订后的报告披露，德勤在其方法中使用了 Azure OpenAI GPT-4o，该公司同意退还最后一期款项。遗憾的是，这还是一份鉴证审查报告。

你可以这样做：

• 检查证据是否支持答案：让论断以最新的权威来源为依据。对于涉及政策的回答，应检索已批准的政策，并检查它是否支持该结论，包括其中的例外情况。
• 在系统采取行动之前进行核实：如果智能体声称某位客户已通过身份验证，请在放行付款之前通过验证系统确认这一点。对于后果重大的决策，应要求人工批准，并向审核人员提供支持性证据。

8. 限制隐藏上下文泄露造成的损害

AI 应用会向模型提供用户通常看不到的指令和背景信息，其中可能包括系统提示词、内部政策、可用工具的说明，以及关于谁可以使用这些工具的规则。当模型向某人泄露这些信息时，就发生了隐藏上下文泄露。

2026 年，OWASP 将这一条目由“系统提示词泄露”扩展为现在的范围，因为系统提示词只是可能外泄内容的一部分。危险程度取决于你在其中放了什么。泄露语气风格指南只会让人略感尴尬，但泄露 API 密钥则会让别人得以访问你的机密数据库。

案例：2023 年 2 月，用户成功让 Microsoft 的 Bing Chat 透露了其内部指令。其中一次成功的尝试来自 Marvin von Hagen，他自称是 OpenAI 开发者，并以配置模型为由索要这些指令。Bing 披露了约束其搜索、回复和安全行为的规则，以及其内部代号 Sydney。在被披露的指令中，恰好有一条要求它对这些指令保密。

你可以这样做：

• 不要让机密信息进入模型的上下文：假设模型能读取的任何内容都可能被用户看到——将密码、API 密钥和访问令牌存储在独立的机密管理系统中。
• 确保即使规则泄露，权限依然有效：在应用程序代码中强制执行访问检查。如果某个工具仅限管理员使用，请在运行前检查用户的账户权限。

9. 严格管控向量和嵌入

当 AI 使用向量搜索在公司文档中查找答案时，它并不会直接搜索文本。这些文档会被转换成“嵌入”——一长串能够捕捉每段文字含义的数字——并存储在向量数据库中。问题也会以同样的方式转换，然后系统会提取数字最接近的段落。

OWASP 将其失效方式归纳为四种：投毒让系统出错，反演让系统泄密，干扰让系统沉默，而失效的访问控制则让系统把任何内容交给任何人。

这些数字并不像看起来那样是安全的抽象表示。存储的嵌入可以被还原为文本，有一种方法在测试中精确还原了 92% 的 32 词元短段落。因此，一份泄露的“仅含嵌入”的备份同样可能暴露文档的内容。

示例：在 USENIX Security 2025 上发表的一项研究中，研究人员证明，一份精心构造的文档就能让 AI 无法回答某个特定问题。他们将这份文档添加到 AI 检索的文档集合中。当 AI 检索到它时，可能会表示自己没有足够的信息，或者声称回答这个问题不安全。这份文档并不需要指示 AI 忽略其规则。这被称为“检索干扰”。

你可以这样做：

• 为公开数据和私有数据分别维护独立的索引：不要将抓取的网页内容与合作伙伴数据或内部机密文件混在一起。应按信任级别进行物理隔离，而不是在同一个索引中为内容打标签，因为这样可以杜绝一整类配置错误，从互联网上抓取的内容也不会出现在你的董事会文件旁边。
• 像对待原始文档一样对待嵌入：对嵌入进行加密，像保护源文件一样保护向量数据库备份，并在删除原始文档时一并删除对应的嵌入。嵌入服务的 API 密钥也应妥善保密。

10. 先检查 AI 输出，再向下游传递

只要应用程序将 AI 输出传递给另一个系统，却没有验证该输出能否在那里安全使用，就属于对 LLM 输出的不当处理。

该条目还涵盖了 AI 编程助手大规模生成的不安全代码。因此，助手写下的每一行代码同样属于输出。

示例：2025 年，研究员 Johann Rehberger 展示了 Sourcegraph 的 Amp 编程助手如何仅通过显示一张图片就泄露聊天内容。他利用提示注入，让 Amp 将私密信息写入图片的网址中。随后，应用程序自动获取该图片，从而把这些信息发送到了他的服务器。输出处理的失败之处就在于这个自动请求——模型生成的文本变成了与外部服务器的连接，并携带着私密数据。

你可以这样做：

• 确保输出在目标位置安全可用：根据响应的去向对其进行检查和处理。对于网页，要防止生成的文本变成可执行代码。对于数据库，要使用预处理查询，将传入的值与命令分开。
• 阻止回答自动建立外部连接：默认禁用模型响应中图片、链接预览和嵌入页面的自动加载。将必要的连接限制在明确批准的目标地址。

Perplexity 如何保障 LLM 的安全？

我们假设上述每一种风险最终都会发生，并据此进行设计，使其即使发生也无法造成太大危害。我们的首席信息安全官 Kyle Polley 在最近的一场研讨会上详细介绍了具体做法。

• 智能体拥有自己的计算机，而且初始状态为空：安装在你笔记本电脑上的智能体工具可以访问电脑中的文件、应用和已保存的凭据。Perplexity Computer 则恰恰相反。每个任务都在各自隔离的沙盒中运行，正如 Polley 所说：“默认情况下，它什么都访问不了。”
• 智能体永远看不到密码：已连接服务的凭据存储在沙盒之外。当智能体需要访问 GitHub 等服务时，它发送的请求不附带任何凭据。网关会检查目标地址和请求是否符合预期，然后在请求发出时添加凭据。智能体可以使用该连接，却拿不到密钥。
• 你的权限会延续过来，而且你还可以进一步收紧：通过 OAuth 建立的连接会保留你在所连接服务中的访问权限。你看不到的内容，你的智能体也看不到。
• 每个网页都被视为陌生人：我们为自家的智能体浏览器 Comet 打造了 BrowseSafe，因为我们测试过的工具在实际使用中无法满足我们的需求。该浏览器会扫描网页及其他外部内容（包括电子邮件），检测其中的提示注入。我们已将模型和数据集全部开源。
• 我们监控智能体及其运行所在的机器：Numbat 位于智能体决定采取行动与工具实际运行之间。Numbat 会记录各款受支持编程智能体的活动，并能在违反所配置策略的操作执行之前将其拦截。Bumblebee 会盘点笔记本电脑、服务器和构建流水线中的软件包，并标记出已知的恶意软件包。两者均已开源。
• 模型提供商不会保留你的数据：我们与第三方 LLM 提供商签订了零数据保留协议。企业管理员还可以将 Perplexity 自身的数据保留期限设置为最短 24 小时。

我们主动构建了 Numbat，原因正如 Polley 用一句话所概括的：“你给智能体的自主权越多，风险就越大。”

LLM 安全常见问题

最安全的 LLM 是哪一个？

没有任何 LLM 能单凭自身就让应用程序变得安全——模型仍然可能把本应读取的内容误当作应当遵循的指令。那些在标准测试中看似强大的防御措施，在压力之下也可能失效。

更好的问题是：哪种配置对你的使用场景来说最安全。这意味着有限的权限、让凭据远离模型、高风险操作需经人工批准，以及由熟悉你防御体系的人员进行测试。

什么是 LLM 漏洞？

LLM 漏洞是指使 AI 系统可能被欺骗、泄露数据或造成损害的弱点，无论这些问题源自攻击者还是系统自身的错误。

十大主要风险分别是：提示注入、敏感信息泄露、过度代理、供应链、数据与模型投毒、无限制消耗、错误信息、隐藏上下文暴露、向量与嵌入弱点，以及不当输出处理。

私有 LLM 安全吗？

在某些方面它是更安全的选择，但并非默认如此。如果你在自己的基础设施或云环境中运行模型，就能对数据处理拥有更多控制权。但没有任何自动化的方法可以防止提示注入、过度代理、投毒或错误信息。

在自托管的情况下，你还需要对下载的模型负责，包括其供应链风险以及它所需的基础设施。