こんにちは、ネクストモード株式会社テクニカルサポート担当です。
これまで、Okta for AI Agents の全体像や Amazon Bedrock AgentCore エージェントのインポート、認可の土台になる ID-JAG トークン交換までを順に見てきました。今回はその続きで、Okta for AI Agents が答える 3 つの問いのうち、「What can they connect to?（何に接続できるか）」 に踏み込みます。
AgentCore Runtime 上のエージェントに Slack の Bot Token を持たせず、Okta の OAuth STS（Brokered Consent）でその都度発行される access token だけで remote Slack MCP を呼びます。そのうえで管理者が Slack の接続を切ったら、本当に止まるのか、まで確認しました。
AWS の ECR や CloudWatch の画面にはあまり立ち入らず、次の 3 点に絞っています。
いちばん最初からうまくいったわけではなく、Redirect URI の不足や、「先に Cross App Access（XAA）で通せないか」といった寄り道もありました。本筋のあとに、その話も書きます。
※本記事は執筆時点の情報に基づきます。Early Access や仕様変更により、画面や挙動が変わる場合があります。最新情報は公式ドキュメントをご確認ください。
SLACK_BOT_TOKEN を置かず、公開チャンネルの履歴を実際に読ませる「呼べた／呼べない」だけだと味気ないので、読めた中身が本物の Slack であることと、接続を外すと止まることを同じ検証のなかで揃える、というのが今回のゴールです。
構成は remote Slack MCP + Okta OAuth STS です。エージェントは remote Slack MCP を、STS で受け取った Slack access token だけで呼びます。xoxb-... のような Bot Token は常設しません。
環境は、AgentCore Runtime（東京）、Okta for AI Agents に取り込み済みの agentcore_demo、検証用 Slack アプリ、remote MCP です。エージェントに Management API 用のトークンは持たせていません。応答の画面は、同じエージェントをローカルのチャットから叩いた結果です。
STS で仲介するにしても、Slack 側には OAuth クライアント（アプリ）が必要です。
https://{Your Okta Domain}/oauth2/v1/sts/callback）を追加します。
ここからが今回の検証の本編です。Okta Admin Console で、Slack 向けの Resource server（STS）と、エージェントの Resource connections を設定します。
補足： 2026.08.0 から画面構成が変わり、Resource server / MCP Servers は Applications and Resources 配下にあります。AI Agents は従来どおり Directory 配下です。
役割を先に整理すると、次のようになります。
設定の流れは次のとおりです。
続いて、前回までの記事で取り込み済みの AI Agent（検証では agentcore_demo）に、Slack を接続先として追加します。ここで許可したアプリに対してだけ、エージェントが STS を進められることを確認します。
確認は、次の流れで進めました。
Bot Token を使わずに Slack の履歴を読めるかどうか、そして Resource connection を切り替えたときにエージェントの応答が変わるかどうかを、このあと確認していきます。
MCP の呼び出しが成功しただけでは、実際に Slack の投稿を取得できているかまでは判断できません。そこで、公開情報のみを扱う RSS フィード用の Slack チャンネルを対象に、エージェントから最新の投稿と直近の要約を取得できるか確認しました。応答にはチャンネル情報と実際のメッセージが含まれており、Slack 側のデータを参照できていることを確認できました。
これで、エージェント側に Bot Token を持たせなくても Slack の履歴を読めることを確認できました。
続いて、同じ構成のまま Okta 側の Slack Resource connection だけを切り替えてみます。まずは有効な状態で読めることを確認し、そのあと無効化したときの挙動を見ていきます。
| Slack Resource connection | エージェントの応答 |
|---|---|
| ACTIVE（同意済み） | #feed-auth0 の履歴が返る（上図） |
| INACTIVE | 接続は管理者によって許可されていない、と返る |
| 再 ACTIVE | 再び #feed-auth0 を読める |
具体的な設定変更は次のとおりです。
なお、エージェント側には Slack の Bot Token は設定しておらず、STS 経由で取得した access token だけで Slack MCP を呼び出しています。
ここからは、検証中につまずいたポイントを整理します。特に Redirect URI と Resource Indicator は、設定ミスに気づきにくい箇所でした。
Okta STS のコールバック URL は、Slack アプリの Redirect URLs にも登録しておく必要があります。Okta 側で Resource server を設定していても、Slack 側に未登録のままだと、同意時に redirect_uri did not match any configured URIs で止まります。
STS の target としてエージェントに渡す値は、Resource server の URL ではなく、Resource connection 詳細に表示される Resource Indicator（ORN） でした。remote Slack MCP の URL をそのまま渡すと invalid_target になるため、ここは混同しやすいポイントです。
前回までの記事で ID-JAG を扱っていたので、最初は Slack も Cross App Access（XAA） で同意なしに接続できないかと考えました。ただ、Slack MCP を STS で動かすだけなら、この確認は必須ではありません。ここでは、今回 STS を選んだ理由として整理しておきます。
ポイントは、エージェントが ID-JAG を渡す相手です。ID-JAG を受け取るのは Okta ではなく、接続先 MCP の認可サーバです。そのため、接続先の認可サーバが ID-JAG に対応しているかを .well-known/oauth-authorization-server で確認します。見るポイントは次の 2 つです。
grant_types_supported に urn:ietf:params:oauth:grant-type:jwt-bearer があるかauthorization_grant_profiles_supported に urn:ietf:params:oauth:grant-profile:id-jag があるか執筆時点の Slack MCP の metadata から、判断に使ったキーだけ抜粋します（metadata）。実際の応答には authorization_endpoint や scopes_supported などもあります。
なので今回は、公開されている認可の手順に合わせて STS（Brokered Consent） で進めています。初回だけ同意があって、そのあとは Admin の Resource connection で止められる、という動きになりました。
同じ metadata を Notion MCP で見ると、様子が違います。こちらも判断に使ったキーだけ抜粋します（metadata）。
こちらには jwt-bearer と id-jag が載っています。Okta OIN の Notion にも Cross App Access があり、Brokered Consent はありません。次回は Notion MCP を XAA で検証してみる予定です。同じ「何に接続できるか」でも、接続先の metadata によって経路が分かれそうです。
今回の検証では、Slack MCP を Okta の STS 経由で呼び出し、Resource connection の切り替えがエージェントの応答に反映されるところまで確認できました。
今回は Resource connection による接続制御の確認に絞ったため、次の内容は扱っていません。
今回は、Okta for AI Agents の 「What can they connect to?（何に接続できるか）」 を Slack MCP で確認しました。AgentCore Runtime 上のエージェントには Bot Token を置かず、Okta の OAuth STS（Brokered Consent）で発行される access token だけで remote Slack MCP を呼び、公開 RSS の #feed-auth0 を読めるところまで確認しています。
ここで効いていたスイッチは、AWS 側の設定ではなく AI Agent の Slack Resource connection でした。Resource connection を切ると読めなくなり、戻すと再び読めるため、接続制御が机上の設定ではなく、実際のエージェント応答にも反映されることを確認できました。
当初は ID-JAG の延長で Slack も XAA に寄せられないかと考えましたが、執筆時点の Slack metadata には jwt-bearer も id-jag もありませんでした。そのため今回は、Slack 公式の OAuth 手順に合わせて STS（Brokered Consent） で進めています。
シリーズの次は、同じ問いを接続先だけ変えます。Notion MCP の metadata には jwt-bearer と id-jag が載っており、OIN 側は Cross App Access で Brokered Consent はありません。次回は Notion MCP を題材に、Cross App Access（XAA） で「同意画面を挟まず、管理者が接続を管理する」経路を見てみます。
AI エージェントのアイデンティティ管理やセキュリティ統制に関するご相談は、ネクストモードまでお気軽にお問い合わせください。