渗透测试通过后，AI Agent 仍可能越权执行

渗透测试全绿，AI 客服仍可能把客户邮箱批量导出。问题可能出在另一条路径：用户编了一个财务总监的身份，Agent 就动用自己的合法权限照做了。原文用这个假设场景说明，基础设施安全和 Agent 行为安全，需要分别验证。

作者的结论很明确：保留传统渗透测试，再增加 AI 红队测试，并在模型、提示词、工具或数据源变化后重复运行。对正在给 AI 接订单、邮件、退款工具的开发者，这比单独讨论模型会不会听话更有用。

系统权限没被突破，为什么数据还是会泄露

原文开场设定了一家公司：AI 客服可以查订单、改客户资料、发邮件，还能在限额内退款。上线前，端口、认证、API 都通过了渗透测试；三周后，有人自称财务总监，要求导出全部客户邮箱，Agent 照办。

这里的三周是故事设定，不是作者披露的真实事故时间线。

传统渗透测试检查的是服务器、网络、应用漏洞、登录会话，以及 Agent 连接的 API 和工具服务器。它能回答攻击者能否绕过认证，却未必能回答：一个已经拥有权限的 Agent，会不会被对话诱导着滥用权限。

拥有调用工具的资格，不等于当前请求有权触发这次操作。

例如，Agent 的服务账号可能确实有导出数据的权限，但用户自称财务总监，并不能证明其身份，更不能证明其有权导出全部客户数据。原文关注的正是这层判断。

这也不代表传统漏洞退场了。作者引用 Microsoft AI Red Team 的材料称，该团队测试了超过 100 个生成式 AI 产品，并在一个视频处理 AI 应用中记录了服务器端请求伪造（SSRF）漏洞。这是被引用的外部发现，不是作者自己的测试结果，也不能据此算出漏洞发生比例。

红队测试要从具体的越权动作开始

AI 红队测试通过模拟攻击者与 Agent 交互，观察它实际采取了什么行动。测试对象包括用户消息，也包括它读取的邮件、工单、文档和工具返回内容。

其中一个关键风险是提示注入（prompt injection）：Agent 本来应该把工单当作待处理的数据，却把工单里藏着的指令当成了行动依据。谁能写入这些内容，谁就可能尝试影响它。

作者给出了一套六步流程，要求全部放在预发布环境，使用测试账号和虚假数据，不接触生产凭据：

1. 保留渗透测试，让它继续覆盖服务器、网络、登录、API 和工具服务器配置。
2. 列出 Agent 能接触的所有工具、数据和文档，同时记录谁能修改这些内容，别漏掉开发者在本地添加的工具。
3. 把风险写成具体攻击目标，例如超额退款、向外部地址发送客户记录、把密码重置到未经验证的邮箱。
4. 每个目标至少设计一条 5 到 10 轮的对话路径，并在文档、工单或工具输出里植入至少一条隐藏指令；遭到拒绝后，继续改写请求。
5. 每种攻击重复运行多次，按明确规则评分，并统计各类攻击的成功率。
6. 每次更换模型、修改提示词、增加工具或数据源后，重新运行整套测试，并逐步自动化。

这里最有价值的是把测试目标写成动作。「测试数据安全」很难执行；「尝试让 Agent 把客户记录发送到外部地址」则有明确的输入、执行过程和失败标准。

多轮对话也有必要。第一次拒绝，只能证明它拒绝了当时的请求，不能证明它在第十条消息中仍能守住边界。

看起来拒绝了，不代表工具没有执行

作者强调，评分要检查工具调用，不能只读最终回复。

如果 Agent 对用户说无法提供数据，却已经调用邮件工具发送了客户记录，这次测试仍然失败。任务是否完成，也不能抵消中途发生的违规动作。原文给出的标准很严格：出现一个危险信号，整次运行就判失败。

作者还举了一个概率例子：如果某种攻击每十次成功一次，单跑一次就有 90% 的概率漏掉它。这个计算假设攻击成功率稳定、各次运行相互独立；它不是文章实测出的攻击成功率。

测试顺序则取决于系统能力。能转钱、发消息、改记录的 Agent，应在上线前做 AI 红队测试；会读邮件、网页、工单、文件的，应测试隐藏指令；连接第三方工具服务器的，需要同时检查服务器认证和其返回描述对 Agent 的影响。新云环境或新暴露的 API，先做渗透测试；模型、提示词或工具刚改过，则重跑行为测试。

我的判断

我认同作者把两类测试分开处理。对接入业务工具的 Agent，仅证明接口认证有效，确实不足以证明每次业务操作都得到正确授权。

但这篇文章更接近测试方法建议，没有展示完整对话、工具调用记录、模型版本，也没有给出这套流程与其他方案的对照数据。六步流程可以拿来组织工作，不能当成已经验证过的防护效果。

开场故事也缺少一个关键细节：导出接口到底有没有独立校验请求者身份和数据范围。如果后端允许 Agent 凭一句身份声明导出全量数据，问题就同时涉及授权设计，不能全部归到模型被说服。

和只在提示词里写禁止事项相比，我更倾向于把退款限额、收件地址限制、数据访问范围落实到工具服务端，再用红队测试检查整个调用链。模型可能判断失误，执行层仍应有清晰的业务边界。

红队测试能发现边界失守，服务端授权则应限制失守后的后果。

此外，一组攻击全部通过，只能说明它通过了这组测试。原文没有交代攻击覆盖率、重复运行次数或可接受风险阈值，这些仍需要团队自行定义。

能拿来做什么

• 给 Node 服务接入 AI 工具前，整理一张能力表，写清每个工具能读写什么、执行时依据谁的身份授权，并逐项确认退款限额和数据范围由服务端校验。
• 从已有客服流程中选出超额退款、外发客户记录、修改重置邮箱三个具体目标，在预发布环境各编写一条 5 到 10 轮的攻击对话，并加入隐藏指令。
• 为测试记录完整工具调用，包括参数、目标地址和实际结果；让违规调用直接触发失败，避免最终回复掩盖已经执行的动作。
• 把成功诱导过 Agent 的对话保存为回归用例，在模型、提示词、工具和数据源变化后自动重跑，并保留按攻击类型统计的成功率。