AI エージェントが担う業務が増えるなか、セキュリティリーダーはどうやって人間の監督を保つべきでしょうか。権限はエージェントが実行できる操作を定めますが、許可された操作であっても人の判断が必要な場合があります。すべてのステップに承認を求めるのが最も安全に見えるものの、複数ステップのタスクでは定型作業でも繰り返し確認が発生します。セキュリティ警告に関する研究では、繰り返しが増えると注意や遵守が低下することが示されています。課題は承認を増やすことではなく、本当に人間の確認が必要な判断に注意を残すことです。
Amazon Quick のスマート承認（Smart Approvals）はこの課題に対応する仕組みで、既存のコントロールの範囲内で対象となる操作を審査します。提案された操作をユーザーの依頼と照らし合わせ、自動で承認するか、ユーザーに差し戻して確認を求めます。追加の権限を与えることも、必須の人間承認を取り除くこともありません。どの操作を必ず人に回すかはセキュリティリーダーが管理し、スマート承認は日常業務における不要な中断を減らすことを目的としています。
境界を定めるのはポリシーです。Quick は自動審査の前に、カスタム権限、Quick ガードレール、コネクタのアクション権限、そしてユーザー自身の設定に基づいて各操作を評価します。拒否された操作は拒否されたままで、必須の人間承認も引き続き適用されます。スマート承認が有効な場合でも、ユーザー設定が「毎回確認」で、他のコントロールが人間の承認を要求していないときに限り対象となります。コネクタ作成時に設定するアクション権限で、特定の操作に人間の承認を必須とすることもできます。
管理者はカスタム権限でスマート承認を利用できる人を決めます。既定では有効ですが、既定で拒否するプロファイルでは明示的に許可する必要があります。ユーザー自身がオフにすることもでき、その設定は会話とスケジュール実行の両方に適用されます。オフにすると、本来なら自動審査の対象となる操作にもユーザーの承認が必要になり、アカウント側の設定で勝手に再有効化することはできません。
審査の仕組みとして、スマート承認は分類器という別のモデルを使い、対象操作をユーザーの依頼と範囲を限定した会話コンテキストに照らして評価します。操作の内容、データの送信先、影響を受ける相手を考慮し、ユーザーのナレッジグラフ（接続された情報源から得た人物と業務上の関係）を参照することもできます。これにより、受信者がユーザーの報告ライン上にいるかといった関係を把握できます。この参照はユーザーの Quick アカウント内に留まります。Quick は分類器が審査した内容（ナレッジグラフのデータを含む）をモデルの学習やサービスの改善には使いません。
依頼と一致する操作でも、人間の確認が必要な場合があります。組織外や報告ライン上の上位者への送信、アクセス権の変更、レコードの削除、支払いの開始などが例です。このリストは完全ではなく、分類器は周辺の文脈も考慮します。依頼との照合は、取得したコンテンツ内の指示がエージェントを誘導しようとする間接的なプロンプトインジェクションへの対策にもなります。Quick はエージェントと分類器の双方に、そうしたコンテンツを指示ではなく情報として扱うよう伝えます。モデルによる審査にも誤りはあり得るため、機密データの移動など必ず人間の承認が必要な操作は、コネクタのアクション権限で必須にすべきです。
判断を行うのは分類器で、権限を執行するのは権限サービスです。自動承認は一度限りで、審査した正確な操作とパラメータにのみ適用され、継続的な権限を与えません。Quick は会話内で自動承認を明示します。分類器が承認しなかった操作は、タイムアウトやその他の審査失敗も含めてユーザーに戻り、自動承認が付与されることはありません。こうした執行上の境界は承認が許す範囲を限定しますが、分類器の判断が正しかったことを証明するものではありません。
たとえば顧客担当者が Quick に、チームの顧客メモと前四半期のメールを使って AnyCompany 向けの四半期レビュー資料を準備させ、指定した同僚 2 名への送信を依頼したとします。送信が自動審査の対象であれば、スマート承認は依頼と会話の文脈に照らして評価します。ここである顧客メモが、資料を約 2,000 人の全営業メーリングリストにも送るべきだと示していた場合、宛先は指定範囲を超えるため、スマート承認は送信をユーザーに差し戻して確認を求める設計です。元の宛先への承認を、より広い宛先に再利用することはできません。
監査面では、Quick の権限サービスがスマート承認に関連する権限更新をユーザーのアカウントの AWS CloudTrail に記録します。各イベントにはユーザー、コネクタ、操作、時刻が含まれ、そのリクエストがスマート承認に関連することが示されますが、権限サービスが付与を受け入れたことや操作が実行されたことを示すものではありません。Quick は権限チェックの結果（コネクタのアクション権限による拒否を含む）や、ユーザーのスマート承認設定の変更も記録します。
調査担当者はこれらのイベントを、CloudTrail 内の他の Quick アクティビティや Amazon CloudWatch Logs 経由で配信されるログと、ユーザーと時刻で関連付けられます。チャットログにはユーザーの依頼、システムの応答、会話の文脈が残り、エージェントメタデータログにはエージェントの変更が記録されます。送信済みメールや更新されたチケットなど送信先システムの記録は、操作が完了したかを裏付けます。これらを組み合わせることで、承認を実行の証拠と見なすことなく経緯を再構成できます。CloudTrail のイベント履歴は 90 日間保持されるため、長期の調査には証跡を設定してください。チャットログには機密情報が含まれ得るため、アクセスを制限し、CloudWatch Logs のデータ保護ポリシーで機密データをマスクすることを検討してください。
導入の第一歩として、スマート承認は既定で有効なため、人間の承認が必要な操作がコネクタのアクション権限で設定されていることを確認します。CloudTrail の証跡を設定し、チャットログとエージェントメタデータログを CloudWatch Logs に配信して調査に備えます。チャットログは配信設定後の活動のみを記録するため、それ以前の承認には会話の文脈が残りません。承認要件とログが整ったら、カスタム権限で明確なワークフローに取り組むパイロットチームに限定し、その後で他のチームへ広げます。
パイロットの前に成功の定義を決めます。定型操作の確認は減り、影響の大きい操作は人に戻る、という状態です。パイロット中は自動承認のサンプルを確認し、組織外への送信や文書が持ち込んだ新しい宛先の追加といった高影響のケースを試して、ユーザーに戻ることを確かめます。また、承認から実行までの各操作をチームが追跡できることも確認します。結果がこれらの基準を満たしたときにだけ対象チームとワークフローを増やし、操作やポリシーの変化に応じて再評価します。
効果的な監督の尺度は、エージェントが承認を求める頻度ではなく、影響の大きい決定を人が掌握し続けているかどうかです。セキュリティリーダーにとってスマート承認の拡大を正当化する根拠は、パイロットから得た証拠であるべきです。確認の減少は、注意を保ち説明責任を弱めない限りにおいて価値があります。