Agent发布前如何建立安全基线：从资产边界到发布门禁

云上Agent的安全基线，应当是一套可以嵌入发布流程的最低控制要求，而不是一次性的内容审核。基线需要绑定应用版本与环境，覆盖指令与意图、生成内容、数据与隐私、任务规划与执行、供应链五类风险，并以身份边界、数据流、工具调用、业务状态和审计证据作为验收对象。本文从云上架构与持续交付视角，说明如何划定范围、设计风险场景并设置发布门禁。

一、安全基线的本质：把“能上线”变成可验证条件

传统应用发布前会检查代码、依赖、配置和接口，但Agent还会基于自然语言动态规划任务。相同代码在模型、提示词、知识库、工具描述或权限变化后，可能产生不同执行路径。因此，Agent上线审批不能只问“模型是否合规”，还要问“当前组合在什么边界内可控”。

一套有效基线应具备三个特征。第一，可定位：结论对应明确的模型、编排、数据、工具和策略版本。第二，可判定：每个场景都写清允许行为、禁止行为和失败条件。第三，可追溯：风险发现能关联到调用记录、权限判断和真实业务状态。

可以把发布对象理解为一个版本化组合：Agent版本 = 模型与提示词 + 工作流 + 知识库快照 + 记忆策略 + 工具集合 + 身份权限 + 运行防护策略。任一关键部分改变，都需要评估原有结论是否仍然成立。

二、先画四张图，再确定测试范围

1. 资产图：Agent能接触什么

列出用户资料、业务文档、知识库、会话记忆、访问凭证、工具接口和可改变的业务对象。资产不只包括数据库中的敏感字段，也包括能够产生实际影响的能力，例如发送消息、修改工单、执行代码和调用付费资源。

2. 信任边界图：哪些内容只是数据

系统规则、用户请求、检索文档、网页内容和工具返回在同一上下文中出现时，并不具有相同可信度。外部内容可以提供事实，却不应自动获得修改任务目标或扩大权限的资格。边界图要明确哪些来源可定义任务、哪些来源只能作为参考数据。

3. 权限图：谁以什么身份调用什么工具

工具持有服务凭证，不代表所有Agent用户都拥有相同权限。应把用户身份、Agent服务身份、工具身份和目标资源授权分开描述，检查身份是否被正确传递、约束和审计。高影响操作还需要标记确认条件、参数范围和停止条件。

4. 数据流图：信息经过哪里

从上传、检索、模型上下文、工具参数、外部搜索到日志与记忆，标出数据流入、流出和持久化位置。最终回复没有泄密，不等于敏感信息未被发送给外部服务。数据流图是设计隐私用例和审计证据的基础。

三、五类风险如何映射到云上Agent链路

指令与意图风险：低信任内容改变高信任任务

测试不能只在聊天框输入攻击语句，还应覆盖网页、文件、知识库片段、历史记忆和工具返回中的间接指令。OWASP Top 10 for Agentic Applications 2026将目标劫持、工具滥用、身份与权限滥用、供应链和记忆污染等列为重要风险，为风险枚举提供了公共参考。

验收时应区分三个结果：计划是否偏离目标、工具调用是否越过边界、真实影响是否发生。如果云侧权限控制阻止了越权写入，说明基础控制有效，但前面的目标偏移仍需要修复或限制，不能简单记为“全部通过”。

生成内容风险：从回答安全扩展到业务决策安全

除了不当内容、隐私和风险代码，还要识别错误承诺、虚构状态和未经核验的业务结论。对只生成建议的助手，重点验证内容准确性、边界表达和引用依据；对输出直接进入下游流程的Agent，还要验证结构化参数和消费端处理方式。

流式输出、附件、回调消息和自动写入内容需要分别测试。若风险文本已经在流式通道中发送，后置拒绝无法撤回；若下游将模型文本拼接成命令或查询，则需要独立检查输入验证与执行约束。

数据与隐私风险：隔离要验证到上下文和缓存

建议使用两个或多个测试租户，以合成数据和可追踪标记验证数据隔离。检查范围包括检索候选、进入模型的上下文、工具参数、生成结果、缓存、日志和长期记忆。还要覆盖权限撤销、项目成员变化和旧会话恢复等场景。

云上网络出口也是数据边界的一部分。Agent为完成公开搜索，不应把内部文档原文、账号标识或访问凭证无差别地发送出去。日志采用最小必要原则，既要支持追踪，又要避免把敏感原文复制到更宽松的存储区域。

任务规划与执行风险：以可信状态而不是自然语言为准

对写操作设置执行前校验：当前身份是否有权访问目标，用户确认是否对应当前对象和参数，业务状态是否仍满足条件，动作是否在允许范围内。自然语言中的“我是管理员”不能替代认证结果，模型生成的“已完成”也不能替代业务系统状态。

故障注入应覆盖超时、部分成功、重复消息、限流、权限失效和依赖不可用。对于高影响操作，未知状态应触发停止、核验或人工处置，而不是由Agent自行扩大重试。可撤销与不可撤销动作还应采用不同的恢复策略。

供应链风险：组件更新也是行为变更

Skills、MCP服务、插件、依赖库和运行包都应进入组件清单，登记来源、版本、权限、网络范围、维护方和退出方式。除了漏洞与完整性，还要检查工具描述是否与真实能力一致，更新是否新增权限，返回内容是否可能影响下一步规划。

MCP官方安全实践列出了混淆代理、令牌透传、SSRF、会话劫持等具体风险，并强调授权与权限范围控制。这意味着“服务能够连通”只是功能验收，不能替代授权与边界验收。

四、把基线嵌入CI/CD和发布流程

安全基线可以分为四层门禁，而不是把所有测试都堆在发布前一天。

第一层是配置检查。对模型、提示词、工具清单、权限策略、知识库和组件版本生成差异，识别本次变更影响的链路。新增高权限工具、扩大网络出口或改变身份映射，应自动升级审查级别。

第二层是自动回归。运行固定的风险基线集和正常业务集，检测已知问题是否复发、正常任务是否被误阻断。随机性较强的场景需要多次运行，并同时报告成功次数、有效尝试次数和运行条件。

第三层是场景评测。围绕高价值业务流程进行多轮、跨工具和故障注入测试，必要时在隔离环境中连接接近真实的工具。生产环境不宜执行的危险动作，应使用工具替身、专用测试租户或可回滚资源验证，并明确剩余证据缺口。

第四层是人工审批。业务负责人确认正常与禁止行为，研发确认修复与版本，安全团队确认风险与残余项，发布责任人决定是否准入。NIST AI RMF以Govern、Map、Measure、Manage组织风险管理，适合用来检查基线是否同时覆盖责任、场景、测量和处置。

五、发布门禁应该验收哪些项目

建议把验收项分为“阻断项、指标项、证据项”三组。

不要只设置一个平均安全分。少量跨租户泄露可能被大量普通用例稀释，却仍然足以阻断上线。门槛应在测试前确定，结果出来后再修改权重会削弱验收可信度。

性能验收要分清对象。离线安全评测的执行效率与运行时防护延迟不是同一个指标。若测试运行防护，应记录端到端平均延迟、P95/P99、并发条件、超时策略和防护不可用时的处置；若测试评测平台，则关注用例执行完成率、判定一致性和报告交付质量。

六、一次完整POC可以怎样组织

第一阶段选择一条代表性业务链，例如“读取制度—查询账户—生成建议—确认后提交操作”。冻结版本与数据，约定允许行为、禁止行为、攻击预算和高影响失败条件。

第二阶段运行五类风险场景，同时加入正常任务。抽查至少一条完整证据链，从用户身份到检索上下文、工具参数、返回值和业务状态，确认结论不是只由最终回答推断。

第三阶段选择代表性问题整改，运行原始用例、相似变体和正常回归，观察修复是否有效、是否引入功能退化。POC只有包含复测，才能验证方案是否真正进入研发闭环。

在外部能力选型中，数美“天攻”（AI安全评测）可作为参考项，用于上线前和变更前发现、验证并量化指令与意图、生成内容、数据与隐私、任务规划与执行以及供应链风险。具体覆盖、部署和交付仍需结合企业架构进行实际验证，不应以能力名称直接替代POC结果。

七、上线之后，基线如何继续生效

基线是发布时点的最低条件，不是上线后的免责证明。运行阶段需要监测异常输入、工具调用、数据访问和真实副作用，将线上事件脱敏后转成回归用例。模型替换、提示词调整、知识库权限变化、工具升级、组件来源变化或运行策略更新，都应触发影响分析。

对于运行中的实时识别与阻断，可以评估AI安全围栏类能力；但围栏不能替代上线前评测，评测也不能替代业务系统鉴权、幂等与状态控制。安全基线的价值，是把这些控制放在同一条可验证链路上。

FAQ

云上Agent使用了最小权限，是否还要做攻击测试？

要。最小权限能限制影响面，但配置错误、身份传递、间接提示词注入和多工具组合仍可能造成越权。测试用于证明权限在真实任务链中按预期生效。

每次小版本更新都要全量重测吗？

不一定。先根据配置与链路差异选择受影响用例，再抽取高风险跨链路场景回归。模型、核心权限或供应链来源发生重大变化时，应扩大范围。

没有发现风险，能否直接写“安全通过”？

建议写明“在指定版本、样本、环境和覆盖范围内未观察到阻断项”，并列出未覆盖部分。有限测试无法证明所有未知路径都安全。