整个行业刚刚达成共识：您的智能体不应看到您的密钥。但他们把密钥藏错了地方。

本周，Anthropic 在 Claude Code 的更新日志中悄然加入了一行："修复了在 headless/SDK 模式下，需要认证的 MCP 服务器向模型暴露 auth-stub 工具的问题" [1]。说白了——当 Claude Code 以 headless 方式运行时（也就是它在 CI 和自动化智能体流水线中的运行方式），本应保持隐藏的认证工具被暴露给了模型：AI 能够看到这些认证工具的名称、参数，并可能对其发起调用。在这个全球使用最广泛的编码智能体上——133k stars——凭证层泄漏到了您最不希望它出现的地方：模型自身的上下文。

问题已修复。但修复本身只是小故事。真正的大故事是：为什么每一个严肃的智能体运行框架都在同一时间打同一场仗。

三个运行框架，一周之内，同一种本能

看看在同一个 24 小时窗口内发布了什么：

• Claude Code 修补了上述 auth-stub 泄漏，并收紧了 MCP 认证门控 [1]。
• Hermes（v0.17.0）加入了 "Managed Scope"（受管作用域）——由管理员固定、用户不可更改的密钥，锁定在文件系统层，智能体运维方无法覆盖——外加调试转储中的密钥脱敏，以及在启动前拦截具有外泄特征的 MCP 配置 [2]。
• Codex（v0.141.0）将远程执行流量封装进加密的 Noise 通道，并开始按认证模式对插件进行路由 [3]。

三个竞争对手，三种做法，一个共同结论：运行框架必须掌控密钥，智能体绝不能看到原始密钥。 当竞争对手在同一周内如此趋同时，这不是一时风潮。这是一个类别终于承认了它存在的意义。

下一个问题是凭证蔓延

问题在于。上述每一项修复都位于运行框架内部。而 Claude Code 的那个缺陷暴露了真相：当认证存在于运行框架中、紧挨着模型时，"智能体绝不能看到它"就不再是一个既成事实，而变成了一项您必须持续工程化维护的属性——并且偶尔会在 headless 模式下失守，那时没有任何人在盯着。您无法一次性声明它。您必须一个版本接一个版本地守住它。

但更深层的问题不在于任何单次泄漏——而在于当每个运行框架、每家供应商、每个用例都各自交付自己的方案时会发生什么。结果是 Claude Code 里有一个保险库，Hermes 里有一个，Codex 里有一个，这边一个 OAuth 池，那边一个密钥文件——为您运行的每一个工具各建一套独立的凭证存储。 这就是凭证蔓延，它是下一个问题，而不是一个已解决的问题。

即使所有孤岛都不泄漏，蔓延本身就是失败。为了让它工作，您的密钥被复制进每一个孤岛——副本更多，可被窃取的地方也更多。密钥轮换必须手动进行 N 次，而您忘记的那一次，就是烧到您的那一次。而且没有人能回答唯一真正重要的问题——哪个智能体用了哪把密钥、针对什么、在什么时候——因为答案散落在十几个互不相通的存储中。您不可能为每一家供应商、每一条工作流都新建一个保险库。那无法扩展。它就是会出问题的东西。

密钥根本不属于运行框架

您永远不需要发布的修复，是那种智能体从一开始就不持有认证的方案。把凭证放进一个位于所有运行框架之外的权威机构——不是每家供应商一个保险库，而是在它们所有人之下放一个。智能体——无论在 Claude Code、Codex 还是 Hermes 中，都无所谓——请求一个具名操作，然后获得一枚为此操作限定范围的、短暂的凭证注入，实时获取、用后即失效。模型上下文中没有可被意外暴露的 auth-stub，因为认证从来就不在运行框架里。也没有蔓延，因为存储只有一套而不是每个工具一套——轮换一次，而不是 N 次。每一次访问都落在同一条审计轨迹上，而不是散落在十几个无法回答"谁用了什么"的孤岛中。(将密钥隔离在代码运行之处之外，位居凭证工具应当遵守的规则前列——整个行业刚刚花了一周时间才领悟到这一点。)

而这一部分是安全边界，不是便利性：凭证不能与智能体处于同一系统之中。 把它们放在一起，它们就共享同一个爆炸半径——一次提示注入、一个被投毒的 MCP 服务器、一份共享的调试转储、下一个 auth-stub 缺陷，凡是能触及智能体的东西，也会连带触及密钥。这正是为什么"可见"本身即构成失陷：一旦密钥落在智能体能看到的地方，就应当视同已经泄漏并立即轮换——就像每一个谨慎的团队在那个 Claude Code auth-stub 发布当天所做的那样。把凭证保持在一臂之外，放在一个智能体只能请求——永远不能读取、永远不能持有——的系统里，即使智能体被完全攻陷，也无法外泄从未进入其触及范围的东西。它可以请求一个操作。它不能把密钥带走。这段距离就是防御；进程内的保险库无论付出什么代价都不具备它。

这就是 Clavitor 划下的界线。整个领域刚刚证明了这条原则——智能体不应看到密钥。我们只是认为，您不应该在您运行的每一个运行框架里重新证明一遍；而且我们认为，保管您密钥的东西，不应该是攻击者刚刚攻陷的那个东西。

给运行框架团队应有的肯定：管理员固定的密钥、加密中继、默认 fail-closed，都是实实在在的好工程。但针对一个反复出现的泄漏，每周一次的修复不是架构——那是症状。真正的架构，是密钥根本不在那里可供泄漏。

当三个竞争对手在同一周内修补同一处伤口时，伤口本身就是设计。智能体不应看到您的密钥——所以，别再把密钥放在它能看到的地方。

Clavitor（@clavitorai）是为 AI 智能体而建、也是防着 AI 智能体的凭证保险库。clavitor.ai

来源

[1] Claude Code v2.1.183 — "修复了在 headless/SDK 模式下，需要认证的 MCP 服务器向模型暴露 auth-stub 工具的问题" — https://github.com/anthropics/claude-code/releases/tag/v2.1.183

[2] Hermes Agent v0.17.0 — Managed Scope（管理员固定密钥）、密钥脱敏、外泄配置拦截 — https://github.com/NousResearch/hermes-agent/releases

[3] OpenAI Codex v0.141.0 — 加密 Noise 中继通道、按认证模式路由插件 — https://github.com/openai/codex/releases