AI Agent 不应直接改基础设施，应只提方案

主流云厂商都已上线可直接改动基础设施的 MCP 服务端：演示效果亮眼，却在关键时刻丢掉了基础设施即代码（IaC）十年积累下来的治理属性。作者援引两起事件作为佐证——Replit 的 Agent 在明确代码冻结期间删除了生产数据库；Amazon Q 的 VS Code 扩展释出时被植入提示词，企图借 AWS CLI 抹除本地与云端资源，所幸因语法错误未真正执行。前者是一个 Agent 自身决策失误，后者则是 Agent 沦为攻击者的工具，但错误的本质相同：拥有破坏性权限的智能体同时又以概率方式执行，并直接持有云端凭据。

破坏性操作的「涌现」

「帮我创建一个数据库」并不是关键场景，那本质上只是语音版的控制台。真正复杂的是 day-2 运维：开发者向 Agent 提出新功能需求，Agent 拆解任务后由若干子 Agent 协作，其中一个子 Agent 推理得出需要新建数据库用户、ACL、带特定保留期的消息主题；又或者连续几次推理后，Agent 判定当前实例规格过低、自动升配。这类基础设施变更并非用户显式请求，而是多层推理链上的「副作用」，具备涌现性。

文章指出，这里的算术已经失衡：Agent 降低了产生变更的成本，变更总量随之线性增长，而人工 Review 仍以人类节奏进行。当变更速率超过 Review 容量时，Review 要么成为瓶颈，要么形同虚设，IaC 赖以成立的「变更速率与审查速率匹配」的假设随之瓦解。

当下的常见链路

目前 Agent 调用云 API 的典型链路如下：

• Agent 宿主启动厂商 MCP 服务端作为本地进程，获取 create_database、update_acl、delete_topic 等工具清单及 JSON Schema；
• 模型在任务中自行选择工具，从上下文推断参数；
• MCP 服务端将调用翻译为云 API，使用从开发者环境继承的凭据执行；
• 结果以 tool result 形式回传模型。

执行变更的身份是开发者本人，Agent 没有独立主体，审计日志无法区分「人」与「代理」的调用。AWS、Google、Azure 已提供 OAuth + IAM 后的远程 MCP 端点，可赋予 Agent 独立身份、逐请求鉴权并完整记录，这已是「请求级治理」的雏形。

旧范式的回潮

Agent 直接调用云 API，相当于把 2014 年工程师在控制台点点鼠标的运维方式搬回来。当时被淘汰的原因是规模撑不住，IaC 才引入「意图—效果」之间的声明式、可版本化、可校验制品。文章认为，调用方换成 Agent 之后，这些治理属性并不因此变得可以舍弃。

分权提案

作者给出的方案是「分权」：提议变更的权限、评审变更的权限、执行变更的权限分属不同角色，Agent 只持有第一种。其落地形态借鉴了已有的 IaC 体系：

• Agent 仅输出意图，例如「服务 payments-recon 需要一个生产 Postgres 实例」；
• 服务端基于组织现有的资产清单与审批模块，把意图渲染为 Terraform/OpenTofu HCL 制品；
• 制品与当前状态做 plan，并由 OPA 等策略引擎校验组织策略；
• 策略违例以结构化、可机器读的 hint 回流到起草步骤，制品自动重生成并复提，直至通过或被标记为需人工介入；哪些违例可自修、哪些必须升级，由策略元数据声明；
• 提议者只能产制品，只有「闸门」在 check 通过后才能执行 plan 与 apply；
• 每一步——意图、生成制品、违例、修复、结果——均写入仅追加审计日志。

文章给出一个完整 trace：Agent 提交的意图被起草器转为一份 HCL 草稿，闸门因「prod_deletion_protection」与「prod_instance_class」两项策略拒绝，并将 self_fixable=true 的修复提示回传，制品随后被改写再次提交。这一闭环的核心是把「决定做什么」「判断该不该做」「真的去做」拆成三个独立角色，与人类宪政设计同理：单点永远不可信，保证只能来自结构。

对组织而言，这一架构没有引入新能力，只是把 IaC 已提供的治理重新包装给一个更快、并发量更高的调用方；而对正在把 MCP 服务端接入生产环境云账号的团队来说，这篇文章提醒了一件被演示效果掩盖的事：一旦「Always Allow」被点下，Agent 拿到的就是开发者本人的全部云端权限。