AI Revocation Window：Gemini API Key 让我重写事故响应#

这两天我一直在想一个很小、但很刺人的细节：在 AI 应用里，一个泄露的 key 到底什么时候才算真的死了？

这个问题过去看起来像云厂商的实现细节。现在不是了。因为同一个 key 后面挂着的，已经不只是地图、日志、数据表，而可能是 Gemini 这样的模型入口、上传文件、缓存上下文、账单额度，以及一个团队刚刚接入的 agent 工作流。

近 24 小时里，TechCrunch/Yahoo 把 Google API key 删除后的安全窗口重新推到讨论中心；更一手的证据来自 Aikido 在 2026-05-21 发布、2026-05-22 更新的测试：传统 Google API key 删除后，最长还能继续认证接近 23 分钟，10 组测试的中位数大约是 16 分钟。Aikido 还明确说，如果项目启用了 Gemini，这个窗口里攻击者可能继续访问上传文件和缓存对话。Google 起初把报告关成 won't fix，后来又重新打开并按 P0 处理。

我觉得这里真正重要的不是“Google 又出了一个安全新闻”。真正重要的是：AI 时代把很多原来可以忍受的 eventual consistency，拖进了权限边界。

删除按钮不是事故响应#

传统系统里，我们经常把凭证删除当成一个完成动作：

泄露了，删掉。

泄露了，rotate。

泄露了，关旧 key，开新 key。

这个 mental model 在 AI 应用里开始变得危险。Aikido 的测试不是在说“有些请求慢一点失败”，而是在说认证系统对同一个已经删除的 key 会呈现不均匀的衰减：有些服务器已经拒绝，有些服务器还接受。攻击者不需要理解你的控制台状态，只需要继续打请求，直到还有一个边缘节点没同步。

这让我重新定义了 incident response 里的“撤销”。撤销不应该是一个布尔值，而应该是一个状态机：

key 已从控制台删除；
新凭证已替换；
下游调用已切换；
旧 key 的成功请求归零；
风险窗口结束；
账单、文件访问、模型调用日志完成复核。

少了后面三步，删除只是用户界面里的安慰剂。

Agent 让 23 分钟变得更贵#

如果一个 key 只能打一个低价值 API，23 分钟已经不好。但如果它能打模型 API，这 23 分钟会被放大。

原因很简单：agent 的调用不是一次请求，而是一串行动。它会读文件、总结上下文、调用工具、写入系统、继续递归。过去凭证泄露的风险主要是“数据被拿走”或“账单被刷爆”；现在还要加上“执行链被接管”。

这也是我认为 AI 安全从“密钥管理”升级成“运行时治理”的原因。我们不能只问 key 是否泄露，还要问：

这个 key 能不能访问模型缓存？
它能不能读用户上传的文件？
它能不能触发工具调用？
它能不能产生不可逆动作？
撤销期间有没有单独的熔断层？

如果答案都在云厂商控制台里，那开发者其实没有完整的控制面。

我会怎么改自己的默认做法#

这件事给我的直接工程结论有三个。

第一，所有 AI API key 都应该默认带约束。能限制来源 IP 就限制来源 IP，能限制 API 范围就限制范围，能用服务账号或更短生命周期凭证就不要长期裸 key。不要把“以后泄露了再删”当成安全策略。

第二，事故响应文档里要把 key 删除写成 30 分钟窗口，而不是瞬时动作。Aikido 的建议也是把删除后的风险窗口按 30 分钟处理。这个数字不优雅，但比“已删除所以安全了”诚实。

第三，agent 系统要有自己的 kill switch。这个开关不应该依赖同一个外部 key 的删除传播，而应该在应用侧阻断：禁用该 tenant 的模型调用、暂停工具执行、冻结高风险 action、切断文件读取路径。云厂商的凭证撤销可以作为底层动作，但不能是唯一动作。

我越来越觉得，AI 应用的成熟度不看 demo 里 agent 能做多少事，而看事故发生时它能多快停下来。模型能力越强，撤销语义就越重要。权限系统里最关键的按钮，可能不是“授权”，而是“现在立刻停”。

这也是今天这条新闻对我的意义：AI 的下一层竞争，不只是模型、上下文、价格、工具生态，而是运行时里那些“不性感但决定生死”的合同。一个 key 删除后还能活多久，一个 agent 接到停止信号后还能动几步，一个上传文件被撤权后还能被模型看到多久，这些东西会变成真正的产品边界。

我不太相信“AI 安全以后会被平台自动解决”。平台会进步，但开发者要先承认一个现实：当 AI 接入真实数据和真实动作之后，eventual consistency 不再只是分布式系统的 tradeoff，它会变成用户数据、账单和执行权限之间的时间裂缝。

参考：