AI 改基础设施，为什么光有权限还不够？得有“证据”

以前改服务器很简单：高级工程师 SSH 上去敲几条命令就完事了。现在不同了。AI 代理在帮我们做迁移、扩容、打补丁，这些操作越来越复杂，我们得先确认「它想干的事到底安不安全」。

传统权限模型已经不够用了。

RBAC 在 AI 时代的问题

现在的生产环境大多靠两种机制保护：

RBAC 管的是：「这个人能写生产环境。」
GitOps 管的是：「我们想要的状态是这个。」

但两者都没回答一个关键问题：「这个改动现在安全吗？」

人操作时会带经验和判断。AI 代理却没有这些。它只是提出变更请求——可能是数据库迁移，也可能是集群升级。我们只检查「能不能做」，却不验证「为什么能做」。

尤其碰到带状态的操作时，问题更明显。改 schema、切数据、调整配置，这些都不是简单 apply YAML，而是带依赖、带回滚、带时间限制的连续步骤。权限系统根本看不见这些细节。

什么是「证据驱动」的变更控制

更好的做法是：每个变更在执行前都要先附上「密码学证据」。相当于给基础设施变更做签名。

流程大概是这样的：

1. AI 代理提出变更 + 理由
2. 系统生成证据，证明这次变更安全
3. 策略引擎检查是否符合授权规则
4. 验证签名是否完整、是否被篡改
5. 全部通过后才真正执行
6. 留下完整、可回放的记录

这些证据包括：

• 针对真实环境的 dry-run 验证
• 运行时漂移检测
• 安全扫描和 SBOM
• 镜像摘要和构建来源
• SLO 影响预测
• 事件链完整性检查

所有内容都会签名、打时间戳，跟发布物一起保存。

真实案例：Oracle 迁移到 PostgreSQL

拿一个真实场景来说：把跑在 Kubernetes 上的 Oracle/APEX 系统迁移到 PostgreSQL。这不是演示，而是带真实数据的割接。

整个流程包括：

• 检查目标集群是否就绪
• 记录变更窗口审批
• 冻结源系统
• 导出数据
• 创建目标恢复点
• 建 shadow table、扩 schema
• 逐行校验
• 流量切到新库
• 割接后验证
• 导出完整审计日志

这远不是一条 kubectl 命令能解决的。

当 AI 代理请求执行这个序列时，证据系统会记录：

• 23 项验证检查（基础设施、schema、安全、合规）
• 20 个飞行事件（记录每一步）
• 20 个独立证据（验证每阶段结果）
• 100% 的放行分数

证据用 ed25519 密钥签名，可以用 torque proof verify --require-signature 随时验证。没有造假，没有篡改。

证据通过了，策略还能再拦一关

有趣的是，就算证据全过了，系统还是会再问一次「是否允许」。测试中同一个请求被拒绝了两次：

1. 第一次：策略白名单里没有这条操作。证据通过了，但没权限。
2. 第二次：证据被篡改过一处。签名验证失败，直接拦截。

这才是 AI 时代的纵深防御：证据 + 策略，缺一不可。

为什么传统工具不够

Argo CD、Crossplane 这些 GitOps 工具，设计初衷不是给 AI 代理用的。它们能告诉你「谁能改」「想改成什么」，但回答不了「这次改动现在安全吗」。

当你开始用 AI 做部署、自动扩缩容、多云迁移，或者处理强合规业务时，就需要一种能用密码学方式解释「为什么这次变更安全」的基础设施。

实际怎么开始

如果你已经在跑 Kubernetes，想尝试 AI 驱动的复杂操作，建议从这几点入手：

1. 生成证据：你的部署系统能不能为每次变更生成密码学证明？
2. 策略即代码：明确列出 AI 代理在什么场景下能执行哪些操作。
3. 审计追踪：每一次变更都要有签名、可回放的记录，包括理由。
4. 放行评分：用量化分数表示「这次改动有多大把握」。

基础设施正在走向自主运行，变更控制也得跟上。从「有没有权限」变成「这里有证据，证明它安全，而且说明了原因」。

只有这样，你才能在凌晨三点放心让 AI 代理去跑生产迁移。