Agent的五类风险可以按指令与意图、生成内容、数据与隐私、任务规划与执行、供应链进行拆解。工程落地时，需要把每类风险对应到真实的数据入口、工具调用和状态变化，而不能只在最终回答前增加一次过滤。本文用一个工单Agent说明检查位置、验证证据与测试方法，所述场景为设计示例。
这五类是便于工程分析的维度，并不代表执行顺序。生成内容可能发生在调用工具之前，供应链问题可能影响全部环节，同一次异常也可能跨越多个风险维度。
一、先把一次任务展开，再寻找安全控制点
假设用户要求"查询工单进度并整理待办"。应用接收指令，检索工单和附件，生成后续计划，选择工具，读取结果，最后形成摘要。若具备更新工单能力，还会出现真实的写操作。
可以先按照以下关系理解链路：用户与任务边界 → 资料检索 → 计划与工具选择 → 参数和授权校验 → 实际执行 → 结果核验与输出。组件和运行环境为整条链路提供支撑。
这里的"计划"指显式的动作序列或工具调用提议，不要求采集模型隐藏的思维过程。能够记录动作目标、参数、授权依据和执行结果，就可以开展大量有效检查。
| 风险类别 | 关键问题 | 建议检查位置 |
|---|---|---|
| 指令与意图 | 任务是否被外部内容带偏 | 输入及资料进入上下文时 |
| 生成内容 | 产物是否适合其接收方 | 回答或中间结果交付前 |
| 数据与隐私 | 当前身份是否有权使用这些数据 | 检索、外发和存储边界 |
| 任务规划与执行 | 动作是否符合授权和当前状态 | 工具执行前及结果返回后 |
| 供应链 | 组件及版本是否可信 | 接入、升级和运行检查时 |
表中的控制点是设计建议。具体应用可以合并实现，但应确认所有实际调用路径均经过必要校验，不能只在演示使用的入口上生效。
二、指令与意图风险：把资料和授权分开处理
工单附件可能包含要求更改任务、读取额外数据或调用工具的文字。如果编排层把附件原文与用户要求混在一起，模型可能错误理解这些内容的角色。
建议保留消息来源、资料来源和任务范围，明确检索结果属于待分析的数据。任务授权应由应用可信状态维护，不能因为文档自称"管理员要求"，就扩大当前可执行动作。
测试时，保持用户任务不变，分别替换正常附件和含任务干扰内容的附件，比较工具选择、数据访问和最终结果。成功标准不仅是模型说"拒绝"，还要确认未发生额外的读取或写入。
语义识别适合帮助发现偏离任务的内容，但需要与确定性的操作限制配合。任务只允许读取时，即使模型生成了修改参数，执行层也应拒绝写操作。
三、生成内容风险：检查所有会被消费的产物
Agent输出包括给用户的答案，也包括提交给工具或下游Agent的摘要、字段和代码。风险可能来自不当内容、敏感信息、具有危险用途的代码，或缺少依据却被下游当作事实使用的结论。
对于用户阅读的结果，应结合业务场景检查内容与依据；对于程序处理的结果，应验证结构、字段类型、允许值和业务含义。JSON能够成功解析，只说明语法符合要求，不能证明其中的目标资源或操作范围合法。
例如，工单摘要生成了"问题已经解决"，但实际状态仍是处理中。应该依据可信的状态查询修正输出，而不是让模型自行补齐一个看似完整的成功故事。
测试应分别断言内容与状态：输出是否包含禁止交付的信息，是否与工具回执及业务事实一致。对于流式输出，也需要明确敏感内容在发送后无法靠后续修改撤回，选择适合业务的检查时机。
四、数据与隐私风险：检索权限必须来自可信身份
工单Agent可能同时接触用户资料、附件、历史对话和内部知识。需要检查的不只是回答有没有泄露，还包括检索是否越权、内容是否被外发、记忆是否串用，以及日志是否保存了多余信息。
应用可以在查询时依据当前身份和租户范围过滤，并在资源访问边界再次验证授权。模型可以提出搜索条件，但不应自行决定自己的租户、身份或访问范围。
缓存和记忆同样需要隔离。只用问题文本作为缓存键，可能把另一用户获得的答案返回给当前用户。实际设计应结合身份、权限和数据版本，并处理权限撤销后的失效问题。
验证时构造两个权限不同的测试用户及对应数据，分别检查检索结果、生成答案、缓存命中和记忆读取。样本宜使用合成数据；记录证据时优先保存资源标识、判定和必要摘要，避免把敏感原文完整复制进日志。
五、任务规划与执行风险：工具合法不等于调用合法
执行安全至少需要检查操作类型、目标资源、参数范围、当前授权和调用时的业务状态。某个"更新工单"工具经过批准，不意味着当前用户可以修改任意工单。
工具参数校验应在执行前完成。对于需要确认的写操作，确认信息应绑定具体对象与动作；如果Agent随后更换了目标、扩大范围或改变关键参数，应重新判断原确认是否仍然有效。
还要考虑失败与重试。网络超时不等于后台未执行。对于可能重复提交的操作，应使用业务支持的幂等机制，并在结果不确定时查询真实状态。没有幂等支持时，不能把自动重试作为默认安全方案。
任务需要明确终止条件，例如达到预设调用次数、连续失败或超过时间预算后停止并上报。限制应结合业务设置，避免异常循环持续修改状态或消耗资源。
验证可以覆盖未授权写入、资源范围改变、重复回调、工具超时和结果不一致。断言以实际副作用为依据：工单是否改变、变更了几次、改变了哪些字段，而不是只检查回答措辞。
六、供应链风险：工具描述、服务实现与依赖都要检查
Agent使用的Skills、MCP服务、插件、依赖库和运行包，应有可追踪的来源、版本和权限记录。工具说明属于需要审查的输入，不能因其出现在工具目录中就天然可信。
接入前可以核对服务功能与权限申请是否匹配，在隔离环境中观察行为。升级后应比较工具描述、参数结构、访问范围和依赖变化，再确定需要重跑哪些测试。
OWASP的MCP安全检查资料涵盖身份验证、授权和凭证处理等问题。它提醒开发者，协议接入成功并不等于完成了服务端安全验证。来源：OWASP MCP安全检查资料
对于应用实现，建议避免把多用途高权限凭证直接交给不必要的组件，依据实际功能缩小权限与网络访问范围。完整性校验能发现部分变更，但无法替代行为测试和漏洞处理。
七、用统一事件记录连接五类风险
建议为任务记录请求标识、任务标识、用户或租户引用、模型与策略版本、工具版本、资源标识、授权结果、执行结果及时间信息。字段需要结合系统设计，不能把这份建议当作固定行业规范。
输入和参数含敏感信息时，应按需脱敏或使用受控存储引用。日志读取本身也应受权限约束。为了排障而无差别保存全部上下文，可能制造新的数据风险。
同一次事件可以具有多个风险标签，同时指定主要触发点和整改负责人。比如组件返回异常指令导致越权更新，既涉及供应链，也涉及指令和执行；统计事件数量时仍应按事件标识去重。
八、上线前如何验证这张风险地图？
每类风险至少准备正常场景、异常场景和边界场景。先测试完整应用，再定位模型、检索、编排或工具层的问题；不要把基础模型的测试结论直接迁移到接入工具后的系统。
效果指标应区分风险任务成功率、正常任务完成率和误拦情况，并明确样本分母。对于实际产生副作用的风险，应单独统计，避免被大量低影响样本稀释。延迟则观察加入防护后整个任务的耗时变化。
在能力分工上，AI安全评测负责验证风险，AI安全围栏负责运行中的识别与处置。例如数美天攻与数美天枢分别对应这两类职责。身份校验、业务幂等和状态管理仍需在应用及业务系统中落实，不能由产品名称推定已经具备。
九、常见问题
是否必须在每一步调用一个安全模型？
不必。确定性权限、参数范围和状态约束应优先由程序执行；需要理解语义和上下文的风险，再采用相应检测方法。应按实际风险配置检查，避免重复调用却没有增加有效覆盖。
提示词注入应归到哪一类？
可将其作为指令与意图风险记录，并根据结果增加数据、执行或其他标签。若来源是被篡改组件，还应关联供应链问题。主要分类方便定位入口，关联标签用于说明传播与影响。
什么情况下需要重新测试？
模型、提示词、检索范围、工具描述、权限或组件版本发生变化时，应评估影响并开展回归测试。保留过去失败的样本及正常对照，验证修复有效，同时确认没有把正常业务一并限制。