AI agent 可以通过 MCP 管理云基础设施，前提是规划与执行相互分离、凭据权限受限、高影响操作需要审批、写入能够安全核对结果、每项影响都有追踪记录，而且恢复流程经过测试。仅仅发现工具并不能提供任何这些控制措施。
最安全的首项能力是只读资源清单。只有 plan 和策略路径在一次性环境中正常运行后，才能增加变更能力。
分离 plan 与 apply
Plan 应明确列出目标租户、环境、资源、依赖、权限变更、成本和不可逆影响。应用该 plan 时，应使用独立工具，或提供绑定到 plan digest 的审批 token。
不要让一个通用工具在模型组装 payload 后接收 dryRun: false。独立的 apply 能力可以让客户端和策略层清楚看到从规划到执行的转换。
Infrastructure as code 工具已经采用这种审核模式。MCP 应保留这条边界，而不是把规划和执行压缩到同一轮模型调用中。
在每一层限制身份权限
MCP 服务器验证客户端及其代表用户的身份。策略限制可见或可调用的基础设施工具。提供商凭据限定到目标账户、项目、环境和操作。提供商随后还会对最终资源执行授权。
Cloudflare 的 MCP 授权架构将身份与授权同 agent 会话状态分开。MCP 身份验证指南介绍了当前协议对 token audience 和透传的要求。
不要让开发工具使用组织所有者 token。如果提供商无法表达所需权限范围，应在其前面增加范围严格受限的控制面。
将每次写入视为一项操作
为已批准的变更分配一个操作 ID 和幂等键。保存 plan digest、调用方、目标资源、尝试次数、提供商请求 ID、状态和结果。每次重试必须引用同一项操作。
发生超时后，应先检查提供商和操作状态，再决定是否重复调用。提供商已经完成工作但客户端未收到响应时，结果未知的情况十分常见。
Agent 恢复指南进一步介绍了基础设施之外的检查点和结果核对。
在产生影响前要求审批
审批应展示：
- 确切的环境和账户；
- 每项要创建、更改或移除的资源；
- 新增权限和网络暴露；
- 预期成本及计费影响；
- 数据丢失或停机风险；
- 操作是否可恢复；
- 审批何时过期。
OAuth consent 授予的是一类访问权限，并不等同于对未来某次生产删除操作的批准。高影响操作仍需要当前有效的策略决策。
优先使用可恢复的操作
提供商支持时，应使用软删除、快照、分阶段流量切换，并保留上一版配置。Railway 的 2026 年 4 月事故报告介绍了 agent 找到一枚权限宽泛的 token，并调用旧版立即删除路径的事故。Railway 最终恢复了存储卷，并将 API 删除改为保留 48 小时的软删除。
这次事故暴露了两个具体问题：凭据权限范围和删除语义都没有限制实际影响。单有审计日志，只能在事后解释删除过程。
限制基础设施输出范围
返回稳定的公开结果，而不是完整的提供商 payload：
{
"operationId": "op_1842",
"state": "pending",
"resources": ["database:db_73"],
"statusUrl": "/operations/op_1842",
"retryAfterSeconds": 15
}
移除提供商凭据、账户级标识符、内部网络详情和调试 header，除非下一项已授权操作确实需要这些信息。
追踪控制路径并设置告警
记录用户、agent、会话、plan digest、审批、工具调用、操作 ID、目标、提供商请求、策略决策、状态转换和最终影响。以下情况需要告警：
- 开发环境身份访问生产目标；
- 新增范围宽泛的权限；
- 重复尝试删除或创建；
- 绕过审批或审批过期；
- 使用高成本资源类型；
- 操作长时间停留在结果未知状态。
生产环境 agent 检查清单将这些字段整理为发布门禁。
测试一次受控故障
在一次性项目中，让 apply 调用在提供商可能已经接受请求后中断。恢复工作流，并确认它会核对第一次操作的结果。然后在运行途中撤销 agent 凭据，验证后续操作均会停止。
还要测试：为开发环境创建的 plan 无法应用到生产环境，而且只要修改其中任何计划资源，审批就会失效。
从仅规划工具开始
先开放资源清单和规划功能，保持 apply 不可用。让 agent 为真实任务生成 plan，并检查运维人员还需要哪些信息。只有审批、重试、追踪和恢复测试全部通过后，才能添加一项范围严格受限的 apply 工具。
下方的提示词会针对当前项目中影响范围最大的工具执行仅规划检查。