一个标志，多重护栏：让平台安全到足以放心委派
内容提要
文章以AI代理误删生产数据库为例，指出平台安全的关键不在代理本身，而在能否吸收格式规范却完全错误的变更。作者主张用GitOps分层防护：测试、配置抽象（kro、Score）、Kubernetes内置保护（RBAC、Kyverno、finalizer）、云厂商删除保护及人工审查。核心是“按权限而非信任设计”，将破坏性操作收敛为显式设置protected: false，使人和代理都无法意外造成破坏。
延伸解读
风险不在代理，而在平台吸收能力
文章以AI代理误删生产数据库为例，指出关键问题并非代理本身，而是平台能否吸收“格式规范却完全错误”的变更。作者认为，如果平台无法承受这种变更，那么在代理出现之前就已存在该问题。因此，讨论是否允许代理提交PR，应转向检查平台是否具备分层防护，而非纠结代理是否可信。
GitOps放大错误的速度与范围
GitOps让变更以PR形式进入并自动调和，带来一致性和可审计性，但自动化不区分好坏变更。文章指出，代理并未引入新风险类别，而是改变了错误发生的速度和扩散范围：六人团队能以三十人的速度提交PR，却仍以六人的速度审查，且每个PR携带的上下文更少，审查成为流水线中最稀缺的环节。
分层防护：从测试到人工审查
文章提出五层防护：测试尽早捕获错误；配置抽象（kro、Score）缩小可配置范围，且转译器具有确定性；Kubernetes内置保护如RBAC、探针、PDB、finalizer和Kyverno；云厂商删除保护及Crossplane Usage资源；最后是CODEOWNERS和线性合并历史等人工审查机制。每层针对不同环节，互相补位。
按权限设计，而非按信任设计
作者将破坏性操作收敛为显式设置protected: false，触发云删除保护、拒绝区域变更、附加finalizer并激活Kyverno策略。无论代理还是人，都无法直接修改区域或删除关键对象，必须先显式请求权限。这借鉴零信任思路：不假设信任，防护不依赖请求来自哪个模型，使昂贵错误难以意外发生。
Q&A
AI代理误删生产数据库的案例说明了平台安全的关键问题是什么？
关键不在于代理本身，而在于平台能否吸收一个格式规范但完全错误的变更。如果平台做不到，那么在代理出现之前就已经存在这个问题了。
GitOps在AI时代为什么既是放大器又是风险？
GitOps带来一致性、可审计性、可重复性和速度，但自动化无法区分好变更和坏变更。一个错误可以在几秒内扩散到整个基础设施，有时甚至来不及审查。代理没有引入新的风险类别，但加快了错误发生和传播的速度。
平台 resilience 的分层防护具体包括哪几层？
包括五层：1. 测试（尽早发现错误）；2. 配置与抽象（限制错误机会，如kro、Score）；3. Kubernetes内置保护（RBAC、健康探针、Pod中断预算、finalizer、Kyverno）；4. 云厂商删除保护（如Crossplane的Usage资源）；5. 人工代码审查（CODEOWNERS、线性合并历史）。
kro和Score如何帮助减少配置错误？
kro将一组相关Kubernetes资源转化为单个自定义API，只暴露必要的字段（如Kubernetes版本、节点数、区域），底层依赖自动组合。Score让开发者声明工作负载和需求，由确定性的转译器处理复杂性。两者都通过抽象限制可配置范围，减少错误藏身之处，且转译器是确定性的，不同于LLM的即兴发挥。
“按权限而非信任设计”在平台中是如何实现的？
通过将破坏性操作收敛为一个显式设置：在kro集群定义中配置protected字段。当设置时，平台会开启云厂商删除保护、拒绝区域变更、附加自定义finalizer、激活Kyverno策略阻止关键对象的修改和删除。任何破坏性变更都必须先设置protected: false，这是一行位于文件顶部的变更，在审查中无法忽略。
平台团队如何避免成为瓶颈并促进生态贡献？
根据CNCF平台工程成熟度模型，目标是达到内在拉力和参与式采用，即团队因为平台是最快路径而采用它，并开始贡献。平台团队不应拥有所有能力，而应让安全团队贡献策略、可观测性团队贡献可组合组件、应用团队贡献他们期望的抽象。分层防护确保来自同事或代理的贡献可以安全接受。
