エージェントにキーを見せるべきでないという結論に、業界全体が合意しました。ただし、隠す場所を間違えています。

今週、Anthropic は Claude Code の changelog に静かな1行を追加しました。「Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode」 [1]。平たく言うと、Claude Code がヘッドレスモード（CI や自動化されたエージェントパイプラインで実行される方式）で動いていたとき、本来隠されているはずの認証ツールがモデルに公開されてしまっていたということです。AI は認証ツールの名前やパラメータを見ることができ、場合によってはそれらを操作しようとしていた可能性があります。地球上で最も使われているコーディングエージェント——スター数 133k——において、資格情報レイヤーが、最も見られてはいけない場所、つまりモデル自身のコンテキストへと漏れ出していたのです。

修正は入りました。しかし、その修正は小さな話です。大きな話は、なぜ本気のエージェントハーネスがすべて、突然同じ戦いを戦っているのかという点です。

3つのハーネス、1週間、同じ直感

24時間という一つの時間窓で出荷されたものを見てください。

• Claude Code は上記の認証スタブ（auth-stub）リークを修正し、MCP 認証のゲートを厳格化しました [1]。
• Hermes（v0.17.0）は「Managed Scope」を追加しました。管理者が固定し、ユーザーが変更できないシークレットをファイルシステムにロックし、エージェント運用者が上書きできないようにしたものです。加えて、デバッグダンプでのシークレットの秘匿、およびデータ持ち出しの形をした MCP 設定の起動前のブロックも含まれます [2]。
• Codex（v0.141.0）はリモート実行トラフィックを暗号化された Noise チャネルでラップし、プラグインを認証モードに応じてルーティングするようにしました [3]。

競合3社、3つのアプローチ、1つの共通の結論です。シークレットはハーネスが所有し、エージェントは生のキーを決して見えてはならない。競合が同じ週にこのように収束するのは流行ではありません。あるカテゴリが、ようやく自らの役割を認めたということです。

次の問題は資格情報の分散です

問題はここからです。これらの修正はすべてハーネスの中にあります。そして、Claude Code のバグがそれを示しています。認証がハーネスの中、モデルのすぐ隣に置かれている限り、「エージェントはそれを見えてはならない」は事実ではなく、設計し続けなければならない性質になります。そして、人間が見ていないヘッドレスモードでは、時にそれに失敗します。一度宣言して終わりではないのです。リリースごとに守り続ける必要があります。

しかし、より深い問題は単一のリークではありません。すべてのハーネス、すべてのベンダー、すべてのユースケースがそれぞれの答えを出荷したときに何が起きるかです。Claude Code の中に Vault、Hermes の中に Vault、Codex の中に Vault、ここに OAuth プール、あそこにシークレットファイル——実行するツールごとに別の資格情報ストアができあがります。これが資格情報の分散であり、解決済みの問題ではなく次の問題です。

どのサイロも漏らしていなくても、分散それ自体が失敗です。動作させるために、シークレットがそれぞれにコピーされます。コピーが増え、盗まれる場所も増えます。ローテーションは N 回、手作業で行う必要があり、忘れた1つが致命傷になります。そして、本当に重要な問い——どのエージェントが、どのキーを、何に対して、いつ使ったか——に答えられる者はいません。答えが、互いに通信しない12のストアに散らばっているからです。ベンダーごと、ワークフローごとに新しい Vault を立ち上げることはできません。スケールしません。壊れるのはまさにそこです。

キーはそもそもハーネスに属していません

出荷し続けなくてよい修正とは、エージェントが最初から認証を保持しない構成です。資格情報を、すべてのハーネスの外に位置する単一の権限に置きます。ベンダーごとの Vault ではなく、そのすべての下に置かれる1つのものです。エージェント——Claude Code でも、Codex でも、Hermes でも、どれでも構いません——は名前付きの1つのアクションを要求し、それ専用にスコープが限定された一時的な資格情報が注入されます。取得はその都度行われ、使用後には消えます。

誤って公開してしまう認証スタブがモデルのコンテキストに存在しません。認証がそもそもハーネスになかったからです。分散もありません。ツールごとに1つではなく、ストアが1つだからです。ローテーションは N 回ではなく1回で済みます。そして、すべてのアクセスは、誰が何を使ったか答えられない12のサイロに散らばるのではなく、単一の監査証跡に残ります。（シークレットを、コードが実行される場所から遠ざけることは、資格情報ツールが守るべきルール の上位に位置します。業界はそれを確かめるのに1週間を費やしました。）

そしてここは、利便性ではなくセキュリティ境界です。資格情報は、エージェントと同じシステムに置くことができません。同一に置けば、影響範囲を共有します。プロンプトインジェクション、改ざんされた MCP サーバー、共有されたデバッグダンプ、次の認証スタブバグ——エージェントに届くものは、キーにも同時に届きます。だからこそ、可視性そのものが侵害です。シークレットがエージェントから見える場所に置かれた瞬間に、すでに漏洩したものとして扱い、ローテーションする。注意深いチームがすべて、Claude Code の認証スタブを出荷当日にそう扱ったのと同じようにです。資格情報を手の届かない距離に置き、エージェントが要求することしかできない——読み取ることはできず、保持もできない——システムに置いてください。完全に侵害されたエージェントでも、手の届かなかったものを外に出すことはできません。アクションを要求することはできても、キーを持ち去ることはできません。この距離こそが防御であり、同一プロセス内の Vault は、どんな代価を払ってもその距離を持てません。

Clavitor が引く線はここです。業界全体が、その原則——エージェントはキーを見るべきではない——を実証しました。ただ、実行するハーネスごとにそれを再証明するのは負担だと考えます。そして、キーを保持するものが、攻撃者が侵害したものと同じであるべきではないと考えます。

ハーネスのチームの功績は認めるべきです。管理者固定シークレット、暗号化リレー、フェイルクローズのデフォルトは、実在する優れたエンジニアリングです。しかし、繰り返し現れるリークへのその場しのぎの修正はアーキテクチャではなく、症状です。アーキテクチャとは、リークされるはずの場所にキーが存在しないことです。

3つの競合が同じ週に同じ傷を塞ぐなら、傷そのものが設計です。エージェントはあなたのキーを見るべきではありません。だから、見える場所に置くのはやめてください。

Clavitor（@clavitorai）は、AI エージェントのために作られ、AI エージェントに対して守るために作られた資格情報ボルトです。clavitor.ai

出典

[1] Claude Code v2.1.183 — "Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" — 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