Auth0 for AI Agentsの新機能5つの提供状況と本番運用：SLA・レート制限・他社比較【2026年11月】

Oktaは2026年5月21日、Auth0 for AI Agentsに5つの機能を追加すると発表しました。Auth for MCP、On-Behalf-Of（OBO）Token Exchange、Agent as Principal、Token Vault with Organizations Support、FGA Permissions Indexです。発表時点で一般提供（GA）だったのは2つだけで、残る3つは「6月上旬予定」やDeveloper Previewでした。本記事では、Auth0のchangelogとdocsで各機能のその後を追い、2026年11月時点の提供段階を整理します。あわせて、本番に載せる前に確かめる稼働率SLA・レート制限・ログの範囲、他のAI向けID基盤との違い、既存の認証からの移行順も扱います。製品全体の仕組みや料金、CIBAによる承認フローはAuth0 for AI Agentsの機能と料金の解説にまとめています。

まとめ：5機能の提供段階と本番運用で確かめること

• 本番で使えるGA機能は3つです。Auth for MCPとOBOトークン交換は2026年5月6日、Token Vaultの組織対応は5月28日にGAになりました。10月から11月13日までの間に、5機能の提供段階は変わっていません
• Agent as Principalは7月30日にEarly Access、FGA Permissions Indexは9月18日にEarly Accessへ進みました。どちらもGAではありません
• 稼働率SLAは「中核サービスの月間平均99.99%」で、対象はEnterpriseのPublic CloudとPrivate Cloudです。下回った月は月額料金の5〜20%がクレジットになります
• Auth0のテナントログに残るのはトークンの発行・交換までです。エージェントが下流APIで何をしたかは、API側でトークンの sub・act から得た主体と、業務操作の内容・リクエストIDを記録しない限り追えません
• 監査証跡が目的ならAgent as Principal、MCPサーバーから自社APIへの最小権限委譲ならOBO、顧客組織ごとの外部トークン分離ならToken Vaultの組織対応を当てます。監査や認可の要になる経路は、GAの機能で組みます

発表の背景：Oktaが挙げたエージェント本番化の3つの障壁

Oktaの発表文は、PwCが2025年4月に米国の経営幹部約300人へ行った調査を引き、エージェントを導入・試行している企業がおよそ8割あるのに対し、「完全で安定した実装」まで進んだのは約3分の1にとどまるとしています。本番化を妨げる障壁としてOktaが挙げたのは、エージェントに固有のIDがなく従業員の操作と区別して監査できないこと、共有シークレットや権限の強すぎるサービスアカウントで接続するしかないこと、権限判定のたびに遅いAPI呼び出しが挟まり認可がスケールしないことの3点です。1つ目にはAgent as Principal、2つ目にはAuth for MCPとOBOトークン交換、3つ目にはFGA Permissions IndexとToken Vaultの組織対応を当てる、という構成です。

Auth for MCPとOBOトークン交換：MCPサーバーから下流APIへの最小権限委譲

Auth for MCPのGAに含まれる4つの構成要素

2026年5月6日のchangelogによると、Auth for MCPは単一の機能ではなく、次の4つを組み合わせた製品機能としてGAになりました。

• Client ID Metadata（CIMD）Registration：MCPクライアントが自分のメタデータ文書をURLで公開し、テナント管理者がそのURLを登録します。Auth0がメタデータを取得・検証し、管理者が確認してからクライアントが作られるため、想定外のクライアント登録を防げます
• On-Behalf-Of Token Exchange：MCPサーバーが受け取ったユーザーのトークンを、下流API用のトークンに交換します
• Resource Parameter Compatibility Mode：MCP仕様は接続先を resource パラメータで示しますが、Auth0が従来APIの指定に使ってきたのは audience です。この差を吸収するモードです
• Enhanced Security Controls for Third-Party Applications：外部の開発者やエージェントが登録するサードパーティアプリに、安全側の既定設定を適用します

Auth for MCPのdocsは、OAuth 2.1とOpenID ConnectでMCP仕様の認可部分を実装できるとしており、ユーザーはOkta、Entra ID、Ping、Google Workspaceなど既存のIdPでログインします。CIMDの仕様と各社の対応状況はCIMD（Client ID Metadata Documents）の仕組みと実装、MCP自体の構成はMCP（Model Context Protocol）の仕組みの解説を参照してください。

OBOトークン交換のリクエストとactクレームによる委譲の記録

OBOトークン交換はRFC 8693のトークン交換を使います。MCPサーバーなどの中間サービスが、ユーザーから受け取ったトークン（subject_token）を /oauth/token に渡し、下流APIをaudienceとする新しいトークンを受け取ります。OBO Token Exchangeの公式ドキュメントにあるリクエストは次のとおりです。

curl --location 'https://YOUR_DOMAIN.us.auth0.com/oauth/token' \
  --header 'Content-Type: application/json' \
  --data '{
    "client_id": "YOUR_CLIENT_ID",
    "client_secret": "YOUR_CLIENT_SECRET",
    "subject_token": "AUTH0_SUBJECT_TOKEN",
    "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
    "subject_token_type": "urn:ietf:params:oauth:token-type:access_token",
    "requested_token_type": "urn:ietf:params:oauth:token-type:access_token",
    "audience": "https://downstream-api.example.com"
  }'

交換後のトークンは、sub が元のユーザーのまま、aud が下流APIに変わり、act クレームに交換を行ったサービスが入ります。さらに下流へ交換を重ねると、act が入れ子になって呼び出しの連鎖が残ります。

{
  "sub": "auth0|user123",
  "aud": "https://first-party-api.example.com",
  "azp": "mcp_server_client_id",
  "act": {
    "sub": "mcp_server_client_id",
    "act": { "sub": "spa_client_id" }
  }
}

サービスアカウントで下流APIを呼ぶと、誰の依頼だったかはトークンから消えます。OBOでは下流APIがユーザー本人の権限で判定でき、返るスコープもユーザーのRBACに従います。共有シークレットを渡さずに済み、操作がユーザーと結び付いたまま残る点が、発表文の言う「被害範囲の最小化」の中身です。

OBOを有効にする設定と、委譲の深さ・レート制限の上限

OBOは中間サービス側のCustom API Clientで有効にします。クライアントのapp_typeはresource_serverとし、resource_server_identifierを受信トークンのaudienceに一致させます。下流APIの識別子を設定する欄ではありません。別途、中間サービスのCustom API Clientから下流APIへのUser-Delegated Accessを許可し、必要な権限を持つclient grantを作成します。ダッシュボードでは Applications の対象クライアントで Token Exchange の On-Behalf-Of Token Exchange をオンにし、Management APIなら次の値をPATCHします。

PATCH /api/v2/clients/{clientId}
{
  "token_exchange": {
    "allow_any_profile_of_type": ["on_behalf_of_token_exchange"]
  }
}

設計で気を付ける上限は2つです。

• 委譲の連鎖は5段までです。交換のたびに1段増えるため、subject_tokenの act がすでに4段ある状態で交換すると400エラー（invalid_request）になります。エージェントがサブエージェントへ何段も委譲する構成では、段数を先に数えておきます
• OBOトークン交換には専用のレート制限があり、Essentials・Professionalでは毎秒8件です。プラン別の値は後の「レート制限」の節で比べます。docsは、トークンを有効期限まで使い回し、API呼び出しのたびに交換しないよう求めています

Agent as Principal：エージェント固有IDとトークン発行の監査

Agent as Principalの登録・クライアント関連付け・トークン発行

Agent as Principalは、AIエージェントを人間のユーザーとも従来のM2Mクライアントとも別の主体として登録する機能です。docsでは次の3段階で動きます。

1. エージェントを登録する（POST /api/v2/agents またはダッシュボード）。生涯変わらない agent_id が払い出されます
2. エージェントをクライアントに関連付ける。エージェント自身は資格情報を持たず、関連付けたクライアントを通じて認証します。1つのエージェントを環境別・リージョン別の複数クライアントに結び付けられます
3. 関連付けたクライアントが発行を受けるトークンに、エージェントのIDが埋め込まれる

エージェントのIDがトークンのどこに入るかは、グラントの種類で変わります。

Auth0はIETFのドラフト「OAuth Actor Profile for Delegation」に沿って、sub_profile と client_profile の2つのクレームを追加しました。値は user、ai_agent、service、browser_app、native_app で、受け取ったAPIは主体が人かエージェントかをトークンから判定できます。ただし client_profile には、Client Credentialsの例の service ai_agent のように空白区切りで複数の値が入ります。文字列の完全一致ではなく、値を分割して判定します。社内で別のレジストリやMCPサーバーにエージェントのIDがすでにある場合は、external_agent_id としてそのIDを持ち込めます。

agent_idによるテナントログ検索とトークン発行の追跡

トークン発行のたびに、agent_id（設定していれば external_agent_id も）がテナントログに書き込まれます。記録の対象は、エージェントに関連付けたクライアントのclient_credentials・refresh_token・標準ログインと、OBOトークン交換です。エージェント単位の監査や異常検知は、Management APIのログ検索で行います。

GET /api/v2/logs?q=agent_id:agt_72jbvv7LfRKYp59gtRLtkn

Auth0 Actionsでは event.agent でエージェントの情報を参照でき、トークン発行時にエージェント別の追加判定を書けます。エージェントを含む機械IDの棚卸しや失効の考え方はノンヒューマンアイデンティティ（NHI）の管理と守り方で扱っています。

Agent as Principal有効化前の下流APIのクレーム互換性

既存のクライアントは、明示的にエージェントへ関連付けない限り動作が変わりません。関連付けはオプトインで、元に戻せます。sub_profile と client_profile を受け取るには、対象のリソースサーバーごとに agent_subject_claims: 'auth0-v1' を設定します。

注意が必要なのはClient Credentialsの場合です。sub がクライアントIDからエージェントのIDに変わるため、sub の形式を検証・解析している下流サービスは、有効化の前に改修が要ります。docsもこの点を明記しています。また、エージェントに関連付けたクライアントでは jwt_bearer グラントを使えません。

提供段階はEarly Accessです。2026年7月30日のchangelogは、Auth0のアカウントチームに連絡して有効化するよう案内しています。Agent as Principalの公式ドキュメントの提供段階の注記には、Oktaの基本契約（MSA）の無償トライアル条項に同意して使う旨が書かれています。本番利用の可否は、申請時にアカウントチームへ確認します。監査要件の厳しい本番経路を、この機能だけに頼る段階ではありません。

Token Vaultの組織対応：マルチテナントSaaSの顧客別トークン分離

Token Vaultは、Google・Slack・GitHubなどサードパーティAPIのトークンの取得・保管・更新をAuth0が代行する機能です。エージェントのコードにAPIキーを置かずに外部サービスを呼べます。2026年5月28日にGAになった組織対応では、Token Vaultの交換とConnected Accountsフローが org_id を最初から最後まで引き継ぎます。トークンは（ユーザー, org_id）の組で保存されるため、同じユーザーが複数の顧客組織に所属していても、組織ごとに別のトークンになります。

B2B SaaSで、1人の担当者が顧客A社とB社の両方のワークスペースにエージェントをつなぐ場合を考えます。組織対応がないと、A社の文脈で動くエージェントがB社のSlackトークンを使えてしまう設計になりかねません。org_id 付きの交換ではこれが既定で分離されます。org_id クレームを持たない交換は従来どおり動くため、Auth0 Organizationsを使っていない既存の実装は影響を受けません。

FGA Permissions Index：RAG検索用の権限フィルタの事前計算

Permissions Indexの権限展開と自社DBへの同期

Auth0 FGAは関係ベース（ReBAC）の認可サービスです。「このユーザーはこの文書を見られるか」を判定するには、ユーザー・チーム・組織・文書の関係グラフをたどる必要があります。RAGや社内検索のように数百万件の候補から閲覧可能なものだけを絞り込む場面では、このグラフ探索が問い合わせのたびに走ることがボトルネックになります。

Permissions Indexは、検索に使う関係（例：can_view）を指定してインデックス化します。関係タプルが書き込まれたときに、その関係から導かれるすべてのアクセス権を計算し、ユーザーとオブジェクトの直接の対応として展開します。docsが提供している「colocated」方式では、展開結果の変化がINSERT・DELETEとして顧客側に流れてくるため、自社DBのアプリデータの隣に保存します。問い合わせ時は業務データとのSQL JOINで済み、FGAへのネットワーク呼び出しは要りません。FGA Permissions Indexの公式ドキュメントは、これをマテリアライズドビューと同じ考え方だと説明しています。FGAが管理する「hosted」方式は、今後提供予定とされています。

結果整合性と未対応のモデル機能：Permissions Indexを使わない場面

Permissions Indexは結果整合性を前提に設計されています。タプルを書き込んでからインデックスに反映されるまで短い遅れがあり、docsは「15秒前までの鮮度なら使う」といった許容範囲をアプリ側で決めるよう求めています。権限を外した直後の判定は、インデックスではなくCheckかListObjectsをHIGHER_CONSISTENCYモードで呼びます。ただしFGAの整合性モードの説明によると、このモードはキャッシュを使わないだけで、リージョン間の複製遅延の影響は残り得ます。退職者のアクセス停止のように確実に止める必要がある操作は、アプリ側にも拒否の仕組みを持たせます。

モデル側にも制約があります。conditions、contextual tuples、but notの左辺のワイルドカードは、インデックス対象の経路に入れられません。タプルの書き込みは単一のプライマリリージョンに寄せたほうが安定する、ともdocsにあります。利用条件は、無料トライアルでは不可、Enterprise契約で1インデックスと1,000万expansionまでが含まれ、超える分はEnterprise向けアドオンです。属性条件（ABAC的な条件）で権限を決めているモデルや、Enterprise以外の契約では、まずFGAの通常のCheck・ListObjectsで足りるかを測るほうが先です。

5機能の後に追加されたエージェント向け機能（2026年7〜11月）

5月の発表以降も、エージェント向けの機能はchangelogで段階的に追加されています。5機能と組み合わせて使う前提のものが多く、いずれもEarly Accessです。

本番の設計に影響が大きいのはCIMDの動的登録です。5月のAuth for MCPのGAに含まれたCIMD登録は、管理者がメタデータURLを登録・承認してからクライアントが作られる方式でした。10月22日の動的登録では、認可フローの開始時にAuth0がメタデータ文書を取得・検証し、その場でクライアントを登録します。不特定多数のMCPクライアントを受け入れるSaaSでは事前登録の手間がなくなる一方、承認を挟まずにクライアントが増えます。同日にEarly AccessとなったApplication Profilesは、動的登録されたクライアント全体に、リフレッシュトークンの有効期限やDPoPなどの既定値を1か所で適用する機能です。Early Accessの段階ではプロファイルはテナントに1つだけで、適用されるのは動的登録されたCIMDクライアントに限られます。管理者が手動で登録したCIMDクライアントやDCRのクライアントには当たりません。動的登録を使うなら、Application Profilesで既定値を先に決めておきます。

Cross App Access Requesting Appは、エンタープライズIdPの信頼関係を使い、ユーザーに「アカウントを接続」を押させずに外部APIのトークンを取得する機能です。Token Vaultの上に作られ、ID-JAG（Identity Assertion Authorization Grant）を使います。対応する接続はOIDCとOkta Workforceです。仕組みとOkta側の設定はOkta Cross App Access（XAA）の解説で扱っています。Auth for UCPは、AIエージェントが利用者の代わりに商品を購入するUniversal Commerce Protocolのサーバーを保護する機能で、Geminiなどのエージェントと事業者のアカウントを連携させる用途です。Auth for UCPのdocsによると、UCPのリソースサーバーに設定できるAPIはテナントに1つで、Auth0 Organizationsには対応していません。

CIMDの動的登録とXAA Requesting Appのchangelogは、Early Accessの利用中はOktaの基本契約（MSA）の無償トライアル条項に同意したものとみなす、と明記しています。Agent as Principalと同じ条件です。

本番運用の前提：稼働率SLA・レート制限・ログの範囲

稼働率SLA 99.99%の対象はEnterpriseの本番利用

Auth0のService Level Agreementsの説明ページは、Auth0プラットフォームの「特定の中核サービス」の月間平均の可用性を99.99%以上としています。このページの対象は、EnterpriseのPublic CloudとPrivate Cloudです。30日の月で換算すると、許容される停止は約4.3分です。下回った月のクレジットは次のとおりで、事象から5営業日以内に請求します。

どのサービスが「中核サービス」に入るかは、このページには列挙されていません。Token VaultやCIBAのようなAI向け機能が対象に含まれるかは、契約時に確認します。現在と過去の稼働状況はAuth0 Status Pageで、Public Cloudの分を公開しています。このページはFree・Essentials・Professionalのプランに触れていないため、セルフサービスのプランで稼働率の保証を前提にはできません。エージェントの認可がAuth0の停止で止まると業務が止まる構成なら、Enterprise契約を前提に見積もります。

提供段階でもサポートの扱いが違います。Auth0のリリース段階の定義では、GAは契約に従ってサポートされ、Early Accessは本番でも使えるもののGAまでに小さな変更があり得る、としています。Betaは本番利用をサポートしません。

レート制限：プランで4倍以上違う認証APIの上限

トークンの発行・交換はすべてAuthentication APIの /oauth/token を通るため、API全体の上限とエンドポイント別の上限の両方がかかります。プラン別のレート制限の設定値は次のとおりです。

Enterpriseは有料アドオンのPublic Performance Burstで、月48時間まで毎秒200・300・400件に引き上げられます。OBOの上限は、Auth0 for AI Agentsのアドオンを購入すると契約の認証API上限まで広がります。CIBAの /bc-authorize は、EssentialsからEnterpriseまでIPアドレスあたり毎分500件です。上限を超えるとHTTP 429が返り、x-ratelimit-limit・x-ratelimit-remaining・x-ratelimit-reset ヘッダーで残りと回復時刻がわかります。Private Cloudでは環境全体の上限を超えるとSLAが無効になる、とポリシーに明記されています。

API呼び出しのたびにトークンを取り直す構成では、トークン交換のレート制限がボトルネックになります。Essentials・ProfessionalのOBO上限は毎秒8件なので、ツール呼び出しのたびに交換する作りでは、数体のエージェントが並行するだけで429が返り始めます。取得したトークンは、ユーザー・組織・呼び先API・スコープ・委譲元を混同しないキャッシュで有効期限まで再利用し、期限切れ前に必要に応じて再取得します。429では x-ratelimit-reset まで待って再試行します。

Auth0の認証ログと下流APIの業務操作ログの記録範囲

Auth0のテナントログが記録するのは、ログイン、トークンの発行と交換、Token Vaultの交換の成否といった認証・認可の出来事です。エージェントが受け取ったトークンで下流APIを呼び、何を読み書きしたかは記録されません。Agent as Principalの agent_id も、トークン発行時にテナントログへ書かれる値です。「どのユーザーの依頼で、どのエージェントが、何をしたか」をつなぐには、下流APIの側で、検証済みのアクセストークンからユーザーとエージェントのIDを取り出し、業務操作の内容とリクエストIDとともに記録します。トークン内のエージェントIDは agent_id というクレームではなく、グラントに応じて sub か act.sub に入ります（external_agent_id を設定していればその値）。

テナントログの保持期間はプランで決まります。Starterは1日、Essentialsは5日、Professionalは10日、Enterpriseは30日です。監査で数か月から数年の保存が要る場合は、ログストリーミングで外部のSIEMやストレージへ送ります。docsはテナントログがリアルタイムでなく、索引に遅れが出ることがあるとしています。異常検知をテナントログの検索だけに頼る設計は避けます。

Auth for MCPの公開導入事例

Auth0は、Auth for MCPを本番で使う顧客の事例を公開しています。Common Roomの事例では、自社のMCPサーバーを顧客に開放するためにAuth0を使い、動的クライアント登録で10万件以上のクライアントを登録しているとしています。Strike Graphの事例は、コンプライアンスデータをAIエージェントで問い合わせるサービスで、Auth for MCPとCustom Token Exchangeを使ってMCPサーバーのトークン交換を数時間で動かしたと書いています。どちらもAuth0が公開するベンダー事例で、第三者の検証を経た数値ではありません。

エージェントの動き方別に選ぶ認可パターン

5つの機能は重なる部分があり、どれを使うかで迷いやすい構成です。判断の軸は「ユーザーがその場にいるか」と「呼び先が自社APIかサードパーティか」の2つです。

表のうちEarly Accessなのは、Agent as PrincipalとPrivileged Workerの2つだけです。ユーザー不在の処理でも、Client Credentialsやリフレッシュトークン交換はGAで使えます。判断の分かれ目は同席の有無より、ユーザーの権限を委譲して動く処理か、エージェント自身の権限で動く処理かです。前者はOBOかToken Vault、後者はClient Credentialsを使います。エージェント自身の権限で動く自律エージェントは、当面エージェントごとにクライアントを分け、監査ログをクライアントIDで区別します。Agent as PrincipalがGAになった時点で関連付けを追加すれば、クライアントを作り直さずに移行できます。関連付けがオプトインで既存クライアントに影響しないためです。

逆に、MCPサーバーに共有のAPIキーやサービスアカウント1つで外部APIを呼ばせる構成は、5つの機能のどれにも乗りません。発表が解消しようとした「スーパーキー」そのものなので、新規のエージェント開発では採らないことを勧めます。社員向けSaaS間のエージェント連携をIdP側で一元管理したい場合は、Auth0側のアプリ対応も含め、OktaをIdPとするOkta Cross App Access（XAA）が対象です。

他のAI向けID基盤との比較：WorkOS・Descope・Stytch・Clerk

MCPサーバーをOAuthで保護する機能は、2026年11月時点で主要なID基盤のほとんどが持っています。差が出るのは、外部サービスのトークンを代わりに保管する仕組み、実行前の承認、細かい認可、既存のユーザー基盤を残せるかの4点です。各社の公式ページの記載を並べます（「記載なし」はその公式ページで確認できなかったという意味で、機能が無いという断定ではありません）。

• WorkOS：MCP Authのページは、AuthKitをMCP仕様に沿ったOAuth 2.1の認可サーバーとして使えるとしています。既存のユーザーとログインを残したまま、WorkOS ConnectをMCPのOAuthフローだけを担うミドルウェアとして置けるのが特徴です。外部サービスのトークンはPipesが担い、ユーザーがOAuthで接続したリフレッシュトークンをWorkOS側に保管して、アプリは getAccessToken() で有効なアクセストークンを受け取ります。2026年11月10日の変更履歴では、WorkOS ConnectがRFC 8693のトークン交換に対応し、別のリソース向けにスコープを絞ったトークンへ交換できるようになりました。Auth0のOBOに近い機能です。FGAと監査ログも製品群にあります。製品の全体像はWorkOSの解説で扱っています
• Descope：Agentic Identity Hubは、エージェントが接続するAPIやMCPサーバーを「Resource」、エージェントがユーザーやテナントの代わりに使う外部トークンの保管庫を「Connection」と呼び分けます。エージェントの資格情報はクライアント登録のほか、DCR・CIMD、AWSやGCPのワークロードのOIDCトークンから得られます。MCP Authのページは、既存の自社製・他社製のユーザー認証を変えずにMCPの認可だけを担えるとしています。2026年10月15日発表の3.0では、ID-JAGの発行が加わりました
• Stytch：Connected Appsは、OAuth 2.1・DCR・CIMDに対応し、既存のCIAMが発行したJWTをそのまま使えるとしています。高リスクの操作にはデバイス認可フローで人の承認を挟めます。2025年9月9日の変更履歴でGAと明記されています。料金は月間アクティブユーザー1万人まで無料で、Connected Apps単独の課金区分はありません
• Clerk：MCPの概要ページは、CIMD、DCRを要するクライアント向けの動的登録、OAuthの同意画面、SDKでMCPに対応するとしています。CIMDは2026年9月に全アプリ向けにGAになりました。Clerkでログインを組んだアプリにMCPサーバーを足す用途です。Auth0との選び分けはClerk認証の解説を参照してください

選び方は、どこまでを1つの基盤でそろえたいかで分かれます。既存の認証を残してMCPサーバーにOAuthを足すだけなら、WorkOS Connect・Descope・Stytch Connected Appsのように既存基盤の前に置ける製品が手軽です。外部SaaSのトークン保管・実行前の承認（CIBA）・FGA・顧客組織ごとの分離までをそろえ、EnterpriseのSLAも求めるなら、Auth0 for AI Agentsを選びます。Auth0の場合もユーザーストアの移行は必須ではなく、既存IdPのトークンをCustom Token ExchangeでAuth0のトークンに交換してToken Vaultを使う構成を、Auth0のdocsが用意しています（次章）。従業員向けのIdPとしてOktaを使っている場合の考え方はAuth0とOktaの違いにまとめています。

既存の認証からの移行：自前の認証基盤と静的APIキー

自前の認証基盤からの移行：移さない方法と移す2つの方法

OBOもToken VaultもAgent as Principalも、Auth0が発行したトークンを起点に動きます。自前のユーザーDBやIdPで認証しているサービスにエージェントを足す道は2つです。1つは既存IdPで認証を続け、そのトークンをCustom Token Exchange（RFC 8693）でAuth0のトークンに交換する方法です。ユーザー移行なしでToken Vaultを使う手順では、交換時にAuth0側へ軽量なシャドウプロファイルを作り、そこに外部アカウントを接続します。docsはこれを暫定策と位置づけ、ID-JAG（Cross App Access）による標準の方法を今後提供するとしています。もう1つはAuth0で認証する方法で、カスタムデータベース接続で既存DBを照会し続けるか、ユーザーをAuth0のユーザーストアへ移します。自前DBを将来畳むなら、移し方は次の2つです。

• 自動移行（lazy migration）：カスタムデータベース接続の設定で「Import Users to Auth0」をオンにすると、ユーザーが初めてログインしたときに既存DBで照合し、成功したら、そのとき入力されたIDとパスワードでAuth0側にユーザーを作成します。パスワードの再設定は要りません。自動移行の手順のとおり、ログインしないユーザーは移りません。残りを一括インポートで移すときは、移行済みのユーザーを除いて投入します。docsは、自動移行の後に一括インポートを重ねると DUPLICATED_USER エラーが起き得るとしています
• 一括インポート：Management APIの POST /api/v2/jobs/users-imports にJSONを渡します。一括インポートの制限は、1ファイル500KB（目安は1,000ユーザー程度）、テナントあたり同時2ジョブ、1ジョブ2時間でタイムアウトです。対応外のアルゴリズムでハッシュしたパスワードは移せず、該当ユーザーは初回ログイン時に再設定が必要です

エージェント対応を急ぐなら、自動移行で始めます。ログインのたびに移るので、エージェントを使うアクティブなユーザーから順にAuth0側のトークンを持つ状態になります。既存DBのハッシュ方式の確認や移行期間中の二重運用の設計から外部に任せたい場合は、認証基盤・ID管理システム開発の支援内容も参考にしてください。

静的APIキーをToken Vaultへ置き換える順番

エージェントのコードや環境変数に置いたGoogle・Slack・GitHubなどのAPIキーは、ユーザーがログインしている間に動く処理から置き換えます。Token VaultはConnected Accountsでユーザーの外部アカウントを接続し、トークンの保管と更新をAuth0が代行するため、ユーザー同席の処理はGAの機能だけで移せます。移行前の確認事項は2つです。Token Vaultの設定手順では、使うクライアントがファーストパーティ・Confidential・OIDC準拠の3条件を満たす必要があります。またリフレッシュトークン交換はリフレッシュトークンのローテーションに対応していないため、ローテーションはオフにします。

設計が分かれるのは、ユーザーがログインしていない時間帯に動くエージェントです。GAの機能では、アプリが保持したAuth0のリフレッシュトークンをsubject_tokenとして渡す「リフレッシュトークン交換」で、ユーザーの再ログインなしに外部サービスのアクセストークンを取得できます。この方式ではユーザーごとのリフレッシュトークンをエージェント側で安全に保管する必要があります。それを避けたい場合の選択肢が、2026年7月30日にEarly Accessとなった Token Vault Privileged Worker です。Private Key JWTかmTLSで認証する信頼済みワーカーが、ユーザーセッションなしで特定ユーザーの外部トークンを取得できます。ワーカーの資格情報は接続先とスコープに固定でき、漏えいしても届く範囲を限定できます。夜間バッチやCIで動くエージェントは、当面はリフレッシュトークン交換で組み、Privileged WorkerのGA後に切り替えるかを判断します。料金プランごとのToken Vault接続数の違いはAuth0の料金の解説を確認してください。

発表文が挙げた業界別の利用場面と対応する機能

発表文は金融・医療・小売・法務の4業種を例に挙げています。どの機能を当てるかは発表文に書かれていないため、次の表の「対応する機能」は本記事の整理です。

銀行の決済は「どのユーザーの依頼で、どのエージェントが実行したか」の両方を残すため、OBOの act とAgent as Principalの agent_id を併用します。高額送金のように実行前に本人の承認を挟む操作は、既存のCIBA（非同期認可）の守備範囲です。CIBAの実装はAuth0 for AI Agentsの解説記事で扱っています。法務の案件単位の制御は、権限を外した直後の遮断が要るため、Permissions IndexにCheckでの再確認を組み合わせます。

未GA機能を前提にした導入計画の注意点

発表文は、Token Vaultの組織対応とAgent as Principalに「将来の製品・機能への言及は提供を約束するものではなく、購入判断の根拠にしてはならない」との注記を付けていました。実際の提供は予定と一致していません。Token Vaultの組織対応は「6月上旬予定」より早い5月28日にGAになりました。Agent as Principalは、英語版の発表文が「6月上旬にDeveloper Preview」、5月25日の日本語版がDeveloper Previewでの提供としていましたが、changelogで確認できる告知は7月30日のEarly Accessで、Developer Previewの実際の提供日は公開資料からは確認できません。監査要件をAgent as Principal前提で設計するなら、発表の日付ではなくchangelogで段階を確かめ、GA前はクライアントの分離と下流APIの記録による代替経路を用意しておきます。

よくある質問

本番環境のAIアプリケーションで、Auth0の稼働率はどの程度保証されますか？

EnterpriseのPublic CloudとPrivate Cloudでは、中核サービスの月間平均の可用性99.99%がSLAで定められ、下回った月は月額料金の5〜20%がクレジットになります。Token VaultやCIBAが「中核サービス」に含まれるかはSLAのページに書かれていないため、契約時に確認します。

Auth0でAIエージェントの操作の監査証跡は取れますか？

トークン発行までは取れます。Agent as Principal（2026年11月時点でEarly Access）を使うと、トークン発行のたびにテナントログへ agent_id が記録され、GET /api/v2/logs?q=agent_id:... で検索できます。業務操作そのものはAuth0のログに残らないため、下流API側でユーザーID・エージェントID・リクエストIDを記録して関連付けます。

Auth0でAIエージェントに最小権限を実装するにはどうしますか？

自社APIを呼ぶエージェントには、OBOトークン交換で呼び先APIだけをaudienceにしたトークンを渡し、スコープをユーザーのRBACの範囲に収めます。外部SaaSのトークンはToken Vaultに預けてコードにAPIキーを置かず、権限の強い操作は実行前にCIBAで本人の承認を挟みます。

大量のAIエージェントのリクエストにAuth0はどこまで耐えられますか？

認証API全体の上限は、Essentials・Professionalで毎秒25件、Enterprise（Public Cloud）で毎秒100件（Performance Burstで月48時間まで最大毎秒400件）です。発行したトークンは有効期限まで使い回し、権限判定の量がボトルネックならFGA Permissions Indexで判定を書き込み時に前倒しします。

マルチテナントのSaaSでエージェントを管理するにはどうしますか？

Auth0 Organizationsで顧客組織を表し、Token Vaultの組織対応で外部サービスのトークンを（ユーザー, org_id）単位に分けます。取得後のトークンを組織間で混用しないよう、アプリ側のキャッシュや処理も組織単位で分離します。

関連記事

• Auth0 for AI Agentsとは？Token Vault・CIBAの設定手順とSDK対応状況・料金【2026年11月】
• Okta Cross App Access（XAA）とは？ID-JAGの仕組みとAgent SSO GA後の導入判断【2026年10月】
• CIMD（Client ID Metadata Documents）とは？MCPでDCRに代わるOAuthクライアント登録の仕組みと実装【2026年10月】
• ノンヒューマンアイデンティティ（NHI）とは？機械IDの管理・リスクと実装者向けの守り方を解説【2026年時点】
• WorkOSとは：SSOとSCIMを外部化するB2B SaaS向け認証基盤を実装視点で解説