Claude 每次都问你批准，也不等于安全

Claude 现在能替你按下 Gmail 的发送键了。

不是只读邮件，也不是把回复放进草稿箱等你手动处理。Claude 的官方发布写得很直接，它可以发送、回复和转发邮件，还能管理 Google Drive 里的文件。

同一个聊天框，昨天给你找资料，今天开始替你做动作。

看起来只多了一个按钮。

责任边界却跨出去了。

好家伙，这类更新特别容易被写成效率故事。以后不用来回切 Gmail，不用手动搬文件，Claude 看完线程就能把回复发出去。演示当然丝滑，我更在意官方反复强调的另一句话。

默认情况下，每次写操作都要用户批准。

很多人看到这里会松口气。只要每次都弹窗，Claude 不就不能偷偷发信了吗？

我自己的判断有点不一样。

批准是一个输入信号，不是一套安全策略。

如果确认框只问「是否允许 Claude 使用 Gmail」，用户看不到收件人、主题、附件、回复对象和正文变化，那次点击几乎没有决策价值。它只是一个穿着权限外套的确定按钮。

就像终端问你要不要执行一段两百行脚本，却只露出文件名。你当然点了批准，可你批准的到底是哪件事？

这次发布真正有意思的地方，就藏在这些动词里。

新版 Google Workspace 连接器文档把 Gmail 的能力列得很清楚。搜索和阅读是一组，起草是一组，发送、回复和转发又是一组。Google Drive 那边不只会查文件，还能分享、移动和移入回收站。

官方演示里，连接器从资料入口变成了真实动作入口

别把它们都塞进一个「读写权限」里。

读错一封邮件，常见后果是回答里混进错误信息。发错一封邮件，内容已经抵达另一个人的邮箱。搜索错一个文件，Claude 可能拿错上下文。分享错一个文件，原本只在团队内流转的内容可能直接露给外部账号。

移动和移入回收站看着都叫文件管理，恢复成本也完全不同。移动通常能搬回来，回收站多数时候能恢复，改了分享权限却可能已经让别人下载过副本。邮件更直接，发送以后没有真正可靠的撤回。

同样是写，影响半径、可逆性和外部可见性差得很远。

Drive 还有一层很容易被聊天界面藏掉的复杂度。

文件权限不一定只挂在文件自己身上，它可能从父文件夹一路继承下来。Google Drive 的共享文档写得很明确，文件被移进另一个文件夹后，新位置的权限会向下传播。原来只有项目组能读的文件，搬进一个更开放的目录，实际可见范围可能跟着变化。

所以「移动文件」的预览不能只给旧路径和新路径。它还要算出移动前后的有效权限，告诉用户有没有新增外部读者、编辑者或者整个域名。路径只变了一行，访问控制列表可能换了一套。

更麻烦的是并发。Google 官方提醒，同一个文件上的并发权限操作不受支持，只保留后一次更新。用户在批准页面看到的是状态 A，另一个管理员随手改完权限，Agent 再按旧预览提交，结果可能已经不是用户刚才批准的那份差异。

这类问题不能靠多弹一次框解决。执行前要重新读取对象状态，核对文件 ID、版本与有效权限。只要关键状态变了，旧批准就作废，重新生成差异再问。数据库里常叫乐观并发控制，放进 Agent 里就是一句人话。

批准绑定的是某个具体状态下的动作，不是一张可以无限复用的通行证。

所以一个像样的批准界面，至少得回答四件事。

模型准备对哪个对象做动作，具体改什么，影响会扩到哪里，出了错能不能撤销。

发邮件时，收件人和抄送里有没有外部域名，正文相对原线程新增了什么，附件到底是哪一个版本，都应该在批准前露出来。分享文件时，旧权限和新权限要并排展示，reader 变成 writer 不能只压成一句「更新共享设置」。移入回收站时，界面也该说明恢复入口和保留时间。

这才叫批准。

不是让用户替系统背锅。

Anthropic 在企业权限上其实已经搭了一副挺完整的骨架。自定义角色文档把每个连接器和具体工具分成三档，Always allow、Needs approval、Blocked。

Always allow 允许成员把某些工具设为免逐次确认。Needs approval 强制每次确认，个人设置里连 Always allow 都不会出现。Blocked 更彻底，工具对模型不可见，也调用不了。

组织级策略是天花板，自定义角色只能往下收。一个人属于多个角色时，角色里的授权会相加，再和组织策略取更严格的结果。Claude Cowork 对可写工具还有额外闸门，默认不允许用户把这类动作设成跨任务永久放行。

厉害了，这里最值钱的并不是多了一个管理员页面，而是权限判断没有交给模型猜。

模型可以建议发信，不能因为上下文里出现一句「以后都不用问我」就给自己升级权限。它可以解释为什么要移动文件，不能自己决定从 Needs approval 切到 Always allow。

权限变化必须发生在模型上下文之外，由确定的身份、角色和组织策略控制。

可问题也跟着来了。

Always allow 到底允许多大？

如果粒度只到「Gmail 连接器」，那它可能同时覆盖搜索、阅读、起草、发信、转发和标签管理。用户只是嫌每次读取邮件都要点确认，顺手把整套工具永久放行，结果发送能力也搭上了便车。

不是哥们，这就不是少点几次弹窗了，这是把读和写绑成一把总钥匙。

更稳的做法，是让授权贴着具体动作走。读取可以长时间允许，起草可以自动，发送继续逐次批准。内部域名收件人和外部域名收件人分开。移动到某个项目文件夹可以放行，修改公开分享权限继续停住。永久授权能拆成一小时、一次任务、一个会话，风险会小很多。

Google 自己的 OAuth 最佳实践也在强调同一件事。权限应该按功能逐步申请，只在用户真的要用某项能力时请求对应 scope，并尽量选择最小、最受限的范围。

连接 Gmail，不该天然等于永久获得读取全部邮件和代发邮件的总权限。一个任务只需要查线程，就别提前拿发送 scope。用户拒绝某项权限，产品应该关闭相关能力，而不是过几分钟换个文案再磨一次同意。

很多朋友可能会说，Claude 继承的本来就是用户现有权限，用户能做的事，Agent 做一下有啥区别？

区别在速度和规模。

一个人手动改错文件，通常一次动一个。Agent 可以在一分钟里处理几十个对象，还可能把同一种误判复制到整批任务。它继承的是同一份权限，放大的却是执行频率、并发和一致犯错的能力。

你想想看，一个拥有整个部门 Drive 权限的管理员，把账号接给可写 Agent。模型没有越权，OAuth 也完全合法，组织策略甚至显示绿色。只要任务理解错了，合法权限照样能把合法文件批量搬到错误位置。

合规不等于没事故。

最小权限还得配最小批量。一次只允许处理多少封邮件、多少个文件、多少个外部收件人，应该有独立限额。批量动作超过阈值，就暂停并展示样本，而不是把五十次写操作压成一个确认框。

说真的，用户点一次「批准这项任务」，很容易以为自己批准的是一个意图。系统真正执行的却可能是四十七次 API 调用。意图层的一次确认，不能自动覆盖执行层的无限次数。

这里还有一个比权限更阴的坑。

重试。

假设发送邮件的 API 已经成功，网络连接却在响应回来前断了。调度器只看到超时，于是自动重试。同一封回复就可能发两遍。第一次是礼貌跟进，第二次开始像催命，第三次收件人大概会怀疑你的 Agent 在工位上抽风。

文件操作也一样。移动成功后响应丢了，重试时旧路径已经不存在。分享权限改完又重放一次，如果调用不是幂等的，审计记录和真实状态可能从这里分叉。

幂等是个工程词，意思很朴素。同一个动作执行一次和执行多次，结果应该一样。对外部写操作，系统最好为每个动作生成唯一的幂等键，让服务端识别重复请求。服务端不支持时，就先读回目标状态，确认上一次是否已经成功，再决定要不要重试。

别把 timeout 直接翻译成 failed。

超时只代表你没收到结果，不代表对方没做事。

这句话放在任何 Agent 运行时里都值钱。模型说要发信只是提议，工具返回成功只是执行结果，外部系统里的真实状态才是验收。三层混成一行「任务完成」，出事时根本不知道该从哪儿查。

我会把可写动作拆成一条很笨的状态链。

prepare -> preview -> approve -> execute -> verify -> record

批准只是中间一扇门，执行后的验证与可撤销路径同样重要

先准备参数和差异预览，再让人批准，然后执行，读回结果做验证，末尾记下外部系统返回的对象 ID。任何一段失败，都保留当前位置，不偷偷从头再跑。

这套东西没什么未来感。

但它能救命。

日志也不能只写一句「Claude 使用了 Gmail」。至少要留下工具名、目标对象、关键参数摘要、提议时间、批准人、批准结果、执行结果和外部对象 ID。敏感正文可以做脱敏或哈希，不影响把动作来路留住。

等用户问「这封邮件是谁发的」时，系统应该能回答是哪个会话提出、哪个策略放行、哪个人批准、哪次 API 调用完成。否则所谓人类在环，只是在界面里放了一只手，事故复盘时连指纹都找不到。

可写 Agent 还会遇到另一个老问题，工具读回来的内容不一定可信。

邮件正文、共享文档和外部网页都可能夹着给模型看的恶意指令。Anthropic 自己在 工具调用文档里提醒，工具结果可能来自不受信任的来源，应该当作不可信内容处理，防止间接提示注入。

这类攻击最麻烦的地方，是它不需要直接拿到 OAuth token。攻击者只要让模型读到一段伪装成业务内容的指令，再诱导它调用已经获批的发送或分享工具，就能借系统自己的权限做事。

逐次批准当然能挡一层，可确认框如果只显示「Claude 请求使用 Google Drive」，用户仍然看不出这次分享动作是由自己提出，还是被文档里一段隐藏文字拐过去的。

所以批准界面还要展示因果链。哪个用户请求触发了动作，模型引用了哪些来源，目标对象为什么被选中。对高风险写操作，允许用户打开一段简短的执行理由和参数差异，比再放一个醒目的红色按钮有用。

坦率讲，真正安全的自动化不会追求所有动作都零摩擦。

它追求把摩擦放在正确的地方。

搜索一封邮件可以顺滑，发送给公司外部联系人就该慢一下。把文件放进私人草稿目录可以自动，改成「知道链接的人都能访问」就该停。普通标签修改可以批量，删除、分享和权限提升要单独计数。

摩擦按风险分层，用户才不会被每一步确认训练成闭眼点允许。

审批疲劳不是用户不重视安全，是产品把太多没有信息量的选择塞给了他。弹十次一模一样的框，得到的不是十次认真决策，而是一次条件反射被重复了十遍。

怎么说呢，Claude 这次把 Gmail 和 Drive 从资料库变成了执行面。对普通用户，这是少切几个窗口。对做 Agent 的人，这是一个很清楚的信号。

模型能力已经不是最难接的那根线了。

难的是把每个动词拆清楚。谁能读，谁能写，谁能分享，谁能删除，哪一步要停，哪一步能撤销，超时以后怎样确认，重试以前怎样去重，事故发生后怎样还原。

这些问题没有一个能靠模型再聪明两分自动消失。

我不反对 Always allow。稳定、低风险、范围明确的任务，免确认当然舒服。可放行条件应该来自一段被验证过的策略，不是因为用户今天赶时间，多点了一个永久允许。

我也不迷信逐次批准。没有对象、差异、影响半径和回滚信息的确认，只会制造安全感，不会制造安全。

草稿是一条建议，发送是一个行为。搜索是一种观察，分享是一次授权。

那个按钮可能只占一个像素点。

按下去以后，Agent 就离开聊天框，进入了别人的收件箱和文件权限表。

船开到这里，批准按钮还不够。

日志、限额、幂等、撤销和最小权限，都得一起上船。