Hermes Agentコミュニティ、プロファイル間の会話検索制限を提案　公開コードがデータ分離の境界を明らかに

Hermes Agentコミュニティは10月30日、session_searchにプロファイル間のアクセス制限を追加するよう求めるissueを提出した。報告者によると、同じホスト上で異なるprofileを別々のユーザーや信頼度の低いタスクに割り当てていても、エージェントはprofileパラメーターやプロファイル名を含む会話リンクを使って、他のprofileの記録を読み取れる。確認時点でissueは未解決のままで、メンテナーによる確認や修正のマージは確認されていない。コミュニティのissue

公式ドキュメントでは、profileはそれぞれ独立したHermesのホームディレクトリとして定義されている。設定、APIキー、メモリ、会話、状態データベースを分けて保存し、コーディングアシスタント、個人用ボット、研究エージェントなどを区別する用途に適している。この保存方式によって状態の混在は避けられるが、今回の報告とコードからは、ツールがディレクトリをまたいでデータを読み取れるかどうかを、デプロイする側が別途確認する必要があると推測できる。Profilesドキュメント

現在のメインブランチでは、検索ツールが会話リンク内のプロファイル名を解析し、_resolve_profile_dbで名前の正規化、形式の検証、プロファイルの存在確認を行ったうえで、対象のstate.dbを読み取り専用モードで開く。この関数には、呼び出し元のプロファイルと照合して許可リストを確認する手順は見当たらない。別のコードでは、会話IDだけを指定してすべてのprofileを自動検索することは禁止されている一方、profileを明示して読み取る方法は残されている。読み取り専用モードは書き込みを制限するが、記録内容がツールの返却結果に含まれることは防がない。公開コード

報告者はsession_search.allow_profilesの追加を提案している。デフォルトでは既存の動作を維持し、リストを指定した場合は読み取り可能な範囲を制限し、空のリストでは自身のprofileだけを許可するという案だ。提案者はブランチで検索ツールのテスト67件に合格したと述べているが、テストスイート全体は実行していない。これらの結果はまだ独立に再現されておらず、この設定も正式な機能にはなっていない。提案とテストの説明

エンジニアリングチームが今後確認すべき点は、profile間検索に認可チェックが追加されるか、またデフォルト値が既存のメモリ検索フローとどう両立するかだ。現時点の証拠から、ツールにプロファイルをまたいで読み取る経路があることは確認できるが、OSのファイル権限を突破できるとまでは言えない。リスク評価では、プロセスが実際に読み取り可能なディレクトリ、ツールへのアクセス範囲、ユーザー間の信頼関係を考慮する必要がある。