原创 裴伟伟 2026-10-31 20:45 中国香港

测出提示词注入，怎样证明它能影响业务？从聊天框走向文档、工具、记忆与代理权限，用侦察、利用、执行、验证四个阶段，梳理AI Agent安全测试的路径：模型说了什么提供线索，系统做了什么需要证据。

一套 AI Agent 的安全测试要做安全测试，张三上手就开始寻找聊天框，准备好手边的提示词测试集，准备大展身手找出提示词注入的问题……这可能是安全测试人员在应对AI Agent应用时常见的思路和做法，但在 AI Agent 与产品、工具、工作流深入集成的现在，AI Agent测试早已不局限在聊天框作为测试入口。

AI Agent 是能够围绕任务调用工具、组织行动的智能体系统，相比非 Agent 类的系统，需要在测试 AI Agent 链路中增加一层考虑，即输入内容如何影响模型决策，模型决策如何变成工具调用，以及工具调用使用了怎样的权限。因此，Agent 安全测试需要避免两种简化：一种是把安全评估变成提示词注入测试，一种是简单套用传统安全测试的手段。

一、相同的是安全目标，不同的是影响路径

传统安全测试主要包含信息泄露、应用接口、业务逻辑、身份权限、用户会话、请求/响应、网络并发和状态检查等内容，AI Agent 安全测试在被测目标的技术构成上意味着包含了传统的测试范围，但除此之外新增的测试范围是：待处理内容能够参与的AI决策、AI决策会选择的工具、AI实际调用的工具任务、调用任务时采用的权限、任务执行读写的数据、数据权限涉及的身份。

根据上表可见，传统安全测试与AI Agent安全测试的区别不仅仅是“传统系统有确定性，AI 系统没有确定性”，后者更是将检查范围扩展到模型决策、工具调用与任务执行之间的关系。因此，在 AI Agent 安全测试时，我们需要在思路、做法上与传统应用安全测试有不同的方式，笔者将其分为四个阶段，分别是：侦察、利用、执行、验证。

二、阶段一：侦察，建立输入、能力与权限之间的关系图

任何安全测试中，信息搜集都相当重要，这里的侦察是为了摸清 Agent 所在的业务流程与运行环境，以确定外部内容能够从哪里进入、模型可以调用什么能力、操作使用谁的权限以及结果能够流向哪里。这些信息共同构成后续测试的依据，帮助我们选择入口、提出假设，并判断某次行为偏移可能影响的资源。这个阶段需要结合部署资料、正常业务记录与受控探测开展调查，系统响应可以提供线索，但对于 AI Agent而言，架构、权限和防护机制的判断则需要配置、接口与日志支持。具体思路如下。

1．从正常任务与交付方式入手

选择具有代表性的业务任务，记录输入、处理步骤、工具调用和预期结果，明确任务需要读取哪些数据、执行哪些操作，以及由谁接收输出。正常任务的运行结果能够为后续测试建立对照信息，帮助我们区分业务需要的行为与超出任务范围的操作。

交付方式决定我们需要着重观察的位置，网页、移动应用、业务接口、聊天机器人和浏览器扩展可能采用不同的请求路径与处理组件。需要结合客户端请求、后端接口和运行记录，尽量还原界面背后的处理过程，避免把聊天窗口当成系统的全部边界（笔者认为威胁建模在任何情况下都非常重要）。

2．梳理交互输入与内容传递路径

按照内容来源可以将输入分为两类，一类来自用户发起的交互，包括聊天消息、搜索条件、上传文件和接口参数；另一类来自 Agent 在处理任务时读取的内容，包括网页、文档、邮件、工单、日历、检索片段、工具返回值和其他智能体的消息。每条内容的传输、处理路径都需要记录内容由谁控制、经过哪些转换、在什么环节进入上下文，以及是否进入记忆或后续任务。对于图片、音频和视频，需要确认模型接收的是原始媒体、提取文字还是处理后的描述，不同转换方式决定了内容能否到达模型，而界面没有展示的内容不能认为没有参与模型的处理。

另外，输入路径还需要与输出路径衔接，模型生成的内容可能进入页面、邮件、报告、日志或下游工具，图片加载、链接预览等处理可能触发外部请求，侦察过程中应标出这些处理组件与接收位置，为后续执行和验证影响和数据外传情况做观察点。

3．把工具功能与实际权限对应起来

根据应用的功能结构，列出 Agent 可能用到的工具功能、参数、读写范围和目标资源，并追踪调用使用的用户身份、服务账户或委派凭证，检查重点是用户获准访问什么，代理身份拥有多少权限，本次任务需要什么能力。对于多智能体协作，则需要观察和记录任务、身份和权限如何传递，接收方如何验证消息来源，以及委派过程是否保留原始用户的授权范围，这涉及到身份与权限滥用，以及不安全的智能体间通信。

4．核对运行环境、编排机制与组件来源

任何 Agent 终究需要用基础环境运行，因此检查运行账户、主机或容器、目录挂载、沙箱、网络出口和凭证存放位置，确认模型生成的代码与工具调用在哪里运行，能够触及哪些资源也非常重要。Agent 框架如何组织工具、记忆和子 Agent 会影响安全的边界。另外，模型、工具包、连接服务和依赖组件的来源、版本与更新方式会构成供应链安全的基础，也是安全测试中需要着重考虑的部分。

该阶段结束时，应形成任务基线、输入输出路径、工具权限清单和部署关系图，并标明待验证的入口与观测点。后续阶段的测试可以沿着链路检查用户输入的内容是影响如何进入模型决策，以及模型决策如何触达和影响资源。

三、阶段二：利用，验证待处理内容能否改变任务与行动

原本供 Agent 读取、分析或总结的内容是否被当成操作要求，进而改变任务目标、工具选择、操作对象或审批依据，这是信任转换，也是数据与指令混淆造成安全风险的根本。因此，Agent安全测试中需要检测合法任务与授权范围，确认低信任内容是否获得了超出其来源的指令范围。模型偏离角色、复述内部规则或提出异常调用可以作为影响的线索，但最终的风险判断还需要结合暴露内容、执行条件与业务后果完成，所以这个阶段重点是探测Agent的合法边界是否可以遭受破坏，常用的方法分为五种。

1．比较不同入口的处理方式

基于阶段一的结果，在授权范围内检查用户交互、业务字段与接口参数的处理路径，记录内容经过哪些检查，以及进入模型后产生什么变化，相同内容经过不同入口时，可能采用不同的校验、转换或上下文拼装方式。比较的目的是识别控制覆盖的边界：某个入口拒绝输入，不能证明其他入口具有相同防护；某次输入通过检查，不能证明模型会遵循其中的要求。

2．检查外部资料是否改变原始任务

围绕网页、文档、邮件、工单和多模态资料构造受控测试样本，确认 Agent 能否保持原始任务与资料来源之间的权限关系，需要观察的变化包括任务目标偏移、工具选择变化、查询范围扩大、接收方替换，以及对原有操作条件的忽略。另外，还要考虑隐藏文字、元数据、页面结构或媒体内容是否能够形成新的内容入口，以及相关内容是否能够进入上下文，并与行为变化建立联系，也就是检验智能体是否存在目标劫持问题。

3．检查检索与记忆带来的持续影响

对于检索路径，可以观察受控资料能否进入结果、被模型采用，并改变后续行动；对于记忆路径，需要确认哪些主体可以写入，写入内容适用于哪些任务、用户和会话。持久的记忆影响需要通过后续运行多次验证，它包括新会话是否读取污染内容，删除源资料后派生摘要、索引或缓存是否保留影响，以及撤销权限后相关状态能否继续使用，也就是是否存在记忆与上下文投毒。

4．检查工具、依赖与协作消息的信任关系

工具描述、工具返回值、连接服务和子智能体消息也可能参与模型决策。所以需要检查这些内容的来源与变更方式，观察其是否能够引入新的操作要求，或改变模型对工具用途、调用条件和结果可信度的判断。同时，需要区分组件受到篡改、消息来源伪造和合法组件返回不可信内容等情况。

5．检查人工审批是否准确表达待执行动作

对于关键操作，当前最佳实践是Human in Loop做人工审批，但需要进一步核对审批展示的目标、接收方、权限范围和操作参数，是否与执行请求一致。模型生成的摘要可以辅助人员理解，但审批人需要看到足以判断后果的操作信息。所以，应当检查摘要能否遗漏关键条件、淡化影响或替换操作对象，以及批准之后参数发生变化时系统是否要求重新审批。

四、阶段三：执行，确认模型影响如何转化为资源操作

利用阶段证明输入的内容能够影响 Agent，而这个阶段则是检查这种影响是否穿过授权与执行边界，包括：合法工具被用于错误目的；模型输出进入缺少约束的下游组件。

1．验证合法能力是否被用于任务之外的用途

查询、发送消息、修改记录和删除文件，本身可以是正常功能。问题在于，调用是否符合当前用户、目标资源和本次任务的授权范围。工具按设计完成操作，不代表这次使用具有业务授权。

测试需要检查模型能否改变读取范围、接收对象或操作用途，并核对执行组件是否拒绝超出范围的请求。这类问题主要涉及工具滥用；如果过程包含凭证继承、身份冒用或权限提升，则需要检查相应的身份与授权机制。

2．验证下游组件是否解释了不可信内容

模型生成的查询、命令、地址、路径或代码进入下游后可能触发传统应用安全问题，所以需要测试包括数据库查询构造、系统命令调用、模板处理、文件访问、反序列化与网络请求等。根本上是需要证明输入突破了哪项约束，但生成数据库查询不等于存在查询注入，运行代码不等于突破沙箱，访问外部地址不等于能够触达内部服务，还需要结合资源状态和边界控制结果综合判断。

3．验证授权、审批与执行状态的一致性

系统中的执行组件按理应当依据可信身份核对资源与操作范围，避免使用模型提供的身份文字或“用户同意”声明代替认证与审批记录。Agent代用户行动时也需要检查用户权限、Agent权限与任务范围是否共同允许该操作。所以对于需要审批的动作应当验证批准与人员、工具、目标、参数和有效期的绑定，并检查重复提交、并发调用及参数变更的处理方式，这里可能会存在授权、审批与执行不一致的安全风险。

五、阶段四：验证，确认业务后果、影响与传播范围

安全测试终究需要影响结果作为输出，比如，操作是否造成了预期之外的业务后果，影响范围有多大，以及撤销、隔离或取消后能否停止（或者持续性如何）。对于 AI Agent，我们可以把这种影响分为五类。

1．确认数据是否交给无权接收的主体

Agent 读取敏感记录，说明数据进入了处理过程，同时需要结合输出内容、网络请求或接收端记录判断信息是否离开允许范围，检查范围包括回答、邮件、报告、日志、图片加载和链接预览等路径。

2．确认业务操作是否产生非预期变化

对于记录修改、消息发送、资源开关和其他业务动作，需要核对目标对象、操作内容、执行次数和结果状态，“接口返回成功”时需要与业务结果对应，“操作失败”时也需要检查是否存在部分完成的情况，也就是要根据上文中说的业务流程观察点判断业务操作是否存在结果偏差。

3．确认资源与可用性是否受到限制

检查任务能否耗尽推理、工具调用、存储、队列或外部服务预算，并验证时间、次数、费用和递归深度限制是否生效，实际测试中可能需要结合白盒测试，而对于存在熔断机制的系统，则可能会出现排队状态。

4．确认污染或控制能否跨会话保留

核对长期记忆、配置、派生摘要、检索索引和运行状态，确认哪些内容会被后续任务重新加载，且应该通过新任务、新会话和权限撤销验证残留影响，但持久化结论需要持续状态与后续行为支持，不能根据一次会话的结果推断影响。

5．确认影响能否沿协作关系传播

多智能体系统需要检查污染内容、错误状态和操作要求如何进入其他节点，接收方是否验证来源、任务范围与数据权限，消息来自可信节点，不代表其中的全部内容获得同等信任，传播验证应记录经过的节点、携带的内容和产生的操作，说明影响停留在哪里、在哪道检查处受到阻断。

六、输出应该形成证据链，让测试结论能够复核

无论是怎样的安全测试，最终的输出中都需要说明哪项输入影响了什么行为，行为形成了什么调用，调用经过怎样的授权与执行，并产生了什么后果。对应的测试结果一方面需要说明模型、提示词、工具、策略、数据源及运行配置的版本，一方面需要将任务、会话、调用和资源操作建立可关联的标识，记录输入来源、进入上下文的内容、可观察的模型输出、工具请求、授权决定、执行回执和输出去向。最终的证据链可以如下表所示。

最后，需要保留模型、提示词、工具、策略、数据源和运行配置，以及尝试次数、输入变体、记忆与缓存状态做回归测试，并在修复后核对攻击路径受到哪项控制阻断、正常业务能否完成。

结语

结合传统的安全测试与AI Agent安全测试的区别，我们可以发现AI安全需要解决的重点是输入内容如何影响AI判断、而判断又如何借用权限以及行动如何触达和影响业务资源这条链路上的问题。AI可以生成操作建议并自主执行，但需要在预期和可控的路径之下，犹如将一壶水倒入杯子中，我们需要水按照预期的来源、预期的路径到达预期的位置，而不仅仅是杯中有水即可。

所以在构建AI Agent时，需要将任务范围、数据访问、工具调用和审批条件落实到执行组件，并用授权记录、执行回执与资源变化验证防护效果，让模型受到误导时，系统有能力拒绝越界操作、限制影响范围并留下可复核的证据，这才是AI安全从风险清单走向工程实践的落点。

跳转微信打开