【Okta for AI Agents】Amazon Bedrock AgentCore のエージェントをインポートしてみた【生成AIセキュリティ対策シリーズ】｜Nextmode Blog

はじめに

こんにちは、ネクストモード株式会社テクニカルサポート担当です。

これまで、Okta for AI Agents の全体像や Cross App Access（XAA）について整理・検証してきました。今回は、Amazon Bedrock AgentCore Runtime 上で動かしている自作の AI エージェントを、Okta for AI Agents 側にインポートするところまで確認した内容をご紹介します。

本記事では、エージェント自体の作り込みや AWS 側の詳細な構築手順には深入りしません。AgentCore 上でエージェントが動いている前提のもと、Okta に「管理対象のアイデンティティ」として載せるところを中心に扱います。

また、MCP 連携や Managed Connections による許可／拒否については今後の検証テーマとします。

※本記事は執筆時点の情報に基づきます。Early Access や仕様変更により、画面や挙動が変わる場合があります。最新情報は公式ドキュメントをご確認ください。

関連記事

今回確認すること

Okta for AI Agents の考え方には、答えるべき 3 つの問いがあります。すなわち、「Where are my agents?（エージェントはどこにいるか）」「What can they connect to?（何に接続できるか）」「What can they do?（何ができるか）」です。

今回はこのうち、「Where are my agents?（エージェントはどこにいるか）」に焦点を当てます。

AWS 上にエージェントを構築することと、企業の ID 基盤上で台帳に載り、所有者やライフサイクルを管理できる状態にすることは、別の段階です。シャドー AI 対策やガバナンスの入口として、「まず Okta に取り込む」こと自体が意味のあるマイルストーンになります。

今回のゴールは、Amazon Bedrock AgentCore Runtime 上のエージェントを Okta for AI Agents から確認し、管理対象として登録できることを確認することです。

前提

検証環境

検証には、次のような最小構成を使いました。

現時点ではエージェントが外部ツール（MCP）を持たず、Okta 側でも認可制御までは踏み込んでいません。あくまで「Runtime 上のエージェントを Okta が見つけ、登録できるか」を実現するための最小構成としています。

AgentCore 側の準備状況

まず、Okta に取り込む対象となるエージェントが AWS 側で作成済みであることを確認します。

今回は、Amazon Bedrock AgentCore Runtime 上に検証用エージェント agentcore_demo を作成し、ステータスが「準備完了」になっていることを確認しました。あわせて、呼び出し時のレスポンスやログも確認済みです。

なお、エージェントの実装や ECR／IAM の詳細な手順は本記事では割愛します。ここからは、この Runtime エージェントを Okta for AI Agents 側に取り込めるかを見ていきます。

Okta 連携用の IAM 権限を準備する

Okta から AWS 上の AgentCore 情報を参照できるようにするため、必要な権限を付与した IAM ユーザーを用意します。

まず、AgentCore の情報取得に必要なアクションを含む許可ポリシーを作成します。今回の検証では、Bedrock、Bedrock AgentCore、STS に対する参照系の権限を付与しました。

次に、このポリシーを IAM ユーザーにアタッチし、Okta 側で利用するアクセスキーを発行します。

なお、本記事では検証目的の構成として IAM ユーザーのアクセスキーを利用しています。実運用では、必要な API のみに絞った最小権限、アクセスキーの保管・ローテーション、利用ログの監査をあわせて検討してください。

Okta for AI Agents にエージェントをインポートする

ここからが今回の検証の本編です。Okta Admin Console 上で、Okta for AI Agents のエージェントインポート機能を使い、AgentCore 上のエージェントが Okta 側に現れることを確認します。

インポートには同期のタイミングの設定もありますが、必要であれば手動でインポートすることも可能です。

手順のイメージは次のとおりです。

1. Okta Admin Console で AWS IAM Identity Center のアプリ設定を開き、AI Agent Import タブを表示します。
2. Enable AI agent import にチェックを入れ、以下の情報を入力します。
   
   
   • Access key / Secret access key：連携用の IAM ユーザーのアクセスキー
   • Platforms：AgentCore
   • AWS regions：Tokyo (ap-northeast-1)
3. Test API Credentials をクリックすると以下のように Verified になり Import settings を入力できるようになります。ここでは以下のような設定としました。
   
   
   • Assign a group owner：作成済みのグループ『AWS AgentCore Owner』
   • Full import schedule：Hourly
   • Repeat every (hours)：1
4. Save configuration をクリックすると、以下のような画面になります。この時点ではまだ初回インポートが実行されていないため、Last Import date は表示されていません。Import now ボタンから即時インポートも可能ですが、今回は次のインポート時刻が近かったため、そのまま待つことにしました。 
   
5. 定期的なインポートが実行されると、以下のように「1 AI agent」と表示され、AI エージェントが見つかったことがわかります。
6. View agents をクリックすると、以下の画面が表示されます。AgentCore のランタイム名が表示されていることがわかります。
   
7. AI エージェント名をクリックすると、以下のように詳細画面が表示されます。
   インポート直後のステータスは STAGED でした。今回は取り込み確認が目的のため、Active 化は次回以降のリソース接続検証で扱います。
   

確認できたこと

今回の検証では、次の点を確認できました。

• AgentCore 上のエージェントが Okta 上で管理対象として表示される
• Okta Admin Console からエージェントの一覧・詳細を追える
• 「クラウド上で動くエージェント」を、企業の ID 基盤上で管理する入口まで進める

今回のポイントは、エージェントが AWS 上で呼べるだけでなく、Okta 側でも管理対象として扱える状態になったことです。これにより、所有者やライフサイクルを追うための土台を作れます。

今回確認していないこと

一方で、今回の検証では次の点までは確認していません。

• MCP などの外部ツール呼び出しそのもの
• Managed Connections / Cross App Access による接続制御
• 許可／拒否ポリシーの検証
• 実運用レベルのポリシー設計
• AI エージェントの Active 化とリソース接続の作成

重要なのは、インポート成功＝認可が効いているではない、という点です。名簿に載ったあとに、何に接続でき、何ができるかを制御する段階が続きます。

これは、冒頭で触れた Okta for AI Agents の 3 つの問いのうち、「What can they connect to?（何に接続できるか）」「What can they do?（何ができるか）」がまだ残っている、という意味です。

まとめ

今回は、Amazon Bedrock AgentCore Runtime 上の AI エージェントを、Okta for AI Agents に取り込んで登録確認するところまでをご紹介しました。

エージェントがクラウド上で動くことだけでなく、企業の ID 基盤上に載せて管理の起点を作るという第一歩を確認できたのが本検証の収穫です。

次回以降は、Slack や Notion などの MCP 連携を試しながら、Okta for AI Agents による接続・認可の制御（許可／拒否）を検証していく予定です。

参考リンク

• Okta 公式ドキュメント AIエージェントのインポートをサポートするアプリ
• Okta 公式ドキュメント Okta for AI Agentsのステータスタイプ