Amazon Quick「Smart Approvals」、AIエージェントの承認確認を重要な操作に絞る新機能
AIエージェントに仕事を任せるほど、人間がどこで最終判断をするかが課題になる。AWSはAmazon Quickの新機能「Smart Approvals」を取り上げ、この問題への考え方を示した。すべての操作に承認を求めれば安全に見えるが、複数ステップの作業では日常的な操作でも確認が何度も出てくる。AWSは、セキュリティ警告の研究では繰り返しによって注意や従順さが下がり得ると指摘する。要は承認の回数を増やすことではなく、本当に人が見るべき判断に注意を残すことだという立場だ。
Smart Approvalsは、承認が必要になりうる操作のうち適格なものを自動で審査する仕組みである。提案された操作を利用者の依頼内容と照らし合わせ、自動承認するか、利用者に確認を戻すかを決める。重要なのは、これが新しい権限を与えたり、必須の人間の承認を取り除いたりしないことだ。境界を決めるのはあくまでポリシーである。Quickは審査の前に、Custom Permissions、Quick Guardrails、コネクターのアクション権限、利用者の設定を確認する。拒否された操作は拒否のままで、人の承認が必須とされた操作も従来どおり必要になる。自動審査の対象になるのは、利用者の設定が「毎回確認する」で、ほかに人の承認を求める統制がない場合に限られる。
審査を担うのは、エージェントとは別の「分類器」と呼ばれるモデルだ。分類器は、操作が何をするのか、データがどこへ渡るのか、誰に影響するのかを、依頼内容と限定された会話の範囲から評価する。接続されたソースから作られるナレッジグラフも参照でき、たとえば宛先が利用者の報告ラインにいる人物かどうかを理解できる。この参照はQuickアカウント内にとどまり、分類器が確認した内容はナレッジグラフのデータを含め、モデルの学習やサービス改善には使われないとされる。依頼と一致していても、組織外や上位の経営層への送信、アクセス権の変更、記録の削除、支払いの開始などは人の確認に値しうる。ただしこの例示は網羅的ではなく、分類器は周辺の文脈も加味する。
依頼との照合は、間接的プロンプトインジェクションへの一つの防御にもなる。これは取得した文書の中に紛れた指示で、エージェントの行動を乗っ取ろうとする攻撃だ。Quickはエージェントと分類器の双方に、そうした内容を指示ではなく情報として扱うよう指示している。それでもモデルの判断は誤り得るため、AWSは機微データの移動など必ず人が承認すべき操作は、コネクターのアクション権限で必須にするよう求める。分類器は判断を示し、権限を強制するのは権限サービスだという役割分担である。
具体例として、営業担当者がAnyCompanyの四半期ビジネスレビュー資料を作らせ、名指しした同僚2人に送るよう頼む場面が示されている。ところが元のアカウントメモに、約2,000人の営業全体の配信リストにも送るよう書かれていたとする。これは宛先を依頼の範囲から広げるため、Smart Approvalsは送信を利用者に戻すよう設計されており、本人は拒否できる。当初の宛先への承認を、広い宛先に流用することもできない。自動承認は一度限りで、審査した操作とパラメータにのみ有効であり、継続的な権限にはならない。承認されなかった場合や、タイムアウトなど審査の失敗も、自動承認にはならず利用者に戻る。自動承認は会話内で表示される。
統制面では、管理者がCustom Permissionsで誰が使えるかを決める。機能は既定で有効だが、deny-by-defaultを有効にしたプロファイルでは明示的な許可が要る。利用者は自分の分をオフにでき、その選択は会話とスケジュール実行の全体に及ぶ。オフにすると、本来自動審査になる操作でも本人の承認が必要になり、アカウント側の設定で再びオンにすることはできない。
監査も重視されている。権限サービスは、Smart Approvalsに関連する権限更新をAWS CloudTrailに記録し、各イベントには利用者、コネクター、操作、時刻が含まれ、Smart Approvals関連の印が付く。ただしこの印は、権限サービスが付与を受け入れたことや操作が実行されたことの証明にはならない。実行されたかどうかは、送信メールや更新チケットなど送信先システムの記録で確かめる。チャットログやエージェントのメタデータログはCloudWatch Logsに配信でき、調査では利用者と時刻でこれらを突き合わせる。CloudTrailのイベント履歴は90日間のため、長期調査にはトレイルの設定が必要だ。チャットログは設定後の活動のみ記録し、機微な内容を含み得るので、アクセス制限やデータ保護ポリシーによるマスキングが勧められる。
導入手順としてAWSは、まず人の承認が必要な操作をコネクターのアクション権限で設定し、ログを整えることを挙げる。そのうえで、特定のチームと業務に限ったパイロットから始める。成功の基準は、日常的な操作のプロンプトが減り、重大な操作は引き続き人に戻ることだ。パイロット中は自動承認を抜き取り確認し、組織外への送信や文書が持ち込んだ宛先の追加といった影響の大きい例を試す。結果が基準を満たしてから展開を広げる。承認の頻度ではなく、重要な判断を人が握り続けているかが、有効な監督の尺度だと同社は述べている。