AIエージェントの登場で、従来のID管理が崩壊する理由
本ブログはグローバルブログ「Your identity stack was built for two kinds of actor. Agents are a third.」の抄訳版です。
これまでの認証・アクセス管理（IAM）は、「人間」と「システム」の2択しか想定していません。しかし今、どちらの定義にも当てはまらない、第3の存在――「AIエージェント」が紛れ込んでいます。
今週、あるエンジニアがエージェントを本番環境にリリースしたとします。そのエージェントは社内APIを叩く必要があるため、エンジニア自身の環境にすでにあるアクセスキーをそのまま使います。エージェントは動き出しました。そして同時に、そのエンジニアが持つ「すべての権限」を手に入れたことになります。
これが、現在デプロイされている大半のエージェントのデフォルトの状態です。エージェント自身にはアイデンティティ（識別情報）がないため、他人のものを借りてくるのです。リリース初日は問題なく動きます。だからこそ、この問題は気づかれないまま見過ごされてしまいます。人間ではないプロセスが、人間のフルアクセス権限を抱え込んで動いているにもかかわらず、監査ログのどこを見ても両者を区別することはできません。
これは、設定ミスではありません。構造的な欠陥（ギャップ）なのです。
そもそも、アイデンティティ＆アクセス管理（IAM）は、システムを扱うアクター（主体）を次の2つのどちらかとして想定しています。すなわち「人間」か、あるいは「固定の権限セットを持つ、長期運用のサービスアカウント」か、です。どちらも安定しており、毎日ほぼ同じような動きをします。私たちのセキュリティ管理、監査モデル、そして権限付与のフローは、すべてその「安定性」を前提に構築されているのです。
しかし、エージェントはそのどちらでもありません。 エージェントは「人の代わりに」行動するため、ただのサービスアカウントではありません。かと言って、独自のスケジュールで起動と破棄を繰り返すため、人間でもありません。
彼らは、現在のIAMスタックが想定していない「カテゴリの空白地帯（ギャップ）」に位置しています。そして、その空白地帯こそが、認証情報が勝手に「借りられてしまう」原因なのです。
なぜ「その場しのぎの対策（パッチ）」では通用しないのか
既存のID・アクセス管理（IAM）の仕組みに、エージェントをただ組み込めば済むという話ではありません。それが不可能な最大の理由は、エージェントが持つ「非決定性（＝その時々で動きが変わる性質）」にあります。これまでのサービスアカウントであれば、毎回同じエンドポイントを、同じ頻度で叩くだけでした。しかしエージェントの場合は違います。2つのエージェントに「同じ権限」と「同じゴール」を与えたとしても、それぞれが全く違う動きをすることがあります。なぜならエージェントは、実行時のプロンプト、文脈（コンテキスト）、そして直前の処理結果に応じて、その場で使うツールや処理ルートを自律的に判断して選ぶからです。
つまり、エージェントが「実際にこれからどんなアクションを起こすか」は、権限を付与する段階（設計時）では予測不可能なのです。ここに根本的なズレが生じます。私たちがこれまでやってきた「最小権限の原則」は、設計時に決めたルールを適用するものです。しかしエージェントが抱えるのは、動いている最中（実行時）にしか分からない問題です。「実行されて初めて次の動きを決める主体」に対して、あらかじめ「やっていいこと」を事前に決めて縛るのには限界があります。
この事実こそが、本連載で最もお伝えしたい核心です。 だからこそ、人間の認証情報を「使い回す」のは危険であり、権限のスコープは極限まで絞らなければならず、委任のプロセスは常に追跡可能でなければならず、そして「一度権限を与えたら終わり」という認証モデルが通用しないのです。これから重要になるのは、「このアクターは誰か」という古い問いではありません。 「このアクターは『今このタスクのために』、何を行う権限を与えられているのか」という、リアルタイムの問いなのです。
ブログの第1回、あるいは導入部分の締めくくり（チェックリスト）ですね。ここは読者に「今すぐ自社環境を確認しなきゃ」と思わせる、行動を促す（Call to Action）セクションです。
英語特有のウィットに富んだ表現（”hostage situation” など）のニュアンスを殺さず、日本の情シスやセキュリティ担当者が「ゾッとする」リアルな現場の言葉に翻訳しました。
いますぐに確認すべきポイントは？
本連載で深い話に入る前に、すでに本番環境で動いているエージェントに対して、今すぐ実行できる3つのチェックリストをお伝えします。
1. 「人間のAPIキー」がシステムに使われていないか？人間ではないプロセス（エージェント）が、個人のAPIキーを使っていないか確認してください。もしエージェントが「デプロイしたエンジニア本人」として認証されているなら、今この瞬間も、その人が持つ特権が本番環境でそのままエージェントに引き継がれています。
2. 監査ログで「人間」と「エージェント」を区別できるか？ログを見ただけで、エージェントの操作と人間の操作をハッキリ見分けられますか？ もし区別がつかないのであれば、インシデントが発生したときの原因究明（インシデントレスポンス）も、監査対応（コンプライアンス）も、同時にすべて破綻することになります。
3. 他を巻き込まずに、そのエージェント「だけ」を停止できるか？特定のエージェント1つを止めるために、「紐づいている人間のパスワードやキーをまるごと変更する」必要があったり、「他の3つのシステムが巻き添えで落ちる」なんてことはありませんか？ もし権限の剥奪（アカウント停止）にそんな副次的ダメージが伴うなら、それは「停止スイッチ」があるとは言えません。システムを人質に取られているのと同じです。
これらはすべて、根本的な解決策ではありません。あくまで「最低限のスタートライン」です。どこでチェックが引っかかるかを見極めることこそが、対策を始める第一歩になります。
根本的な解決へのアプローチ（あるべき姿）
本連載のこれ以降の回では、この課題に対する解決策を、下層から1ステップずつ積み上げる形で解説していきます。
まずは、エージェントに対して「安定的かつ検証可能な実行時プリンシパル（識別情報）」を与えることから始めます。これがあって初めて、適切な権限付与、アクションの追跡、そしてエージェント単体での権限剥奪が可能になります。
次に、現実の複雑な運用に耐えうる設計が必要です。エージェントがツールを呼び出し、そのツールが別のエージェントを呼び出す……といった複雑なプロセス（ホップ）を経ても、アイデンティティが途切れてはいけません。「誰が最初に要求したのか」「今この瞬間、どのアクターが呼び出しを行っているのか」を常に追跡できるようにするためです。
さらに、エージェントが利用する認証情報は、エージェントのモデル（LLM）そのものから完全に分離されていなければなりません。そうしなければ、一度プロンプトインジェクションの攻撃を受けるだけで、認証情報が読み取られ、外部に流出してしまうリスクがあるからです。
その上のレイヤーでは、「ルールをどこで管理すべきか」、そして「エージェントが自身のプラットフォーム外の領域で動く瞬間に、誰がその行動の可否を判断するのか」というガバナンスの問題が生じます。
そしてこれらすべての土台となるのが、ライフサイクル管理です。アイデンティティとは、一度作ったら終わりの静的な記録ではありません。エージェントが動いている間、常にプロビジョニング、権限の絞り込み（スコープ）、剥奪、そして再評価を繰り返し続ける動的なプロセスであるべきなのです。
「アイデンティティ」こそが、すべての土台です。認証、ガバナンス、そしてオブザーバビリティ（可観測性）は、すべてその上に成り立っています。土台であるアイデンティティの設計を誤れば、その上の仕組みはすべて崩壊してしまいます。
DataRobotが果たす役割
DataRobotが提供するエージェントプラットフォームは、エージェントのアイデンティティを、デプロイ時に「後付けされたおまけ」としてではなく、最優先すべき「第一級のインフラ（First-class infrastructure）」として扱います。
そのアプローチは、本連載で提唱している方向性そのものです。
- 個別のアイデンティティ付与: 各エージェントに、権限を最小化した固有のアイデンティティを与えます。
- 委任チェーンの可視化: エージェントがツールや他のエージェントを呼び出す際、その委任のつながりを維持し、監査可能な状態に保ちます。
- 一元的なガバナンス: 単一のコントロールプレーンで、それらのアイデンティティを統制します。
- 既存システムとの連携: 企業がすでに運用している既存のIDプロバイダー（IdP）やワークロードアイデンティティシステムと、信頼関係をシームレスに連携（フェデレーション）させます。
今後の連載スケジュール（全6回）
Part 1：認証情報の「借り物競争」を終わらせる
なぜ人間のアクセスキーをそのまま引き継ぐことが、実質的な「特権昇格（Privilege Escalation）」になってしまうのか。その根本原因を解剖します。「最初に入国審査でスタンプを押されたパスポート（＝一度きりの認証）」ではなく、「実行時にその都度判断される権限」こそが解決策となる理由を解説します。 近日公開予定です。まずはここからスタートします！
Part 2：第一級のインフラとしての「エージェントID」の定義
真のエージェントアイデンティティとは何か。それは「独立したプリンシパル」「制限された権限スコープ」「明確な所有者」、そして「緊急停止スイッチ（キルスイッチ）」の4つを備えたものです。また、証明（Attestation）によってそのIDの信頼性を担保する方法や、優秀なエンジニアなら誰もが抱く疑問「これって既存のワークロードアイデンティティ（SPIFFE等）と何が違うの？」という問いに答えます。
Part 3：委任チェーン（Delegation Chain）の追跡
エージェントからツール、さらに別のエージェントへと処理が渡っていく「委任の連鎖」を追いかけます。チェーンをフラットに簡略化（横着）したときに発生する「代理人問題（Confused Deputy問題）」の危険性と、現場でその連鎖が維持されるか破壊されるかを左右する2つのプロトコル、MCP（Model Context Protocol）とA2A（Agent-to-Agent）の実践に迫ります。
Part 4：認証情報を「モデル（LLM）」に触れさせない設計
エージェントのコンテキスト（プロンプトの文脈）は、常に外部からの攻撃に晒されています。プロンプトインジェクションを1発受けるだけで、中のデータはすべて読み取られてしまうのです。だからこそ、生の認証情報をエージェントのプロセスに渡してはいけません。ブローカーが認証情報を保持し、境界線で認証をインジェクションする（動的に差し込む）ことで、エージェントにはスコープを絞った最小限の権限（Capability）だけを渡すアーキテクチャを解説します。
Part 5：認可とガバナンスの最適解
ガバナンスはプラットフォーム側で一元管理し、既存のID基盤（IdP）へと信頼をシームレスに連携させる。そして、コントロールの強さを「爆発半径（影響範囲の大きさ）」に合わせて最適化する手法を考えます。さらに、まだ誰も綺麗に解決できていない最前線の課題――「エージェントが、自身のプラットフォームの統制が及ばない『外部の信頼ドメイン』をまたいで行動するとき、何が起きるのか」に切り込みます。
Part 6：ライフサイクルとしてのアイデンティティ
アイデンティティを「動的なライフサイクル」として捉えます。常時与えられた特権（永続的な権限）を排除し、タスク実行時のみ、その瞬間だけ有効な「ジャストインタイム（JIT）」の認証情報へとシフトします。連載の原点である「非決定性（予測不可能性）」へと話を戻し、最終回として、あなたの会社の実環境にいるエージェントに対して実行すべき「6つの監査チェックリスト」を提示します。
さあ、準備はいいですか？ もし、競合よりも一足先にスタートを切りたいなら、今すぐ社内の環境を見渡して、動いているエージェントを1つ見つけてみてください。そして、「それは『誰の』認証情報を使って動いているのか」を確かめてみてください。そこを突き止めることこそが、このセキュリティ問題を解決する第一歩です。