OpenHands 1.20、エージェントプロファイルでシークレットを選択可能に　サーバー側で範囲を制限

OpenHandsは9月17日に1.20.0をリリースし、会話に提供できるシークレットをエージェントプロファイルで選択できるようにした。自動化タスクでも保存済みのプロファイルを選択できる。コーディングエージェントをスケジュール実行やチームのワークフローに組み込むエンジニアにとって、タスクごとに認証情報の範囲を絞る手段となる。例えば、コードを調査するエージェントには読み取り用の認証情報を渡し、デプロイ用のキーは渡さない、といった設定が可能になる。[リリースノート](https://github.com/OpenHands/OpenHands/releases/tag/v1.20.0)

この変更は、シークレットの受け渡しと認可の間にあった隔たりを埋めるものだ。既存のSecret Registryは、ターミナルコマンド内のシークレット参照を検出し、必要に応じて環境変数を注入するとともに、出力内の機密値をマスクする。これらの仕組みが扱うのは、シークレットの利用方法だ。今回、会話に渡すシークレットをプロファイルで事前に制限できるようになり、エージェントが無関係な認証情報を取得する可能性を低減する。[公式ドキュメント](https://docs.openhands.dev/sdk/guides/secrets)

中心となるフィールド`secret_refs`には3つの意味がある。`null`は互換性を維持するため制限を設けず、空の配列はユーザーのシークレットを渡さず、名前のリストは指定した項目だけを許可する。フィルタリングは、サーバーがプロファイルを解決した後、会話のシークレットレジストリとコンテキストを作成する前に行われる。そのため、クライアントが余分な認証情報を送っても許可範囲を拡大できない。開始時の範囲は会話の再開に備えて保存され、その後プロファイルを変更しても、既存の会話の範囲が直接広がることはない。[サーバー側の実装](https://github.com/OpenHands/software-agent-sdk/pull/4931)

フロントエンドでは、互換性維持のためのフォールバック処理も修正された。制限付きのプロファイルは、その識別情報を保持してサーバー側で解決する必要があり、プロファイルなしでの起動に暗黙に切り替わることは許されない。選択UIは、バックエンドが`profile_secret_scope_v1`への対応を宣言している場合にのみ表示される。今回の実装ではCloudバックエンドが対象外となっているため、ローカルのインターフェースで利用できる機能を、そのままクラウドでも同等の保護が提供されていると解釈することはできない。[フロントエンドの変更](https://github.com/OpenHands/OpenHands/pull/17237)

デフォルトは引き続き`null`であるため、アップグレードだけで既存のプロファイルの制限が自動的に厳しくなるわけではない。ACP経由で起動するエージェントについては、ユーザーレジストリに保存されたプロバイダーの認証情報も許可リストの制限を受けるため、選択漏れによって認証に失敗する可能性がある。通常のLLMプロファイルとMCP認証には、別の受け渡し経路がある。また、今回の変更では、ACPの子プロセスが親プロセスの環境変数を継承する問題には対処していない。[適用範囲の説明](https://github.com/OpenHands/software-agent-sdk/pull/4931)

導入時には、空のリスト、認証情報を指定した場合、会話の再開をそれぞれテストし、自動化が実際にどのプロファイルを参照しているかを確認する必要がある。技術面で次に注目すべき点は、インターフェースで選択内容を保存できるかだけでなく、各デプロイ先のバックエンドが同じシークレットポリシーを一貫して適用できるかどうかだ。