要点

AI エージェントの ID 管理は、認証認可の部品ではなく統制基盤になり始めた

2025年後半から 2026年3月までに公開された Microsoft Entra Agent ID、Amazon Bedrock AgentCore Identity、Google Cloud Agent Identity、 MCP、A2A、Auth0、Okta、さらに Microsoft Purview、Google Cloud AI Protection、AWS の Policy / Guardrails、NVIDIA NeMo Guardrails を並べると、 AI エージェントは単なるサービス アカウントの言い換えではなくなりつつある。公開資料から読み取れるのは、エージェントを独立した権限主体として発行し、 必要に応じてユーザー委任の認可を重ね、その上にプロトコル上の認証メタデータと統制を載せる設計が、新しい比較軸になってきたという点である。

4方向

整理できる設計

エージェント固有の ID、ユーザー委任、プロトコル認証、統制レイヤーの4方向へ分けて見られる。

3形態

権限主体の持ち方

エージェント単独、ユーザー委任、エージェントとユーザーの併記が主要な形である。

36件

公開根拠

公式 docs と公式 announcement だけで、権限設計と統制の比較までできるだけの一次情報が揃っている。

1結論

ID 管理が実装責務を変える

今後は「どのトークンを使うか」より「誰の権限として動くか」を先に設計する必要がある。

なぜ重要か

サービス アカウントだけでは、エージェントの委任と責任分界を支えきれない

従来のアプリ ID やサービス アカウントでも API 呼び出しはできる。しかしエージェント運用では、それだけでは粗すぎる。 なぜなら、エージェントはバックグラウンド処理として自律的に動く一方で、ある場面では利用者同意に基づいて外部 SaaS や社内データへ触れ、 さらに MCP や A2A のように別の system や別の agent に動的接続しにいくからだ。ここで必要になるのは、「誰の権限で動いたのか」を 接続先サービスと監査ログの両方から追えること、そして権限の発行・交換・失効を prompt の約束事ではなく認証基盤で扱えることだ。

共有サービス アカウントは権限が粗くなりやすい

複数エージェントが同じ認証情報を使うと、最小権限と失効の単位が崩れやすい。エージェントごとに権限主体を分ける動きは、この問題への反応と読める。

ユーザー委任だけではエージェント側の責任主体が薄れる

ユーザー トークンだけを見せる構成では、どのエージェントが代行したのかが接続先サービスから見えにくい。AWS や Google の docs は、エージェントとユーザーを併記できる形へ寄っている。

動的接続では認証要件を事前に把握できることが重要になる

MCP や A2A のように接続先が増えるほど、相手がどの認証方式を要求するのかをメタデータで伝える必要がある。これは個別 integration の外側にある設計責務である。

4つの方向

公開情報を並べると、エージェント ID 管理は4方向に整理できる

1. エージェント固有の ID

  • エージェント自体に固有の権限主体を発行し、所有者、ライフサイクル、監査をひもづける方向である。
  • Microsoft Entra Agent ID、AWS AgentCore Identity、Google Cloud Agent Identity がこの層を明示的に扱っている。

2. ユーザー委任とツール接続

  • エージェントが利用者同意や管理された接続を通じてユーザー権限を借りる方向である。
  • Copilot Studio のアクション認証、AWS の 3LO と workload access token、Google の delegated OAuth、Auth0 の user-on-behalf 型がここに入る。

3. プロトコルレベルの認証認可

  • MCP と A2A は、接続先が必要とする認証条件をプロトコル上で事前に分かるようにする。
  • MCP の基礎認証、client credentials、enterprise-managed authorization、A2A の Agent Card / security scheme が代表例である。

4. 統制とライフサイクル管理

  • エージェントの所有者、公開範囲、認証方式、アクセス認定、影のエージェント検出、実行時の安全制御を扱う層である。
  • Microsoft Agent Registry、Google Cloud AI Protection、Microsoft Purview、Okta の discovery / certification に加え、NVIDIA NeMo Guardrails は実行時ガードレールの面でこの方向に近い。

プラットフォーム整理

各サービスを「誰の権限で動くか」で並べる

エージェント固有の ID

権限主体: エージェント単体

付与方法: エージェント作成時または配備時に専用 principal を発行

強制点: Entra policy、IAM、AgentCore directory、resource 側 role

代表サービス: Microsoft Entra Agent ID、Microsoft Agent 365、Amazon Bedrock AgentCore Identity、Google Cloud Agent Identity

ユーザー委任

権限主体: ユーザー、またはエージェントとユーザーの併記

付与方法: OAuth 同意、3LO、管理された接続、トークン交換

強制点: scope、接続ポリシー、管理された認証情報、接続先サービス側の同意確認

代表サービス: Copilot Studio のアクション認証、AWS supported auth patterns、Google delegated access、Auth0 の AI agent flows

プロトコル認証

権限主体: エージェント client、enterprise の認可ブローカー、または service identity

付与方法: OAuth メタデータ discovery、client credentials、enterprise-managed authorization

強制点: authorization server と対向 resource server

代表サービス: MCP Authorization、MCP OAuth Client Credentials、MCP Enterprise-Managed Authorization、A2A specification、Auth0 for MCP

統制レイヤー

権限主体: owner / sponsor がひもづく登録済みエージェント

付与方法: registry 登録、access review、secret / connection 管理、影のエージェント検出、runtime guardrail の適用

強制点: registry、directory、audit log、certification workflow、guardrail runtime

代表サービス: Microsoft Entra Agent Registry、Microsoft Purview、Google Cloud AI Protection、Okta の AI agent discovery / certification、NVIDIA NeMo Guardrails

権限付与の仕組み

対向サービスは、トークンの有無ではなく権限主体の文脈を見てアクセスを許可する

重要なのは、エージェントがトークンを持っていること自体ではない。対向サービスは、そのトークンが誰に発行され、どの同意や policy を経てきたのかを見てアクセス可否を決める。 ここでは、権限主体、認証情報の出所、対向サービスが検証するもの、制御点の4点で整理できる。

1. エージェント単独の権限

  • 権限主体: エージェント単体
  • 認証情報: エージェント用に発行された JWT、access token、workload identity
  • 対向サービス: issuer、audience、role、IAM policy を検証する
  • 制御点: role、policy、resource binding

バックグラウンド処理や範囲を絞った自動化には向くが、利用者文脈を必要とする操作にはそれだけでは足りない。

2. ユーザー委任の権限

  • 権限主体: ユーザー
  • 認証情報: OAuth 同意で得た user-scoped token、管理された接続
  • 対向サービス: ユーザーの scope、consent、app registration を検証する
  • 制御点: scope、delegated permission、connection policy

support や finance 系の SaaS 連携では自然だが、どのエージェントが代行したかを別途残さないと監査粒度が粗くなる。

3. エージェントとユーザーの併記

  • 権限主体: エージェントとユーザーの両方
  • 認証情報: token exchange、workload access token、委任フローの監査ログ
  • 対向サービス: ユーザー権限を見つつ、どの workload / agent から来たかも検証する
  • 制御点: scope と policy を二層で持つ

委任を保ちながら説明責任を失わないための形であり、各社 docs がこの方向へ寄っているのは実運用上かなり重要である。

4. 中央ブローカーと登録台帳

  • 権限主体: enterprise の control plane に登録されたエージェント client
  • 認証情報: enterprise-managed auth server や managed connection が発行
  • 対向サービス: broker が出した token と advertised metadata を検証する
  • 制御点: registry、authorization server、certification workflow

MCP の enterprise-managed authorization や identity vendor 側の統制機能は、認証情報の散在を減らしつつ失効と監査をまとめる方向と読める。NVIDIA NeMo Guardrails は broker そのものではないが、tool call と外部 system 連携の直前直後を検査する実行時制御点として、この層に隣接している。

プラットフォーム別の導入像

Microsoft Purview、Google / AWS、NVIDIA の統制レイヤーを並べると、ID 管理が実務の統制へつながる

エージェント ID だけでは、企業導入の全体像は説明しきれない。実際の導入では、ID 管理の上に「どのデータに触れてよいか」「どの対話を監査・保護するか」 「どのツール呼び出しを止めるか」を載せる必要がある。ここを見ると、Microsoft Purview、Google Cloud、AWS、NVIDIA はそれぞれ別の名前で近い役割を製品化し始めている。

Microsoft: Agent 365 + Entra Agent ID + Microsoft Purview

Microsoft 側では、Agent 365 と Entra Agent ID がエージェントの権限主体を持ち、Purview が grounding data、interaction、Microsoft 365 Copilot agents の統制を担う構図が見える。

  • 向いている用途: Microsoft 365 内の文書検索、要約、社内申請、Teams / SharePoint / OneDrive を横断する業務支援
  • 利点: エージェント単位の権限と、データ保護・監査・コンプライアンスを同じ tenant の中でつなげやすい

Google Cloud: Agent Identity + AI Protection + Model Armor

Google Cloud 側では、Agent Engine の agent identity に IAM を重ね、AI Protection、Model Armor、Agent Engine Threat Detection で資産の見える化と実行時保護を足す構図が見える。

  • 向いている用途: Cloud Storage や BigQuery を使う社内ナレッジ assistant、文書ベースの問い合わせ対応、RAG 型の業務支援
  • 利点: アクセス権、AI 資産 inventory、prompt / response の保護を Google Cloud 側でまとめて見やすい

AWS: AgentCore Identity + Policy + Bedrock Guardrails

AWS 側では、AgentCore Identity が権限主体を持ち、Policy が agent code の外側で tool access を制御し、Bedrock Guardrails と Organizations policy が入出力と組織横断の制約を担う構図が見える。

  • 向いている用途: 複数 step の業務自動化、社内運用 agent、複数 account や外部 tool をまたぐ承認付きワークフロー
  • 利点: 権限、ツール利用、guardrail を別層で強制できるため、agent code 側の自由度を上げても統制を外に残しやすい

NVIDIA: NeMo Guardrails + AI safety recipe

NVIDIA 側では、NeMo Guardrails が input / retrieval / dialog / execution / output の各 rail を持ち、特に agentic security と execution rails で tool call と外部 system 連携を検査・遮断する。AI safety recipe は、build / deploy / run の各段階で評価と方針適用を回す運用像を示している。

  • 向いている用途: open model を使う agent や、LangGraph などで外部 tool を多用する agent に実行時ガードレールを追加したいケース
  • 利点: agent 固有 ID の発行基盤がなくても、prompt injection、危険な tool 引数、off-policy な出力への防御線を外付けしやすい

読み方

名前は違っても、Microsoft Purview、Google Cloud AI Protection / Model Armor、AWS Policy / Guardrails、NVIDIA NeMo Guardrails は、「エージェント ID の上に統制をどう載せるか」という同じ設計課題に答えている。

  • 違いは、データ保護寄りに始めるか、AI 資産保護寄りに始めるか、ツール利用制御寄りに始めるか、実行時ガードレール寄りに始めるかである。
  • NVIDIA は Entra Agent ID や AgentCore Identity のような agent 固有 ID 発行面より、tool 利用時の安全制御と policy enforcement の面で比較に入る。
  • 共通点は、認証だけで導入を終わらせず、監査、失効、保護、発見を同じ運用面に置いていることだ。

具体例と利点

ID 管理の効果は、高権限の業務を狭く安全に切り出す場面ではっきり出る

M365

Microsoft 365 / Copilot 系 agent の社内アクセス

Microsoft 365 リソースや Copilot action を使うエージェントでは、agent ID を固有の権限主体として持ちつつ、 必要な action だけユーザー認証を重ねる構成が現実的である。利点は、バックグラウンド処理と利用者同意が必要な処理を同じエージェント内で分けて管理できることだ。

SaaS

support / finance 系 SaaS へのユーザー委任アクセス

CRM、ticketing、経費、請求のような system では、エージェントが利用者同意に基づいて限定 scope で API を呼ぶ形が向いている。 利点は、既存の権限モデルを保ったまま agent を導入しやすい点と、過剰権限の shared secret を避けやすい点である。

MCP

MCP / A2A で別 system や別 agent へ接続する

動的接続では、接続先がどの認証方式を要求するかをメタデータで配れることが重要になる。 利点は、client ごとの個別実装を減らし、enterprise 側で auth server や client credential policy を差し替えやすくなることだ。

Gov

影のエージェントと認証情報の散在を抑える

owner 不明のエージェント、散在する OAuth grant、長寿命 secret は、エージェント数が増えるほど管理不能になりやすい。 discovery、registry、access certification を先に置く利点は、エージェント導入を増やしても失効とレビューの単位を保ちやすいことである。

この方式の利点

権限主体をエージェント / ユーザー / ブローカーに分けて管理すると、最小権限、監査可能性、失効、委任の4点を同時に改善しやすい。 これは security のためだけでなく、運用チームがエージェントを増やせる速度そのものに効く。

導入設計

先に決めるべき論点は、モデル選定より権限主体の設計に近い

観測点

公開資料がそろって示しているのは、agent auth の本質が「認証方式の比較」ではなく「権限主体と管理責務の切り分け」にあるということだ。

  • エージェント主体、ユーザー主体、接続 owner を同一視しない。
  • 長寿命 secret を配るより、short-lived token、token exchange、managed connection を優先する。
  • 権限チェックは prompt や wrapper に埋めず、IdP、policy、resource server のどこで強制するかを明示する。
  • MCP / A2A の接続は、auth metadata と許可済み client の管理まで含めて設計する。
  • registry、discovery、certification を rollout の最後ではなく最初の統制基盤として扱う。

結論

認証方式そのものより、ID・委任・統制をどう束ねるかが比較軸になってきた

AI エージェントの認証認可の比較軸は、単に OAuth を使うかどうかではなくなっている。公開資料から読み取れる現在地は、 エージェントを独立した権限主体として持ち、必要に応じてユーザー委任とプロトコル認証を重ね、その上に registry、discovery、certification、データ保護、runtime guardrail を載せる方向である。 どの vendor が勝つかはまだ早いが、どの platform がエージェントを governable な identity として扱えるかは、すでに明確な選定軸になり始めている。