Okta
オクタ
Okta for AI Agents（O4AA）の検証環境を作ってみた！ －AIエージェントのセキュリティを実際に動かして確かめる－
はじめに
AIエージェントの業務利用が、「チャットボットに質問する」段階から「エージェントに作業を任せる」段階へと移りつつあります。それに伴って課題になってきているのが、AIエージェントのセキュリティ ― とりわけ、そのエージェントは誰の権限で、どこまでのデータに触れてよいのかという問題です。この課題に対してOktaが提供しているのが Okta for AI Agents（以降、O4AA）です。
ただ、O4AAは「試してみたい」と思っても検証のハードルが高い機能でもあります。そこで弊社では、エージェントとアクセス先アプリをセットにしたデモコンソールを作成しました。本記事では、その構築と動作確認の様子をご紹介します。
1. Okta for AI Agents（O4AA）とは
従来、AIエージェントに権限を持たせる方法としては、担当者のアカウントやAPIキーをそのまま渡す、という運用が少なくありませんでした。手軽ではあるものの、この方法には次のような課題が残ります。
- 権限が過剰になる ― 借りたアカウントが持つ権限すべてに、エージェントも手が届いてしまう
- ログで区別がつかない ― 監査ログに残るのは借りたアカウント名だけで、人の操作かエージェントの動作か追跡できない
- エージェント単位で止められない ― IDとして登録されていないため、停止する単位が存在しない
O4AAでは、エージェント自身をOktaに登録したうえで、Resource Connections（リソース接続）としてアクセス先を定義します。エージェントは実行時にOktaからトークンを受け取り、その範囲内でのみリソースにアクセスできます。
2. デモコンソールで検証環境を作ってみた
O4AAの動きを理解するには、実際にエージェントを動かしてみるのが一番の近道です。しかし、いざ検証しようとすると準備が意外と重い作業になります。必要なものは大きく2つです。
- Oktaに登録し、トークン交換を実装したAIエージェント側のアプリケーション
- そのエージェントがアクセスするリソース側のアプリケーション
つまり「エージェントを作る」だけでは足りず、「アクセスされる側」も併せて用意しないと、許可されるケースと拒否されるケースを見比べられません。実際、パートナー様からも検証環境の準備が難しいというお声をいただいていました。
そこで弊社にて、この2つをセットにしたデモコンソールを作成しました。
デモコンソールの構成
作成したデモコンソールは、デモ用AIエージェントとXAA対応デモアプリがセットになったものです。OktaテナントとSlackについては、別途ご用意いただく必要があります。
図1：デモコンソールの構成
※ 図中のXAA／STSは、AIエージェントがリソースにアクセスする際の2つの接続方式です。アクセス先の性質によって使い分けが変わります。違いについては第4章で補足します。
※ 管理画面やデモコンソールの表示上は、XAA対応デモアプリを「ACME」という名称で登録しています。以降のスクリーンショットに出てくる「ACME」は、すべてXAA対応デモアプリを指します。
セットアップ
セットアップ画面は5つのステップで構成されています。順に進めていくと、Oktaへのアプリ登録から接続テストまで一通り完了します。
まず、ユーザーをOktaにサインインさせるOIDC Webアプリを用意します。ここで得たIDトークンが、この後エージェントがリソースへアクセスする際の本人確認の起点になります。「半自動設定」を押すとOkta側にWebアプリが作成され、Client IDなどが自動で入力されます。
図2：ステップ1 ― OIDC Webアプリの設定
次に、AIエージェントが自分自身をOktaに認証するための鍵を登録します。この鍵で署名したclient assertionを使って、エージェントはユーザーに代わってトークンを取得します。秘密鍵はエージェント側にのみ保存され、Oktaへは渡りません。
図3：ステップ2 ― AI Agentの認証鍵の登録
続いて、アクセス先となる2つのリソースを接続します。ひとつはSlackで、XAA非対応のリソースとしてOAuth STSのResource Server Connectorで接続します。
図4：ステップ3 ― Slackの接続（非XAA）
もうひとつがXAA対応デモアプリです。こちらは「半自動設定」でカスタム認可サーバー、スコープ、アクセスポリシー、リソース接続までまとめて作成されます。アクセストークンに入るスコープをOkta側で制御できるのが、この構成のポイントです。
図5：ステップ4 ― XAA対応デモアプリの接続
Okta側の設定を確認する
セットアップが完了すると、Okta管理画面ではAIエージェントが一つのIDとして登録され、リソース接続に2件（認可サーバーとアプリケーション）が並んだ状態になります。それぞれに許可されたスコープが設定されているのが分かります。
図6：Oktaに登録されたAIエージェントとリソース接続
3. 動かしてみる ― 許可されるとき、拒否されるとき
設定が終わったら、実際にエージェントへ依頼を投げてみます。まずはXAA対応デモアプリに対して「問い合わせ一覧を見せて」と入力します。エージェントはOktaからトークンを取得し、許可されたスコープの範囲でアクセスして結果を返します。
図7：許可されるケース（200 OK）
ここで、Okta側のスコープ設定を変更してみます。許可していた tickets:read を外し、tickets:reply だけを残した状態にします。
図8：スコープから tickets:read を外す
この状態で同じ依頼をすると、エージェントはリソースにたどり着けません。ID token から ID-JAG への交換の時点で止まり、エラーが返ります。
図9：拒否されるケース
Slack（非XAA）の場合
次に、XAA非対応のリソースであるSlackに対して「チャンネル一覧を見せて」と依頼してみます。こちらは挙動が変わり、まずユーザーの同意を求められます。
図10：同意待ちの状態
同意ページを開くと、Slack側の許可画面が表示されます。ここでユーザーが許可すると、エージェントはSlack用のトークンを受け取れるようになります。
図11：Slackの同意画面
同意後にもう一度同じ依頼をすると、今度はチャンネル一覧が取得できました。
図12：同意後、チャンネル一覧の取得に成功
同じ「エージェントがリソースにアクセスする」動作でも、XAAとSlack（STSによる接続）とで挙動が違うことが分かります。この違いについては、最後の章で補足します。
トレース画面で裏側を見る
トレース画面では、実際にどのトークンがどこで交換されたのかを順を追って確認できます。ID token から ID-JAG、ID-JAG からアクセストークンへと交換され、リソースのAPIが呼ばれるまでの流れが可視化されます。
図13：トレース画面（Okta制御の内訳）
4. 補足：XAAとSTS、2つの接続方式の違い
ここからは補足として、構築の過程で整理した内容に触れておきます。O4AAでは、接続先のリソースの性質に応じて複数のリソースタイプが用意されています。
| リソースタイプ | 概要 |
| Authorization server | Okta のカスタム認可サーバーで保護されたリソースへのアクセス。 XAA（Cross App Access）が対応し、ID-IAG を使用 |
| Resource server | サードパーティの認可サーバーが発行したアクセストークンを、 Okta が仲介して利用。 STS（brokered consent）フローに対応 |
| Secret | Okta Privileged Access に保管された静的な認証情報を使用 |
| Service account | Universal Directory に定義されたアプリ向けのサービスアカウント。 Okta Privileged Access に保管 |
このうち、AIエージェントからアプリケーションへアクセスさせる際に登場するのが XAA と STS です。
XAA（Cross App Access）
XAAは、アクセスする側とされる側の両方が同じIdP（Okta）を信頼していることを前提とした方式です。Oktaが両者の間に立ち、ポリシーに基づいて接続の可否を判断します。トークンのやり取りは次のように進みます。
図14：XAA（ID-JAG）のトークン交換フロー
ポイントは、この一連の流れにユーザーの同意画面が挟まらないことです。判断はIdP側のポリシーで完結します。自律的に動くAIエージェントの場合、処理の途中で人間の承認を待てないケースが多いため、この性質が効いてきます。
なお、発行されるID-JAGは有効期間5分程度の短命なトークンです。最終的に得られるアクセストークンはOktaの標準的なアクセストークンであるため、失効操作も可能です。
STS（brokered consent）
一方のSTSは、リソース側がXAAに対応していない場合の方式です。今回のデモにおけるSlackが、これに該当します。この場合、アクセストークンを発行するのはOktaではなくサードパーティ側の認可サーバーで、Oktaはその取得と受け渡しを仲介する立場になります。
XAAとの最大の違いは、ユーザーの同意（consent）が必要という点です。エージェントがユーザーの代理として動く前に、本人の同意を得るステップが入ります。図10・図11で同意画面が表示されたのは、まさにこの仕組みによるものです。
使い分けの整理
| XAA | STS | |
| リソースタイプ | Authorization server | Resource server（Application / MCP Server） |
| 前提 | リソース側も Okta を信頼し、カスタム認可サーバーで保護 | リソース側はサードパーティの認可サーバーを使用 |
| トークン発行元 | Okta（ID-IAG → アクセストークン） | サードパーティ（Okta が仲介） |
| ユーザー同意 | 不要（IdP のポリシーで判断） | 必要 |
| 主な用途 | XAA に対応した自社アプリ | Slack 等の既存 SaaS（OIDC 対応） |
整理すると、「アクセス先がOktaの世界の中にあるか、外にあるか」が分岐点になります。中にあればXAAでポリシー主導の制御ができ、外にあればSTSでOktaが仲介しつつ、ユーザー同意を挟む形になります。
まとめ
本記事では、O4AAの検証環境をデモコンソールで構築し、実際に動かしてみた様子をご紹介しました。エージェントを一つのIDとして登録し、リソース接続でアクセス範囲を定義する。そしてスコープを変えると、エージェントの挙動がその場で変わる。文章で読むよりも、実際に画面で追ったほうが理解の早い部分だと感じています。
O4AAは現在も機能追加が続いている領域であり、対応範囲や設定手順も変化しています。本記事の内容は執筆時点のものである点はご了承ください。
「まずは動かして感触を掴みたい」という方に向けて、デモコンソールをご用意しています。配布をご希望の方、O4AAの検証やAIエージェントのセキュリティにご興味のある方は、ぜひ弊社までご連絡ください。
参照元（Okta公式ドキュメント）
お問い合わせ・資料請求
株式会社マクニカ Okta 担当
- TEL：045-476-2010
- E-mail：okta@macnica.co.jp
平日 9：00～17：00
