让 Agent 提交变更，用 GitOps 把住上线关

我会给 AI Agent 一个生产 Kubernetes 集群的 root 权限吗？不会。那我会让它提交 pull request 吗？非常乐意。

这听起来似乎自相矛盾，但只要看看 GitOps 架构中真正的控制点在哪里，就不难理解了。控制点不在集群本身，而在于一项变更抵达集群之前所经过的路径。

让我想通的那个思路

本月早些时候，CNCF Ambassador Mauro Morales 在 CNCF 博客上发表了《别给 AI Agent root 权限，让它们提议系统的下一个状态》。他的核心观点很简单：Agent 应该检查系统的当前状态，并提议下一个状态，而不应该亲自应用这个状态。它的提案必须经过与所有人工变更相同的软件交付流水线：评审、CI、测试、构建、签名、发布、部署。

文章里有一句话让我印象很深：如果你给了 Agent root 权限，却指望一份写得很好的 AGENTS.md 就能防止它犯下无法挽回的错误，那就是在自欺欺人。模型具有非确定性。你无法保证结果，就必须保证它所经过的路径。

他的文章主要讨论操作系统层和不可变主机。我想从 Kubernetes 和 GitOps 的角度看看同一条原则，因为对许多平台团队来说，这条边界早已存在。只是面对 bot 时，我们并不总能严格执行。

GitOps 早就划好了边界

如果你在使用 Argo CD 或 Flux，这套模式几乎平淡得没什么新意。规则早已明确：不在 Git 里的东西，就不会进入集群。控制器会持续协调，让集群趋近仓库中声明的期望状态，并纠正状态漂移。

因此，Agent 的安全权限范围应该是这样的：

• 可以读取指标、日志、事件，以及 Git 中的 manifests，以便诊断问题。
• 可以写入一个分支，以 pull request 的形式提出变更。
• 仅此而已。没有 cluster-admin 权限，不能对生产环境执行 kubectl apply，也不能直接访问同步控制器。

Agent 因而成为另一名贡献者。它的变更是一份 diff，人可以阅读，CI 可以测试，策略检查可以拒绝。如果变更有问题，关掉 PR 就行。如果合并之后才发现问题，就 revert 一个 commit，而且你能准确知道，是哪个 commit、哪个身份引入了这项变更。

这种可追溯性往往被低估。它不仅是为了阻止错误变更，也是为了在事后弄清楚：改了什么、什么时候改的，以及是谁或什么程序提出的。

漏洞：“多走几步的 root 权限”

我认为，Mauro 文章中最重要的一点是：Agent 使用的身份可以提出变更，但绝不能批准、合并变更，也不能修改流水线。否则，你只是把 root 权限换成了多走几步就能拿到的 root 权限。

而现实中的配置，恰恰容易在这里失守。一种常见的做法是：

• 有人为 Agent 创建一个 bot 账号或 GitHub App。
• 配置细粒度权限需要时间，于是“暂时”给它仓库的 admin 权限。
• 分支保护为这个账号设置了例外，或者 bot 可以借助第二个 token 批准自己的 PR。
• 流水线定义就在同一个仓库里，而且 bot 可以编辑。

到了这一步，PR 流程就成了走过场。Agent 可以提出变更、批准变更、合并变更，还能修改本该拦住它的 CI 任务。随后，Argo CD 会忠实地同步所有进入 main 的内容。理论上，集群受到 GitOps 的保护；实际上，大门已经敞开。

面对这样的配置，我会检查什么

这些都不需要新工具。大多只是把你可能已经具备的配置，一视同仁地应用到非人类身份上：

• 每个 Agent 使用独立身份。 不与人类或其他自动化程序共用 token，这样审计记录才有意义。
• 分支保护不允许 bot 绕过。 必须由人类评审，必须通过状态检查，也不允许 Agent 账号利用 admin 权限绕过保护。
• 禁止自我批准。 发起 PR 的身份不能同时批准这个 PR，也不能留着另一个 token，让它有机会这么做。
• 保护流水线文件。 对 CI 定义、Argo CD Application 对象或策略文件的修改，必须通过 CODEOWNERS 交由人类负责人审核。
• 使用短期、限定范围的凭证。 Agent 读取可观测性数据的权限应有有效期，访问范围也应仅限于它需要的数据。
• CI 中的策略检查必须在异常时拒绝放行。 如果策略检查无法运行，或无法作出判断，结果就应该是“不予批准”，绝不能悄悄亮绿灯。

最后一点尤其值得强调。一个在缺少数据时依然放行的关卡，根本算不上关卡。对于 Agent 提出的变更，这一点更加重要，因为提案数量的增长速度，可能远远超过评审者所能投入的注意力。

我不认为解决办法是让 Agent 远离生产环境相关的工作。它们很适合读取信号、关联分析日志、提出修复方案，尤其是在凌晨 3 点，本来需要一位疲惫的值班工程师来完成这些工作的时候。真正的办法，是让它们遵守团队里每位工程师都已经遵守的同一套约定：你可以提出任何建议，由系统决定哪些变更可以应用。

GitOps 多年前就给了我们这套约定。现在要做的，是确保 bot 账号确实受它约束，而不是因为那样配置更省事，就悄悄凌驾于约定之上。

所以，我想再问一遍我在 LinkedIn 上问过的问题：说实话，如今你们的 Agent 在生产环境里，到底被允许做多少事情？

如需采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。