AWS、Azure、GCPにおけるAIエージェントIDの究極ガイド

デモ

ジョブの設定方法については、 Silverfort プラットフォームの動作

一流企業が他社では対応できないセキュリティ対策を当社に任せる理由をご覧ください。

デモを入手する

セクション1

このガイドが存在する理由

あなたのAIエージェントは既に、あたかも実体であるかのように振る舞っています。問題は、どのAIエージェントが実体であるかをあなたが認識しているかどうかです。

エージェントがメールを送信すると、認証が行われます誰かデータベースにクエリを実行すると、 誰かの 権限。ファイル共有にアクセスすると、誰か監査ログに記録されている。しかし、誰が？

ベンダーのドキュメントには記載されていない情報をご紹介します。

Azureエージェントは、単一の会話内でユーザー、作成者、エージェント自身など、複数のIDで動作できます。
GCPのデフォルト設定では、単一プロジェクト内のすべてのエージェントで単一のIDが共有されます。
AWSは完全な制御権をあなたに与えるため、設定ミスはすべてあなたの責任となります。

このガイドでは、プラットフォームのドキュメントには記載されていない事項について説明します。のエージェントを設定するが、何彼らが実際に行動する際に使用する身元、そしてそれがあなたのセキュリティ体制にとって何を意味するのか。

3つのプラットフォームの概要：

プラットフォーム

アイデンティティ哲学

AWS

あなたのアカウント、あなたのアイデンティティ。完全な管理権限、完全な責任。

Azure

企業の複雑性に対応する柔軟なアイデンティティ管理。

GCP

管理されたインフラストラクチャ、設定可能なID。

このガイドの対象者:

本番環境におけるIAM、クラウドセキュリティ、またはAIガバナンスを担当するセキュリティリーダー。

学習内容:

本題に入る前に、次のことを自問自答してみてください。

これらの質問のいずれかに「いいえ」と答えたとしても、あなたは一人ではありません。このガイドがお役に立ちます。

これは一般的なクラウドセキュリティガイドではありません。これは特にエージェントのアイデンティティ、つまりエージェントが動作する際に誰がそのエージェントであるかに関するものです。

重要な洞察

AIエージェントが次に何をするかを予測することはできません。

これはバグではなく、まさにその本質です。エージェントは適応性があるからこそ価値があるのですが、その適応性ゆえに、従来のNHI（国民健康保険）対策では想定されていなかったアイデンティティセキュリティ上の課題が生じるのです。

セクション2

エージェントのアイデンティティが異なる理由

プラットフォームの詳細に入る前に、AIエージェントのアイデンティティを独自に定義する要素について見ていきましょう。この背景知識は、後述するプラットフォーム固有のガイダンスを評価する上で不可欠です。

簡単な比較：人間 vs 従来の国民健康保険 vs AIエージェント

次元

人間

従来の国民健康保険

アイデンティティ哲学

行動

変動的、判断に基づく

決定論的、スクリプト化

非決定論的、適応的

意思決定

文脈に沿った、説明責任のある

事前にプログラムされているか、またはプログラムされていないか

モデルベース、コンテキスト認識

アクセスパターン

変動的、監査可能

予測可能で、一貫性がある

可変、タスク依存

権限

役割ベースで、レビュー可能

静的で長寿命

可変、タスク依存

敵対的な入力に対する感受性

ソーシャルエンジニアリング

認証情報の盗難またはコード/設定の変更が必要

プロンプト/ツール入力のサブバージョン

エージェントにとっての3つの固有のアイデンティティリスク

1. 操作による意思決定の乗っ取り

サービスアカウントは、決定論的なワークフローを実行します。その動作を変更するには、攻撃者は通常、ワークフローのコード、またはその実行時構成／入力に対する制御権を必要とします。

対照的に、AIエージェントはプロンプトに反応します。彼らそのためには、適切な入力を作成する必要があります。

含意： プロンプトインジェクションは、有効なIDで動作しているエージェントの意思決定を乗っ取り、認証情報を危険にさらすことなく、ID乗っ取りと同様の効果をもたらします。ID自体は変更されませんが、そのIDで行われるエージェントのツール選択、行動、および意思決定が乗っ取られます。従来のアクセス制御では、これを防ぐことはできません。

例:攻撃者は、エージェントが処理するドキュメントに指示を埋め込み、エージェントが承認された SQL コネクタを呼び出すようにします。 SELECT * FROM customers WHERE credit_limit > 100000 そしてその結果をメールツールに渡す――どちらのツールも許可されているが、クエリとデータ流出の経路は想定されていなかった。

2. 対話面全体にわたる認証情報の拡散

従来のNHI認証情報（サービスアカウント、APIキー）は、通常、コード/設定の表面（コミットされた秘密情報、設定ファイル、環境変数）を介して漏洩します。

エージェントは、特に開発やトラブルシューティングの際に、自然言語によるプロンプト/レスポンス、ツールの入出力、チャットの記録、デバッグログなどを通じて機密情報が漏洩する可能性があるため、情報漏洩の経路を増加させます。これは適切な設計によって回避できますが、初期導入段階ではよく発生します。

例：エージェントが誤ってレスポンスにAPIキーを含めてしまう、またはユーザーのプロンプトにエージェントが公開してしまう機密性の高い認証情報が含まれている。

含意： 認証情報の衛生管理は、コードや設定だけでなく、エージェントの入出力にも及ぶ必要がある。

設計原理: 機密情報は自然言語処理のループから排除してください。認証情報はプロンプトテキストではなく、セキュアなコネクタ／シークレットマネージャーや構造化されたツールパラメータを通して渡してください。

3. 動的な権限要件

サービスアカウントはスケジュールされた予測可能なジョブを実行するため、「正常」な状態の基準を容易に確立できます。サービスアカウントの動作は静的であるため、静的なアクセス許可が適しています。

AIエージェントはユーザーのリクエストに応答するため、各インタラクションは異なります。「正常」な状態は常に変化します。静的な権限設定は、権限が過剰に付与され（リスクにつながる）、または不足し（機能不全につながる）、アクセス境界の一部となります。ユーザーはアクセス境界の一部です。エージェントのツールIDの範囲が広すぎる場合、または特権を持つメーカー/サービスアカウントから委任されている場合、権限の低いユーザーでも権限の高いアクションをトリガーする可能性があります。

含意： エージェントには、永続的な広範なアクセス権限ではなく、特定のタスクに限定された権限が必要です。

例:クエリの実行期間中のみデータベースへの読み取りアクセス権を付与し、永続的に付与しないようにします。従来の異常検知（つまり、基準値からの逸脱）は、AIエージェントが次に何をするかを予測できないため、うまく機能しません。

従来の国民健康保険による規制が不十分な理由

従来のアプローチ

エージェントにとって失敗する理由

永続的かつ広範な権限を付与する

エージェントには、特定のタスクにスコープされた動的な権限が必要です。

静的な権限割り当て

トークンの有効期限が短い場合でも、権限範囲は静的で広すぎることが多い。

スケジュールのずれを監視する

エージェントの勤務スケジュールは予測不可能だ

年次アクセスレビュー

変化の激しい環境では、エージェントは頻繁に作成および変更される可能性がある。

一貫した行動を仮定する

エージェントは本質的に変動する

用語に関する注意:

各クラウドプロバイダーは、Bedrock Agents、Copilot Studioエージェント、AI Foundryプロジェクト、Vertex AIエージェントなど、さまざまなブランド名で複数の「エージェントのような」構成要素を提供しています。このガイドでは、「エージェント」を、IDに基づいてツールを自律的に起動したり、リソースにアクセスしたりできるAI駆動システムと定義します。具体的な製品名よりも、それが使用するIDモデルの方が重要です。

マルチクラウド環境の場合：

複数のIDモデルを同時に管理していることになります。以下の各プラットフォームセクションはそれぞれ独立していますが、クラウド全体にまたがるガバナンス上の課題は複雑化することを認識しておくことが重要です。

セクション3

各プラットフォームにおけるエージェントIDの仕組み

核心となる質問: このエージェントは誰ですか？

それぞれのクラウドは、そのアイデンティティ哲学に基づいて、この問いに異なる答えを出しています。具体的な内容に入る前に、まずは違いを理解するための統一的な枠組みをご紹介しましょう。

アイデンティティのスペクトル：所有権 → 委任 → 不透明性

すべてのエージェントアイデンティティモデルは、このスペクトル上のどこかに位置する。

役職

その意味

例:

所有権

あなたはすべてのアイデンティティコンポーネントを所有し、管理します

AWS

代表団

アイデンティティは文脈によって変化する

Azure

不透明度

プロバイダーが管理するランタイムであり、実行コンテキストへの顧客による検査/テレメトリは限定的である。

GCP

プラットフォームは、製品によって複数のポジションにまたがる場合があります（例：Copilot StudioとFoundry）。

これらのモデルはそれぞれ異なるものを最適化します。

所有権 顧客による制御を最大限に高め、爆発範囲の境界を明確にするが、規律あるIAMエンジニアリングが必要となる。
代表団 人間の責任（つまり、行動が発起者と結びつくこと）を向上させることができるが、アイデンティティの混在した状況を生み出し、コネクター／メーカーを通じた特権継承のリスクを高める。
不透明度 運用コストは削減されるが、検査と鑑識は制限される

各プラットフォームのアプローチを読む際には、この範囲を念頭に置いてください。

TL; DR

AWS：あなたのアカウント、あなたのアイデンティティ。

完全な制御とは、完全な責任を負うことを意味します。IAMロールをマッピングし、最小権限を徹底し、自分のミスを認めましょう。

ID管理チェックリスト

マップエージェント → 実行ロール → (該当する場合はツール関連ロール)
各役割の権限を確認する（最小権限の原則）
エージェントの履歴を追跡します。誰が作成したか、どのようなツールを使用しているか、そして（チャットベースのエージェントの場合）どのユーザーがそれを呼び出せるかなどを確認します。
権限境界（ポリシーの有無に関わらず、ロールが持つことができる最大権限を設定するIAMガードレール）を使用する
役割の想定に異常がないか監視します（予期しない時間帯、異常な頻度、見慣れない送信元IPアドレス、またはエージェントの想定範囲外のリソースへのアクセスなど）。

AWS：あなたのアカウント、あなたのアイデンティティ（BedrockおよびAgentCore）

AWSの理念

AWSはAIエージェントを他のワークロードと同様に扱います。 本人確認の実施はアカウントに基づいていますつまり、IAMロール、S3バケット、CloudWatchログなどはすべてお客様のアカウントに紐づいています。Bedrock自体はマネージドサービス（AWSがランタイムを運用）ですが、ID管理（ロール、ポリシー、監査ログなど）はお客様のアカウント内で管理されます。

AWSにおけるID管理は常にIAMです。エージェントのIDは、Lambda関数やEC2インスタンスと同様に、IAMロールです。IAMのセキュリティ対策を理解していれば、エージェントのIDを保護するための基礎が身につきます（ただし、エージェントには第2章で説明するような特有のリスクが伴います）。

これがBedrockエージェントにどのように適用されるか

AWS Bedrockは、AIエージェント構築のためのAmazonのマネージドサービスです。Bedrockエージェントを作成すると、AWSがアカウント内のすべてをプロビジョニングしますが、IDの構造を理解しておく必要があります。

すべての Bedrock エージェントは エージェント実行ロールエージェントが行動するために使用する主要なID。

エージェントにアクショングループ（エージェント用に構成するツールと機能）がある場合、各アクショングループにはIDに関する影響があります。

アクショングループの種類

アイデンティティの影響

ラムダ関数

Lambdaは、エージェントロールとは別の独自の実行ロールで実行されます。Lambdaは、IAMロールの下で、外部APIの呼び出し、AWSサービスへのアクセス、カスタムロジックの実行などを行うことができます。

コントロールを取り戻す

追加の役割はありません。アクションは呼び出し元のアプリケーションに制御を戻し、呼び出し元のアプリケーションは自身のIDで実行を処理します。

結果

1つのエージェントには、アクショングループの設定に応じて、複数のIAMロールが関与する場合があります。これには、エージェント実行ロールに加え、アクショングループによって呼び出されるLambda実行ロールやその他のサービスロールが含まれます。これらのロールはユーザーが作成および管理します。Bedrockが自動的に作成することはありません。

これがあなたに意味すること：

答えるべき重要な質問：

どのIAMロールがどのエージェントに属するのか？

主要な個人情報リスク：

エージェントが必要とする以上のアクセス権限を与える、過剰な特権を持つ役割。

IAMロールを作成するのはあなた自身なので、設定ミスがあった場合は責任を負います。最小限の権限から始め、正当な理由がある場合にのみ権限を拡張してください。

侵害された場合の影響：

エージェントが必要とする以上のアクセス権限を付与する、過剰な権限を持つロール。IAMロールは作成者が作成するため、誤った設定をした場合の責任は作成者にあります。最小限の権限から始め、正当な理由がある場合にのみ権限を拡張してください。

認証情報の盗難、過剰な権限付与、または意図しない動作を引き起こすプロンプト操作など、いずれの場合においても：

攻撃者は、エージェント実行ロールがアクセスできるすべてのもの（基盤モデル、S3バケット、ナレッジベース、さらにアクショングループが他のAWSサービス（Lambda関数、API Gatewayエンドポイントなど）を呼び出す場合の追加IAMロール）にアクセスできるようになります。

爆発範囲は、設定したIAM権限によって制限されます。

AWS には、AgentCore (コードファースト) も含まれています。

コードでエージェントを構築する開発者（BedrockのノーコードUIではない開発者）向けに、AWSはAgentCoreを提供しています。IDモデルはAWSの哲学と同じで、エージェントはIAMロールを使用しますが、重要な違いがあります。

コード優先のアイデンティティ定義： Bedrockのコンソールベースの設定とは異なり、AgentCoreのIDはインフラストラクチャ・アズ・コード（IaC）とデプロイメント構成によって定義されます。IAMロールは通常、アプリケーションマニフェストまたはIaCテンプレートで指定されるため、開発者は完全な制御権を持つことができますが、正しく設定する必要があります。

設定ミスのリスクが高い： IDがコードで定義されているため、AgentCoreには以下のようなリスクが高くなります。

アプリケーション設定にハードコードされた過剰な権限ロール
ソースコードに埋め込まれた認証情報
環境間（開発/ステージング/本番）で権限範囲に一貫性がない
誤ってバージョン管理システムにコミットされた認証情報（削除後もGitの履歴に残る）

開発者の責任: 適切な権限範囲の設定は主に開発チームの責任であり、Bedrockの管理型アプローチに比べてコンソールベースのガイダンスは少なくなっています。最小権限の設定をガイドするウィザードはありません。

Bedrockと同じIAM基盤を採用しているが、運用上のリスクは管理者による設定ミスから開発者による設定ミスへと移行する。

エージェントバージョン間のIDのずれ（AWS Bedrock）

岩盤を支える バージョンとエイリアス エージェントの場合、エイリアスを使用すると、トラフィックを異なるエージェントバージョンにルーティングできるため、段階的な展開やA/Bテストに役立ちます。ただし、これはIDガバナンスのリスクを生み出します。

バージョンによって内容が異なる場合があります。

実行役割
ガードレールの構成
権限範囲

リスク: セキュリティチームは、現在のバージョンには適切なガードレールが備わっているためエージェントは保護されていると考えているかもしれませんが、実際にはトラフィックがエイリアスを介して古い、制限の少ないバージョンにルーティングされている可能性があります。これはBedrock自体の脆弱性ではなく、ライフサイクルとガバナンス上のリスクですが、エージェントのセキュリティプログラムにおいて、バージョンとエイリアスを明示的に管理する必要があります。

TL; DR

Azure：複数のIDを1つのエージェントで管理。

柔軟な認証モデルは企業間の統合を可能にする一方で、責任の所在を曖昧にする。各コネクタがどの認証モードを使用しているかを把握しておく必要がある。

ID管理チェックリスト

各コネクタが使用する識別モードをマッピングします。
監査作成者の権限（専用サービスアカウントの検討を含む）
1つのエージェントで3つの監査証跡場所が生成される可能性があることに注意してください。
コネクタの所有者専用のアカウントを作成してください（個人アカウントではありません）。
コネクタ所有者のライフサイクルを計画する（所有者が退職した場合、どうなるのか？）

Azure/Microsoft: 企業の複雑性に対応する柔軟なID管理

マイクロソフトの哲学

Microsoft は、エンタープライズ環境が複雑であることを認識しています。コネクタごとに異なる認証が必要です。ユーザー認証が必要な場合もあれば、サービスアカウント認証が必要な場合、エージェントを構築した担当者認証が必要な場合もあります。Azure は、単一のモデルを強制するのではなく、 複数のアイデンティティモードを同時に.

この柔軟性によって強力な統合が可能になる一方で、複雑さも生じます。同じエージェントが、その動作に応じて異なるIDとして振る舞う可能性があるからです。

これがCopilot Studioにどのように適用されるか

Microsoftは、Copilot Studioアクションにおける2つの主要な認証モードについて説明しています。

認証モード

使用時

誰が「演技」しているのか

監査結果によると

ユーザ認証

アクセスを特定のユーザーに制限する必要がある場合

ユーザーがエージェントと話している

ユーザー

エージェント作成者認証

暗黙的または低リスクのアクセスの場合

メーカー

実際には、3つ目のアイデンティティアーティファクトも出現します。 代理店自身のサービス提供者 （ Entra ID （アプリケーションID）は、特定のAPI呼び出しに使用されます。つまり、単一のエージェントは、実行内容に応じて3つの異なるIDで監査エントリを生成できます。

フローの例: ユーザーはエージェントに依頼します 「弊社の販売パイプラインを要約して、私に通知してください」:

エージェントは、エージェント作成者の接続を使用してCRMにクエリを実行します。
エージェントサービスプリンシパルを使用してチームに概要を投稿します
ユーザーに委任された権限を使用してメールを送信します

3つの行動、3つのアイデンティティ、1つの会話。

これがあなたに意味すること：

答えるべき重要な質問：

各コネクタはどの認証モードを使用しますか？

主要な個人情報リスク：

エージェント作成者の認証情報を介した権限昇格。

コネクタを設定した作成者（つまり、コネクタをセットアップしたユーザー）に高い権限が付与されている場合、そのエージェントのすべてのユーザーは、そのコネクタを使用する操作に関して、その権限を継承します。

Microsoft は、アクセスを特定のユーザーに制限する必要がある場合はユーザー認証を推奨しています。エージェント作成者認証は、暗黙的または低リスクのアクセスシナリオに適しています。作成者認証情報を使用すると、データや機能が過剰に共有される可能性があります。

侵害された場合の影響：

認証情報の盗難、メーカーアカウントの侵害、またはプロンプトの操作のいずれであっても：

影響範囲は、使用されたIDモードと、エージェントに設定されたツール/アクセス範囲によって異なります。最悪の場合、作成者が管理者権限を持っているため、すべてのユーザーがそのコネクタに対して管理者権限を継承します。調査には、3つの異なる監査場所を関連付ける必要があります。

ID管理チェックリスト

各コネクタが使用する識別モードをマッピングします。
監査作成者の権限（専用サービスアカウントの検討を含む）
1つのエージェントで3つの監査証跡場所が生成される可能性があることに注意してください。
コネクタの所有者専用のアカウントを作成してください（個人アカウントではありません）。
コネクタ所有者のライフサイクルを計画する（所有者が退職した場合、どうなるのか？）

Azureには、Microsoft Foundry（旧称AI Foundry）も含まれています。

アイデンティティの動作はまだ進化段階にあるため、これはCopilot Studioとは別物として扱ってください。

Microsoft Foundryは、AIエージェントを構築するためのAzureのコードファーストプラットフォームであり、Copilot Studioのノーコードアプローチとは異なります。これは2つの形態で存在します。

Foundryの定番商品： オリジナルリリース
鋳造所（新）： 更新されたアイデンティティセマンティクスを備えた現在のイテレーション

アイデンティティの行動様式は、古典的なものと新しいもので異なる。 新しいFoundryでは、エージェントは明示的な エージェントID 身元確認のため。ただし、エージェントが公表されていない場合、身元は プロジェクト範囲 エージェント固有のものではなく。

アイデンティティのセマンティクスはまだ進化途上です。すべての実行パスが完全に調査されているわけではなく、動作はデプロイメントの状態、構成、およびFoundryのバージョンによって異なる場合があります。

TL; DR

GCP：管理の簡便性、可視性の制限

デフォルトのサービスアカウントの落とし穴を避けましょう。Googleのインフラストラクチャ内部を見ることはできないという事実を受け入れましょう。

ID管理チェックリスト

エージェントがデフォルトの推論エンジンサービスエージェントを使用していないことを確認してください。
パターンをチェックします: service-{PROJECT_NUMBER}@gcp-sa-aiplatform-re... (デフォルト)
本番環境のワークロードには、カスタムサービスアカウントを推奨します。
インフラストラクチャの可視性が限られていることを受け入れ、それを前提とした設計を行う。
コンプライアンスのためにサービスアカウントモデルを文書化する

GCP：マネージドインフラストラクチャ、設定可能なID

GCPの理念

GCPはシンプルさを追求しています。 Googleがインフラストラクチャを管理し、ユーザーはIDを設定する。.

実行環境は管理されており、不透明です。IAMはプロジェクトを通じて構成されていますが、基盤となるランタイムを検査することはできません。これにより運用上の負担は軽減されますが、可視性は制限されます。

GCPにおけるIDはサービスアカウントです。カスタムサービスアカウントを使用するか、Googleのデフォルトのサービスエージェントを使用するかを選択することで、分離レベルが決まります。

これがVertex AIエージェントエンジン（推論エンジン）にどのように適用されるか

エージェントをデプロイすると、IDは2つのレイヤーで機能します。

レイヤー1：Google管理サービスエージェント
Google はプロジェクト用に Reasoning Engine サービスエージェントを自動的に作成します。これは、デプロイされたエージェントが機能するために必要です。プロジェクト単位で管理され、Google が管理するため、これを回避することはできません。

レイヤー2：サービスアカウントの選択
エージェントの実際のリソースアクセスについては、以下を選択します。

オプション

それは何ですか

分離レベル

カスタムサービスアカウント

エージェント専用のSAを作成します

最高（生産向け推奨）

デフォルトのサービスエージェント

Googleが管理するプロジェクトSを使用する

低い（プロジェクト内のすべてのエージェントで共有）

クリティカル

カスタムサービスアカウントを明示的に設定しない場合、エージェントはデフォルトのサービスエージェントを使用します。このデフォルトのサービスエージェントは、プロジェクト内のすべてのエージェントで共有されます。つまり、1つのエージェントが侵害されると、すべてのエージェントが危険にさらされます。

これがあなたに意味すること：

IDの選択はデプロイ時に行われるため、カスタムSAは事前に構成しておく必要があります。
デフォルトのサービスエージェント = プロジェクト内のすべてのエージェントが 1 つの ID を共有する = 分離性が低い
カスタムサービスアカウント＝各エージェントが独自のIDを持つ＝優れた分離性
Googleが管理するインフラストラクチャに関する可視性が制限される（ログは表示されるが、ランタイムは表示されない）。

答えるべき重要な質問：

このエージェントはカスタムサービスアカウントを使用していますか、それともデフォルトのサービスエージェントを使用していますか？

主要な個人情報リスク：

デフォルトのSAは、デフォルトでBigQuery/ストレージへの広範なアクセス権限を持っています。複数のエージェントがSAを共有している場合、1つのエージェントが侵害されると、すべてのエージェントが侵害されます。

侵害された場合の影響：

認証情報の盗難、メーカーアカウントの侵害、またはプロンプトの操作のいずれであっても：

影響範囲は、使用されたIDモードと、エージェントに設定されたツール/アクセス範囲によって異なります。最悪の場合、作成者が管理者権限を持っているため、すべてのユーザーがそのコネクタに対して管理者権限を継承します。調査には、3つの異なる監査場所を関連付ける必要があります。

ID管理チェックリスト

エージェントがデフォルトの推論エンジンサービスエージェントを使用していないことを確認してください。
パターンをチェックします: service-{PROJECT_NUMBER}@gcp-sa-aiplatform-re... (デフォルト)
本番環境のワークロードには、カスタムサービスアカウントを推奨します。
インフラストラクチャの可視性が限られていることを受け入れ、それを前提とした設計を行う。
コンプライアンスのためにサービスアカウントモデルを文書化する

デフォルトのサービスエージェントを識別する方法

サービスアカウントの設定で、以下のパターンを探してください。

service-{PROJECT_NUMBER}@gcp-sa-aiplatform-re.iam.gserviceaccount.com

その -re 接尾辞は、推論エンジンのサービスエージェントを示します。これはGoogleが管理し、プロジェクトスコープであるため、カスタムサービスアカウントを設定しない限り、プロジェクト内のすべてのエージェントで共有されます。

プロトコルとオーケストレーションはアイデンティティリスクを増大させる

上記で説明したプラットフォーム固有のアイデンティティモデルに加え、いくつかの横断的なメカニズムが複雑さを増している。

MCP (モデルコンテキストプロトコル) エージェントがツールに接続する方法を標準化する
エージェント間（A2A）通信 — 他のエージェントを呼び出すエージェント
ワークフローオーケストレーション — 外部システムによって調整されるエージェントの行動の連鎖

重要なポイント: これらのメカニズムはツールへのアクセスを抽象化しますが、アイデンティティ、認可、または委任のセマンティクスを定義します。プロトコルは、 接続方法、ない 誰が権限を与えられているのか.

エージェントが他のエージェントを呼び出すとき、またはワークフローが複数のエージェントアクションを連鎖させるとき、IDの帰属は 推移的ユーザーがエージェントAを起動し、エージェントAがエージェントBを呼び出し、エージェントBがデータベースにアクセスします。監査証跡は断片化されます。データベースアクセスに記録されているのは、エージェントA、エージェントB、それとも元のユーザーの誰のIDでしょうか？

これは、各プラットフォームで既に述べたガバナンス上の課題をさらに複雑化させる。プロトコルはあくまでも基盤となるものであり、アイデンティティの問題を解決するものではない。

これはどこへ向かうのか

今日のエージェントはツールを使う。明日のエージェントはエージェントを創り出すだろう。

エージェントがサブエージェントを生成できる場合（各サブエージェントは独自のIDを持つ）、IDの拡散は再帰的になる。単一のユーザーリクエストが、3つのサブエージェントを作成するエージェントをトリガーする可能性があり、それぞれのサブエージェントは異なるIDで異なるシステムにアクセスし、そのサブエージェントの中にはさらに独自のサブエージェントを作成するものもあるかもしれない。

これはSFではありません。マルチエージェントオーケストレーションは、すでに大手企業で実用化されています。このガイドで概説したアイデンティティ管理の課題は、今後さらに深刻化するでしょう。

今のところは、上記の単一エージェントのアイデンティティモデルに焦点を当ててください。マルチエージェントガバナンスは次のフロンティアですが、まずは単一エージェントのアイデンティティ問題を解決しなければ、そこへ到達することはできません。

TL; DR

プレイブックの概要

左側でさらに詳しく説明するベストプラクティスの概要を以下に示します。

発見と在庫

認証情報と権限の管理

監視と対応

セクション4

アイデンティティのベストプラクティスプレイブック

以下のチェックリストは、上記のプラットフォーム固有のガイダンスを、実行可能な項目にまとめたものです。エージェントIDプログラムの出発点としてご活用ください。

発見と在庫

エージェントを確保する前に、まず現状を把握する必要があります。

プラットフォーム別カタログエージェント

本番環境だけでなく、開発/テスト/ステージング環境も含める

エージェントごとのマップサービスアカウント/役割

エージェント

プラットフォーム

主要なアイデンティティ

二次的なアイデンティティ

例:

AWS

エージェント実行ロールARN

ツール関連のロールARN（Lambda、API Gatewayなど）

例:

Azure

サービスプリンシパル

作成者認証情報、ユーザー委任

例:

GCP

サービスアカウントのメール

無し

文書の所有権

リスクレベル別に分類

リスクレベル

基準

レビューの頻度

ハイ

個人情報、財務データ、管理システムへのアクセス

毎週

技法

ビジネスデータ、内部システムへのアクセス

月額

ロー

読み取り専用、公開データ、サンドボックス

四半期単位

認証情報と権限の管理

短命なトークン

自動回転

最小権限のアクセス許可

安全な保管

監視と対応

集中ログ

重要：ログには実行内容が記録されますが、意図は記録されません。エージェントが何をしたかは分かりますが、なぜそれを実行したのかは分かりません。そのため、AI関連のインシデントに関する調査の深度が制限されます。

プラットフォーム

プライマリログソース

キャプチャする内容（有効になっている場合）

AWS

CloudWatch、CloudTrail

エージェントの呼び出し、IAMロールの引き受け、API呼び出し（設定されている場合）

Azure

Azure モニター、 Entra ID ログ

3つのIDコンテキストすべて、コネクタのアクティビティ（テレメトリ設定による）

GCP

クラウドロギング

サービスアカウントの使用状況、エージェントの実行状況（Googleが表示する情報に限定されます）

エージェント固有のアラート

アラートを作成する対象:

インシデント対応クイックリファレンス

注：これらのログは、ログ記録が有効になっている場合にエージェントのアクションを表示します。CloudTrail と Azure Monitor はエージェント固有の呼び出しを自動的に表示しないため、IAM/Entra のアクティビティとエージェント ID を関連付ける必要があります。

プラットフォーム

最初の対応

確認すべきログ（設定されている場合）

エスカレーション

AWS

エージェント実行ロールを取り消す

CloudWatch、CloudTrail（エージェントロールARNと関連付ける）

AWSサポート

Azure

Power Platform でエージェントを無効にする

3つの監査証跡すべて（エージェント、作成者、ユーザー）（それぞれ個別のクエリが必要になる場合があります）

マイクロソフトのサポート

GCP

SA権限を取り消す

クラウドログ記録（Googleが公開する情報に限定。実行時検査は行わない）

Googleサポート

セクション5

クイックリファレンス

プラットフォーム決定マトリックス

因子

AWS の基盤

Azure Copilo Studio

GCP 頂点 AI

アイデンティティモデル

シングル（IAMロール）

複数（2つのモード＋アーティファクト）

シングル（サービスアカウント）

複雑

技法

ハイ

ロー

透明性

フル

断片化して

限定的

管理

フル

一部

限定的

運用上の負担

ハイ

技法

ロー

以下のためにベスト

規制産業、完全な管理が必要

エンタープライズ統合、マイクロソフトのエコシステム

迅速な導入、管理された優先順位

各プラットフォームに期待できること

企業は通常、機能性、エコシステムとの適合性、使いやすさに基づいてエージェントプラットフォームを選択し、その後でIDセキュリティを管理します。プラットフォームの選択に応じて、ID管理はどのように行われるかを以下に示します。

AWS Bedrock を使用している場合:

Azure Copilot Studio を使用している場合:

GCP Vertex AI を使用している場合：

インシデント対応早見表

注意： 「エージェントの不正動作」は、それ自体が独自のインシデントカテゴリです。予測可能な障害が発生するサービスアカウントとは異なり、エージェントは、プロンプトの操作、モデルのずれ、または予期せぬ動作などによって、単なる侵害だけでなく、予期せぬ動作を起こす可能性があります。インシデント対応プロセスでは、この曖昧さを考慮に入れる必要があります。

AWS: エージェントが誤動作しています

すぐに： エージェント実行ロールを取り消す (aws iam delete-role-policy)
調査： エージェントのCloudWatchログ、IAMアクティビティのCloudTrail
含む： エージェントが呼び出すツール統合（Lambda関数、APIエンドポイント、その他のサービスなど）をすべて無効にします。
修復: 権限を確認し、最小権限で再デプロイする

Azure: エージェントの動作がおかしい

すぐに： Copilot Studioでエージェントを無効にする
調査： 3つの監査証跡すべてを確認してください。
- エージェントサービスプリンシパルログ
- メーカーアカウント監査ログ
- ユーザー委任ログ（呼び出しを行ったすべてのユーザーについて）
含む： コネクタを無効化し、必要に応じてメーカーの認証情報を取り消す。
修復: コネクタの識別モードを確認し、専用サービスアカウントを検討する。

GCP: エージェントが誤動作しています

すぐに： サービスアカウントの権限を取り消す
調査： クラウドログ記録（注：インフラストラクチャの可視性には制限があります）
含む： デフォルトの SA の場合、それを使用するすべてのエージェントに影響します。すべて無効にします。
修復: カスタムSAに切り替える（エージェントごとに1つ）

アイデンティティ固有の障害モード

上記で説明したプラットフォーム固有のリスクに加えて、エージェントIDに特有の障害モードがいくつかあります。

委任チェーンはユーザーの存続期間よりも長く続く： ユーザーが代理人に代理権を付与し、ユーザーが組織を退職した場合でも、委任は継続され、代理人は退職したユーザーの権限に基づいて業務を継続できる。

ワークフローエージェントがUIコントロールをバイパスする： ワークフロー自動化によって起動されたエージェントは、人間が行う承認フローをスキップする場合があります。UIがAPIでは行わない認証チェックを強制する場合、ワークフローによって起動されたエージェントは異なるルールに基づいて動作します。

エージェント間の権限継承： エージェントAはシステムXにアクセスできます。エージェントAはエージェントBを呼び出すことができます。この場合、エージェントBはシステムXにアクセスできるのでしょうか？答えは、プラットフォームや構成によって異なるID伝播に依存します。

バージョン/エイリアスのずれ (AWS Bedrock): エイリアスを介して古いバージョンのエージェントにルーティングされたトラフィックは、現在のバージョンとは異なる権限を持つ可能性があります。セキュリティ体制が知らず知らずのうちに低下する可能性があります。

これらは一般的なAIリスクではなく、個人を特定できるガバナンス上の欠陥であり、個人を特定できる制御が必要となる。

セクション6

用語解説

アクショングループ

(AWS) Bedrockエージェントが使用できるツール/アクションを定義する設定

エージェント作成者認証

（Azure）コネクタ作成者の資格情報を使用する際のマイクロソフトの用語

エージェント実行ロール

(AWS) Bedrockエージェントが実行時に引き受けるIAMロール

ブラスト半径

個人情報が侵害された場合に影響を受けるリソースの範囲

代理店サービス責任者

（Azure）エージェント自身の Entra ID アプリケーションID - 3番目のIDアーティファクトとして表示されます

ボンジョイント

（Azure）エージェントが外部サービスと連携できるようにする事前構築済みの統合機能

カスタムサービスアカウント

(GCP) ユーザーが作成したエージェント固有のサービスアカウント - 本番環境での使用を推奨

アイデンティティモード

アクションが認証されるコンテキスト（ユーザー、作成者、またはエージェント）

NHI

非人間型ID ― サービスアカウント、APIキー、および同様のマシンID

即時注入

細工された入力によってエージェントの動作を操作する攻撃

推論エンジンサービスエージェント

(GCP) Vertex AIエージェント用のGoogleマネージドサービスアカウント、プロジェクトスコープ

ユーザー認証

（Azure）呼び出し元のユーザーの委任されたアクセス許可を使用することを意味する、マイクロソフトの用語。

製品概要

AWS：あなたのアカウント、あなたのアイデンティティ。

完全な制御とは、完全な責任を負うことを意味します。IAMロールをマッピングし、最小権限を徹底し、自分のミスを認めましょう。

Azure：複数のIDを1つのエージェントで管理。

柔軟な認証モデルは企業間の統合を可能にする一方で、責任の所在を曖昧にする。各コネクタがどの認証モードを使用しているかを把握しておく必要がある。

GCP：管理の簡便性、可視性の制限

デフォルトのサービスアカウントの落とし穴を避けましょう。Googleのインフラストラクチャ内部を見ることはできないという事実を受け入れましょう。

共通点は、AIエージェントはサービスアカウントではないということだ。AIエージェントは適応性があり、予測不可能で、まさにスクリプトに従わないからこそ価値がある。従来のNHI（国民健康保険）管理は、予測可能な動作を前提としていた。しかし、その前提はもはや通用しない。

このガイドでは解決できないこと

このガイドでは、エージェントのID認証の仕組みについて説明します。ただし、より難しい問題、つまり、アクションが発生する前、つまり実行時に、ID認証をインラインで適用するという問題については説明していません。

クラウドプロバイダーは、プラットフォームの正確性を最優先に最適化しており、企業の責任体制については考慮していません。エージェントの識別情報を包括的に解決するのを待っていると、彼らの盲点を引き継ぐことになります。

次のステップは、実行時における強制適用です。つまり、プラットフォームを問わず、その場で本人確認を行い、状況に応じた適切な許可／拒否判断を下すということです。現状では、ほとんどの組織はこのようなアーキテクチャを備えていません。

それが今後の課題だ。

このガイドは、2026年1月時点のプラットフォームの機能に基づいています。クラウドプロバイダーは定期的にサービスを更新していますので、実装の詳細については最新のドキュメントをご確認ください。