AIエージェントのセキュリティはアイデンティティから始まるが、企業に必要なのは認証情報だけではない

Google Newsは9月2日、AIエージェントに関する警告を取り上げた。しかし問題は、また一つのセキュリティ・チェックリストにとどまらない。この記事は、エージェントがさらに広がる前に企業が三つの問いに答えなければならないと主張する。エージェントはどこに存在するのか、何に接続できるのか、そして何を実行できるのか。

この枠組みは、Oktaのセキュリティ製品マーケターであるAriel Zommer氏が寄稿したGuidePoint Securityの記事で示された。中心的な主張はシンプルだ。エージェントが認証を行い、企業システムに到達し、あるいは人間による継続的な指示なしに行動できるようになった時点で、それはアイデンティティの問題となる。

タイミングも重要である。NISTはGuidePointの記事が公開される1週間未満前の8月27日に、別途アイデンティティに関する警告を発表した。Microsoft、Okta、その他のアイデンティティ・プロバイダーも、エージェントのアイデンティティを正式な製品オブジェクトへと位置づけ始めている。

この収束は、企業内での議論を変える。中心的な問いはもはや、モデルが正確な回答を生成できるかどうかではない。その結果として実行されるすべての行動に、可視化された実行主体、限定された権限、責任者、そして取り消し可能な接続があるかどうかだ。

アイデンティティ管理はすでに従業員、アプリケーション、従来型ワークロードを統制しているため、この議論には既視感がある。エージェントがこのモデルを複雑にするのは、その行動が確率的であり、接続が変化し、一つの要求が多くの下流処理を引き起こしうるためだ。

したがって、アイデンティティは必要条件ではあるが、十分条件ではない。認証情報はエージェントを識別できても、その時点の行動が安全だと証明することはできない。本当の争点は、説明責任を伴う自律性と、組織が完全には追跡できない利便性重視のアクセスとの間にある。

Google Newsが実際に取り上げたもの

これは新たな脆弱性の開示ではない。エージェントの導入が企業のアイデンティティ管理を追い越しているという、協調的な警告である。

元のアイデンティティに関する主張は、GuidePoint Securityにより2026年9月2日に公開された。Oktaの従業員が執筆し、パートナーの視点として提示されている。

この区別は重要である。読者はこの記事を、一つの商用プラットフォームがすべてのエージェント・セキュリティ問題を解決するという独立した証拠ではなく、ベンダーが支援する分析として受け止めるべきだ。その三つの問いは、測定可能な統制上のギャップを表しているため、依然として有用である。

最初の問いは、組織のエージェントがどこに存在するかを問う。棚卸しには、社内開発エージェント、SaaS製品に組み込まれた機能、クラウドホスト型エージェント、従業員が認可したツール、実験的システムを含めなければならない。

従来の資産台帳では、こうしたカテゴリーを見落としがちだ。開発者は、承認済みのクラウドアカウント内にエージェントを作成しても、それを独立した業務アプリケーションとして登録しない場合がある。従業員もOAuthを介して外部ツールを認可できる。

OAuthは、一つのアプリケーションが別のサービスへの限定的なアクセス権を取得できるようにする認可標準である。その利便性は、基盤となるエージェントを承認していないチームから、継続的な信頼関係を見えにくくする可能性がある。

したがって発見には、コードリポジトリのスキャン以上のものが必要だ。セキュリティチームには、クラウドのインベントリ、アプリケーション登録、OAuth許可、サービスアカウント、ブラウザシグナル、APIゲートウェイの記録、Model Context Protocol接続も必要となる。

Model Context Protocol、すなわちMCPは、AIアプリケーションが共通のインターフェースを通じてツールやデータに接続できるようにする。統合を簡素化する一方で、到達可能なシステムの範囲を広げる可能性がある。

二つ目の問いは、発見された各エージェントが何に接続できるかを問う。このマップは、業務アプリケーション、内部API、データベース、コラボレーションシステム、シークレット、サービスアカウント、その他のエージェントを対象にすべきだ。

接続だけでは、リスクの全体像は分からない。セキュリティチームは、認可方式、権限スコープ、認証情報の有効期間、業務上の責任者、承認履歴、取り消し経路も把握する必要がある。

三つ目の問いは、エージェントが接続後に何を実行できるかを問う。読み取りアクセス、レコード変更、コード実行、資金移動、ユーザーなりすましでは、結果の重大性が大きく異なる。

こうした権限は組み合わさることもある。メールを読み取り、サポートチケットを作成するエージェントは、各接続を別々に確認すると限定的に見える。しかし、指示を抽出して外部アクションを起動できる場合、その影響はより大きくなる。

Google Newsは、この警告をより広い読者層の前に届ける一助となった。しかし重要な出来事は、集約レイヤーの下で進んでいた。アイデンティティ・ベンダーと公的標準化機関は、エージェントを企業における第一級の行為主体として位置づける方向で収束している。

この変化は、セキュリティリーダーにより明確な出発点を与える。同時に、エージェントのアイデンティティを、それを起動したユーザー、アプリケーション、またはサービスアカウントから区別するよう求める圧力も生む。

借用した従業員トークンでは、この区別を明確に行えない。複数のエージェントが使用する一つの共有APIキーでも同様だ。どちらの構成も、監査やインシデント調査における帰属を弱める。

当面の変化は概念的なものだが、運用にも及ぶ。企業は現在、作成、所有、認可、レビュー、停止、廃止を含む、エージェントごとの独立したライフサイクル記録を必要としている。

アイデンティティはAIのコントロールプレーンになった

エージェントには固有のアイデンティティが必要である。なぜなら、帰属を伴わない権限は、日常的な自動化を際限のない調査問題へと変えるからだ。

アイデンティティおよびアクセス管理、すなわちIAMは、誰がどの条件でリソースにアクセスできるかを決定する。既存のIAMシステムはすでに、ディレクトリ、ポリシーエンジン、アクセスレビュー、トークンサービス、監査記録を提供している。

これらのコンポーネントは、企業に実用的な基盤を与える。企業はエージェントを登録し、責任者と結び付け、具体的な権限を付与し、エージェントが変更または廃止された際にその権限を取り消せる。

NISTも最近のアイデンティティ基盤に関する分析で、この立場を強調した。同機関は、初期導入では確立されたアイデンティティ慣行よりも、機能と即時の価値が優先されていると警告した。

NISTはまた、認証情報の共有を中核的な問題として指摘した。共有認証情報は、調査担当者が、誰、どのサービス、あるいはどのエージェントが取引を実行したのかを確実に特定できないため、説明責任を損なう。

エージェントがタスクを委任すると、この問題はいっそう鮮明になる。ユーザーが一つのエージェントに営業ブリーフィングの準備を依頼する場合を考えよう。そのエージェントは、アカウントデータのために別のシステムを呼び出し、競合調査のために第三のサービスを利用する可能性がある。

引き渡しのたびに、認可判断が生じる。企業は、元のユーザー、行動するエージェント、要求されたリソース、そして要求の目的を保持しなければならない。

この連鎖がなければ、ログにはサービスアカウントがデータベースにアクセスしたことが示されるにすぎない。どのエージェントが行動を開始したのか、どのユーザーが要求したのか、その行動が承認済みワークフローに合致していたのかは説明できない。

第一級のアイデンティティは、この文脈の一部を取り戻せる。各エージェントには汎用アカウントを借用させるのではなく、一意の識別子を与える。そうすれば、ポリシーは特定のエージェントを対象にできる。

このモデルは、割り当てられたタスクに必要な最小限のアクセスにアイデンティティを制限する最小権限を支える。また、無関係なアプリケーションや従業員を妨げることなく、権限を取り消すことも可能にする。

短命トークンは、この設計を強化する。トークンとは、限定されたスコープと期間について付与された権限を表す署名付き認証情報である。有効期限を短くすることで、盗まれた認証情報の価値を下げられる。

フェデレーテッド認証情報も、もう一つの改善策となる。信頼されたワークロードは、再利用可能なシークレットをコード、設定ファイル、またはエージェントのメモリ内に保存せずにトークンを要求できる。

所有者の指定が、基本記録を完成させる。すべての本番エージェントには、目的、権限、レビュー、廃止について責任を負う、名前のある個人または説明責任を持つチームが必要だ。

所有者は、最初のプロトタイプを作成した開発者だけであってはならない。エージェントのアクセスが依然として必要かどうかを誰かが判断しなければならないため、業務上の所有責任が重要となる。

ライフサイクルの状態も重要だ。実験用エージェントは、テスト終了後に本番環境の権限を保持すべきではない。置き換えられたエージェントも、APIキーがまだ機能するという理由だけで有効なままにしてはならない。

この構造は、従業員やアプリケーションのガバナンスに似ている。しかしエージェントは、ツール、指示、モデル、委任タスクがそれぞれ独立して変化しうるため、より頻繁な評価を必要とする。

したがって企業は、アイデンティティ・ディレクトリを静的なアドレス帳ではなく、コントロールプレーンとして扱うべきだ。登録はガバナンスを開始するが、継続的なポリシー適用がそれを意味あるものにする。

この区別は、正当な実験も守る。開発者は、導入後に大規模なセキュリティレビューを待つのではなく、定められたエージェント登録の経路を利用できる。

使いやすい登録プロセスでは、目的、所有者、環境、ツール、データ分類、権限、予想される運用上の境界を記録すべきだ。また、有効期限またはレビュー日も設定すべきである。

承認済みの経路が未登録エージェントを作るより遅ければ、チームはそれを迂回する。したがってアイデンティティ・プログラムは、隠れた導入よりも安全なオンボーディングを容易にしなければならない。

ここで、ナレッジマネジメントの実践がガバナンスを支援できる。チームには、意思決定、所有者、要件、承認、後続の変更を結び付ける検索可能な記録が必要だ。

インベントリだけでは、エージェントがどこで登録されたかに答えるにすぎない。連携した運用知識は、なぜそれが存在するのか、現在の行動が依然としてその目的に合致しているのかを説明する。

三つの問いは三つの異なる失敗を明らかにする

発見、接続の統制、行動のガバナンスは別個の領域であり、一つを満たしても他の失敗を補うことはできない。

「自社のエージェントはどこにあるか」という問いは、可視性を試す。開発者のアカウント、従業員のブラウザ、またはSaaS管理者の設定内にしか存在しないエージェントを、セキュリティチームは統制できない。

有用なインベントリには、認可済みと未認可の両方の導入を含める必要がある。また、稼働中のエージェントを、テンプレート、放棄された実験、無効化されたインスタンス、AI機能を使用する通常のアプリケーションと区別しなければならない。

インベントリでは、すべてのエージェントの環境と運用状態を特定すべきだ。開発、テスト、本番のエージェントに、同じ承認前提を適用すべきではない。

セキュリティチームは、何をエージェントと見なすかも決めなければならない。テキストを返すだけのチャットボットは、ツールを呼び出したりレコードを変更したりするシステムとは異なる権限プロファイルを持つ。

定義は行動に焦点を当てるべきだ。ソフトウェアが行動を選択し、接続されたツールを呼び出し、または限定的な人間のレビューのもとで作業を委任するなら、それは統制対象に含まれる。

「何に接続できるか」という問いは、組織の信頼グラフを試す。信頼グラフは、アイデンティティ、認証情報、アプリケーション、リソース、委任先サービスの間の関係を記録する。

このグラフは、直接的な到達範囲と間接的な到達範囲を示すべきだ。エージェントがデータベースへのアクセス権を持たなくても、同じデータベースを照会できるサービスを呼び出す権限を持っている場合がある。

エージェント間接続は、マッピングをさらに難しくする。一つのエージェントが別のエージェントにコンテキストや権限を渡すことで、プラットフォームや管理境界をまたぐ連鎖が生まれる。

企業は、各接続が常設アクセスを利用するのか、タスク固有の認可を利用するのかを記録しなければならない。常設アクセスはタスク間も利用可能なままであり、エージェントが侵害された場合の露出を増大させる。

「彼らは何ができるのか？」という問いは、実行時の制御を検証するものです。その答えは、アプリケーション登録からコピーしたAPIスコープの一覧ではありません。

あるスコープがファイル変更を許可していても、ポリシーは通常の編集とリポジトリの削除を区別しなければなりません。同じ技術的権限でも、ビジネス上の影響が異なる行為をカバーし得ます。

実行時認可は、提案されたアクションが発生する時点で評価します。実行するエージェント、起点となったユーザー、リソースの機密性、要求された操作、場所、現在のリスクシグナルを考慮できます。

一部の判断は自動のままであるべきです。低リスクの照会すべてに人の承認を求めれば、エージェントがもたらすはずの生産性が失われます。

影響の大きいアクションには、より強い摩擦が必要です。本番システムの変更、資金移動、規制対象情報の開示、元に戻せない削除には、明示的な保護措置が求められます。

Human-in-the-loopによる承認は選択肢の一つです。エージェントが機密性の高いアクションを完了する前に、定義された判断ポイントへ人を置きます。

承認には意味のある文脈が必要です。リソース、データ、目的、想定される影響を示さずに「アクションを許可」とだけ表示するプロンプトは、形式的なチェックボックスに成り下がります。

組織には、信頼できる無効化機能も必要です。キルスイッチは、目に見えるインターフェースだけを無効にするのではなく、接続されたシステム全体でエージェントの有効なアクセスを取り消すべきです。

その能力は認証情報アーキテクチャに依存します。エージェントが分散したAPIキー、キャッシュされたトークン、外部サービスにコピーされた認証情報を使う場合、中央での失効は十分に機能しません。

したがって、この3つの問いは連続した流れを成します。ディスカバリーで主体を確立し、接続マッピングで潜在的な到達範囲を定義し、アクションガバナンスで実際に行使される権限を制御します。

この流れを省略すると、誤った安心感が生まれます。組織は完全なエージェント台帳を維持していても、掲載されたすべてのエージェントに過剰な権限が付与されたままになり得ます。

また、狭く限定したトークンを発行していても、従業員が作成したエージェントを見落とすことがあります。あるいは、エージェントのアクションを記録していても、それを帰属させるのに十分なアイデンティティ文脈を保持していない場合があります。

このフレームワークの価値は、そうした失敗の境界にあります。各問いは、監査人やセキュリティリーダーに「責任あるAI」についての漠然とした保証ではなく、検証可能な具体的主張を与えます。

アイデンティティ制御だけでは、アクションが賢明かどうかを判断できない

有効なアイデンティティは誰が行動しているかを示しますが、エージェントが要求を理解し、安全なアクションを選んだことまでは保証しません。

この限界が、この記事の中心的なトレードオフを定義します。企業にはアイデンティティベースの制御が必要である一方、同じ認証情報を使う従来型アプリケーションよりもエージェントの振る舞いは予測しにくいままです。

従来型のサービスは、既知のワークフロー向けに書かれたコードを実行します。エージェントは、指示を解釈し、ツールを選び、パラメーターを生成し、返された情報に応じて経路を調整できます。

この柔軟性が価値を生みます。しかし同時に、認証が成功したという事実だけでは、次の判断がユーザーの意図に沿う証拠にはなりません。

プロンプトインジェクションは、この隔たりを例示します。エージェントは文書、メール、Webページ、取得したレコードに含まれる悪意ある指示に遭遇し、それを自身のタスクの一部として扱う可能性があります。

攻撃者はエージェントのアイデンティティを盗む必要はありません。正しく認証されたエージェントを操作し、正当な権限を誤用させようとすることができます。

OWASPは、アイデンティティと権限の悪用をagentic security risksの一つとして挙げています。このカテゴリには、委任チェーン、継承されたロール、キャッシュされた認証情報、エージェントのコンテキストに対する操作が含まれます。

ツールの誤用も別の問題を生みます。エージェントが承認済みのツールを、安全でない引数で、あるいはワークフローの誤った段階で呼び出す可能性があります。

アイデンティティ制御は、未承認のツールへのアクセスを拒否できます。しかし、許可された呼び出しの一つひとつがユーザーの実際の目的を支えているかどうかを、単独で判断することはできません。

したがって、セキュリティアーキテクチャでは、モデルを信頼できない意思決定コンポーネントとして扱う必要があります。結果が重要となる場面では、決定論的な制御をモデルの外部に維持すべきです。

決定論的な制御は、確率的な応答を生成するのではなく、明示的なルールに従います。例として、権限チェック、スキーマ検証、取引上限、必須の承認ゲートが挙げられます。

ポリシーエンジンは、エージェントが提案する内容を評価すべきであり、エージェント自身が自らを統制することに依存してはなりません。エージェントが自身の権限を制御するルールを書き換えられてはなりません。

入力と出力の検証も引き続き重要です。ツールのパラメーターは、想定されるスキーマ、リソース制限、データ分類、承認済みの宛先に適合すべきです。

ネットワーク制御は、到達範囲をさらに狭めることができます。公開インターネットへのアクセスを必要としないエージェントに、デフォルトでそのアクセスを与えるべきではありません。

アイデンティティは、承認済みの受信者への不適切な開示を防ぐものではないため、データ制御も重要です。ポリシーは、データの機密性、目的、保持期間も考慮しなければなりません。

監視では、サインインだけでなく行動にも焦点を当てる必要があります。認証成功後に異常な列挙、大量ダウンロード、拒否されたアクションの繰り返しが続く場合は、調査に値します。

ここで、アイデンティティファーストという主張には慎重な表現が必要です。アイデンティティは、説明責任、失効、ポリシーの基盤を提供します。それは完全なエージェント安全システムではありません。

商用のアイデンティティプラットフォームは、登録とトークンを一元化できます。しかし、接続されたすべてのモデルが操作に耐え、曖昧な目標を正しく解釈することまでは保証できません。

ベンダー中立性も依然として不確実です。エージェントは、Microsoft、Google Cloud、Amazon Web Services、Salesforce、ServiceNow、社内フレームワーク、特化型SaaS製品にまたがることになります。

各プラットフォームはエージェントを異なる形で表現できます。クロスプラットフォームのアイデンティティには、相互運用可能なトークン、一貫したクレーム、信頼できる発行者、引き継ぎ後も有効なポリシーが必要です。

MCPは別の境界を加えます。企業はエージェントを統制していても、ツールを正確に公開し、自身の認証情報を保護する外部サーバーに依存する可能性があります。

アイデンティティレイヤー自体も侵害から守る必要があります。集中管理されたディレクトリとトークンサービスは、多数のエージェントに一度に影響を及ぼし得るため、価値の高い標的になります。

企業は管理業務を分離し、高権限の変更を保護し、異常なポリシー変更を監視すべきです。エージェントガバナンスを、広範な権限を持つ単一のコンソールアカウントに委ねることはできません。

監査ログにも同じ懐疑的な姿勢が必要です。大量のイベントがあっても、自動的に有用な証拠が得られるわけではありません。

調査担当者には、ユーザー要求、エージェントのアイデンティティ、委任されたエージェント、選択されたツール、認可判断、影響を受けたリソース、最終結果を結び付ける記録が必要です。

保持ポリシーは、調査や規制レビューに十分な期間、そのチェーンを保存しなければなりません。機密性の高いプロンプトや出力には、最小化またはアクセス制限が必要となる場合があります。

正しい結論は、ベンダーメッセージよりも限定的です。制御には既知の主体が必要なため、アイデンティティはエージェントセキュリティの出発点です。

それでも、セキュリティには、その主体を囲む多層防御が必要です。これらの層には、制約されたツール、外部ポリシー、保護された認証情報、データ制御、監視、人によるレビューが含まれます。

MicrosoftとOktaはモデルを製品へと変えつつある

アイデンティティファーストという考え方は、カンファレンスでの言葉から、ディレクトリ、トークンフロー、ディスカバリーシステム、失効制御へと移りつつあります。

Microsoft Entra Agent IDは、大手プラットフォームが現在どのようにエージェントを直接表現しているかを示す例です。Microsoftは、エージェントアイデンティティを一意の識別子を持つ特殊なサービスプリンシパルとして説明しています。

サービスプリンシパルは、アイデンティティテナント内でアプリケーションまたはワークロードを表現します。エージェント版は、ポリシーとログがエージェントをその基盤となる設計図から区別できるようにします。

Microsoftのautonomous authentication flowは、エージェントアイデンティティを再利用可能な本番シークレットから分離します。ドキュメントでは、クライアントシークレットの代わりにマネージドIDまたは証明書を推奨しています。

自律型エージェントは、自身のアイデンティティでアプリケーショントークンを要求できます。対話型エージェントは、認証済みユーザーのために行動する場合、委任フローを使用できます。

この違いは不可欠です。自律的に動作する夜間レポーティングエージェントは、サインイン済みの従業員に代わって一つのアクションを実行するアシスタントと同一視されるべきではありません。

On-behalf-of認可は、委任の間もユーザーとの関係を保持します。生成されるトークンは、ユーザーを主体、エージェントを行為者として識別できます。

この設計により、リソースサーバーは認可判断により多くの文脈を利用できます。システムは、そのユーザーがそのエージェントを通じて要求された操作を実行できるかを確認できます。

Microsoftは、ユーザーのようなオブジェクトを必要とするリソース向けの特別なエージェントユーザーアカウントについても文書化しています。こうしたアカウントは、通常の人間用認証情報を使わずにメールボックスやコラボレーション機能をサポートできます。

これらのアカウントには制限があります。Microsoftによれば、特権管理者ロールは付与できず、ある種の権限昇格に対する境界を設けています。

Oktaは、プラットフォーム中立のアイデンティティという立場から同じ市場に取り組んでいます。同社の4月のagent identity launchでは、ディスカバリー、登録、管理された接続、ガバナンス、無効化について説明されました。

同社は、ディレクトリが外部プラットフォームからエージェントをインポートし、カスタムエージェントを登録できると述べています。また、OAuth同意シグナルを通じたシャドーエージェントの検出についても説明しています。

Oktaは、GuidePointのゲスト記事で繰り返された同じ3つの問いを軸に製品を位置付けています。この一致は、記事の商業的な文脈を裏付けています。

製品メッセージは慎重に検証すべきですが、実装カテゴリは具体的です。企業には、エージェントのためのディレクトリ、接続のための限定的なトークン、アクションのためのポリシー施行が必要です。

プラットフォームが相互運用可能な制御を公開すれば、競争は購入者に利益をもたらすはずです。Microsoftのモデルは、EntraとMicrosoft Graphを中心とする組織に適合する可能性があります。

Oktaは、複数のクラウド、アプリケーション、エージェントフレームワークにまたがるガバナンスを重視しています。クラウドプロバイダーは当然、自社のエージェントサービスを既存のワークロードアイデンティティシステムと統合するでしょう。

危険なのは断片化です。企業は、クラウドごとに1つのエージェントインベントリ、アイデンティティプロバイダー内に別のインベントリ、さらにSaaS管理ポータル内に複数のインベントリを抱える可能性があります。

組織が正規の所有権およびライフサイクルプロセスを定義しない限り、これらのインベントリは一致しません。ディスカバリーツールは、並行する情報源を作るのではなく、そのプロセスに情報を流し込むべきです。

トークンの互換性も別の課題です。OAuthは認可の仕組みを標準化できますが、ベンダーごとにアイデンティティクレーム、委任の証跡、実行時ポリシー制御が異なる可能性があります。

エージェント間通信は重要性を高めます。最初のエージェントはユーザーから委任された権限を持つ一方、下流のエージェントはアプリケーション権限の下で自律的に動作する可能性があります。

認可チェーンは、権限がどこで変化したかを示さなければなりません。そうでなければ、承認済みのユーザー要求が、目に見える権限昇格なしに広範なマシンアクションへ変わり得ます。

調達チームは、実際のワークフローに対して製品をテストすべきです。洗練されたディレクトリインターフェースよりも重要なのは、そのプラットフォームが影響を受けるすべてのコネクタにわたってアクセスを失効できるかどうかです。

また、エクスポート可能性もテストすべきです。監査データは、一つの独自調査ビューに依存せず、インシデント対応、コンプライアンス、移行のためにアクセス可能でなければなりません。

セキュリティチームは、可視性を改善するためだけに新しいエージェントプラットフォームへ無制限のアクセスを付与することを避けるべきです。ディスカバリーアーキテクチャ自体にも、最小権限のレビューが必要です。

したがって市場は、共有インフラとしてのアイデンティティへ向かっています。勝者となるのは、単にエージェントを登録するだけの企業ではありません。

それらはプラットフォーム間で帰属情報を保持し、常設の認証情報を減らし、きめ細かな取り消しを可能にし、外部ツールが評価できるポリシー判断を記録として可視化する。

エージェントを拡大展開する前に企業が検証すべきこと

次の段階は、「ファーストクラスのアイデンティティ」という言葉を何社のベンダーが繰り返すかではなく、導入の証拠によって測られる。

最初の指標は、企業がシャドーエージェントを含む完全なインベントリを構築するかどうかだ。正式なオンボーディングだけで作られたディレクトリでは、最もリスクの高い導入を見落とす。

組織は、アイデンティティ記録をOAuth付与、クラウドリソース、ブラウザテレメトリー、API利用状況、SaaS設定と照合すべきである。大きな乖離があれば、アイデンティティファーストという約束は弱まる。

二つ目の指標は、短命でスコープが限定された認可が、静的なシークレットに置き換わるかどうかだ。新しいエージェント向けに最新トークンを発行できるかよりも、移行件数の方が重要である。

チームは、埋め込みAPIキー、共有サービスアカウント、長期間有効なリフレッシュトークンを利用する既存エージェントを特定すべきだ。その後、こうした認証情報がどれほど速く廃止されるかを測定する必要がある。

Microsoftのドキュメントは、企業にとって一つの技術的な基準点を示している。同社の本番環境向けガイダンスは、保存されたクライアントシークレットよりも、フェデレーション認証情報とマネージドIDを推奨している。

三つ目の指標は、実行時の制御がクロスプラットフォームの委任をまたいでも維持されるかどうかだ。これにより、エージェントのアイデンティティが真のインフラになるのか、それとも別の孤立した製品カテゴリにとどまるのかが決まる。

有効なテストは、複数のエージェントとツールを起動する一つの人間のリクエストから始められる。調査担当者は、無関係なログを手作業で突き合わせることなく、完全な連鎖を再構築できるべきである。

記録には、起点となった人物、参加したすべてのエージェント、各トークン交換、適用されたポリシー、影響を受けたすべてのリソースが特定されていなければならない。

取り消しは同じ連鎖全体で機能すべきだ。起点となるエージェントを無効化しても、委任済みの認証情報や下流のセッションが有効なまま残ってはならない。

企業は敵対的テストも実施すべきである。レッドチームは、認可されたエージェントが取得することを想定されたコンテンツの中に、悪意ある指示を埋め込める。

このテストでは、モデルが指示を受け入れた後に、外部ポリシーが危険な操作を阻止できるかどうかが明らかになるべきだ。アイデンティティだけでは、その結果は生まれない。

ビジネスリーダーには、許容できる自律性を判断するための枠組みが必要である。結果の重大性は大きく異なるため、すべてのエージェントに同一のレビューを求める必要はない。

公開文書を読むリサーチアシスタントと、本番コードを編集するエージェントでは、リスクが異なる。買掛金処理を担うエージェントは、さらに別のカテゴリをもたらす。

アクセスレビューには、こうした違いを反映すべきである。影響の大きいエージェントには、より短い認定サイクル、より厳格な制限、より強い監視、そして明確に定められた人間の承認ポイントが必要だ。

インシデント対応計画には、行為主体としてエージェントを含めなければならない。チームは、アイデンティティの停止、トークンの無効化、コネクタの隔離、ログの保全、影響を受けたデータの特定を行う方法を把握しておくべきだ。

この計画は、侵害されたサードパーティ製エージェントも対象にする必要がある。企業内部のコードが侵害されていなくても、事前に付与されたOAuthの信頼は危険なままであり得る。

セキュリティチームはベンダーに対し、コネクタの侵害をどれほど迅速に開示し、発行済みアクセスを取り消すのかを確認すべきだ。契約文言では、ログ、通知、調査支援を扱う必要がある。

開発者には、設計段階でより明確な基準が必要である。すべての新規エージェントは、所有者、ツール、データ分類、認可パターン、許容される結果の最大範囲を宣言すべきだ。

この情報は、社内のAIワークフロー記録の一部にできる。プロダクト、セキュリティ、エンジニアリングの各チームは、変更を本来の目的に照らしてレビューできるようになる。

Google Newsの記事は有用な確認点を示しているが、繰り返しを解決と取り違えるべきではない。アイデンティティプロバイダーは、企業が回答を実装する以上に、問題を明確に定義してきた。

この三つの問いは、実用的な最初のレビューを形作る。組織はすべてのエージェントを把握できるか。到達可能なすべてのシステムをマッピングできるか。重要なすべての操作を制約し、再構築できるか。

「はい」と答えるには、ディレクトリ、トークン、ポリシー、ログによる証拠が必要だ。監査のために管理されるスプレッドシートは、実行時の制御を証明しない。

まず一つの本番ワークフローから始め、人間の意図から最終的な影響までを追跡する。共有認証情報を排除し、すべての接続を狭め、自動操作を停止すべき地点を定義する。

次に、負荷がかかった状況で取り消しと再構築をテストする。どちらかが失敗するなら、そのエージェントは組織が安全に説明できる範囲を超えた自律性を持っている。

Google Newsは次の見出しへ移っていく。企業が、すべてのエージェント操作を限定された権限、明確な所有者、強制可能なポリシーに結び付けられるようになるまで、アイデンティティのギャップは残り続ける。