Agent 治理成了主战场：这周 5 个云厂商全在补权限，没一个在补能力

【摘要】10 月 19 日到 26 日这一周，AI 领域几乎没有新的重磅模型发布。Claude Code、Codex、Google、AWS、OpenAI 全在补权限：事件上报、凭证遮蔽、IAM 分层、工具注册审批、只读属性策略。这不是巧合——当 Agent 真的开始碰生产系统，企业买的不再是能力，是可审计的边界。这篇拆解这一周的几道护栏，以及一个关键设计：Google 把"建议"和"强制"分成了两层。

目录

一、这一周发生了什么：能力没动，闸门多了
二、Claude Code：把"被拦下"变成可观测事件
三、Codex：让凭证不再出现在对话记录里
四、Google：skills 是建议，IAM 才是强制
五、AWS：给工具加一道审批工作流
六、为什么云厂商在这时候集中补权限
七、给团队的三个问题

一、这一周发生了什么：能力没动，闸门多了

先把这周的几件事摆出来。

10 月 20 日，AWS 发布 Agent Registry。 一个托管服务，用来编目和发现 MCP 服务器、Agent 和 Agent Skills。发布者注册协议描述符和可搜索的描述，运行时由 orchestrator 搜索已批准的记录、拿到端点、构造客户端。搜索结果不返回能力的调用凭证或认证方式。

10 月 22 日，Anthropic 把 Agent Skills 捐给 Linux 基金会。（这个我另写一篇）

10 月 22 日，OpenAI 的 Decisions API 正式上线。 跑在 GPT-6 Luna 上，一次最多 400 题，只收输入费用。

10 月 22 日起，Google 的 Data Agent Kit 陆续有新动作。 它是 37 个开源 skills 加一套 MCP 工具，能在 Antigravity、Claude Code、Codex、Cursor 里直接操作 Google 的数据服务。

10 月 23 日，Codex CLI 0.164.0 发布。 远程 Bash 和 Zsh 快照工作阶段会遮蔽凭证，包括自定义供应商的凭证。

10 月下旬，Claude Code 连发 2.1.304 到 2.1.310。 其中 2.1.307 开始，在权限规则、自动模式、安全检查、hook 或沙箱拦下、询问或退回某个工具调用时，都送出 claude_code.safety_event OpenTelemetry 事件。2.1.310 让企业版自定义角色新增"云端工作阶段"和"Remote Control"权限。

10 月 26 日，MiniMax M3.1 Flash 发布，Agent 任务成本较前代降约 70%。

把这周串起来看，格局很清楚：模型侧只有 MiniMax 和 Kimi 在动能力，剩下所有动作都在权限、审计、凭证、审批。

一个可以传播的观点句：当 Agent 还在演示阶段，没人关心它能碰什么；等它真的开始动生产数据，大家第一个问题不再是"它能不能做"，而是"它做错了我怎么知道、怎么拦、怎么追溯"。

二、Claude Code：把"被拦下"变成可观测事件

先看 Claude Code 的 2.1.307。这条改动看起来不起眼：多送一个 OpenTelemetry 事件。

但它解决的是治理里最要命的一个缺口——盲区。

Agent 有权限系统，但你不知道它今天被拦了多少次、拦的都是什么。运维团队看到的只有"任务成功了"或者"任务失败了"，中间那些"本该执行但被规则拒绝"的操作是隐形的。

加上 safety_event 之后，被拦下的每一次操作都变成一条结构化事件：什么时候、哪条权限规则、哪个工具调用、hook 还是沙箱拦的、是询问还是直接退回。

2.1.310 补的是另一半——谁能开这些权限。企业版自定义角色新增"云端工作阶段"和"Remote Control"，Owner 可以按角色开开关。

两件事合起来才完整：每一次拦截都有记录，谁能配置这些规则也能按角色管。

有个细节值得注意。

2.1.309 修的是沙箱里 Bash 指令执行前会先在沙箱外跑 shell 启动文件的问题。看起来是小 bug，但它正好压在"沙箱边界"这个关键词上。

那一周 Claude Code 的窗口版本几乎全是权限与安全修复——符号链接的 Read deny 绕过、sandbox 自动放行下环境变量前缀绕过 Bash deny，都在名单上。

沙箱和 deny/ask 规则的组合，目前仍然不稳。 这是官方自己在修的。

三、Codex：让凭证不再出现在对话记录里

Codex CLI 0.164.0 里有一条，AI 编程助手领域的从业者应该重点关注：

远程 Bash 与 Zsh 快照工作阶段中，会遮蔽凭证（包含自定义供应商的凭证）。

为什么这条重要？因为它是 AI 编程助手领域的经典事故源。

Agent 要执行远程命令，就得拿到密钥。

而密钥一旦被写进命令行，就会同时出现在三处：shell 历史、Agent 的工具调用记录、以及对话上下文里。

对话上下文尤其麻烦。它可能被压缩、被摘要、被存进会话数据库，也可能随着请求发到模型提供方那边。

于是就有了这一系列改动：Claude Code 的 hook 拦截、Codex 的凭证遮蔽、OpenClaw 的"secret egress proxy 拒绝不可信证书链"、“Fish Audio 和 Gradium 错误不再暴露 API key”。

同一个问题被五家厂商在同一周各自修了一遍。 这在 AI 工具史上不常见。

四、Google：skills 是建议，IAM 才是强制

这一周最有设计感的改动在 Google。

Data Agent Kit 的 GA 版本随附 37 个 Apache 2.0 协议的开源 skills。里面有一个叫 accidental-data-loss-prevention，描述开头就是 “STOP AND VERIFY”，指示 agent 在任何不可逆操作前必须获得明确的用户同意，并列举了具体清单：DROP TABLE、TRUNCATE、缺 WHERE 条件的 DELETE 或 1=1、对生产 bucket 的存储删除、gcloud projects delete、KMS 密钥销毁。

流程是：停下 → 解释影响 → 等待肯定同意。

听起来很严格。但 InfoQ 那篇分析里，Google 的产品经理 Jeff Nelson 说了一句关键的话——原话大意是：那只是建议，agent 是被要求去遵守它的。第二个控制不是。

真正的强制在 IAM 层。用只读服务账号 + 身份模拟跑 agent；或者用一条 IAM deny 策略，挡住任何"非只读"的 MCP 工具：

api.getAttribute('mcp.googleapis.com/tool.isReadOnly', false) == false

这条 deny 会撤销 mcp.googleapis.com/tools.call 权限，可以挂在组织、文件夹或项目层级。配套的属性还能限制 resource.service 和 tool.name。

这就是那套两层护栏的完整逻辑：

一个可以传播的观点句：把"请不要 DROP TABLE"写进 skill，和把 DROP TABLE 从 IAM 里删掉，是两件完全不同性质的事。前者依赖模型听话，后者依赖平台不让你。

但这套设计有三个已知限制，InfoQ 那篇也点了：

1. 被 deny 的工具仍然出现在 tools/list 里——agent 能看到自己有的能力，只是调用的时候会失败
2. 这些控制只覆盖 Google Cloud 的 MCP 服务器，别的平台不管
3. resource.service 和 tool.name 只在 gcloud 命令行有，控制台里没有

顺便说，Google 后来还补了一批"helper skills"专门做 IAM 相关的事：生成并校验最小权限策略、几秒内定位 403 的缺哪个权限、用 90 天历史访问日志模拟变更的爆炸半径、以及通过 PAM 做按时授予、用完即收的临时提权。

其中"模拟爆炸半径"这一条我觉得是这周最被低估的功能。它解决的是一个真实痛点：IAM 收紧权限是好事，但一收就可能打断线上业务。没有模拟，你只能在用户投诉里发现问题。

五、AWS：给工具加一道审批工作流

AWS Agent Registry 的思路和 Google 互补：Google 管的是"这个 agent 能碰什么"，AWS 管的是"这个工具能不能被发现"。

具体机制是审批工作流。autoApproval 设为 false 时，一条新记录必须走 DRAFT → PENDING_APPROVAL → APPROVED。提交和状态更新都是 IAM 授权的，publisher 和 approver 可以是不同的人。只有完成审批流程的记录，才会出现在可发现的数据面里。

AWS 那篇博客里有一句话点出了这套设计的价值：

这套模式把此前和 orchestrator 发布耦合在一起的几项能力解耦了。新增一条兼容的、已批准的 Registry 记录，不需要改 orchestrator 代码。

也就是说，"能不能被 agent 发现"从代码发布流程，变成了一个管理动作。

还有一个细节：Registry 搜索结果不返回能力的调用凭证或认证方式。授权（用 IAM 还是自定义 JWT）和调用认证（Cognito OAuth、Boto3 签名）是分开的。

AWS 官方自己的总结是这么分类的收益：解耦发布、治理式发现、认证分离、用目录搜索代替 prompt stuffing。

最后这条尤其值得记。过去 agent 的做法是把所有工具描述塞进上下文；现在改成搜索出一小批候选。搜索质量取决于描述、描述符质量、查询设计和评测——这让"description 怎么写"从工程细节变成了决定效果的核心变量。

六、为什么云厂商在这时候集中补权限

把这一周串起来看，能看到一条清晰的产业逻辑。

第一，Agent 有了身份。 OpenAI 的 Dots 给每个 dot 独立云工作区和企业身份；Google 的 Data Agent Kit 让 agent 以你的身份或服务账号身份连接数据云；AWS Agent Registry 给 MCP 服务器配 IAM 授权。身份一旦有了，权限就成了绕不开的问题。

第二，Cloudflare 把 10 万个电商站点开放成 Agent 可调用工具（WebMCP 协议）。工具的调用边界第一次成了公开的协议设计问题。

第三，也是最实际的：事故已经发生了。 那一周里有一件事被反复提到——Meta Muse 的"分享链接"本身是数据外泄入口（GhostShares 漏洞，10 月 22 日修复并重开分享）。这正好说明：Agent 产品的攻击面不只在模型，也在"分享"这个动作。

所以云厂商集体补权限不是跟风，是必然。

有一个视角我觉得被低估了：这些护栏最终都落在云上。

skills 是软建议，跑在你本机还是云上效果差不多；但 IAM、Principal Access Boundary、VPC Service Controls、Model Armor，这些只有云能提供。当 Agent 有了生产身份，能给它划硬边界的只有云平台。

这直接解释了为什么 Google、AWS 都在同一周推这类服务——Agent 治理的战场在云上，不在模型里。

七、给团队的三个问题

如果你是团队里负责引入 AI 工具的人，这一周的动作值得转化成三个自查问题：

第一，我们能不能回答"agent 今天被拦了多少次"？

如果答案是不行，那就缺一个可观测层。Claude Code 的 safety_event 是个起点——把拦截变成事件，接到你现有的日志系统里，观察一两周被拦的操作类型，再决定放宽哪些。

第二，我们的"不要做危险操作"是靠提示词还是靠权限？

如果答案是提示词，那它就是个建议。Google 的两层护栏给了对照：skills 层写建议，IAM 层写强制。至少挑一类不可逆操作（删数据、删密钥、删项目），把它从 IAM 里真正堵上。

第三，我们把工具暴露给 Agent 的时候，有审批流程吗？

AWS 的 DRAFT → PENDING_APPROVAL → APPROVED 是个很轻的模板，但解决的是"谁能让 agent 用上这个工具"这个真问题。发布者与审批者分离，在企业环境里几乎是硬要求。

这周还有一件事我得记一下：这些控制大多只覆盖自家云。Google 的 IAM 策略管不了别家的 MCP 服务器，AWS 的 Registry 也管不了 Google 的工具。企业如果跨云用 Agent，边界就得自己另外建。

你们团队现在给 Agent 划边界，靠的是提示词还是权限？ 评论区聊聊，这两种做法的实际差别，比想象的大。