何をどこまでさせようか？Entra ID で Agent に ID を渡してみよう！

Azure Travelers 何をどこまでさせようか？ Entra ID で Agent に ID を渡してみよう！ りゅうすけ＠生きニキ りゅうすけ＠生きニキ 1

Azure Travelers 今日の問い AI エージェントを "人間と同じように" 扱ったら何が起き る？ 社員と同じ「ID」を渡す 社員と同じ「権限」を割り当てる 社員と同じ「統制」をかける そして自律的に動かしてみる りゅうすけ＠生きニキ 2

Azure Travelers なぜ "人間と同じ ID" なのか 観点 サービスアカウント / app key 人間と同じユーザー ID 扱われ方 「ツール」 「同僚」 監査ログ "アプリが X した" "agent01 が X した" 権限の単位 API スコープごと 役割 (User Admin など) 利用可能な統制 アプリ向けの限定セット CA / PIM / DLP / IRM … ライフサイクル IT 部門が管理 HR 的に管理可能 → 人間扱いすることで 数十年蓄積された "人間向け統制" がそのまま使えるかを問う りゅうすけ＠生きニキ 3

Azure Travelers エージェントに与えたもの agent01 社員アカウント (人間と同じ「ID」) ライセンス (M365 E5) 役割の "資格" (必要時に申請して取得) 限定されたツール 「( 何ができるか」の境界) 実行基盤: Azure 上に閉じたエージェントランタイム りゅうすけ＠生きニキ 4

Azure Travelers 検証したい仮説 「人間向けの統制は、AIエージェントにも効くのか？」 検証する3つの層: 層 アイデンティ ティ ガバナンス コンテンツ 統制 Conditional Access Privileged Identity Management DLP / Sensitivity Label → 今日は上2つを実演 りゅうすけ＠生きニキ 「人間向け」の例 「会社のIPからしか業務システム使え ない」 「特権操作は申請+上長承認」 「機密ファイルは外部共有不可」 5

Azure Travelers Demo ① Conditional Access 「コンテキストで縛る」 アイデンティティ層のガードレール りゅうすけ＠生きニキ 6

Azure Travelers Demo ① 問いと仕掛け 問い: エージェントの認証情報が 流出した とき、人間向けの CA で守れるか？ 仕掛け: ポリシー: 「指定された場所からのみ agent01 を許可」 場所 = エージェントのランタイムが居る場所だけ これが本当に効くなら: 普段の動作 → 通る 認証情報が手元に漏れたら → 即ブロック りゅうすけ＠生きニキ 7

Azure Travelers Demo ① 結果 エージェントの動作環境外から agent01 のサインインを試行: これに対するアクセス権がありません Error Code: AADSTS53003 (Conditional Access policy enforcement) サインインそのものは成功した。 でも コンテキスト で弾かれた。 → 「正しい認証情報を持っていても、ポリシー違反なら通さない」 りゅうすけ＠生きニキ 8

Azure Travelers Demo ① 示唆 エージェント特有の弱点: 認証情報がプログラム的に管理される (= 流出リスクが高い) 一度漏れると気づきにくい 人間向け CA がそのまま緩和策になる: 実行場所、デバイス、時刻、リスクスコア etc. "Where / How" の縛りは AI 時代もそのまま有効 りゅうすけ＠生きニキ 9

Azure Travelers Demo ② PIM 申請 → 承認 → 操作実行 「特権は人間が握る」 ガバナンス層 = Human in the Loop りゅうすけ＠生きニキ 10

Azure Travelers Demo ② 問いと仕掛け 問い: エージェントに 強い権限 が必要な操作をさせたいとき、人間がブレーキを握れ るか？ 仕掛け: エージェントは普段、強い権限を 持っていない 必要時に 自分で申請 できる でも 承認は人間 が握る (時限付き) = 既存の特権管理 (PIM) のフロー、そのまま りゅうすけ＠生きニキ 11

Azure Travelers Demo ② シナリオ (1/2) エージェントへの依頼: 「ユーザー test-demo を作成して」 ① エージェント: ユーザー作成を試みる ↓ 権限不足で失敗 ↓ ② エージェント自身が判断: 「権限昇格を申請します」 ↓ PIM 承認依頼が人間に届く エージェントは 自分の権限不足を認識して、自分で申請 する りゅうすけ＠生きニキ 12

Azure Travelers Demo ② シナリオ (2/2) ③ 人間 (ryusuke_admin) がメール / 管理画面で承認 ↓ ④ エージェントに 1時間限定で 強権限が付与される ↓ ⑤ エージェント: もう一度ユーザー作成を試みる ↓ 成功 ↓ ⑥ 1時間後、権限は自動失効 すべての操作は監査ログに記録される りゅうすけ＠生きニキ 13

Azure Travelers Demo ② 示唆 エージェント時代の "承認ワークフロー" は新規開発不要 既存の特権管理 (PIM) の枠組みが、AI 時代にもそのまま当てはまる: エージェントが自律的に 申請 する 人間が 判断 する システムが 記録 する → 「Human in the Loop」は既存資産で作れる りゅうすけ＠生きニキ 14

Azure Travelers 振り返り: 効いた統制 層 統制 アイデンティティ Conditional Access ガバナンス PIM 監査 Unified Audit Log 結果 コンテキストで止める 人間承認で握る 全行動を追跡可能 結論: 人間向けに設計された統制は、エージェントにもそのまま機能する りゅうすけ＠生きニキ 15

Azure Travelers 振り返り: 新しく考えるべきこと 認証情報の保管場所が新たな攻撃面 (CAで守る対象になる) プロンプトインジェクション で tool を悪用されるリスク 監査ログには 「行動」は残るが「思考過程」は残らない 申請理由 (justification) を LLM が書く ことの是非 → 既存統制でベース は守れる。LLM 固有の脅威は別レイヤーで追加検討 りゅうすけ＠生きニキ 16

Azure Travelers もう一段だけ抽象的に エージェントが起こしうるミスは、本質的に人間にも起こせ る 機密ファイルを外部にうっかり共有する 上長承認なしに特権を勝手に活性化する 怪しいネットワークから業務システムに入る これらは 「社会人ならやらない」 前提 で運用されてきた 多くの人間が "社会人として振る舞えている" からこそ、 これらの統制は 滅多に発動しなかった だけ → AI 時代は、暗黙の「社会人としての規範」を 統制で明文化する フェーズ りゅうすけ＠生きニキ 17

Azure Travelers まとめ AI エージェントは "新人の同僚" として扱える 既存の Entra / E5 統制は エージェントにもほぼそのまま効く "何を" "どこまで" の答え: 渡すツールを最小化 コンテキストで縛る (CA) 危険操作は人間承認 (PIM) AI 時代のセキュリティは ゼロから作らなくていい ただし 暗黙だった "規範" を明文化する 必要がある りゅうすけ＠生きニキ 18

Azure Travelers 余談: Microsoft Entra Agent ID Microsoft が AI エージェント専用の 第3のID をリリース (プレビュー) ユーザー でも アプリ でもない、エージェント専用 ID 大量・短命・動的なエージェント運用を前提に設計 エージェント ID と ユーザーアカウントの "ペアリング" に対応 既に Microsoft 自社サービスで本番運用 (CA Optimization / Copilot Studio) りゅうすけ＠生きニキ 19

Azure Travelers Agent ID で嬉しくなること 今回の構成は そのままでも十分機能する。 Agent ID を入れると、こんな点が プラットフォームに任せられる ようになる: 「AI が実行した」と監査ログ上で明示 運用タグで仕分けせず、構造的にAIと識別される AI 専用のセキュリティ機能 Agent向け CA / Identity Protection / 異常検知が標準提供 大量・短命なエージェント運用がしやすい bulk 作成、即破棄、エフェメラルな運用が前提設計 ライセンス効率 ペア元ユーザーのライセンスで複数 Agent をカバー可 Microsoft が定義した "エージェント" として整理される りゅうすけ＠生きニキ 社内ルールではなく標準定義 → コンプラ対応が楽 20

Azure Travelers Thanks! りゅうすけ＠生きニキ りゅうすけ＠生きニキ 21