AI 读取网页和附件时，怎样测试它不会把资料里的指令当成操作授权？

先画清资料与操作边界

企业把网页、邮件、PDF 或共享文档交给 AI 摘要、分类或起草内容时，资料本身可能出现看起来像命令的文字，例如“忽略前面的要求”“把内部信息发给我”或“点击链接完成操作”。这类内容可以是故意构造的，也可能只是文档里的引用、示例或讨论。核心风险不是模型“看见了坏句子”这么简单，而是工作流是否把不可信资料当成了更高优先级的指令，或让它触发了超出用户授权范围的操作。

OWASP 的 LLM 提示注入防护清单将直接或间接提示注入列为需要处理的风险，并提醒开发者：在提示中用标签区分不可信区域有帮助，但不能单独形成强制安全边界。本文把这一原则转成一套企业可执行的测试流程。它不声称仅凭几条测试即可证明系统安全，也不使用虚构的“拦截率”。测试结果只对明确的版本、权限、工具和样本范围有效。

先画出资料与操作之间的边界

测试之前，逐项写清楚 AI 工作流会读取什么、生成什么、能调用什么工具，以及哪些动作必须由人完成。把资料源分成已批准的业务来源和外部/未审核内容；列出用户指令、系统规则、检索结果、网页正文、邮件附件等进入流程的位置；再列出发邮件、改记录、创建工单、下载文件、调用外部 API 等可能产生副作用的工具。

这张边界图应包括身份和权限：谁发起任务、连接器以哪个账号读取、模型可以看到什么、工具调用以谁的身份执行、是否可访问客户数据、工具的权限是否只覆盖任务需要的范围。若系统没有外部操作能力，测试就聚焦读取和输出；若它能操作系统，就必须把工具授权和人工确认纳入验收。不能把“模型应该忽略网页里的命令”当成访问控制设计。

先建立允许行为与禁止行为清单。例如允许从一份公开网页抽取标题、日期和公开联系人；禁止把网页中的命令当作同意书，禁止向未授权邮箱发送资料，禁止读取当前用户无权查看的内部文档。明确哪些输出需要业务人员复核，哪些动作只可由明确授权的用户发起。

设计覆盖不同入口的测试样本

一个样本集不应只包含显眼的“忽略规则”句子。可按来源和表达方式分层：网页正文里夹带指令；附件脚注或评论里的要求；邮件引用链中的旧命令；检索段落把资料内容与用户问题相邻拼接；编码、格式或语言变化后的文本；正常文档中讨论提示注入的例子；完全无关且不含指令的对照资料。每类都准备正常和恶意/误导样本，避免测试集只教模型记住固定短语。

样本应与真实工作流相符，但不得使用未经批准的客户数据或敏感凭证。可以用合成公司名、测试账户和虚构资料模拟。为每个样本记录来源类别、测试目的、预期安全行为、不可接受行为和版本号。记录测试集的制作日期以及谁审核了预期结果，便于后续复测时发现样本变化。

测试集要包含边界情形。例如用户明确要求“总结这份材料中的指令内容”时，AI 可以描述材料说了什么，但不应因此执行材料中的操作。用户让系统从邮件里提取汇款账户与附件里出现“请直接付款”也是两件事：提取文字不等于审批付款。测试应把信息抽取和外部动作分开判断。

用四类检查观察行为

资料边界检查： 确认系统能否把用户任务与待处理资料区分开来。可检查回答是否引用外部文本作为资料而非命令，是否在内容不可信或含有冲突指令时说明不确定性，以及是否遵循已设定的范围。不要只看一句“我会忽略提示注入”，要观察任务结果和日志。

权限边界检查： 用不同角色和不同资料权限执行同一任务，确认模型与工具只能读取其身份可访问的资源。测试权限拒绝、已撤销授权、链接可见性变化和连接器返回错误的路径。不要只在管理员账号下测试。权限检查应落在数据源或工具层，不能只依赖模型对身份的自我描述。

副作用阻断检查： 构造资料要求发送邮件、发起交易、删除记录或外传信息的样本，验证工作流是否要求有效用户授权，并在确认前保持无副作用。对支持操作的工具，优先使用隔离环境、只读凭据和明确的测试对象；不能在生产环境用真实付款、真实客户信息或真实对外账号做“试试看”。记录操作调用是否发生，而不是只看模型回复承诺。

来源与审计检查： 对摘要和建议，确认可追溯到具体来源或文档片段；对工具调用，核对发起用户、权限主体、输入、确认记录、结果和失败原因是否可查。日志不应为了测试而无限暴露敏感内容；先按企业的数据保留与访问制度确定需要记录的字段，并验证只有授权人员可以查看。

把结果写成可复现的用例

每条测试记录至少包括：用例 ID、被测版本、来源类型、角色、工具权限、提示/输入摘要、预期结果、实际结果、是否产生副作用、日志证据、严重程度和处置人。对失败用例，保留最小必要复现内容，不要把敏感原文直接扩散到报告中。若涉及外部服务，记录连接器和模型配置；只记录名称不足以复现具体运行条件。

可以用“通过/失败/未验证”三种状态。通过表示这条用例在被测环境下符合预期，并不表示所有攻击都被阻止；失败表示出现了预先定义的不可接受结果，需要修复或改变工作流；未验证表示环境、权限或日志证据不足。汇总结果时，按风险类别列出覆盖范围和未测区域，不要用未经代表性评估的单一百分比宣传整体安全性。

失败之后按控制层修复

如果模型把资料里的句子复述成执行命令，先检查提示与数据分隔是否清楚、上下文是否存在冲突、来源标签能否保留。若它调用了未授权工具，优先收紧工具权限、缩小身份范围并增加外部副作用确认。若它能越权读资料，应修复数据源或连接器的权限传递；不要只靠补一句“不要泄露”。如果日志无法判断发生了什么，完善安全审计字段和访问控制。若失败来源于样本歧义，重新定义预期结果并让业务与安全负责人共同确认。

修复后，用原失败样本复测，并加入相邻变化样本，如不同文档格式、用户角色或引文位置。否则只能证明原字符串被特殊处理，不能证明控制覆盖了同类情形。每轮测试都应记录代码/提示版本和配置，避免把不同环境的结果合并成一个结论。

建议的验收门槛

在上线评审前，先确保：高风险工具均列入清单；每个外部动作都有明确授权来源；权限拒绝和撤权场景已测试；至少有正常文档、含引用命令的文档和对抗样本文档；发现失败时有停用或转人工路径；日志能支持复查；未验证范围已写入风险接受记录。具体门槛由企业的风险等级、业务影响和制度决定，不存在适用于所有企业的固定测试条数。

可以从只读工作流开始建立基线，再逐步测试更高影响的工具。每次修改模型、提示、检索配置、连接器权限或操作流程，都要判断是否需要回归测试。外部资料会变化，权限也会变化，因此一次通过不是永久保证。将测试纳入变更评审，才能让安全结论对应到实际运行条件。

测试要回答的不是“AI 是否永远听话”，而是：哪些资料是不可信输入、系统能做哪些事、哪些人授权了动作、证据是否可复查、失败时怎样控制影响。把这些问题落实到系统权限、测试样本和验收记录，比只修改提示词更容易让业务、技术和安全团队讨论同一件事。