エージェントにSSH鍵を丸ごと渡している：資格情報ブローカーという空白

どんな問題か

Hacker NewsのShow HNに出たGhbrkというツールが、痛いところを突いた。AIエージェントがSSH鍵やAPIトークンに一切触れずにgitとghを実行できるブローカーだ。注目すべきはツールそのものより、それが暴いた空白のほうだ。コーディングエージェントを使うチームの多くは、ホームディレクトリのSSH鍵、環境変数のトークン、フル権限のPATがそのまま見えるシェルをエージェントに渡している。悪意あるWebページのプロンプトインジェクションに一度引っかかれば、デバッグ中にトークンがログに出れば、鍵はそのまま漏れる。人間の社員には最小権限・短命トークン・監査ログが当たり前なのに、エージェントという新しい「社員」には入社初日にマスターキーの束を丸ごと渡す。漏れてもどの呼び出しから漏れたのか、たどる記録すらない。

なぜ今か

コーディングエージェントはデモを抜け、毎日コミットしデプロイする段階に入った。エージェント一体が人間ひとり分の資格情報を要求し始めたのに、セキュリティチームの装備はまだ人間アカウント基準のままだ。シークレットマネージャーは鍵を保管するだけで、「その鍵を握ったプロセスが何を実行しているか」は見ない。その隙間にGhbrkのような個人ツールが現れて注目を集めること自体がシグナルだ。個人の間に合わせが標準インフラ層へ昇格する直前の空白、コンテナ時代の初期オーケストレーションツールが通った道と同じ場所にいる。日本市場では追い風がもうひとつある。大企業へのエージェント導入は情報システム部門のセキュリティ審査が関門で、「エージェントが全ての鍵を読める」構成では稟議が通らない。監査ログと権限分離を最初から示せる構成は、そのまま導入の通行証になる。

どう作るか

エージェントには鍵の代わりにブローカーのソケットだけを見せる。エージェントが「このリポジトリにpush」と要求すると、ブローカーがポリシーを評価し、リポジトリの範囲、ブランチ、コマンドの許可リスト、頻度制限、通過した要求だけボールトから短命の資格情報を取り出して代理実行し、結果だけを返す。鍵は1バイトもエージェントのコンテキストに入らない。force pushや本番シークレットへのアクセスといった危険な操作はSlack承認へエスカレーションし、全呼び出しを監査ログに残す。

flowchart LR
  A[AIエージェント] -->|コマンド要求| B[資格情報ブローカー]
  B -->|ポリシー評価| P[ポリシーエンジンと監査ログ]
  B -->|短命キー貸与| V[資格情報ボールト]
  B -->|代理実行| G[git・gh・API]

入り口は狭く取る。特定のコーディングエージェント向けのドロップインラッパーから始めて一行インストールで済ませ、次にエージェントフレームワーク統合、最後に企業IAMや既存ボールト(HashiCorp Vault、クラウドKMS)との連携へ登る。課金はシート課金に、監査・コンプライアンス機能を上位プランとして載せる。

成功の条件

第一に摩擦ゼロ。インストールが一行を超えるか、エージェントが目に見えて遅くなれば、開発者は鍵を元に戻してしまう。第二にデフォルトポリシーの均衡。安全でありながら実作業を止めない初期値を引けるか。作業を塞ぐツールは金曜には無効化される。第三に標準の座の先取り。エージェントフレームワークとCIの生態系に統合として食い込み、「エージェントの資格情報はこれを通す」が慣行になった側が市場を持っていく。