エンタープライズ向けソフトウェアは、クラウドへの移行以来、最も重大な転換期を迎えています。
AIエージェントは、もはや孤立して動作する実験的なツールではありません。エンタープライズ環境において主体的に行動する存在となりつつあります。これらはワークフローを開始し、機密データにアクセスし、複数のシステムにまたがってマシンスピードで動作します。そして、こうしたエージェントがアプリケーションとますます接続するようになるにつれ、エンタープライズのセキュリティは、もはや単一の製品やプラットフォームによって定義されるものではなくなっています。それは、企業がそれらの接続に対してどれだけの可視性と制御を持っているかによって定義されるのです。
この現実は、エンタープライズ向けSaaSの構築者やAIプラットフォームを、新たな「共有されたセキュリティ責任」の中心に位置づけます。エージェント時代においては、アプリケーション同士がどのように接続するかという点に、最初から信頼を組み込む必要があります。
統合に潜む見えにくいリスク
過去1年の間に、業界では一連のSaaSサプライチェーンインシデントが発生しました。そこでは、攻撃者は中核インフラを侵害したのではなく、信頼されていた統合を悪用しました。複数のケースにおいて、長期間有効、あるいは再利用可能なトークンがあるアプリケーションから盗まれ、それが再利用されることで、数十、場合によっては数百の下流にあるエンタープライズ環境へのアクセスが得られました。
Oktaも、この種のリスクから無縁ではありませんでした。ほとんどの現代的な企業と同様に、私たちは事業運営のために幅広いSaaSベンダーのエコシステムに依存しています。だからこそ、私たちは利用するアプリケーションに対して、強力なアイデンティティフェデレーション、スコープ付きアクセス、ネットワーク制限、監査可能性といった、基本となるセキュリティ管理策を確立しています。これらの対策は極めて重要であり、最近のSaaS侵害時にも被害範囲を限定し、盗まれたトークンがOkta環境に再利用されるのを防ぐ助けとなりました。
そして今、AIエージェントがエンタープライズのワークフローにおいて能動的な主体者となるにつれ、セキュリティチームは、既存のモデルでは想定されていなかった新しいクラスのアクセス課題に目を向ける必要があります。
静的な資格情報、ユーザーが付与するOAuth同意、管理されていないサービスアカウントといった、従来のアプリケーション間認可モデルは、エージェントが自律的に行動を開始し、動的に接続を確立し、人の関与なしに複数のシステムを横断して動作する世界を想定して設計されたものではありません。AIエージェントが登場すると、アクセスパターンは非決定的となり、統合は急速に増加し、単一のトークンが侵害された際の影響範囲は劇的に拡大します。
エンタープライズ規模でエージェントからアプリ、アプリからアプリへのアクセスを保護するための、オープンでベンダーニュートラルなプロトコルであるCross App Access（XAA）は、このギャップを埋めるために設計されています。
エージェント型AIが変えるセキュリティの前提
Model Context Protocol（MCP）のような標準は、AIエージェントがツールやデータソースとやり取りしやすくすることで、イノベーションを加速させてきました。その相互運用性は強力ですが、エンタープライズによって管理された認可がなければ、新たなセキュリティ上の死角も生み出します。
今日あまりにも多くの場合、アクセス判断は、個々のユーザーによって暗黙的に行われるか、アプリケーションロジックの中に直接埋め込まれています。企業は、どのエージェントがどのシステムに接続しているのか、どの権限を持っているのか、問題が起きたときにそのアクセスをどのように取り消せばよいのかについて、ほとんど可視性を持っていません。
これは、大規模では持続不可能です。セキュリティチームには、人間のユーザー、アプリケーション、あるいはAIエージェントのいずれによってアクセスが開始されるかに関わらず、一元的な制御、監査可能性、そして一貫してポリシーを適用できる能力が必要です。
SaaS構築者とAIプラットフォームにとって、なぜXAAプロトコルが重要なのか
XAAは、アイデンティティプロバイダー、SaaSベンダー、AIプラットフォームを横断して動作するよう設計された、オープンで相互運用可能なプロトコルです。これにより、企業は利用する製品に関係なく、一貫した認可ポリシーを適用できます。
XAAはOAuthの拡張であり、MCPにおける認可の拡張でもあります。これにより、認可判断を個々のアプリケーションから切り離し、エンタープライズのアイデンティティプロバイダーに集約します。企業は、脆弱なトークンや繰り返されるユーザー同意プロンプトに依存することなく、アプリ間およびエージェントからアプリへのアクセスに関するポリシーを中央で定義し、強制できます。
SaaS構築者やAIプラットフォームにとって、これは単なるセキュリティ改善ではなく、競争優位性でもあります。
XAAを採用することで、以下が可能になります。
ガバナンス、監査可能性、失効（リボーク）に関するエンタープライズの期待に応える統合を提供する
リスクの高いトークンの氾濫や静的な資格情報を排除する
繰り返される認可プロンプトを排除し、同意疲れや過剰権限、偶発的なアクセスのリスクを低減することで、顧客オンボーディングを簡素化する
一度構築すれば、顧客環境やアイデンティティプロバイダーを横断して相互運用できるようにする
そして最も重要なのは、エンタープライズが実際にAI主導のアクセスを管理したい方法、つまり散在するシークレットや場当たり的な承認ではなく、アイデンティティ、ポリシー、そして可視性を通じて管理するという考え方と整合できる点です。
新たな共有責任と明確な期待
Oktaでは、エージェント型の未来を安全にするには、エコシステム全体が足並みをそろえて進む必要があると考えています。アイデンティティプロバイダー、企業、SaaSベンダーのすべてに役割があります。しかし、その役割は、企業が依存する製品に、正しいセキュリティ基盤を組み込むことから始まります。
私たち自身の内部運用や、顧客がSaaSエコシステムに期待する振る舞いを見ていくと、一つのことが明らかです。企業はもはや、中央管理の監督外で動作するユーザー管理の接続や静的な資格情報に満足していません。彼らは、依存するアプリケーションやAIプラットフォームが、アプリ間およびエージェントからアプリへのアクセスに対して、現代的で標準に基づいた制御をサポートしているという保証を求めています。
だからこそ、XAAは私たちにとって非常に重要なのです。私たちはXAAを、エージェント時代においてアプリケーション間の信頼がどのように確立されるかという点における重要な進化であり、大規模なエンタープライズ顧客にサービスを提供するあらゆるSaaSベンダーにとって不可欠な能力だと考えています。これらの制御に早期から投資するベンダーは、顧客の高まり続ける期待に応え、システミックリスクを低減し、ますます相互接続が進むエンタープライズ環境に自信を持って参加できる立場にあります。
私たちの目標は、SaaS構築者やAIプラットフォームと緊密に協力し、この移行を実用的で、相互運用可能で、開発者に優しいものにすることです。なぜなら、意味のあるセキュリティの進歩は、エコシステム全体がともに前進したときにのみ実現するからです。
XAAを始めるには
エージェント型AIへの移行は急速に進んでいますが、より強力な認可モデルの採用が必ずしも複雑である必要はありません。
SaaS構築者やAIプラットフォームがXAAを簡単に検討・採用できるようにするため、Oktaは、実験段階から本番対応までを支援する、ベンダーニュートラルな開発者向けリソース群に投資してきました。これには、技術ドキュメント、リファレンス実装、そしてローカル環境を構築することなくXAA対応の統合を確認できる新しい開発者向けプレイグラウンドが含まれます。
すでにAuth0上で構築しているSaaSベンダーにとっては、道筋はさらに簡単です。XAAはAuth0のお客様向けに標準で提供されており、現在はベータ版としてサポートされています。これにより、既存のOAuthインフラを使ってXAAを有効化でき、エージェントからアプリ、アプリからアプリへのアクセスを保護するために必要な労力を大幅に削減できます。
MCPサーバーを保護する場合でも、エージェントからアプリへのアクセスを有効にする場合でも、既存のOAuthベースの統合を近代化する場合でも、これらのツールは、XAAを迅速に評価し、エンタープライズ管理型の認可がどのようにアーキテクチャに適合するかを理解するために設計されています。
エージェント型エコシステムが進化し続ける中で、今こそISVが一歩先を行くべき時です。企業がデフォルトで信頼できる統合を構築し、AI駆動型ソフトウェアが接続される方法の中核に、アイデンティティと認可を据えるべきなのです。
