ブラウザーを更新するとエージェントの承認プロンプトが再表示されるのはなぜですか？

エージェントの承認プロンプトが更新後に再び表示されることが多いのは、インターフェース上の確認とサーバーの永続的な承認状態が、1つのイベントとしてコミットされていないためです。

ユーザーが承認をクリックし、ダイアログが消えたのを確認してブラウザを更新すると、同じ質問に再び直面することがあります。承認リクエストがまだ保留中だった、期限切れになった、またはクライアントのメモリにしか保存されていなかったため、ページが楽観的にプロンプトを非表示にした可能性があります。その後、エージェントのバックエンドは永続状態からワークフローを再構築し、同意があったとみなすのではなく、再度確認を求めます。

ページのメモリとワークフロー状態の有効期間は異なる

シングルページアプリケーションでは、表示中のプロンプト、ボタンの状態、ローカルでの確認をJavaScriptのメモリに保持できます。更新するとその実行環境は破棄され、セッションストレージ、サーバーAPI、またはその両方からデータが再読み込みされます。この境界を越えて永続化されていない状態は失われます。

ページセッションストレージのブラウザモデルでは、データはオリジンとトップレベルのブラウジングコンテキストごとに分離され、同じページセッション内であれば更新後も保持できます。通常のメモリ内状態にはこのような永続性がなく、ローカルストレージには異なる、より長期的なセキュリティおよびライフサイクルの境界があります。

結果に影響する承認については、サーバーが引き続き権威を持つべきです。クライアント側での永続化はインターフェースの継続性を高める可能性がありますが、ブラウザのフラグを権限として扱うと、実際の対象を再検証せずに、古い状態、改変された状態、またはタブ間の状態によってアクションが承認されるおそれがあります。

楽観的UIは失敗した承認コミットや遅れて届く承認コミットを隠す可能性がある

クリック後、サーバーのトランザクションが完了する前にインターフェースがダイアログを閉じることがあります。ネットワークの中断、セッションの期限切れ、重複リクエスト、またはデータベースの競合によって、ボタンは成功したように見えても、承認レコードがワークフローのステップに紐付かない可能性があります。

ストレージのライフサイクルルール仕様は、永続的なローカルストレージとセッション単位のストレージを区別し、ブラウジングコンテキスト間でのストレージイベントを定義しています。複数のタブで同じ承認が表示されていても、サーバー側で勝つべき決定は1つだけである場合、こうしたライフサイクルの違いが重要になります。

承認レコードには、安定したリクエストID、アクションダイジェスト、実行者、スコープ、決定、タイムスタンプ、有効期限、コミット済みステータスが必要です。この紐付けがなければ、バックエンドは以前のクリックがこの正確なアクションを対象としていたのか、それとも更新後に再生成された見た目が似たリクエストを対象としていたのかを判断できません。

再度のプロンプト表示は意図的な安全境界である可能性がある

短期間のみ有効な承認や1回限りの承認は、ツール呼び出しに重要な変更があった場合に引き継がれるべきではありません。ユーザーがプロンプトを確認した後に、引数、ファイルのバージョン、送信先、権限、またはポリシーが変更された場合、再確認を求めることで、あるアクションを承認したのに別のアクションが実行される事態を防げます。

クライアントストレージのセキュリティに関する分析では、ローカルストレージとセッションストレージのどちらもページのスクリプトからアクセスできるため、機密性の高いセッション権限をクライアント側のトークンだけに委ねるべきではないと指摘されています。サーバー側のチェックと保護されたCookieは、それぞれ異なる安全策を提供します。

すべての繰り返し表示されるプロンプトをバグだと考えることが、問題の境界です。承認が期限切れになった場合やアクションダイジェストが変更された場合、再表示は正しい動作です。一方、同じスコープでコミット済みかつ有効期限内の承認が、ビューの再読み込みだけを理由に失われたり重複したりする場合は、欠陥です。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

1つの承認をクリックからツール実行まで追跡する

承認リクエストID、アクションダイジェスト、ブラウザのタブ、ユーザーセッション、クリック時刻、API確認、データベースコミット、ワークフロー遷移、更新時刻、ツール実行を記録します。レスポンス前、コミット後、2つ目のタブ、期限切れ後、1つの引数を変更した後に更新するテストを行います。

承認スコープを使用して、スコープのテストを定義します。コミット済みの承認は、一致するアクションとポリシー境界だけを対象とし、対象や期限切れのレコードが変更された場合は、新しい理由を示す新しいプロンプトを表示するべきです。

通常の更新後も同じ永続的な承認が維持され、変更された作業を承認しないことが確認できれば合格です。コミット前にUIが非表示になる場合は保留状態を表示し、重複送信が届いた場合は、最新のブラウザ画面を信頼するのではなく、承認エンドポイントを冪等にします。