agentic-sdlc-controls

Agentic SDLC Controls

流水线中的 Agent 使用你的凭据，以机器速度执行任务，而且不会厌倦重复工作。这正是它的价值所在，也是威胁模型所在。要审查的是边界，而不是 Agent 的意图。

适用于任何拥有写入权限的编码 Agent——Claude Code、Codex、Cursor、OpenCode，或调用模型的 CI 作业。这里的内容与具体使用哪一种无关。

1. 确认 Agent 实际可以访问什么

先盘点，再下结论。针对每个 Agent 或自动化流程：

• 身份：它使用谁的凭据运行？是具名的服务身份，还是某个人的个人令牌？
• 代码仓库：拥有读取、写入还是管理权限？它能推送到默认分支，还是只能创建 PR？
• 环境：它能访问预发布环境吗？生产环境呢？客户数据呢？
• 密钥：运行时环境中有哪些值？其中哪些是任务实际需要的？
• 网络：它能发起任意出站请求，还是出站流量受到限制？

把这些内容记成表格。常见的问题并非微妙的配置错误，而是根本没人列出过这些信息。

2. 区分可逆操作与不可逆操作

对 Agent 可以执行的每项操作进行分类：

类别	示例	控制措施
可逆、影响范围受限	编辑文件、运行测试、创建 PR	允许执行
可逆、可见	推送分支、评论议题	允许执行，并记录日志
难以撤销	合并到 main、发布软件包、迁移架构	设置人工审批关卡
不可逆	删除数据、轮换生产凭据、发送外部邮件、花费资金	绝不委派

需要重点把守的是第三行。重要的是可逆性，而不是操作听起来有多危险。

3. 在运行时强制执行关卡，而不是依赖提示词

要求不要做某事，只是一种偏好。Agent 无法绕过的控制措施才是边界。

• 优先采用 Agent 执行过程中的机制：操作前钩子、权限允许/拒绝列表，以及本地配置无法覆盖的托管设置
• 验证 Agent 在非交互模式下运行时关卡仍然有效——许多审批提示会在 CI 中被静默跳过
• 检查拒绝路径是否经过测试。未经测试的关卡，就像一扇没人知道是否敞开的门
• 确认 Agent 无法编辑限制自身行为的文件

直接问：如果 Agent 尝试执行其权限范围内最糟糕的操作，什么会阻止它？有人实际观察过这个机制生效吗？

4. 根据任务和影响范围限制凭据

• 每种 Agent 用途使用独立身份；不要共用个人令牌
• 优先使用短期凭据，而非长期密钥；有效期应与任务时长相匹配
• 按环境划分自主权限：在沙箱中权限较宽，在预发布环境中收紧，在生产环境中降至最低
• 在任务允许的情况下默认只读——许多审查和分类 Agent 根本不需要写入权限
• 隔离执行环境，防止遭到入侵或行为异常的 Agent 访问工作区以外的内容

5. 将 Agent 输入视为不可信内容

Agent 会读取议题、PR 描述、依赖项 README、网页和工具输出。这些内容都可能包含指令。

• 任务期间获取的内容不得提升任务允许执行的操作范围
• 检查 Agent 的工具结果是否会在未经关卡控制的情况下，反馈到特权操作中
• 在 Agent 会读取的来源中注入一条无害指令进行测试，并观察它是否会照做

6. 确保能够重建操作过程

对于 Agent 生成的任何更改，审计人员或事件响应人员都需要弄清：提出了什么要求、生成了什么内容、谁批准了，以及使用了什么配置。

• 将提示词、计划和规格与差异一起纳入版本控制
• 在更改发生时记录 Agent 配置（权限、钩子、模型、技能集），而不是事后从 HEAD 读取
• 将审批记录为事件，而不是依赖某人对点击按钮的记忆

如果这些记录不够完善，可以配合使用 ai-change-evidence 技能，了解如何将其转化为审计证据。

范围与参与规则

仅审查你拥有或获书面授权评估的流水线。测试某项防护措施，意味着尝试执行该措施本应阻止的操作——请在沙箱或预先安排的时间窗口内，经所有者同意后进行，切勿擅自针对生产环境测试。注入测试使用无害标记；如果防护措施失效，切勿植入任何可能造成危害的内容。

输出

针对每项发现，报告：Agent 可以访问什么、缺少或未强制执行哪项防护措施、可触发该问题的具体操作步骤，以及能够解决问题的最小改动。将“Agent 目前就能做到”与“更好的实践”分开说明。为每项缺陷注明负责人；没有负责人的防护措施就不算防护措施。