AIエージェント認証、OAuth 2.0が標準も「トークン管理のボトルネック」が業界共通課題に——AWS・Databricks・MongoDB・Oktaが独自レイヤーで対応

AIエージェントが複数の外部SaaSやデータベースに自律的にアクセスする構成が広がる中、認証・認可の設計が各社共通のボトルネックとして浮上している。基盤はいずれもOAuth 2.0だが、実装方式は企業ごとに異なり、ユーザー権限を維持したまま「誰が何にアクセスしたか」を追跡できる仕組みづくりが焦点になっている。

AWS AgentCoreの3層認証、Salesforceと非対応のTableauで対応が分岐

NTTデータが構築したマルチSaaS横断AIエージェントの事例では、AWS AgentCoreのIdentityとGatewayを組み合わせ、認証ポイントを3箇所に分けて処理している。ユーザー認証にはOktaが発行するJWTアクセストークンをOAuth 2.0プロバイダとして利用し、AgentCore Runtime側で検証することで、エージェントは常に「認証済みユーザーコンテキスト」で動作する仕組みだ。Salesforce連携ではAgentCore GatewayのMCPターゲット機能を使い、OpenAPI定義を介したOAuth 2.0 Authorization Code Flowをゲートウェイ側が主体的に管理し、エージェント自体はトークン管理を意識しない設計とした。一方でTableauはOAuth 2.0ではなくPersonal Access Token(PAT)方式を採用しており、AgentCore Identity標準機能ではユーザー単位のPAT管理ができないため、Gateway Interceptorsによるカスタム認証で対応している。OAuth対応SaaSと非対応SaaSが混在する現実に、実装側が個別対応を迫られている実態が見える。

X MCPサーバーは動的クライアント登録非対応、OSSブリッジ「xurl」が必須に

2026年6月30日に提供開始されたX(旧Twitter)公式MCPサーバーは、X APIのOAuth 2.0が動的クライアント登録をサポートしていないため、AIクライアントを直接MCPサーバーURLに向けることができない。そこでX開発者プラットフォームチームが提供するOSSのCLIツール「xurl」をローカルブリッジとして挟み、AIクライアント側はstdio経由のJSON-RPCをxurlに送り、xurlがHTTPS+BearerトークンでMCPサーバーへ中継する2段構成を取っている。初回起動時にはブラウザでOAuth 2.0ログインを一度行えばトークンが`~/.xurl`にキャッシュされ自動更新される仕組みだが、ヘッドレス環境では`xurl auth oauth2 --headless`による事前認証が必要になる。標準的なOAuth 2.0仕様がそのままAIエージェント連携に適用できない現実的な制約例といえる。

Databricks・MongoDB・Oracleはユーザー委任型OAuthで権限昇格を回避

DatabricksはUnity AI Gatewayを通じて、GitHubなど外部MCPサーバーへの接続における「各プロバイダー独自のOAuthアプリ登録、独自クライアントシークレット、独自トークン更新ロジック」を一元管理する方針を示した。同社は顧客から「認証がボトルネックになっており、数分で終わるはずの作業に数週間かかる」という声が繰り返し寄せられていると説明している。MongoDBも2026年9月1日のイベント「MongoDB.local Seoul」で正式リリースしたAtlasマネージド型MCPサーバーで、ユーザーはOAuthを通じて自身の権限範囲内でのみエージェントにアクセスさせる委任方式を採用し、読み取り専用権限のみ付与すればエージェントは書き込みを実行できない設計とした。OracleのAI Database AgentもGemini Enterprise連携でOAuthクライアントのclient_id/client_secretを個別データベースごとに発行し、認証されたデータベースユーザーの参照権限を超えて昇格することがない設計を明示している。3社に共通するのは「エージェントに与える権限をユーザー本人の権限を超えさせない」という原則だ。

Oktaは「OAuthの限界」を指摘、Cross App Accessとシャドーエージェント検知で対抗

Oktaは2026年3月17日、AIエージェント向けID管理機能「Okta for AI Agents」を同年4月30日(米国時間)から提供すると発表し、シャドーAIエージェントの検知機能を組み込んだ。さらに同年6月22日には「Cross App Access」を発表し、複数アプリと自律連携するAIエージェントにおいて既存OAuthによる認可管理が分断されている課題を指摘している。各社がOAuth 2.0を土台にトークン管理やゲートウェイの中央集権化を進める一方で、Okta自身がOAuthの設計限界を公に認め、アプリ横断の認可を再設計する動きを見せている点は、業界全体がまだ過渡期にあることを示している。

まとめ：標準は定まるも実装は依然として企業ごとにバラバラ

AWS、Databricks、MongoDB、Oracle、Xの各事例を見ると、OAuth 2.0がAIエージェント認証の事実上の共通基盤であることは間違いない。しかしPAT代替が必要なTableau、動的クライアント登録非対応のX API、プロバイダごとに異なるトークン更新ロジックなど、現場では標準仕様だけでは解決できない課題が山積している。Oktaが提起する「OAuthの限界」への対応も含め、今後はAgentCore IdentityやUnity AI Gatewayのような中央集権型の認証レイヤーが、企業のAIエージェント導入における事実上の必須コンポーネントになっていく可能性が高い。