企業のアイデンティティー／アクセス管理は、従来、人を中心に構築されてきた。
従業員がサインインし、自分の身元を証明し、役割に応じたアクセス権を受け取り、その権限を使ってタスクを実行する。アイデンティティーチームがユーザーの権限を管理し、セキュリティーチームがアクティビティーを監視し、アクセス権は定期的に見直される。
組織内で人間が主な行動主体だった時代には、このモデルはおおむねうまく機能していた。
AIエージェントがその前提を変えつつある。
現代のAIエージェントは、テキストを生成したり質問に答えたりする以上のことができる。アプリケーションとやり取りし、APIを呼び出し、情報を取得し、企業向けツールを使い、複数のステップからなるワークフローを実行できる。
環境によっては、人間の介入をほとんど受けずに継続的に動作することもある。
そこに新たなアイデンティティーの問題が生じる。
もはや問うべきなのは、「誰がアクセス権を持っているのか？」
組織はさらに、次の点も問う必要がある。AIエージェントには何が許可されているのか、なぜそれを実行しているのか、どのアイデンティティーを使っているのか、そしてそのアクセス権をいつまで有効にしておくべきなのか。
NISTは最近、この課題を強調し、企業がエージェント型AIを急速に導入する一方で、従来のセキュリティーガードレールでは自律システムが生み出す新たなリスクに十分対応できない可能性があると指摘した。
これは、従来のIAMが無意味になるということではない。むしろ企業は、アイデンティティーセキュリティーを拡張し、新たな種類のデジタル行動主体に対応する必要がある。
AIエージェントは従来のサービスアカウントではない。
組織はこれまでも、非人間アイデンティティーに長年対応してきた。
サービスアカウント、APIキー、アプリケーションアイデンティティー、ワークロードアイデンティティーは、あらゆるリクエストの背後に人がいるわけではなくても、すでに企業システムにアクセスしている。
AIエージェントには、重要な違いがある。
従来のサービスアカウントは通常、定められた機能を実行する。AIエージェントは指示を解釈し、ツールを選び、情報を取得し、目標を達成するためにどのアクションを取るかを判断する可能性がある。
その結果、変動性が高まる。
例えば、財務チームを支援するよう設計された社内AIエージェントを考えてみよう。
エージェントに許可される操作：
- 財務レポートの読み取り
- 社内文書リポジトリーの検索
- 顧客情報の取得
- レポートの作成
- 別のアプリケーションへの情報送信
同じエージェントがレコードの変更、取引の承認、機密性の高い顧客データへのアクセスもできる場合、セキュリティー上の問題はより複雑になる。
タスクを完了する必要があるというだけでエージェントに広範な権限を与えると、不要なリスクを招く可能性がある。
だからこそ、AIエージェントに従来のアプリケーションで使われてきたアクセスモデルをそのまま継承させるべきではない。
従来のIAMが答えるのは「誰か」だが、エージェントでは「なぜか」も問われる
従来のIAMは、アイデンティティーとアクセスに重点を置いている。
ユーザーが認証され、システムがアクセスを許可するリソースを決定し、ポリシーが実行可能な操作を制御する。
AIエージェントには、さらに文脈のレイヤーが必要になる。
あるエージェントに顧客データベースへのアクセス権があるとしよう。
だからといって、データベース上のあらゆる操作が許可されるとは限らない。
セキュリティーシステムは、次の点も把握する必要がある。
- 誰がタスクを開始したのか？
- エージェントは何を達成しようとしているのか？
- どのアプリケーションまたはツールにアクセスしているのか？
- どのような情報が要求されているのか？
- その情報の機密性はどの程度か？
- そのリクエストは、エージェントの通常の挙動と一貫しているか？
- 権限をいつまで有効にしておくべきか？
これにより、アイデンティティーセキュリティーは、コンテキストと意図を認識したアクセス判断へと移行する。
エージェント型アイデンティティーに関する最近の研究でも、従来のIAMモデルと、非人間アイデンティティーや委任された権限を使ってマシンの速度で動作するエージェントとの隔たりが同様に浮き彫りになっている。
非人間アイデンティティーの増加がIAMの状況を変える。
企業のアイデンティティーチームは、増え続ける非人間アイデンティティーにすでに対応している。
クラウドワークロード、アプリケーション、API、自動化プラットフォーム、サービスアカウントはいずれも認証情報を必要とする可能性がある。
AIエージェントは、そこに別のカテゴリーを加える。
やがて組織内には、SaaSアプリケーション、クラウド環境、社内システム全体で異なる機能を実行するエージェントが数百、数千存在するようになる可能性がある。
これにより、いくつかの実務上の問題が生じる。
1. アイデンティティーの棚卸し。
セキュリティーチームは、どのAIエージェントが存在するのかを把握する必要がある。
これは簡単そうに聞こえるが、AIシステムは異なる事業部門、開発チーム、個々の従業員によって作成される可能性がある。
組織は、存在を把握していないアイデンティティーを効果的に保護できない。
2. 所有権。
すべてのエージェントには、説明責任を負う所有者を置くべきだ。
AIエージェントが機密情報にアクセスできる場合、誰かがそのアクセス権を承認し、引き続き必要かどうかを見直す責任を負う必要がある。
3. 権限管理。
エージェントには必要な権限だけを付与すべきだ。
顧客レコードを読み取るエージェントに、削除権限まで自動的に与えるべきではない。
4. 認証情報管理。
長期間有効な認証情報は、さらなるリスクを生む。
可能であれば、組織は短期間だけ有効な認証情報、ワークロードアイデンティティー、その他の仕組みを検討し、不要な恒常的アクセスを減らすべきだ。
5. アクティビティー監視。
アイデンティティー管理は認証で終わりではない。
セキュリティーチームは、アクセス権を受け取った後にエージェントが実際に何をしているのかを可視化する必要がある。
最小権限がこれまで以上に重要になる。
最小権限は、常に重要なセキュリティー原則だった。
AIエージェントは高速かつ反復的に動作できるため、その重要性をさらに高める。
人間のユーザーなら、タスクの実行中にミスをすることがある。自律システムなら、同じミスを数百、数千件のレコードにわたって繰り返す可能性がある。
企業のCRMにアクセスできるAIエージェントを考えてみよう。
連絡先情報の更新だけが必要なのに、顧客データベース全体をエクスポートする権限まで与えれば、不要な情報漏えいリスクが生じる。
より良いモデルでは、エージェントのアクセスを次に限定する。
- 特定のアプリケーション
- 特定のデータ
- 特定のアクション
- 特定の期間
- 特定の業務目的
これにより、エージェントが侵害されたり予期しない挙動を示したりした場合の潜在的な影響を大幅に抑えられる。
恒常的な権限が新たなリスクを生む。
もう1つの重要な検討事項は、AIエージェントがどれほど長くアクセス権を保持するかだ。
従来の環境には、数カ月、あるいは数年間にわたって権限が有効なままのサービスアカウントが存在することが多い。
アイデンティティーが自律システムに属する場合、そのモデルはますます不安視されるようになる。
問うべきなのは、まず
「このエージェントにアクセス権を与えるべきか」、
という点だけではなく、セキュリティーチームは次の点も問うべきだ。
「このエージェントには今すぐアクセス権が必要か」。
一時的なアクセス、またはジャストインタイムアクセスにより、攻撃者や侵害されたエージェントが認証情報を悪用できる時間を短縮できる。
また、実行するタスクと、その実行に必要な権限との関係をより明確にできる。
人間のアイデンティティーも依然として重要だ。
AIエージェントの台頭があっても、アイデンティティーチェーンから人間がいなくなるわけではない。
多くの企業環境では、エージェントは依然として個人、チーム、または業務プロセスに代わって動作する。
その関係性は可視化されたままでなければならない。
例えば：
従業員 → 承認済みタスク → AIエージェント → アプリケーション → データ
セキュリティーチームは理想的には、重要なアクションをこのチェーンをたどって追跡できる必要がある。
AIエージェントが機密情報をダウンロードした場合、組織はどのエージェントがそのアクションを実行したのか、何がそれをトリガーしたのか、どの権限を使ったのか、そして適切な場合には、どの人間または業務プロセスがタスクを開始したのかを特定できなければならない。
これにより説明責任が高まり、インシデント調査も容易になる。
IAMとセキュリティー運用は連携する必要がある。
AIエージェントのアイデンティティーは、IAMだけの問題として扱うことはできない。
アイデンティティーシステムは権限を設定できるが、セキュリティー運用チームは、その権限が使われたときに何が起きるのかを理解する必要がある。
ここで、アイデンティティーのテレメトリーとセキュリティー監視の結び付きがますます強くなる。
異常な一連の流れは、次のようになる：
- AIエージェントが通常どおり認証する。
- 以前に利用したことのあるアプリケーションにアクセスする。
- 突然、大量の機密データを要求する。
- 通常のワークフロー外にある別のシステムへのアクセスを試みる。
- その挙動がセキュリティーアラートを発生させる。
個々の認証イベントのどれも、疑わしく見えない可能性がある。
問題は、その一連の流れにある。
だからこそ組織は、アイデンティティー、アプリケーション、クラウド、セキュリティー運用の各データを横断して可視化する必要がある。
企業が今すべきこと
組織は一夜にしてIAMアーキテクチャーを全面的に再設計する必要はない。
実務的な出発点は、明確な基盤を確立することだ。
1. AIエージェントの棚卸しを行う
組織全体で現在稼働しているAIエージェントを特定する。
IT、セキュリティー、エンジニアリング、ビジネスの各チームが作成したエージェントを含める。
2. すべてのエージェントのアイデンティティーを特定する
各エージェントが使用するサービスアカウント、API認証情報、ワークロードアイデンティティー、その他の認証メカニズムを記録する。
3. 権限をマッピングする
各エージェントが何にアクセスできるのかを正確に把握する。
過剰な権限や不要な恒常的権限がないかを重点的に確認する。
4. 所有者を割り当てる
本番環境のすべてのAIエージェントには、ビジネス面と技術面の明確な所有者を置くべきだ。
5. 恒常的なアクセスを減らす
可能な場合は、恒久的で広範なアクセスではなく、短期間だけ有効な権限やタスク固有の権限を使用する。
6. エージェントの挙動を監視する
セキュリティーチームは、AIエージェントに関連する認証、データアクセス、API呼び出し、異常なアクティビティーを監視すべきだ。
7. アイデンティティーをインシデント対応に結び付ける
疑わしいアクティビティーが発生した際、セキュリティーチームは関与したエージェントを迅速に特定し、そのアクセスを取り消すか制限するとともに、関連するアクティビティーを調査できる必要がある。
8. 他の特権テクノロジーと同じようにAIエージェントを見直す
機密性の高い企業システムに接続されたAIエージェントには、他の特権アイデンティティーや重要なアプリケーションと同じレベルのセキュリティー上の注意を払うべきだ。
企業IAMの未来は、よりコンテキスト重視になる
AIエージェントは、必ずしも従来のIAMに取って代わるわけではない。
その前提の一部を明らかにしているのだ。
長年にわたり、アイデンティティーシステムは予測可能な人間の行動を中心に設計されてきた。人々はサインインし、タスクを実行してサインアウトする。アプリケーションには定義された機能がある。サービスアカウントは比較的限定された特定の業務を実行する。
AIエージェントは異なる動作をする可能性がある。
指示を解釈し、複数のシステムとやり取りし、マシンの速度でアクションを実行できる。
その結果、企業のアイデンティティー管理では、誰または何がアクセスを要求しているのかだけでなく、その主体が何をしようとしているのか、何をすることが許可されているのか、そしてアクションの実行時点でその挙動が引き続き信頼できるのかも、ますます把握する必要がある。
これに早期に取り組む組織は、自律システムを制御不能な特権アイデンティティーにすることなくAIを導入できる、より強い立場に立てるだろう。
目標は、AIの導入を遅らせることではない。
すべてのAIエージェントが、適切なアイデンティティー、限定されたアクセス、説明責任を負う所有者、そしてアクションを許容可能な範囲内に保つのに十分な監視を備えるようにすることだ。
最後に
AIエージェントは、企業テクノロジーの状況に重要な変化をもたらしている。
生産性を高め、複雑なワークフローを自動化できる一方で、システムにアクセスして自律的に行動する能力は、アイデンティティーセキュリティーに新たな側面をもたらす。
認証、認可、最小権限といった従来のIAMの原則は、依然として不可欠だ。違いは、組織が今や、増え続ける機械主導の主体にそれらの原則を適用する必要があることだ。
したがってIAMの次の段階では、単にログインを制御することよりも、企業全体のデジタルアイデンティティー、権限、意図、挙動を制御することが重視されるようになる。
関連記事：AI時代の脅威インテリジェンスは、すでに持っているものから始まるは、セキュリティー運用でエージェント型AIを導入する前に、セキュリティーチームが実行可能なインテリジェンス、再現可能なプロセス、効果的な自動化を優先すべき理由を解説している。