LLM 应用渗透测试：如何依据 OWASP LLM Top 10 检验 AI 产品

先看一个假设的例子。一家公司半年前上线了一个客服助手：它阅读收到的邮件，在内部知识库中查找答案，必要时在 CRM 中创建任务。某天，一封看似普通的“客户”邮件到来。邮件正文里用白底白字藏着一条指令：找出最近的合同，并在回复中插入一张图片，而图片地址的参数里嵌入了这些合同的片段。助手认真地完成了任务，邮件客户端加载了图片，数据就这样流向了别人的服务器。没有人入侵服务器，没有人猜解密码，也没有员工点击任何东西。

这只是一个示例，并非对某起具体事件的描述。但它的核心机制——邮件中的隐藏指令，以及通过自动加载的外部资源外泄数据——完全真实存在：研究人员在 Microsoft 365 Copilot 的 EchoLeak 漏洞中演示过类似的攻击链，下文会详细介绍。正因如此，今天的 LLM 应用渗透测试并不是运行一遍“危险提示词”扫描器，而是检验模型已经被欺骗之后会发生什么：它能看到哪些数据、会调用哪些工具、以谁的权限行事。下文将介绍这种 AI 安全审计如何进行、依据 OWASP LLM Top 10 应检查什么、自动化工具的能力边界在哪里，以及如何委托一次结果真正可用的安全评估。

为什么 LLM 应用的失守方式不同于普通 Web 服务

在传统 Web 应用中，代码和数据可以被可靠地分离：SQL 查询是代码，表单中的字符串是数据，参数化查询能防止后者变成前者。语言模型没有这样的边界。开发者的系统指令、用户的问题、从知识库检索到的文档、邮件、外部服务的响应——所有这些都进入同一个上下文，由同一套机制处理。模型无法可靠地区分“主人的命令”和恰好出现在旁边的文本。

由此产生了最主要的一类攻击——提示注入（prompt injection）。直接注入是指用户自己对模型说“忽略之前的指令”。间接注入则危险得多：恶意指令并非来自对话者，而是来自应用在工作中处理的内容——邮件、PDF、网页、商品卡片、工具响应。攻击者无需访问你的聊天界面，只要把文本放到你的助手会去读取的地方就够了。

这里必须区分具体漏洞和风险类别。基于提示注入的具体漏洞是可以修复的——EchoLeak 就是如此。但这一风险类别本身无法靠一次修改系统提示或一个输入过滤器来消除：这些措施能降低已知攻击的成功率，却不能保证不会出现新的措辞。因此，成熟的做法已经转变：不再试图打造无法被欺骗的模型，而是围绕模型构建系统，使模型被欺骗时不会造成严重后果。重要操作在模型之外授权，工具权限削减到最低，不可逆操作由人工确认。

做快速自评时，研究者 Simon Willison 提出的“致命三要素”（lethal trifecta）规则很实用。它指的是三种属性的组合：智能体可以访问私有数据、会处理不可信内容、能够向外发送信息——邮件、HTTP 请求，甚至回复中的一张图片。这种组合本身并不能证明数据泄露很可能发生，但它是一种危险的组合：一旦存在，就需要单独测试数据外泄场景，并论证它为什么不会得逞。切断三环中的任何一环，是值得与其他措施一并考虑的架构措施之一。

1. 邮件不可信内容
2. AI 智能体将内容当作指令
3. 工具读取私有数据
4. 外部请求将数据传出系统

这是一条示例攻击链。渗透测试需要检查从输入内容、数据访问到对外传输的完整路径。

OWASP LLM Top 10：标准的意义以及 2026 年的变化

OWASP Top 10 for LLM Applications 既不是法规，也不是认证检查清单，而是一种共同语言。它的作用是让开发者、安全团队、渗透测试承包方和审计方以相同方式理解同一类风险，并使报告中的发现可以在不同项目和不同年份之间对比。

当前版本是 OWASP Top 10 for LLM Applications 2026，项目于 2026 年 8 月 3 日发布。部分厂商资料至今仍把 2025 版列表称为“当前版本”，因此首先应向承包方确认其依据的是哪一版。好的报告会同时给出两个编号，例如“LLM03:2026 / LLM06:2025”，使发现在新旧两套坐标体系中都能被正确理解。

2026 版最显著的变化是 Excessive Agency（过度代理）从第六位升至第三位。这反映了 LLM 产品正从聊天机器人转向能够自行调用 API、写入数据库并发送消息的智能体。提示注入仍居第一位。系统提示泄露风险更名为 Hidden Context Exposure（隐藏上下文暴露）并扩大了范围：现在涵盖任何隐藏上下文——策略、配置、用户画像、工具描述。Improper Output Handling（不当输出处理）即对模型输出的不安全处理，在列表中下移，但这只是相对位置的变化，并不意味着通过模型响应实施的 XSS 变得不那么危险。

另一项新变化是：编制排名时，除了从业者的评估外，还考虑了公开事件的数据。无论某个风险在排名中位居何处，对渗透测试而言实际结论都是一样的：发现注入还不够，必须证明它会导致什么——数据泄露、工具滥用、数据篡改或经济损失。

针对带有工具和记忆的系统，OWASP 另外发布了一份列表——Top 10 for Agentic Applications。它描述了简单聊天机器人所没有的风险：智能体目标劫持、工具和权限滥用、记忆投毒、智能体之间的不安全通信、级联故障、对人类信任智能体的利用。如果你的模型拥有工具，就应同时应用这两份列表。

下面是 2026 版主列表的简明速查表，已转换为对产品而言的后果。

上线前值得了解的三个案例

抽象类别最好通过真实故事来理解。以下三个案例展示了三种不同的攻击面：模型本身、模型周围的框架，以及承载一切的基础设施。

事件分析

EchoLeak：一封邮件，零次点击

Aim Labs 的研究人员证明，一封邮件就足以让 Microsoft 365 Copilot 从用户的工作上下文中提取数据，并在无需任何点击的情况下将其发送出去。该漏洞的编号为 CVE-2025-32711。值得关注的不是注入本身，而是一连串的绕过：邮件措辞绕过了本应拦截此类攻击的分类器；特殊格式的 Markdown 链接逃过了去除外部 URL 的机制；图片会自动加载，而请求经由内容安全策略允许的 Teams 域名发出。Microsoft 在服务端修复了该问题，2025 年 6 月公开披露，未报告在真实攻击中被利用的迹象。

对产品负责人的启示是：多个防护机制在同一条攻击链中被绕过，最终使整个系统发生数据泄露。一年前，PromptArmor 的研究人员在 Slack AI 中展示了类似的逻辑：发布在公共频道中的一条指令，促使助手生成一个“请重新认证”链接，链接地址中嵌入了受害者私有频道中的机密。需要检验的不是逐个过滤器，而是从不可信文本到输出通道的端到端路径。

事件分析

LangGrinch：当模型响应变成漏洞利用

2025 年 12 月，LangChain 维护者发布了关于 langchain-core（LangChain 框架的基础包）中漏洞 CVE-2025-68664 的安全公告；相关报道称其为 LangGrinch，描述该问题的研究人员中包括 Cyata 的专家。序列化函数没有对服务键 lc 进行转义，而 LangChain 正是用这个键来标记自己的对象。如果这类数据随后被反序列化，攻击者就能从环境变量中提取机密（在启用从环境加载机密时——这是以前的默认行为），并以自己的参数实例化 LangChain 可信命名空间中的类。根据该公告，受影响的是 langchain-core 1.0.0 至 1.2.5（不含 1.2.5）的版本以及所有低于 0.3.81 的版本；修复已在 1.2.5 和 0.3.81 版本中发布。这是该 CVE 的最低历史修复版本，而不是今天应安装哪个版本的建议：请以当前受支持的版本为准，并检查你的依赖项。

这个故事的关键在于攻击向量。据维护者本人评估，最常见的攻击路径经由模型响应中的服务字段，这些字段可以通过提示注入加以控制，随后会被序列化，例如在流式输出时。这意味着攻击者的文本可能变成对你应用代码的攻击。在这里，“AI 风险”与“普通漏洞”之间惯常的界限变得模糊：只测提示词的测试发现不了这种问题，只测代码的测试也展示不出如何触达它。你需要一个同时审视两个层面的承包方。

事件分析

Langflow：新包装下的老式 RCE

用于搭建 LLM 流水线的低代码平台 Langflow 存在漏洞 CVE-2025-3248：通过代码校验端点实现的未认证远程代码执行。CISA 将其列入在真实攻击中被利用的漏洞目录，Trend Micro 观察到有人借此植入 Flodrix 僵尸网络。没有提示词，没有模型——这是 LLM 开发工具中的典型 RCE。不难想象一种会让此类漏洞格外危险的部署错误——比如一个仍可从互联网访问的实验环境。这是一个假设场景，并非对受攻击者的描述，但这正是渗透测试中值得寻找的那类错误。

模型供应链也属于同一类问题。早在 2024 年，JFrog 的研究人员就报告在 Hugging Face 上发现了大约一百个可能恶意的模型。这个数字描述的是所发现的可疑制品，而不是一百个相同的漏洞利用：每个制品的危险程度取决于其内容和加载方式。研究人员清楚地演示了这种风险机制本身：加载 pickle 格式的模型时，文件中嵌入的代码可能被执行，甚至可以反弹 shell。结论相同：AI 技术栈就是普通的基础设施，老问题一样不少，还增添了新问题。

AI 智能体安全：权限决定损害

即使是没有工具的聊天机器人，也可能泄露机密数据——来自所连接的知识库、隐藏上下文、对话历史。工具在此基础上增加了一类新的后果：系统以自身名义执行的操作和数据修改。成功注入之后究竟会发生什么，取决于智能体能够做什么。OWASP 指出了三个根源：功能过多（“以防万一”给了智能体某个工具）、权限过大（只需读取权限的地方却用了管理员令牌）以及自主性过强（不可逆操作无需确认）。智能体的每个操作都必须经过不依赖模型判断的授权。

在渗透测试中，这表现为：承包方首先清点工具，并查明每个工具以谁的权限运行——以用户身份还是使用共享服务账户。应优先寻找权限宽泛的长期有效密钥：一旦存在这样的密钥，任何成功注入的后果都会急剧加重。然后是各种场景：迫使智能体向外部地址发送邮件；修改其他客户的 CRM 记录（典型的 IDOR，只不过是通过智能体实现）；用“这已经得到领导批准”之类的话绕过确认；在人工批准操作与执行操作之间替换参数。智能体之间的链条要单独测试：如果一个智能体读取另一个智能体的输出，注入就可能在整个系统中传播。

关于如何评估和限制权限，我们在测试 Excessive Agency 与限制 AI 智能体权限一文中有更详细的介绍。

委托 Pentest.red 进行评估的一个好时机，是你的助手获得第一个“写入型”工具的时候：发送消息、修改记录、支付、执行代码。在原有的数据泄露风险之上，又增加了操作和修改带来的风险，威胁模型也应随之重建。

RAG 安全检查：泄露发生在模型之前

RAG（检索增强生成）是一种模式：模型在回答之前，先在内部数据库（通常是向量数据库）中查找相关的文档片段。OWASP 2026 版非常精准地表述了核心观点：如果检索取出了用户无权访问的文档，那么授权失败发生在模型之前。任何“不要显示机密内容”的提示都无法修复这一点——服务器端的检索授权是必需的。

因此，RAG 安全检查首先要问：检索是以谁的身份执行的？如果所有查询都经由同一个服务账户，而“按权限”过滤只是以文字形式写在系统提示中，那么系统在租户之间就没有技术边界，测试必须检查用户 A 能否通过语义相近的问题获取用户 B 文档的片段。承包方会检查服务器端按租户和访问权限的过滤、向量数据库 API 能否被直接访问、与 SharePoint 或 Confluence 等来源的权限同步，以及被删除的文档是否真的从索引中消失。

这一主题的另一半是写入。谁能添加会进入索引的文档：通过反馈表单的客户、通过 wiki 的员工、与工单系统的集成？如果存在这样的路径，攻击者就可以向数据库“播种”在检索结果中占主导并携带指令的文本。这就是 RAG 场景下的数据投毒。在模型权重本身中寻找后门属于模型评估任务，通常不在应用渗透测试的范围内。

我们另文介绍了具体步骤：如何开展基于证据的 RAG 安全评估。

1. 用户角色与租户
2. 访问控制获准访问的文档
3. RAG 检索仅检索允许的片段
4. LLM在权限范围内回答

用户无权访问的文档，其片段就不应进入上下文。提示词中的要求不能代替服务端授权检查。

泄露、隐藏上下文以及模型输出的一切

除了 RAG，机密数据还可能通过一些容易被遗忘的地方泄露：包含完整提示的日志、工具调用记录、响应缓存、会话之间共享的记忆。如果团队为调试开启了详细追踪，其中可能包含个人数据和机密，而对它们的访问权限有时比对系统本身还要宽——这一点值得单独检查。

关于隐藏上下文，最好一开始就达成现实的共识。系统提示应被视为可能被提取的：OWASP 明确建议假定隐藏上下文是可被发现的。由此得出两条规则：系统提示不得存放机密；授权必须在服务器端执行，而不是写在模型指令中。不含机密的提示泄露本身通常是低严重性的发现，而嵌在提示中的 API 密钥或授权逻辑则属于高或严重级别。发现的价值取决于被泄露的内容，而非泄露这一事实本身。

模型输出同样是不可信数据。如果响应在浏览器中以 HTML 或 Markdown 渲染，就可能导致 XSS 以及前面提到的通过图片外泄数据。如果响应被插入 SQL 查询、shell 命令或服务器端请求的 URL 中，就会出现注入和 SSRF。如果模型生成的代码随后会被执行，就需要沙箱。这里的防护是经典的：参数化查询和上下文相关的转义、严格的渲染策略和 CSP、在传给工具之前按模式校验结构化输出。

另一个不那么显眼的类别是无限制的资源消耗。一个精心构造的请求就可能引发模型和子智能体调用的级联：既可能造成拒绝服务，也可能造成“钱包耗尽”（denial of wallet），即攻击者直接烧光你的令牌预算。此类测试要谨慎进行，并且只能在事先约定的费用上限内开展。

最后，模型的回答可能被视为承诺。一个有代表性的例子是 2024 年的 Moffatt 诉 Air Canada 案：航空公司的聊天机器人向客户承诺可以追溯适用丧亲优惠票价，不列颠哥伦比亚省的仲裁庭驳回了机器人是“独立主体”、公司无需为其言论负责的主张，并在该案中认定航空公司负有责任。这是基于具体事实、在特定司法辖区作出的裁决，并非普遍适用的法律规则，但它表明，用“那是机器人说的”来推脱未必能保护你。在渗透测试中，值得检查能否迫使助手确认一个不存在的折扣、退款条件或具有法律意义的措辞，以及系统是否会基于未经核实的回答触发操作。

扫描器的能力边界

用于测试 LLM 的自动化工具确实有用。NVIDIA garak 用大量攻击探针测试模型，Microsoft PyRIT 借助攻击方模型编排多轮攻击，promptfoo 将检查嵌入 CI/CD 并提供 OWASP 预设，Giskard 也能扫描 RAG 场景。这些工具作为回归测试效果很好：每次修改提示或模型后，确认已知攻击没有卷土重来。

局限不在于扫描器从根本上无法测试授权或多步攻击链，而在于通用的扫描运行不会去做这些。如果不了解产品、没有基于角色的账户和专门编写的场景，工具就不知道对某个用户而言哪些文档属于“别人”、你有哪些工具、什么算作损害，因此无法完整覆盖跨租户泄露或“邮件 → 检索 → 工具调用 → 数据外泄”这样的链条。带有此类角色和场景的定向自动化是可以构建的，而且是人工测试的宝贵补充。另外还要记住模型周围的代码，例如 LangGrinch 的情况——它需要用其他方法检查。garak 的作者在论文中明确写道，该工具不覆盖代码执行和访问控制不足的问题。一项对几款流行扫描器的独立比较也表明，自动化评估器在判断攻击是否成功时会出现明显错误。

更发人深省的是由 OpenAI、Anthropic、Google DeepMind 和 ETH Zürich 的作者完成的研究《The Attacker Moves Second》。他们选取了十二种已发表的提示注入和越狱防御措施（其中大多数声称攻击成功率接近于零），并对其进行自适应攻击——针对每种具体防御量身定制攻击。对大多数防御而言，成功率超过 90%。这是针对特定防御和模型的实验结果，而不是任何产品被攻破的概率。但结论是可靠的：静态测试集和自适应攻击者是不同的对手，在前者面前表现良好的防御，未必能抵挡后者。

还有一个纯技术层面的特点——非确定性。例如，同一次攻击可能在十次尝试中成功三次。这是在给定测试条件下（具体的模型、版本、设置、上下文）观察到的结果，而不是攻击在生产环境中成功的概率。一次失败同样说明不了什么，因此规范的发现会注明尝试次数、成功占比、模型版本和日期。缺少这些信息的报告既无法复现，也无法在复测中验证。

为避免混淆不同类型的工作，有必要把它们区分开。表中的 AI 红队测试指的是一种狭义形式——内容安全测试，即检验模型违反可接受内容政策的倾向；在实践中，这个术语也用于更广泛的演练，直至对系统的全面攻击。

LLM 应用渗透测试如何进行

工作从界定边界开始，而不是从攻击开始。承包方与团队一起明确系统的组成：哪些模型及版本、哪个编排器、哪些工具及其权限、哪些数据源接入 RAG、是否有记忆和 MCP 服务器、输入通过哪些通道进入、存在哪些角色和租户、哪些数据和操作对业务至关重要。

接下来构建威胁模型——一张标注了信任边界的数据流图。从图上可以看出不可信内容在哪里与私有数据相遇，以及系统在哪里有对外通道。威胁会被映射到 OWASP LLM Top 10、智能体列表和 MITRE ATLAS——一个关于 AI 系统攻击技术的知识库，可以看作机器学习领域的 ATT&CK。

LLM 项目中的侦察有其特殊性：提取系统提示和工具描述、识别模型和框架、枚举 API、搜寻暴露在外的面板（例如前面提到的 Langflow）。随后进入主要的人工部分：针对具体业务逻辑定制的注入、多轮场景，以及通过改写、编码和翻译成其他语言来绕过过滤器——主要针对英语调校的防御措施，值得单独用其他语言（例如俄语）进行测试。对智能体要测试超出场景的调用、参数替换、绕过确认以及通过工具输出传递注入。对 RAG 要测试检索授权、隔离以及投毒的可能性。

传统攻击面必须单独检查：认证、文件上传、通过“按 URL 获取页面”工具实施的 SSRF、聊天组件中的 XSS、存在漏洞的依赖项。仅限于提示词的测试会让这部分攻击面未经检验，而那里同样会出现严重漏洞——Langflow 的例子清楚地说明了这一点。

访问方式对结果影响很大。黑盒贴近现实但成本高：需要还原提示和工具，而且由于非确定性，很难区分“没有漏洞”和“运气不好”。灰盒是合理的基线：提供多个角色和租户的账户、架构说明、工具清单、系统提示，以及可显示上下文内容和工具调用情况的追踪访问权限。白盒增加了编排代码、IAM 设置和 RAG 流水线，有助于详细研究集成情况——数据如何序列化、权限在哪里检查。像 LangGrinch 这样的存在漏洞的库版本，也可以通过检查依赖项版本发现，无需完整访问代码；白盒则能帮助判断该漏洞在你的具体应用中是否可被触达。

1. 范围系统、角色与限制
2. 场景人工测试与攻击链
3. 发现证据与实际影响
4. 复测修复后重新验证

自动化测试补充人工评估。每项发现都应记录测试条件、尝试次数和观察到的结果。

如何评估发现的严重性

CVSS 很适合 Langflow 中 RCE 这样的“经典”漏洞，但难以体现注入的概率性特征：一次在二十次中成功一次、却会导致整个客户数据库泄露的攻击，需要不同于稳定 XSS 的解读方式。OWASP 正在开发一套独立的评分体系 AIVSS，它建立在 CVSS v4.0 之上，并增加了针对智能体因素的修正——自主性、工具访问、对其他系统的影响。该项目仍在发展中，早期版本以草案形式发布，因此如果你要依赖它，请确认当前版本，并注意系数可能会变化。

目前的实用做法是结合多个维度：带向量的 CVSS v4.0 基础分、明确的观察成功率（在测试条件下多少次尝试中成功了多少次）、业务影响（哪些数据和操作变得可触达），以及对于智能体相关发现，将 AIVSS 作为额外参考。关键在于严重性要有依据，而不是凭感觉估计。

报告应是什么样子，为什么需要复测

报告是记录渗透测试结果的主要文件，与之并列的还有与团队一起逐项复盘发现、用于回归测试的场景以及复测。它最能体现真正的工作与走过场之间的区别。在好的报告中，每项发现都可复现：确切的提示和输入数据、包含上下文、工具调用和响应的完整日志、尝试次数和成功占比、模型版本和日期。报告中有有依据的严重性评估，映射到 OWASP 2026 和 2025、智能体列表以及 MITRE ATLAS，并清楚描述业务后果。另外还应有管理层摘要，以及对评估范围和限制的说明。

高质量报告中的建议应包含架构措施，因为一次修改提示并不能消除这一类风险。这些措施包括：最小权限和短期令牌；以用户而非服务账户的身份执行操作；不可逆操作由人工确认；区分可信指令与不可信数据；模型之外的访问策略引擎；输出编码并禁止自动加载外部图片；上下文中不放任何机密；RAG 中的服务器端过滤；限额和配额；模型组件清单和安全的权重格式；记录工具调用日志。

复测不是走过场。LLM 系统中的修复往往具有概率性：团队修改了提示措辞，攻击在三次尝试中都不再成功，但在第十次时又通过了。使用可比的场景重新测试，可以评估修复后是否仍能复现该问题。应记录尝试次数和条件：在有限样本中没有攻击成功，并不能单独证明风险已被完全消除。

何时委托评估以及如何准备范围

LLM 应用渗透测试的自然时机包括：公开上线；添加智能体、工具、MCP、记忆或 RAG；更换模型或供应商；更改防护机制或数据流水线。另一个契机是客户和监管机构的要求，但在这里切勿夸大。在欧洲，《人工智能法》第 15 条要求高风险系统达到适当水平的准确性、稳健性和网络安全，包括防范数据投毒和对抗性攻击的措施；这并不是普遍要求委托外部渗透测试，但评估结果可以成为合规证据的一部分。在俄罗斯，对含 AI 系统的保护要求载于俄罗斯联邦技术与出口管制局（FSTEC）关于国家信息系统信息保护的第 117 号令中；其适用性和具体措施取决于系统的类型和级别，因此应向合规专家确认。

渗透测试的质量很大程度上取决于准备工作。承包方需要了解系统的组成：界面、编排器和库的版本、模型、向量数据库、记忆、MCP。需要一份注明权限并标出哪些操作不可逆的工具清单，以及一份数据源清单，说明谁能向其写入。需要至少两个角色和两个租户来测试隔离，以及一个接近生产环境、使用合成数据的测试环境。

事先约定令牌预算和停止阈值、测试时间窗口、联系人以及发现严重问题时的处理流程。明确规定禁止事项：不真实发送邮件和付款（只用桩/模拟），不对生产环境施加负载，不进行无法回滚的索引投毒，遵守模型提供商的使用规则。并且务必提供追踪记录的访问权限——没有它们，许多发现既无法证实也无法否定。进行这种准备时，一个方便的模板是渗透测试范围表单。

如果你计划与 Pentest.red 讨论评估，请在第一次会面时带上架构图、智能体工具及其权限清单、RAG 来源清单以及角色和租户说明。通常这些就足以共同确定合理的边界和访问方式。

如何选择承包方

AI 安全市场还很年轻，同一个名称下销售的服务差异很大。询问承包方在智能体和 RAG 方面的实际经验，并索取一份脱敏的样例报告：从中可以迅速看出是否有证据和业务影响分析。确认他们依据哪一版 OWASP，以及是否考虑智能体列表和 MITRE ATLAS。了解人工工作所占比例、使用哪些工具以及如何验证其命中结果、每个场景尝试多少次以及如何记录成功率。务必询问他们是否测试授权、租户隔离、API 和依赖项，而不仅仅是提示词；如何评估严重性；是否包含复测；是否提供架构建议。单独的一个问题是机密性：是否使用外部模型生成攻击，以及在这种情况下你的提示和数据会流向何处。

以下情况应当警惕：有人提议“一天之内用 AI 扫描器把你的机器人扫一遍”；样例报告只有截图而没有损害场景；讨论范围时没人询问智能体权限和租户；承诺“注入将变得不可能”；没有费用上限和停止流程；承包方依据 2023 版编号工作。关于如何按工作范围、方法和结果比较各家报价，请参阅我们的AI 安全评估服务选择指南。

我们尚不知道的事

坦诚地讨论 LLM 安全，就必须承认数据存在空白。目前没有可靠的公开统计说明有多大比例的 LLM 应用易受某种风险影响：厂商的数据基于其自身客户群，彼此不可比。IBM 与 Ponemon 关于 2025 年数据泄露成本的研究常被引用，但其样本是 600 家已经发生过数据泄露的组织。在该样本中，13% 报告发生过影响其 AI 模型或应用的事件，而这 13% 中几乎全部缺乏适当的 AI 访问控制。这说明被研究的子群体存在访问控制问题，但它既不是所有公司中的占比，也不是你的公司发生事件的概率。

针对智能体的攻击基准测试结果同样不能直接套用：它们是在特定的模型、任务和防御上得出的，而且基准本身很快会过时——在旧测试集上表现良好的防御，在新测试集上可能明显逊色。部分重要研究目前仍只是预印本，针对智能体风险的评分体系也仍在形成之中。这些都不是推迟评估的理由，而是要求承包方在你的系统上拿出证据、而非引用他人百分比的理由。

评估结束后应要求什么

如果把一切归结为一个决定，那就是：需要检验的不是模型，而是围绕模型的系统；不是在理论上，而是在你的产品上，结合你的权限、数据和工具。把扫描器留给 CI/CD 中的持续回归测试，而在上线前以及每次扩大权限后，委托包含大量人工工作的渗透测试。

如果你正准备上线聊天机器人、RAG 系统或带工具的智能体，或者扩大了已投入运行的 AI 产品的权限，可以在我们的渗透测试服务框架下与 Pentest.red 团队讨论评估的范围和形式。评估结束时，应要求上文所述、也是我们建议向任何承包方提出的成果：附有尝试次数和成功率的可复现发现、使用测试数据安全演示业务影响的场景、映射到 OWASP 和 MITRE ATLAS 的有依据的严重性评估、架构建议以及对修复的复测。