一括更新などをキュー worker で後追い実行する設計で、実行時の認可コンテキスト（権限主体：UserSession 等）を「作成時に payload へ権限スナップショットを保存して復元する」方式は危険。復元した権限主体が一部の権限フィールド（groupPermission / itemPermissions / roleType など）を欠くと、権限ヘルパーが「未設定＝全許可（全レコード変更可）」とフェイルオープンし、作成時に通ったユーザーが worker 側で昇格した権限で実行できてしまう。対策は snapshot 方式を取り下げ、worker 側で task.userId / adminId から user / tenant / role の各 repository を引いて現在の完全な権限主体を再構築し、既存のサービスに渡す。加えて、一括操作の作成時に機能権限（MANAGE 等）と item 権限だけを検証し、指定された各レコードの更新可否（レコードアクセス）を検証しないと、同一テナント内の本来触れないレコードを指定して更新できる。認可は操作対象の各レコードのアクセス可否まで確定させる。権限ヘルパーがフェイルオープン設計の場合は、部分的な権限オブジェクトを渡すこと自体が昇格に直結すると意識する。