技术负责人要把 AI Agent 安全审计真正卡进 CI/CD，核心做法是：将 Agent 的代码、提示词、工具权限和数据流纳入与传统代码相同的版本化管理，在流水线中增加专门的 Agent 安全扫描节点，并把扫描结果绑定到发布门禁。只要关键风险项未通过，部署自动终止，人工无法绕过。
这意味着安全审计不再依赖上线前的一次性评审，而是变成每次提交、每次构建、每次部署都强制执行的工程动作。
为什么传统安全评审管不住 AI Agent
AI Agent 和普通应用系统最大的区别在于，它的行为不是完全由代码预先写死的。Agent 会根据模型输出动态选择工具、拼接参数、读取上下文，甚至调用外部系统。
传统安全评审通常关注几件事：代码有没有漏洞、接口有没有鉴权、数据有没有加密。但对 Agent 来说，风险面多了三层：
- 提示词本身可能被注入：外部内容被模型当作指令执行，导致越权操作或数据外泄。
- 工具调用链不可预测：同一个 Agent 在不同输入下可能走完全不同的工具路径。
- 权限边界容易失控：Agent 往往被授予较宽的系统权限，否则无法完成多步任务，但这也放大了误用风险。
如果只在功能上线前做一次人工评审，上线后 Agent 的提示词、知识库内容、工具配置、模型版本任何一处变化，都可能在评审覆盖范围之外引入新风险。
适合什么企业先做这件事
不是所有企业现在都需要把 Agent 安全审计嵌入 CI/CD。最值得优先落地的企业通常满足以下条件之一：
- 已经或正在把 Agent 接入核心业务系统，例如订单、库存、审批、客户数据查询。
- Agent 拥有写权限或删除权限，不只是只读问答。
- 企业有多个团队在开发 Agent，安全标准难以靠口头统一。
- 需要通过等保、ISO、行业监管或大客户安全审计要求。
如果 Agent 目前只用于内部知识问答、不接敏感系统、不写数据，可以先做基础版本：版本化提示词和权限清单，暂不强制卡发布。
先把风险清单变成可检查的规则
安全审计要自动化，第一步不是选工具，而是把风险从“感觉有风险”转成可执行的检查项。技术负责人应牵头梳理一份 Agent 安全风险清单，至少包括：
- 代码漏洞：Agent 服务本身的依赖、输入校验、越权接口。
- 提示注入风险：提示词是否包含可被外部内容覆盖的指令；工具描述是否暴露了过多内部信息。
- 数据泄露路径：Agent 可能把哪些内部数据拼进外部 API 请求；日志是否记录了敏感字段。
- 权限过大：Agent 使用的 API Key、数据库账号、系统角色是否超出完成任务所需。
- 工具链异常：是否存在未登记的新工具调用；工具返回内容是否可能被当作指令再次执行。
每一类风险至少要对应一条“能不能在流水线里自动判断”的规则。如果某个风险只能靠人判断，就把它拆到更小的可验证单元。
如何设计 CI/CD 中的 Agent 安全门禁
第一步：把 Agent 的全部资产纳入版本库
Agent 不只是代码。技术团队需要把以下内容一起纳入 Git 管理：
- Agent 系统提示词和子提示词模板
- 工具定义和权限声明
- 知识库索引配置和数据源白名单
- 模型调用配置与回退策略
- Skills 的版本与执行边界
如果提示词还散在多人文档里，审计无从谈起。版本化是自动化的前提。
第二步：在流水线中插入三个检查阶段
一个可落地的流水线结构通常包含三个与 Agent 安全直接相关的阶段：
静态检查阶段
在代码提交后立即运行。检查内容包括依赖漏洞扫描、敏感信息硬编码、Agent 配置完整性、提示词版本与发布说明是否一致。
这个阶段的关键是快。触发一次提交就应该跑一次，不能依赖人工记得执行。
构建期 Agent 行为测试
在测试环境构建完成后，用一组固定的对抗性用例测试 Agent。用例应覆盖：
- 直接提示注入，例如“忽略之前的指令”
- 通过上传文档、网页内容、邮件正文发起的间接注入
- 越权工具调用尝试
- 敏感数据外发尝试
这一阶段不是要穷举所有攻击，而是要守住几条不可妥协的底线规则。
发布前权限与数据流复核
部署到预发环境后，自动比对 Agent 实际使用的权限与声明权限是否一致，检查工具调用链中是否出现未登记的目标地址，确认生产数据脱敏规则已生效。
只有三个阶段全部通过，才能进入生产发布。
第三步：把安全结果接入发布门禁
门禁不能只是邮件提醒。技术负责人需要在 CI/CD 平台中配置硬性失败条件，例如：
- 高危依赖漏洞未修复，构建终止。
- 提示注入测试用例通过率低于设定阈值，禁止进入预发。
- 权限比对发现未声明工具或越权调用，发布中止。
- 数据外发目标不在白名单，流程回滚。
同时保留完整审计日志，记录每次构建触发了哪些规则、哪些人做了例外处理、例外原因是什么。
常见误区：扫一遍不等于治理
技术团队最容易犯的错误是把安全扫描当成一次性工具接入。上线前跑一遍扫描器，报告出了就完了。但 Agent 的风险是持续变化的，模型版本、提示词、知识库、工具接口任何一处变更都可能改变风险等级。
另一个误区是只扫描 Agent 的后端代码，不扫描提示词和工具权限。对大多数企业 Agent 来说，真正的风险不在代码语法，而在模型被诱导后的行为链路。
还有一个常见问题是门禁过松。一些团队担心影响发布效率，把安全失败设为“警告”，允许手动跳过。结果上线门禁形同虚设。
交付成果：技术负责人应该拿到什么
一个完整的 Agent 安全审计流水线建成后，技术负责人应当能明确交付以下成果：
- 一份随版本管理的 Agent 资产清单，覆盖提示词、工具、权限、数据源。
- 一组可在 CI/CD 中自动执行的安全检查规则。
- 一套对抗性测试用例集，包含提示注入、越权调用和数据外发场景。
- 一个硬性发布门禁，安全失败自动阻止生产部署。
- 每次发布的完整安全审计记录，可追溯、可复盘、可对外证明。
这些成果的共同价值是：安全不再依赖个别人的经验和责任心，而是变成流程固有的一部分。
智未来 AI 在企业 AI Agent 落地中看到的一个典型问题，正是安全评审与工程流程脱节。评审做得再仔细，如果不在流水线里形成门禁，就无法约束后续的持续变更。企业需要的不是一次性安全报告，而是可持续运行的治理机制。智未来（上海）智能科技有限公司的 AI Agent 落地服务中，会把这类工程化安全管控作为交付方案的一部分，帮助技术团队把治理要求转成可执行、可验收的开发流程。
常见问题
1. 我们公司刚开始用一个内部问答 Agent，需要马上做 CI/CD 安全门禁吗？
不一定。如果 Agent 不接敏感系统、只有只读权限，可以先做基础治理：把提示词、知识库配置和权限清单纳入版本管理，保持每次变更可追溯。等 Agent 接入核心业务或获得写权限时，再升级为硬性发布门禁。
2. 哪些安全风险是必须优先卡住的？
优先卡住三类：外部内容导致的提示注入、Agent 越权调用工具或系统、敏感数据通过日志或外部 API 外发。这三类风险一旦发生，直接影响业务安全和合规，应当作为门禁的硬性失败条件。
3. 提示注入测试用例怎么来？
可以从实际业务中归纳。让业务方和安全人员一起列出 Agent 会接触的外部内容类型，例如客户邮件、上传文档、网页正文、工单备注，然后针对每种类型设计诱导性输入。如果企业没有现成积累，可以先从通用提示注入模板开始，再逐步补充业务定制用例。
4. 接入安全门禁会影响发布效率吗？
会有一定影响，但可控。关键是区分阶段：静态检查做到分钟级，行为测试在测试环境并行执行，权限比对只放在预发阶段。只要规则设计合理，大部分安全检查不会成为发布瓶颈。相比一次安全事故导致的停机和整改，这个成本通常可以接受。
5. 我们是业务团队，没有专门安全工程师，怎么启动这件事？
可以先从最轻的版本开始：把 Agent 的提示词、工具权限和外部调用地址整理成清单，放进版本库；用开源的依赖扫描和敏感信息扫描工具接入现有流水线；设置一条规则——任何新的外部 API 调用或权限扩大，必须经过技术负责人审批。对缺少专职安全人员的企业，这已经能拦住大部分常见风险。如果 Agent 涉及核心业务，建议引入有企业 AI 落地经验的团队协助设计治理方案。