AIエージェントのためのアイデンティティとアクセス制御
あなたの財務チームが、月次決算プロセスを支援するエージェントを準備していると想像してください。このエージェントは、未処理の仕訳を読み込み、照合を確認し、未完了項目に関するコメントのドラフトを作成できます。デモではすべてが順調に進みます。しかし、エージェントが実際に調整案をERPに送信し始めたとき、突然、チームを立ち止まらせる疑問が浮上します。このアクションを実際に実行しているのは誰なのか？エージェントは特定のコントローラーの代理として行動しているのか？それとも独立したシステムとしてか？そして、結果が間違っていた場合、誰が責任を負うのか？
この疑問は、単なる技術的なものではありません。それは、企業がエージェントをどのように捉えるかという本質に触れています。すなわち、匿名の支援ツールとして見るのか、それとも、制御と説明責任の点で人間や他のアプリケーションと同等に扱う必要があるデジタルアクターとして見るのか、ということです。
現在、多くの組織はエージェントのモデル、プロンプト、API統合についてかなり先進的に考えています。しかし、ユースケースがデモから本番環境へと移行し始めると、しばしば見落とされる点が一つあります。それは、エージェントに明確なアイデンティティがないことです。エージェントは汎用的なサービスアカウントで動作し、権限が広すぎ、アクションの発生源を説明するのに十分なログがありません。その結果、エージェントが請求書の読み取り、チケットのオープン、注文ステータスの変更、調達ワークフローのトリガーを開始したときに、企業は基本的な質問に答えられなくなります。エージェントが使用しているアイデンティティは何か、誰の代理として行動しているのか、どのような権限を持っているのか、どのワークフローのコンテキストでアクションが発生したのか。
エンタープライズにとって、これは些細な詳細ではありません。明示的なアイデンティティとアクセスのモデルがなければ、監査可能性、説明責任、実行時ガバナンスは、エージェントが実際に価値を提供し始めたまさにその時に崩壊します。
エージェントは匿名スクリプトではない
従来のエンタープライズアーキテクチャでは、人間、アプリケーション、サービスアカウント、スケジュールされたプロセスといった、いくつかのタイプのアクターを認識することに慣れています。エージェンティックAIは、新たなカテゴリーを追加します。それは、推論し、ツールを選択し、複数のステップにわたって行動できるデジタルアクターです。そのため、エージェントは、たまたまバックグラウンドで動作している匿名スクリプトのように扱われるべきではありません。
エージェントは明確なアイデンティティを持つ必要があります。なぜなら、企業は3つの基本的なことを知る必要があるからです。誰がアクションを実行したのか、そのアクションは誰の権限で実行されたのか、どのワークフローでアクションが発生したのか。この3つがなければ、エンタープライズ制御は曖昧になります。
調達エージェントが、インテークリクエストを受け取り、契約を確認し、ERPに購買依頼のドラフトを作成する場合を想像してみてください。そのアクションが、単一の汎用サービスアカウントのアクティビティとしてのみ記録されている場合、問題が発生したときに、企業は、アクションが特定のユーザーによってトリガーされたのか、スケジュールされたワークフローの一部なのか、特定のイベントのためにエージェントが自律的に行動したのか、あるいはアクセスの悪用があったのかを区別できません。これは、財務決算、カスタマーオペレーションズ、ITオペレーションズでも同様です。エージェントがビジネス状態に触れ始めたら、そのアイデンティティは、人間や他のアプリケーションのアイデンティティと同様に追跡可能でなければなりません。
エージェントのアイデンティティは、説明責任の基盤でもあります。従来の運用モデルでは、説明責任は通常、アナリスト、承認者、スーパーバイザー、システム所有者といった人間に帰属していました。エージェンティックモデルでは、アクションの一部がデジタルレイバーに移行します。それは説明責任がなくなることを意味しません。むしろ逆に、説明責任はより明示的にされる必要があります。企業は、このエージェントはどの機能に属するのか、ビジネスオーナーは誰か、テクニカルオーナーは誰か、どのツールの使用が許可されているのか、どのようなアクションの制限が許可されているのかを答えられなければなりません。そうしなければ、組織は危険な状況に直面します。エージェントは実際に行動しているのに、その影響に見合った制御モデルが存在しない、という状況です。
さらに、アイデンティティはトラストバウンダリーも決定します。社内の従業員とやり取りするエージェントは、外部の顧客にサービスを提供するエージェントとは異なります。ナレッジベースを読むだけのエージェントは、支払いステータスを変更できるエージェントとは異なります。検証済みユーザーのコンテキストで動作するエージェントは、パブリックチャネルまたはセミパブリックチャネルにサービスを提供するエージェントとは異なります。したがって、エージェントのアイデンティティは単なる技術的な名称ではありません。それは、アクセスできるデータ、呼び出せるツール、必要とされる監視のレベルを決定します。すべてのエージェントが同じように扱われる場合、企業は寛大すぎるか、制限が強すぎるかの2つの極端に陥る傾向があります。どちらも良くありません。
静的なロールベースの権限では不十分
エージェントのアイデンティティが明確になったら、次のステップは認可です。ここで、多くの組織が新しい形で古い間違いを犯します。静的なロールに基づいてアクセスを許可し、それで十分に安全であると期待するのです。エージェンティックAIにとって、このアプローチは粗雑すぎます。
エージェントの権限は、エージェントのロールだけでなく、コンテキストによっても決定されるべきです。すなわち、代理されているユーザー、実行中のタスク、アクセスされているデータ、情報の機密性、実行されようとしているアクションのリスクです。このアプローチは、コンテキストアウェア認可として知られています。
買掛金勘定の簡単な例を考えてみましょう。エージェントは、不一致を分析するために、請求書、発注書、入庫伝票を読むことができます。エージェントは、解決策の推奨事項を作成できます。しかし、エージェントは自動的に支払いステータスを変更したり、支払いブロックを解除したりすることはできません。なぜなら、最後のアクションは、単に読んだり推奨したりするよりもはるかに高いリスクプロファイルを持つからです。
人事オペレーションの例：エージェントは、オンボーディングのステータスと書類の完全性を読み取り、採用担当マネージャーへの通知のドラフトを作成できます。しかし、エージェントは、適切な承認なしに、報酬データや雇用ステータスを変更することはできません。カスタマーオペレーションの例：エージェントは、顧客のチケット履歴と権利を表示し、ポリシーが満たされている場合は低価値の返金を準備できます。しかし、特定のしきい値を超える返金は、スーパーバイザーのレビューのために停止する必要があります。
これらすべての例において、静的なロールでは不十分です。必要なのは、実行時コンテキストを考慮した認可です。
実際には、エージェントがツールを呼び出したりデータにアクセスしたりするたびに評価されるべき、4つのコンテキストの次元があります。第一に、元のユーザーまたはプリンシパルのコンテキスト：エージェントは特定の従業員、特定のチーム、または特定のビジネス機能の代理として行動していますか？もしそうなら、エージェントの権限は、明確な理由なしに元の権限を超えてはなりません。第二に、タスクまたはワークフローのコンテキスト：エージェントは、分析、ドラフト作成、トランザクション実行、または承認サポートのうち、どの段階を実行していますか？各段階のアクセス権は異なる必要があります。第三に、データのコンテキスト：アクセスされるデータは、一般、内部、機密、または極めて機密性が高いものですか？そのデータは、給与、ベンダーの銀行詳細、戦略的契約、または保護された顧客情報に関連していますか？第四に、アクションのリスクのコンテキスト：データの読み取り、ドラフトの作成、変更の実行、トランザクションの承認は、4つの異なるリスクレベルです。それらの制御は同一視されるべきではありません。
なぜこれが重要なのでしょうか？なぜなら、過剰な権限を持つエージェントは、エンタープライズにおける最も現実的なリスクの一つだからです。誘惑は大きいものです。パイロットを迅速に成功させるために、チームはしばしばエージェントに広範なアクセスを許可します。短期的には、これによりデモが加速します。長期的には、監査が困難で、スケール時に危険な、過剰な権限を持つエージェントを生み出します。より健全な原則は、人間とアプリケーションのセキュリティと同じです。最小権限の原則です。違いは、エージェンティックAIでは、エージェントがコンテキストをまたいで動作するため、最小権限をより動的に適用する必要があることです。
委任された権限：エージェントは誰の代理で行動するのか？
エージェントのアクションの多くは、実際にはエージェント自身のものではありません。エージェントはしばしば、誰かまたは何らかの機能の代理として行動します。したがって、企業はエージェントのアイデンティティとその権限のソースを明確に区別する必要があります。これが委任された権限の本質です。
エンタープライズの実践では、エージェントのアクションは通常、3つのソースのいずれかに由来します。第一に、ユーザーからの指示：例えば、購買担当者が調達エージェントに契約を確認し、購買依頼のドラフトを作成するよう依頼する場合です。この場合、エージェントはユーザーの明示的な指示に基づいて行動します。第二に、スケジュールされたワークフローまたは正式なビジネスプロセス：例えば、毎晩、財務決算エージェントが未処理の例外をチェックし、フォローアップを送信する場合です。ここでは、その権限は組織によって承認されたワークフローに由来します。第三に、イベントベースの自律的トリガー：例えば、IT運用エージェントが特定のサービスが失敗したというイベントを受信し、診断を実行してインシデントをオープンする場合です。または、サプライチェーンエージェントが出荷遅延のイベントを受信し、緩和オプションを準備する場合です。これらの場合、アクションは人間の直接のコマンドではなく、イベントによってトリガーされます。
これら3つの権限のソースは、システム内で区別されなければなりません。そうでなければ、監査証跡は非常に重要なコンテキストを失うことになります。
健全な委任された権限には限界がなければなりません。最低限、委任はいつでも取り消し可能であり、時間制限があり、タスクの範囲が制限され、関連する場合はトランザクション価値が制限される必要があります。調達の例：エージェントは、特定の限度額未満の標準的な購買カテゴリについて、リクエストのドラフトを作成できます。それを超える場合、エージェントは推奨のみ行うことができます。カスタマーサービスの例：エージェントは、特定の基準を満たす顧客に対して、特定の金額までのグッドウィルクレジットを処理できます。それを超える場合、エージェントは停止しなければなりません。ITオペレーションの例：エージェントは、非本番環境または特定のサービスにおいて、低リスクの是正ランブックを実行できますが、重要な本番変更を承認なしに行うことはできません。
一般的な弱点の一つは、委任がビジネス上では理解されていても、技術的な制御に変換されていないことです。システムは、誰が権限を与えたのか、どのエージェントが実行したのか、権限がいつ有効だったのか、どのツールが使用されたのか、アクションがポリシーに準拠していたのかを明確に記録できなければなりません。これがなければ、企業は、正当なアクション、権限外のアクション、もはや有効であるべきでないアクションを区別するのに苦労することになります。
エンタープライズのための実装パターン
エージェントのためのアイデンティティとアクセス制御を原則で終わらせないために、企業はそれを運用可能な実装パターンに変換する必要があります。
第一に、各エージェントに正式なサービスアイデンティティを付与します。本番環境に導入される各エージェントは、汎用アカウントを共有するのではなく、独自のサービスアイデンティティを持つべきです。このアイデンティティは登録され、所有者がおり、エンタープライズエージェントカタログにリンクされている必要があります。最低限必要なメタデータは次のとおりです。エージェントの名前と目的、ビジネスオーナー、テクニカルオーナー、プロセスドメイン、許可されたツール、リスクティア、ライフサイクルステータス。これは、エージェントが、放置された実験ではなく、運用資産として扱われるために重要です。
第二に、すべてのツールコールをポリシーエンジンにバインドします。エージェントは、ツールが利用可能だからといって自由に呼び出せるべきではありません。各ツールコールは、エージェントのアイデンティティ、ユーザーまたは権限ソースのアイデンティティ、アクションのタイプ、データオブジェクトまたはトランザクション、ワークフローのコンテキスト、適用される承認ルールを評価するポリシーエンジンを通過する必要があります。このパターンにより、制御はログイン時だけでなく、エージェントが行動しようとするまさにその実行時に行われます。これは、エージェンティックAIが動的であるため非常に重要です。同じセッションが、異なるリスクレベルの複数のステップを含む可能性があります。認可は、初期のアイデンティティだけでなく、これらのステップに従う必要があります。
第三に、アクションのタイプに基づいて権限を分離します。最も有用な設計の一つは、アクセス権をアクションの層に分離することです。読み取り、推奨、ドラフト作成、実行、承認です。この分離は、従来のアプリケーションアクセスモデルよりもエージェントにとってはるかに適切です。財務の例：読み取りは、仕訳、照合、証拠を表示するため。推奨は、例外処理を提案するため。ドラフト作成は、コメントや調整案のドラフトを準備するため。実行は、許可された特定のアクションを転記するため。承認は、重要な項目についてはほぼ常に人間に残されます。調達の例：読み取りは、契約、ベンダー、ポリシーを表示するため。ドラフト作成は、購買依頼を作成するため。実行は、リクエストをワークフローに送信するため。承認は、人間の承認者に残されます。この分離により、企業はすべての権限を一度に開放することなく、エージェントの自律性を段階的に高めることができます。
第四に、可能な場合は、ジャストインタイムおよびスコープ指定されたアクセスを使用します。より機密性の高いアクションについては、アクセスを永続的に有効にすべきではありません。エージェントが特定のタスクのためだけに一時的にアクセスを取得し、タスクが完了したらアクセスが終了する方が安全です。このアプローチは、設定ミスや悪用が発生した場合の影響範囲を減らすのに役立ちます。
第五に、アクションを真に説明する監査ログを保存します。エージェントの監査ログは、APIが呼び出されたことを記録するだけでは不十分です。エンタープライズに適したログは、ユーザーまたは権限ソース、エージェントのアイデンティティ、ポリシー決定、実行されたツールコール、使用された入力、生成された出力、発生したかスキップされた承認、システム内の最終的な状態変更を関連付ける必要があります。これが、監査の質問、インシデント調査、またはエージェントの品質評価に答えるための最小限のトレイルです。企業がこのチェーンを再構築できない場合、エージェントは実際には本番規模の準備ができていません。
これらのパターンが実際にどのように機能するか
財務決算では、決算オーケストレーションエージェントは独自のサービスアイデンティティを持ちます。照合ステータス、未処理の仕訳、証拠を読み取ることができます。コメントやフォローアップのドラフトを作成できます。しかし、重要な調整については、ポリシーエンジンが人間の承認を強制します。ログは、権限を与えたコントローラー、ドラフトを準備したエージェント、適用されたポリシー、仕訳の最終ステータスを記録します。
調達のインテークから発注書までのプロセスでは、調達エージェントはプロセス段階に応じて、要求者または購買担当者の代理として行動します。契約、ベンダーマスター、カテゴリポリシーを読み取ることができます。標準的なカテゴリについては、リクエストのドラフトを作成できます。トランザクション価値が制限を超えているか、ベンダーが承認されていない場合、実行のためのツールコールは拒否されるか、承認ワークフローにリダイレクトされます。
カスタマーオペレーションでは、サービスエージェントは独自のアイデンティティを持ち、検証済みの顧客のコンテキストで動作します。チケット履歴と権利を読み取ることができます。ポリシーが満たされている場合、少額のグッドウィルクレジットを実行できます。VIP顧客、繰り返し発生するケース、または限度額を超える価値については、エージェントは推奨のみを行い、スーパーバイザーを待ちます。
ITオペレーションでは、インシデント対応エージェントは可観測性プラットフォームからイベントを受信します。特定のサービスに対して、低リスクの診断と是正を実行できます。重要な本番環境に影響を与えるアクションについては、ポリシーエンジンがオンコールエンジニアの承認を要求します。すべてのステップが記録されます。元のイベント、行動したエージェント、呼び出されたランブック、その結果、システム状態の変更。
これらのパターンがまだ適切でない場合
すべての組織が、すぐに成熟したモデルを適用できる準備ができているわけではありません。エージェントをスケールする準備がまだ整っていないことを示す、いくつかの危険信号があります。エージェントが依然として一意のアイデンティティなしに共有サービスアカウントを使用している。ユースケースを先に進めるために、権限が広範に付与されている。読み取り、ドラフト作成、実行の権限が分離されていない。委任された権限が明示的に記録されていない。ツールコールがポリシーエンジンや実行時制御を通過しない。監査ログは最終出力のみを記録し、決定の連鎖を記録しない。インシデント発生時にエージェントのアクセスを迅速に取り消す方法がない。ビジネスオーナーがエージェントが使用するツールとデータを正確に把握していない。
これらの症状のいくつかがまだ存在する場合、エージェンティックAIをスケールすると、価値よりもリスクが急速に拡大します。
また、明確なロールバック手段のない重要なトランザクションに触れるドメイン、実行時ルールに変換できるポリシー定義がまだないドメイン、データがまだ安定していないドメイン、プロセスの所有権がまだ曖昧なドメインには、実行の自律性を持つエージェントはまだ適していません。そのような状況では、まず読み取り、推奨、ドラフト作成から始め、同時にアイデンティティ、ポリシー、ロギングを強化する方が安全です。
持ち帰るべき質問
このトピックを理解した上で、今すぐ行うべきいくつかの決定があります。第一に、あなたの企業におけるエージェントのアイデンティティモデルを決定します。各エージェントは、正式なサービスアイデンティティ、ビジネスオーナー、テクニカルオーナー、明確なリスクティアを持つことになりますか？第二に、使用する認可モデルを決定します。企業は静的なロールに依存し続けるのか、それとも各ツールコールに対してコンテキストベースの認可に移行するのか？第三に、委任された権限のモデルを定義します。エージェントはいつユーザーの代理で、いつワークフローの代理で、いつ自律的なイベントのために行動するのか？委任はどのように制限、取り消し、監査されるのか？第四に、エージェントの権限レベルを分離します。アクセス権は、読み取り、推奨、ドラフト作成、実行、承認の間で既に区別されていますか？第五に、最低限の監査可能性基準を決定します。企業は、ユーザー、エージェント、ポリシー決定、ツールコール、入力、出力、最終的な状態変更を関連付けることができますか？
もし明日、監査人、規制当局、またはリスク委員会が「このアクションを実行したのは誰か、誰の権限で、なぜシステムはそれを許可したのか」と尋ねた場合、あなたの企業は口頭での説明ではなく、完全な証拠をもって答えることができますか？答えが明確でない場合、さらに多くのエージェントを追加する前に、次の優先事項は新機能ではありません。優先事項は、エージェントをエンタープライズアクターとして信頼できるものにする、アイデンティティ、認可、委任を構築することです。