GitHub Repo
Hermes Agent、プロファイル間の認証情報フォールバックを修正 完全な分離はなお検証待ち
メインブランチで認証情報スコープに所属ディレクトリの情報を追加し、値の欠落や初期化失敗時に生じる分離の問題を一部修正。レビューでは別のフォールバック経路にも疑問が示されており、導入側は実際のバージョンを確認する必要がある。

Nous Researchは9月23日、認証情報の分離に関する一連の修正をHermes Agentのメインブランチにマージした。エージェントがプロファイルを切り替えた後、キーがない場合や読み取りエラーが発生した場合に、起動時の環境の認証情報を引き続き使用してしまう挙動に対処するものだ。修正対象はデスクトップバックエンド、スケジュールされたジョブ、MCP接続に及ぶ。現時点で確認できるのはメインブランチの変更であり、既存のインストール環境にも修正が含まれているとは限らない。[マージ記録](https://github.com/NousResearch/hermes-agent/pull/120128)
Hermesの各プロファイルは、それぞれ独自のデータディレクトリと認証情報を持つ。問題は、従来の認証情報スコープが名前と値だけを保持し、所属ディレクトリを記録していなかった点にある。一部のバックエンドは、複数のプロファイルでプロセスを共有するモードを無効にしていても、別のプロファイルのジョブを実行する。その際、値が欠けているとプロセスの環境変数にフォールバックし、起動時のプロファイルのキーを取得する可能性があった。[当初の修正説明](https://github.com/NousResearch/hermes-agent/pull/119459)
新しいロジックでは、スコープに所属ディレクトリの情報を持たせ、別のプロファイルの処理中にキーが見つからなければ、呼び出し元が指定したデフォルト値を返す。テストは通常のルーティングに加え、ホームディレクトリを切り替えずにジョブを実行する経路も対象としている。起動時のプロファイル自身に対する環境変数の注入は維持される。[修正とテスト](https://github.com/NousResearch/hermes-agent/pull/119459) 運用の観点では、研究用プロファイルにサービスのキーがない場合、機能が利用できなくなるか、設定の補完を求められるのが妥当だ。業務用プロファイルの認証情報を自動的に流用すると、リクエストが誤ったアカウントに紐づき、データへのアクセス範囲や費用の負担先まで変わる可能性がある。
もう一つの修正では、スコープの設定処理を、必ずクリーンアップが実行される処理ブロックに含めた。従来は、ディレクトリが破損している、または削除されているなどの理由で初期化の途中にエラーが発生すると、不完全な状態が残り、後続の操作も誤ったディレクトリを参照し続ける可能性があった。修正では失敗時のクリーンアップと回帰テストを追加し、一つのMCP接続の再登録に失敗しても、ほかの接続の処理が妨げられないようにした。[初期化の修正](https://github.com/NousResearch/hermes-agent/pull/119486)
ただし、プルリクエストのレビュアーは、共通のツール用認証情報リゾルバー、一部のAPIキーの読み取り、未登録のプラグインの認可設定にも疑問点が残ると指摘している。これらのコメントは特定のコミットを対象としており、現行のすべてのバージョンに脆弱性があると断定する根拠にはならない。同時に、プロファイル間で生じるこの種の問題がすべて解消されたと宣言するにも不十分だ。[レビューでの議論](https://github.com/NousResearch/hermes-agent/pull/120128)
導入側は今後、インストール済みのコミットを確認し、各プロファイルに認証情報を設定したうえで、値の欠落、読み取り時の例外、プロファイルの切り替えをテストする必要がある。公式のアーキテクチャドキュメントも、プロファイルの分離にはエンドユーザーの認証と認可が含まれないと明記している。このため、サービスへのアクセスを受け付ける入口には、別途アクセス制御を設計する必要がある。[アーキテクチャドキュメント](https://hermes-agent.nousresearch.com/docs/developer-guide/multiplexing-gateway)