Oktaが発表したもの
Oktaは8月24日、Agent SSOの一般提供を発表しました。対応するAIエージェントをUniversal Directory上のIDとして登録し、管理者が接続先を集中ポリシーで制御できます。Oktaによると、この機能は同社の中核SSO製品に含まれ、オープンなCross App Access（XAA）プロトコルを基盤とします。
Oktaの発表では、XAAはOAuthを拡張し、MCPのEnterprise-Managed Authorization拡張として組み込まれています。Agent SSOは、ハードコードされた認証情報や広範で長期間有効な権限の代わりに、ID管理された短期トークンを利用します。Claude、Slack、Notion、Datadog、Figma、Supabaseなど、エージェント、SaaS、開発ツール、MCP基盤にまたがる連携先も挙げられています。
本番運用にとって重要な理由
本番エージェントは一度ログインするだけではありません。複数アプリを横断し、人やサービスの代理で行動し、開始時の業務が終わった後もアクセス権が残る場合があります。認可判断を企業のIDプロバイダーへ集約すれば、エージェントの棚卸し、接続制限、アクセス取消、ライフサイクルの証跡を一元管理できます。
静的キーの漏えいや広すぎるOAuth権限が、データ流出や重要操作につながり得る金融・業務システムでは特に重要です。短期認証情報と集中ポリシーは影響範囲を縮小しますが、エージェント、接続先アプリ、その間にあるツールやMCPサーバーが一貫して対応して初めて効果を発揮します。
Agent SSOだけでは解決できないこと
ID管理が答えるのは、どのエージェントが接続し、どのリソースへ到達できるかです。要求された操作が妥当かどうかまでは保証しません。正しく認証されたエージェントでも、プロンプトインジェクションに従う、古い情報を使う、顧客口座を取り違える、部分障害後に決済を重複実行するといった問題は起こり得ます。
そのため開発側には、アクション層の第二の制御基盤が必要です。限定的なツールスキーマ、取引・情報持ち出しポリシー、承認閾値、冪等性、頻度・金額上限に加え、利用者の委任、エージェントID、モデル判断、ツール呼び出し、実際の状態変更を結ぶ監査記録が求められます。取消テストでは、新規トークンの発行だけでなく、キャッシュ済みセッションや実行中処理も確認すべきです。
Ineezaの見解
Agent SSOの意義は、エージェントID管理を個別の統合作業から共通の企業基盤へ変える点にあります。ただし、あらゆる操作の妥当性を保証するものではなく、最小権限でエージェントを運用する土台として捉えるべきです。ID層の接続ポリシーと、実行境界の決定論的な統制を組み合わせる設計が最も堅牢です。