【Okta】Okta for AI Agents 検証記事まとめ：AI エージェントの登録・接続制御・可視化【生成AIセキュリティ対策シリーズ】

はじめに

こんにちは、ネクストモードのゆきなわです。

ネクストモードでは、2026年4月に一般提供が始まった Okta for AI Agents について、昨年の発表段階からいち早く機能検証を行い、その内容をブログでお届けしてきました。

本記事では、これまでに弊社で公開した実践的な検証記事7本を、業界連合 Blueprint Alliance が示す AI エージェント統制の「4つの問い」に沿って紹介します。

⚠️本記事は2026年10月現在の情報に基づきます。紹介する各記事は、それぞれの執筆時点の画面・仕様で検証しています。早期アクセス（Early Access）機能やベータ版、提供予定の機能を含むため、機能や仕様、提供時期等は予告なく変更される場合があり、将来の機能を確約するものではありません。最新情報は公式ドキュメント等をご確認ください。

4つの問いと検証記事の対応関係

Oktane 2026 の Partner Summit で発表された業界連合 Blueprint Alliance は、ホワイトペーパーでAI エージェントの統制（ガバナンス）を次の4つの問いで整理しています。

1. Where are my agents?（エージェントはどこにいるか）
2. What can they do?（エージェントは何ができるか）
3. What are they doing?（エージェントは何をしているか）
4. How do I respond?（どう対応するか）

Okta for AI Agents 発表当初は「エージェントはどこにいるか」「何に接続できるか」「何ができるか」の3つの問いでした（弊社記事「【Okta】Okta for AI Agents とは？シャドー AI 時代に備えるエージェント管理の全体像」）。

4つの問いでは、接続と権限が「何ができるか」にまとまり、実行時の統制にあたる「何をしているか」「どう対応するか」が加わっています。Blueprint Alliance の詳細は弊社記事「【Oktane26】Partner Summit で発表：AI エージェントを守る Blueprint Alliance とは？」をご覧ください。

本記事でこれから紹介する検証記事を、4つの問いと Okta の機能に当てはめると次のとおりです。

※表の記事名は略称で、正式タイトルは各記事の紹介箇所に記載しています。

①エージェントはどこにいるか：AI エージェントを Okta に登録する

エージェント登録は、ほかの3つの機能を使う場合も前提になる操作です。カスタム構築のエージェントは手動で登録し、サードパーティのビルダープラットフォームで構築されたエージェントはインポートで取り込みます。手動登録の例は、②で紹介する Agent SSO の記事で取り上げています。

Amazon Bedrock AgentCore のエージェントをインポートする

AgentCore インポートの記事（「【Okta for AI Agents】Amazon Bedrock AgentCore のエージェントをインポートしてみた」）では、AgentCore Runtime（東京リージョン）で動く TypeScript の最小エージェントを、Okta for AI Agents のインポート機能で取り込んでいます。

• 検証内容：AWS IAM Identity Center のアプリ統合にある［AI Agent Import］タブでインポートを有効にし、［Import now］でエージェントを取り込みました
• 検証結果：AgentCore 上のエージェントが Okta 管理コンソールの一覧・詳細に表示されました。インポート直後のステータスは STAGED でした。インポートだけでは接続を制御できない点も記事で強調しています

②エージェントは何ができるか：接続先を Okta で一元管理する

「何ができるか」は、エージェントがどこに接続し、何を許可されているかで決まります。Okta for AI Agents では、接続先が ID-JAG に対応していれば XAA、対応していなければ STS（Brokered Consent）で接続を管理します。MCP サーバーに XAA を適用した仕組みが EMA です。

アプリや API への接続：Cross App Access（XAA）

Cross App Access（XAA）では、ユーザーの SSO を起点に Okta が ID-JAG を発行し、接続先の認可サーバーが ID-JAG をアクセストークンに交換します。エージェントがどこに接続できるかを Okta で一元管理するため、接続先ごとの同意画面でのユーザー操作が不要になります。

サンプルアプリで Cross App Access を試す

「【Okta】Cross App Access検証レポート AIエージェント連携の可能性と見通し」は、一般提供より前の2025年11月に、早期アクセス機能だった Cross App Access を試した記事です。

• 検証内容：Okta が公開しているサンプルアプリ（リクエストアプリの Agent0 とリソースアプリの Todo0）を追加し、［Managed Connections］タブで2つのアプリを接続しました
• 検証結果：事前に接続を定義しておくことで、AI エージェントが追加の認証・認可なしに Todo アプリのタスクを読み取り、追加できました。本記事の公開当時は、Cross App Access に対応した SaaS はまだありませんでした

「誰の代理か」を示すトークンの交換をステップバイステップで確認する

ID-JAG トークン交換の記事（「【Okta】取り込み済み AgentCore エージェントの認可土台として ID-JAG トークン交換を検証してみた」）では、AgentCore インポートの記事で取り込んだエージェントを有効化し、ID-JAG を使ったトークン交換をローカルの CLI から実行しています。

• 検証内容：カスタム認可サーバーに xaa:read スコープと JWT Bearer を許可するアクセスポリシーを設定し、このカスタム認可サーバーをエージェントのリソース接続に追加しました
• 検証結果：Org Authorization Server で id_token から ID-JAG へ、カスタム認可サーバーで ID-JAG から access_token への2段階の交換が成功しました。リソース接続を無効化すると、アクセストークンは発行されなくなります

MCP サーバーへの接続：EMA（Enterprise-Managed Authorization）と STS

EMA に対応した MCP サーバーであれば、Okta 側は XAA と同じ設定で接続できます。対応しているかどうかは、MCP サーバーの認可サーバーメタデータに jwt-bearer と id-jag が含まれているかで確認できます。

対応していない MCP サーバーには、Okta の STS（Security Token Service）を使った Brokered Consent で接続します。この方式では、初回だけユーザーが接続先の同意画面で許可し、以降は Okta が保管したトークンをもとにアクセストークンをエージェントへ渡します。

STS（Brokered Consent）と XAA（EMA）の接続フローの違い

次の3本の記事では、MCP サーバーの対応状況による接続方式と挙動の違いを具体的に解説しています。

STS で接続する：初回だけ同意し、Okta がトークンを仲介する

Slack MCP（STS）の記事（「【Okta for AI Agents】Slack MCP 呼び出しを Resource connections で制御してみた」）では、2026年8月時点の Slack MCP に、Okta for AI Agents のエージェントから接続しています。

• 検証内容：Slack MCP のメタデータに jwt-bearer と id-jag がなかったため、STS で接続しました。Slack アプリ統合の［Resource server］タブで STS を設定し、エージェントのリソース接続に Slack を追加しています
• 検証結果：Bot トークンを常設せず、公開チャンネルの投稿履歴を読み取れました。同意画面は初回のみ表示され、リソース接続を INACTIVE にするとエージェントは「接続は管理者によって許可されていない」と応答します

EMA で接続する：同意画面なしで、常設トークンも置かずに接続できる

Notion MCP（EMA）の記事（「【Okta for AI Agents】Notion MCP を Cross App Access で呼び出してみた」）では、ID-JAG を受け付ける Notion MCP に EMA で接続しています。

• 検証内容：Notion アプリ統合の［Resource server］タブで Cross App Access（XAA）の Issuer URL を設定し、エージェントのリソース接続に Notion を追加しました
• 検証結果：常設の Notion トークンなしでデータベースのタイトルを読み取れました。前提として、Notion 側で Enterprise-managed connections を有効にする必要があります

EMA で接続する（Agent SSO）：基本 SSO ライセンスでも同意画面なしで接続できる

2026年8月に一般提供が発表された Agent SSO は、主要な Okta SSO プランに追加料金なしで含まれる機能です。Agent SSO の記事（「【Okta】Agent SSO とは？基本 SSO プランで Slack MCP 接続を検証」）では、Okta for AI Agents を契約していない基本 SSO プランの環境で、Slack MCP への接続を改めて検証しています。

• 検証内容：手動登録した自作エージェントから、Cross App Access（XAA）を有効にした Slack アプリ統合に接続しました。基本 SSO プランでは STS を使えず、接続方式は XAA（EMA）のみです
• 検証結果：2026年9月時点の Slack MCP のメタデータは jwt-bearer と id-jag に対応しており、同意画面なしで公開チャンネルの履歴を読み取れました。Slack 側で Enterprise-managed authorization を有効化し、アプリを組織にインストールしておく必要があります

③エージェントは何をしているか：Agent Gateway でツール呼び出しを可視化する

Oktane 2026 で一般提供が発表されたエージェントゲートウェイ（Agent Gateway）は、エージェントと MCP サーバーの間でツール呼び出しを中継し、公開するツールの絞り込み、遮断、ログの記録を Okta 側で行います。

Agent Gateway で公開ツールの絞り込み・遮断・ログを確認する

Agent Gateway 現地検証の記事（「【Oktane26】Okta for AI AgentsのAgent Gatewayを現地で検証してみた」）では、Okta の Preview Sandbox を使い、自作の MCP クライアントから Agent Gateway を経由して Slack 公式のリモート MCP サーバーに接続しています。検証結果は次のとおりです。

ツール呼び出しを1回ごとにログで追える点は、「エージェントは何をしているか」への直接の回答と言えます。

一方、現状の遮断方法では「どう対応するか」に十分に対応できていません。Gateway 全体を無効化すれば数分で遮断できますが、エージェント単位で委任リンクを削除しても、実行中のセッションは動き続けました。

発行済みトークンの失効と実行中セッションの停止まで行えるキルスイッチの拡張版は、2026年 Q4 に一般提供予定です。

おわりに

本記事では、Okta for AI Agents の検証記事7本を、AI エージェント統制の4つの問いに沿って紹介しました。

「エージェントはどこにいるか」「何ができるか」「何をしているか」の3つの問いについては、それぞれ主要な機能を検証記事で取り上げてきました。

一方で、エージェントの自動検出など、まだ検証記事にできていない機能もあります。「どう対応するか」に応えるキルスイッチの拡張版とあわせて、今後検証を進めていく予定です。

本記事が AI エージェントの接続を Okta で管理したい方の参考になれば幸いです。

Okta に関するお問い合わせ

Okta for AI Agents を活用した AI エージェントのセキュリティ対策に関するご相談は、ネクストモードまでお気軽にお問い合わせください。