Oktaが「Agent SSO」を全ユーザーへ一般提供
米Oktaは2026年8月27日、AIエージェント向けの認可プロトコル「Cross App Access(XAA)」を土台にした「Agent SSO」を、Okta Platformの全ユーザーに一般提供すると発表した。IT Leadersの報道によれば、XAAは2025年から一部ユーザー向けに先行提供されていたが、今回すべての契約ユーザーが追加費用なしで利用できるようになった。XAAはOAuthの拡張仕様であるRFC 8693(トークン交換)とRFC 7523(JWTプロファイル)、さらにインターネットドラフト「Identity Assertion Authorization Grant」を組み合わせ、AIエージェントがSlackなど外部サービスへアクセスする際に、ユーザーが毎回同意画面を操作する必要をなくす仕組みだ。
Oktaは、業務プロセスへのAIエージェント導入が進んでいるにも関わらず、人間の従業員と同じアイデンティティ管理・セキュリティ制御を適用している組織はわずか34%にとどまると指摘している。Agent SSOでは、Claudeのようなエージェントを導入した場合もOktaの「Universal Directory」に正規のアイデンティティとして登録し、人間の社員と並べてアクセス権や利用状況を監視できる。同社は2026年3月17日にも「Okta for AI Agents」を発表しており、シャドーAIの検知と認証を組み合わせる機能をすでに投入していた。
AWSはBedrock AgentCoreで多層のポリシー適用を実装
Amazon Web Servicesは、Amazon Bedrock AgentCoreにおいて、Oktaとは異なるアプローチでOAuthを組み込んでいる。AWSブログの解説では、AgentCore Identityが認証トークンを受け取り、ユーザーの権限を定義するカスタムOAuthクレームを抽出、AgentCore Runtimeを通じてエージェントのセッション内に渡す構造が示されている。ツール実行前にはAgentCore Gatewayがポリシー適用点として機能し、AgentCore Policyがリクエストの権限を検証、同時にGoogle DriveやDropboxなど外部サービスの認証情報プロバイダーを確認する仕組みだ。
具体例として、ジュニアアナリストが経営幹部の報酬データにアクセスしようとした場合、リクエストはデータベースに到達する前にGatewayの段階で拒否されるという。ユーザーがGoogle DriveへのOAuth同意を与えていない場合は、エージェントが明確なエラーを返し、初回アクセス時に同意プロンプトを表示してトークンを保存する。この多層防御は、どのチームがツールを構築したかに関わらず一貫したセキュリティを適用する狙いがある。
DatabricksとMongoDBも独自の委任認証を投入
Databricksは「エージェントウィーク」の一環として、Unity AI Gatewayを通じたモデル・MCP・ツールの一元管理を発表した。同社のブログは、顧客から「認証がボトルネックだ」との声が多いと明かしている。GitHubやGlean、Atlassianなど外部MCPサーバーごとに独自のOAuthアプリ登録・クライアントシークレット・トークン更新ロジックが存在し、本来数分で済むはずの接続作業に数週間かかっているという実態が背景にある。
一方、MongoDBは2026年9月1日にソウルで開催した「MongoDB.local Seoul」で、Atlasのマネージド型MCPサーバーを正式リリースした。BigGoファイナンスの報道によれば、ユーザーはOAuthを通じて自分の権限範囲内でのみエージェントがアクセスできるよう設定でき、読み取り専用権限を付与すればエージェントは書き込み操作を実行できない。誰がどの作業を実行したかを追跡・監査できるログ機能も備え、韓国の製造・金融・公共市場を主要な攻略対象に据えている。
OSS・中小規模製品でもOAuth 2.1採用が広がる
大手クラウドベンダーだけでなく、国産オープンソースCMS「baserCMS」も5.4.0でAIエージェント連携機能を搭載し、認証にOAuth 2.1を採用した。ASCII.jpの記事によれば、AIエージェントは連携を許可したユーザーの権限で動作し、管理画面でできない操作はエージェントからも実行できない。MCPという共通仕様を採用しているため、Claude・ChatGPT・Visual Studio CodeなどMCP対応クライアントであれば同じ仕組みで接続できるという設計だ。
断片化する認可基盤と今後の論点
OktaのXAA、AWSのAgentCore Identity、DatabricksのUnity AI Gateway、MongoDBのユーザー委任認証、baserCMSのOAuth 2.1——いずれもOAuthを土台にしながら、トークン交換の方式や中間トークンの発行者、ポリシー適用のレイヤーはベンダーごとに異なる。ZDNet Japanの報道も、AIエージェントの急増によってOAuth認証の脆弱性が顕在化し、IAMを介した中央管理の必要性が指摘されていると伝えている。複数のクラウド・SaaSベンダーを併用する企業ほど、認可の仲介役をどこに集約するかという設計判断が重くなっている状況だ。