【Okta for AI Agents】Slack MCP 呼び出しを Resource connections で制御してみた【生成AIセキュリティ対策シリーズ】

» Okta » 技術 » 生成AIセキュリティ対策シリーズ » AI
テクニカルサポート

はじめに

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

これまで、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 点に絞っています。

  1. Slack アプリ準備と Resource server（STS）設定
  2. Okta Admin Console での接続先登録と Resource connections
  3. Slack Resource connection の許可／拒否が、実際の Slack 読取結果として見えること（Bot Token なし）

いちばん最初からうまくいったわけではなく、Redirect URI の不足や、「先に Cross App Access（XAA）で通せないか」といった寄り道もありました。本筋のあとに、その話も書きます。

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

 

今回確認したこと

  • Slack アプリを作り、Okta の Slack アプリ Resource server（STS） に Client ID / secret / scopes を載せる
  • AI Agent の Resource connections に Slack を追加し、Resource Indicator をエージェントへ渡す
  • Runtime に SLACK_BOT_TOKEN を置かず、公開チャンネルの履歴を実際に読ませる
  • Slack Resource connection を Deactivate すると履歴は読めなくなり、Activate すると再び読める
  • 初回の同意と、Redirect URI まわりのハマりどころ

「呼べた／呼べない」だけだと味気ないので、読めた中身が本物の 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 用のトークンは持たせていません。応答の画面は、同じエージェントをローカルのチャットから叩いた結果です。

 

Slack アプリの準備

STS で仲介するにしても、Slack 側には OAuth クライアント（アプリ）が必要です。

  1. Slack API でアプリを作ります。
  2. OAuth & Permissions で remote MCP が使うスコープを付けます。
  3. 同じ画面の Redirect URLs に、Okta STS のコールバック（https://{Your Okta Domain}/oauth2/v1/sts/callback）を追加します。
  4. Basic Information の App Credentials から Client ID / Client secret を控えます。

 

Okta 側の設定

ここからが今回の検証の本編です。Okta Admin Console で、Slack 向けの Resource server（STS）と、エージェントの Resource connections を設定します。

補足： 2026.08.0 から画面構成が変わり、Resource server / MCP Servers は Applications and Resources 配下にあります。AI Agents は従来どおり Directory 配下です。

役割を先に整理すると、次のようになります。

  • Resource server：Slack OAuth クライアント情報を持つ場所
  • Resource connections：AI Agent に接続許可を与える場所
  • Resource Indicator（ORN）：AgentCore Runtime に渡す値

設定の流れは次のとおりです。

  1. Slack アプリ統合の Resource server で STS を有効にし、Client ID / Client secret / scopes を載せます。
  2. AI Agent の Resource connections に Slack を追加し、ACTIVE にします。
  3. 接続詳細の Resource Indicator（ORN）を控えて、エージェントへ渡します。

Resource server を設定する

  1. Okta Admin Console > Applications and Resources > Applications で、Slack のアプリ統合を開きます。
  2. Resource server タブを開きます。
  3. Security token service (STS) を選び、Edit をクリックします。
    Okta Admin Console の Resource server タブで、Security token service（STS）の設定を編集する画面

  4. Slack アプリの Client ID / Client secret と、remote MCP で使う scopes を入力して Save します。
    Okta の STS 設定で Slack アプリの Client ID、Client secret、scopes を入力して保存する画面

  5. Enabled と表示されていることを確認します。
    Okta の Resource server 画面で Security token service（STS）が Enabled になっていることを示す画面

Resource connections に載せる

続いて、前回までの記事で取り込み済みの AI Agent（検証では agentcore_demo）に、Slack を接続先として追加します。ここで許可したアプリに対してだけ、エージェントが STS を進められることを確認します。

  1. Okta Admin Console > Directory > AI Agents で対象エージェントを開き、Resource connections を表示します。
    Okta Admin Console の AI Agent 詳細で、Resource connections を表示して接続先を追加する画面

  2. Resource type として Application を選び、Connect to では App configured for AI Agent access を選択します。
    Okta の Resource connection 追加画面で、Resource type に Application、接続方法に AI Agent access 用アプリを選ぶ画面

  3. Application instance で Okta で作成済みのアプリケーションを選択し Add をクリックします。この画面で表示される Resource Indicator は AgentCore Runtime に設定します。
    Okta の Resource connection 追加画面で Slack アプリを選択し、AgentCore Runtime に渡す Resource Indicator を確認する画面

  4. Resource connections に Application として Slack が追加されていることを確認します。
    Okta の AI Agent 詳細で、Slack が Application の Resource connection として追加されていることを示す画面

チャット UI で挙動を確認する

確認は、次の流れで進めました。

  1. チャット UI から、対象ユーザーとしてエージェントに質問する
  2. エージェントが Okta の OAuth STS を使って Slack MCP 用の access token を取得する
    チャット UI からエージェントを呼び出した際に、Okta の OAuth STS 経由で Slack MCP 用の access token 取得へ進むことを示す実行ログ

  3. 初回はユーザー同意が必要なので、Slack の同意画面で許可したあと、同じユーザーとしてエージェントを再実行する
    初回実行時に Slack へのアクセス同意が必要であることをエージェントの応答として示す画面

  4. 同意後にもう一度呼ぶと、Slack チャンネル内の投稿履歴が表示されることを確認する

Bot Token を使わずに Slack の履歴を読めるかどうか、そして Resource connection を切り替えたときにエージェントの応答が変わるかどうかを、このあと確認していきます。

許可時に読めた内容

MCP の呼び出しが成功しただけでは、実際に Slack の投稿を取得できているかまでは判断できません。そこで、公開情報のみを扱う RSS フィード用の Slack チャンネルを対象に、エージェントから最新の投稿と直近の要約を取得できるか確認しました。応答にはチャンネル情報と実際のメッセージが含まれており、Slack 側のデータを参照できていることを確認できました。

エージェントが Slack の公開チャンネル #feed-auth0 から最新メッセージと直近の要約を取得できたことを示す画面

 

これで、エージェント側に Bot Token を持たせなくても Slack の履歴を読めることを確認できました。

 

接続を無効化すると本当に止まるのか

続いて、同じ構成のまま Okta 側の Slack Resource connection だけを切り替えてみます。まずは有効な状態で読めることを確認し、そのあと無効化したときの挙動を見ていきます。

Slack Resource connection エージェントの応答
ACTIVE（同意済み） #feed-auth0 の履歴が返る（上図）
INACTIVE 接続は管理者によって許可されていない、と返る
再 ACTIVE 再び #feed-auth0 を読める

具体的な設定変更は次のとおりです。

  1. Resource connection から Slack を INACTIVE 状態にします。
    Okta の AI Agent 詳細で Slack Resource connection を INACTIVE に切り替える画面

  2. 同じ呼び出しが失敗することを確認します。管理者によって許可されていない、と返ります。
    Slack Resource connection を無効化した状態で、エージェントが管理者により接続を許可されていないと返す画面

  3. もう一度 Activate して、同じ呼び出しを行います。再び Slack チャンネル内の投稿履歴を読めることを確認しました。

なお、エージェント側には Slack の Bot Token は設定しておらず、STS 経由で取得した access token だけで Slack MCP を呼び出しています。

 

設定時に注意したいポイント

ここからは、検証中につまずいたポイントを整理します。特に Redirect URI と Resource Indicator は、設定ミスに気づきにくい箇所でした。

Redirect URI を Slack 側にも登録する

Okta STS のコールバック URL は、Slack アプリの Redirect URLs にも登録しておく必要があります。Okta 側で Resource server を設定していても、Slack 側に未登録のままだと、同意時に redirect_uri did not match any configured URIs で止まります。

Resource Indicator（ORN）を指定する

STS の target としてエージェントに渡す値は、Resource server の URL ではなく、Resource connection 詳細に表示される Resource Indicator（ORN） でした。remote Slack MCP の URL をそのまま渡すと invalid_target になるため、ここは混同しやすいポイントです。

Cross App Access（XAA）ではなく STS を選んだ理由

前回までの記事で 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 などもあります。

Slack MCP の認可サーバ metadata で、grant types が authorization_code と refresh_token のみであることを確認する画面

なので今回は、公開されている認可の手順に合わせて STS（Brokered Consent） で進めています。初回だけ同意があって、そのあとは Admin の Resource connection で止められる、という動きになりました。

同じ metadata を Notion MCP で見ると、様子が違います。こちらも判断に使ったキーだけ抜粋します（metadata）。

Notion MCP の認可サーバ metadata で、jwt-bearer と ID-JAG に対応していることを確認する画面

こちらには jwt-bearer と id-jag が載っています。Okta OIN の Notion にも Cross App Access があり、Brokered Consent はありません。次回は Notion MCP を XAA で検証してみる予定です。同じ「何に接続できるか」でも、接続先の metadata によって経路が分かれそうです。

 

今回わかったこと

今回の検証では、Slack MCP を Okta の STS 経由で呼び出し、Resource connection の切り替えがエージェントの応答に反映されるところまで確認できました。

  • Slack アプリ、Resource server（STS）、Redirect URI（STS callback）を組み合わせて設定できた
  • Resource Indicator（ORN）を渡すことで、Bot Token なしで remote Slack MCP から公開チャンネルの履歴を読めた
  • Slack Resource connection を ACTIVE／INACTIVE／再 ACTIVE に切り替えることで、許可・拒否・復帰をエージェントの応答として確認できた
  • 未同意時の同意要求、Redirect URI 不足、Resource Indicator の指定ミスを切り分けられた

 

今回の検証範囲外

今回は Resource connection による接続制御の確認に絞ったため、次の内容は扱っていません。

  • 監査ログを含めた運用設計
  • Slack MCP で利用するスコープの最小化
  • Slack MCP を XAA（ID-JAG → Slack access token）で呼び出す検証
  • Notion MCP を XAA で呼び出す検証（次回予定）

 

おわりに

今回は、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） で「同意画面を挟まず、管理者が接続を管理する」経路を見てみます。

 

参考リンク

Okta に関するお問い合わせ

AI エージェントのアイデンティティ管理やセキュリティ統制に関するご相談は、ネクストモードまでお気軽にお問い合わせください。

SaaSバナー_Okta