2026年末までに、多くの人が少なくとも1つのAIエージェントを利用するようになると予測されている。Boxの最高経営責任者（CEO）Aaron Levie氏によれば、今後5年以内に、1人当たり数十から数百、場合によっては1000ものエージェントが稼働する可能性があるという。これらのエージェントは自律的な観察に基づいて意思決定を行い、複数のデータソースや他のエージェントと連携して成果を最適化する。
この将来像は、デジタルリソースを不正アクセスから守るために多大な努力を払っている組織にとって脅威となり得る。AIの支援を受けて業務を効率化することが求められる従業員は、エージェントを起動し、企業システムへのアクセス権を付与しようとするだろう。
現在、こうしたアプリケーション間アクセスに利用される認証情報であるOAuthトークンは、この新たな課題に対応するには不十分な可能性がある。
数年前、エージェント型AIが登場する以前から、Oktaはユーザーが「Slack」などのアプリケーションに業務データへのアクセスを許可する際の承認方法に根本的な欠陥があることを認識していた。同社の「Identity Platform」やMicrosoftの「Entra」などのアイデンティティー・アクセス管理（IAM）システムは、どのユーザーがどの企業リソースにアクセスできるかを管理する中央制御プレーンとして機能している。
しかし、同じシステムが他のアプリケーションに対してユーザーに代わりリソースアクセスを許可する方法については、監視の範囲外に置かれていた。こうした決定はエンドユーザーに委ねられ、IAMの死角や回避可能なセキュリティリスクを生じさせていた。Oktaはこの抜け穴を塞ぐため、インターネット技術特別調査委員会（IETF）と協力し、新しいオープンスタンダードの策定を進めている。
新標準の提案
Oktaは社内やプロモーション資料でこの仕様を「Cross-App Access（XAA）」と呼んでいるが、IETFの標準化議論では「Identity Assertion Authorization Grant（IAAG）」という名称で知られている。独自技術や事実上の標準と異なり、オープンスタンダードは業界に制約なく提供される技術である。MicrosoftやPing Identityなど、Oktaの競合を含む企業や開発者は、発明者へのロイヤリティーを支払うことなく独自の実装を構築できる。
HTTPはウェブブラウザーがあらゆるウェブサイトにアクセスできるようにする中核技術であり、オープンスタンダードの代表例だ。パスキーを機能させるWorld Wide Web Consortiumの「WebAuthn」とFIDO Allianceの「Client to Authenticator Protocol（CTAP）」も同様にオープンスタンダードである。
企業は技術を発明し、オープンスタンダードとして世界に提供できるが、その評価基準は他社による採用率にある。Oktaによれば、Google、Amazon、Salesforce、Box、ZoomなどがIAAGの初期採用企業だ。
MicrosoftのAI Innovations担当コーポレートバイスプレジデントであるAlex Simons氏は米ZDNETのインタビューで、同社がクラウドベースのIAMソリューション「Entra」でIAAG標準をサポートする計画を明らかにした。Oktaのアイデンティティー標準ディレクターAaron Parecki氏が当初仕様の著者として登場していたが、最新のドラフトではPing IdentityのBrian Campbell氏が共著者として記載され、Pingも協力していることが示されている。
提案された標準のタイミングは偶然にも非常に良い。Parecki氏によれば、Oktaがこの問題に取り組み始めた当時、エージェント型AIはまだ視野に入っていなかった。しかし現在、スマートでスケーラブル、時には完全に自律的なソフトウェアのカテゴリーが急成長しようとしている中、この新標準はIT管理者に、アプリケーションとエージェントを人間と同じレベルで安全に制御し、可視化するための必要なコントロールと透明性を提供する態勢を整えている。
委任アクセスの舞台裏
技術的な詳細は省略するが、通常は次のような処理が行われる。あるアプリケーション（クライアントアプリケーション）がエンドユーザーに代わり、別のアプリケーション（リソースサーバー）に直接アクセスする場合、いわゆる「委任アクセス」では、リソースサーバーの運営者は、クライアントアプリケーションがエンドユーザーになりすまして認証するための特別なログイン認証情報を発行するよう求められる。
このシナリオでは、エンドユーザー（OAuth標準では「リソース所有者」）は、自身のアクセス権の一部または全部をクライアントアプリケーションに委任していることになる。この特別な認証情報はOAuthトークンと呼ばれる。リソースサーバーがトークンを発行する前に、通常はダイアログボックスを通じてエンドユーザーに委任の許可を求める。エンドユーザーが同意すると、リソースサーバー（多くの場合、認可サーバーが代理で対応）はOAuthトークンをクライアントアプリケーションに発行し、その安全な保管はクライアント側の責任となる。実質的には、これはユーザーIDとパスワードに相当する。
2025年、世界最大級のブランドの一部が利用していたSalesforceのインスタンスから、10億件以上の顧客レコードが犯罪的かつ回避可能な形で流出した際、脅威アクターは盗まれたOAuthトークンを悪用して犯行を実行した。
エンドユーザーがOAuthトークンの発行に同意し、クライアントアプリケーションがそれを受け取ると、そのトークンはリソースサーバーへのログイン認証情報として使用される。これは人間がログイン時にIDとパスワードを提示するのとほぼ同じ仕組みだ。OAuthトークンには、付与したリソース所有者、委任された特定のアクセス権（ユーザー権限の一部）、発行元のリソースサーバーがひも付けられる。
例えば、Google（リソースサーバー）がSlack（クライアントアプリケーション）に発行したOAuthトークンはGoogle専用であり、SlackのユーザーIDに関連付けられる。SlackはこのトークンをZoomなど別のアプリケーションに提示できず、他のユーザーに代わってGoogleに提示することもできない。トークンには永続的なものと有効期限付きのものがあり、発行者はいつでもトークンを無効化できる。これはパスワードを変更したり、玄関のカギを取り替えるのと同じ概念だ。
