AIエージェント統制は「IDの層」と「コンテンツの層」に分かれた｜BoxとOktaの発表を読み解く

こんにちは、ひろかずです。

AIエージェントの統制BoxとOktaがコンテンツとIDのそれぞれでAIエージェント統制の実装点を発表しました。AIエージェントの統制を考える切り口となりますので、これらを題材に解説していきます。

忙しい人向けの要約

• Boxは2026年7月21日（米国時間）、AIエージェントから企業コンテンツを守る機能群「agent security and governance」を発表しました。agent guardrails、プロンプトインジェクション検出、MCPガードレール、分類ベースのアクセスポリシー、監査証跡などを含みますが、機能ごとに対象（Boxネイティブのエージェントか、Box MCP Server等を経由するサードパーティのエージェントか）と提供段階が異なります。
• Oktaは同じ週に「Okta for AI Agents」の新機能として、Agent Gateway（リサーチリリース）、Agent-to-Agent Connections（一般提供）、Resource Access Certifications for AI Agents（早期アクセス）を発表しました。
• 2つの発表は、エージェント統制の実装点が「ID層（誰が・何に接続できるか）」と「コンテンツ層（何を読ませ・何をさせるか）」の二層に分かれたことを示しています。両層は、相互に補完する関係です。
• 提供段階は機能ごとにバラバラであり、「発表＝今日使える」ではありません。Boxで一般提供中なのはプロンプトインジェクション検出（Logモード）のみで、他は2026年7月下旬〜2026年後半の提供目標です。OktaのAgent Gatewayはリサーチリリース段階です。
• 今すぐやるべきことは製品導入ではなく、エージェントの台帳化と、自社データの「重心」がどこにあるかの特定です。

何が起きているの？

2026年7月21日（米国時間）、Boxは企業コンテンツ上で動作するAIエージェントを統制する新機能群「agent security and governance」を発表しました。対象はBoxネイティブのエージェントだけではありません。Claude、ChatGPT、GeminiといったサードパーティのAIエージェントがBoxのコンテンツに触れる際にも、Box側の統制が適用されます。

発表された機能は6つです。Box公式ブログでは、機能ごとに対象となるエージェント・接続経路と提供段階（発表時点の目標）が示されています。なお、機微な操作の前に人間の承認を挟むhuman-in-the-loop制御は、独立した機能ではなく、agent guardrailsの一部（承認なしの一括削除の防止など）として説明されています。

Boxは、これらの機能がEnterprise Advancedプランの顧客向けに数か月以内に展開されると発表しています。

その3日後、Okta Japanは2026年7月24日付で「Okta for AI Agents」の新機能を発表しました。柱は3つです。

同じ週に、2つの大手SaaSベンダーが同じ課題への答えを出しました。ただし、答えは同じではありません。

なぜ情報システム・セキュリティ担当者に関係するの？

BoxとOktaの2つの発表は、単なる新製品のニュースにとどまりません。

Boxの2026年版「State of AI in the Enterprise」レポート（米・英・仏・日のIT意思決定者1,600人超を調査）によれば、組織の83%はすでに重要なタスクでAIエージェントを試行しています。統制の整備を待たずに現場の利用が先行しており、放置すればシャドーITの再現となります。誰も台帳を持たないままエージェントが増えていく状況は他部門の話ではなく、情シスやセキュリティ担当者自身が向き合うべき話です。

2つの発表を並べると、担当者が押さえるべき統制の実装点が二層に分かれたことが見えてきます。どちらの層も、既存の業務の延長線上にあります。

Oktaが統制するのはIDの層 — IdP運用の守備範囲が広がる

Oktaが統制するのは、どのエージェントが、誰の代理として、どのツールに接続できるか、という点です。Agent Gatewayは認証情報をエージェント本体から隔離し、接続の瞬間にポリシーを評価します。Oktaは、AIアプリケーションの76%が内製ではなく購入されている（Menlo Ventures「2025: The State of Generative AI in the Enterprise」調査）ことを踏まえ、コードを改修できないサードパーティ製エージェントが最大のセキュリティ課題だと説明しています。

コードを改修できないエージェントには、利用する企業の側が静的な認証情報を渡さざるを得ず、過剰な権限・ユーザー特定不能・監査ログ不在という問題が生じます。このID層の統制は、サービスアカウントの棚卸しや特権ID管理など、情シスがIdPで担ってきた業務の延長線上に位置します。エージェントのIDライフサイクル管理は、情シスの所管と言えるでしょう。

Boxが統制するのはコンテンツの層 — データ分類・DLP運用の成熟度が問われる

接続が正当であっても、そのエージェントが「どのファイルを読み、何をしてよいか」は別の問題として残ります。同レポートでは、調査対象のITリーダーの90%が、AIエージェントに企業コンテンツへのアクセスを許可する最大の障壁としてセキュリティ・規制・信頼の懸念を挙げました。

この層の統制は機密度分類ラベルを前提とするため、現在のBox Shield・DLP運用の成熟度がそのまま効き目を左右します。分類が未整備なら、製品の提供を待っても守れません。セキュリティ担当者が進めているデータ分類の整備が、そのままエージェント統制の土台になります。

問題は「どちらか」ではなく「どちらから始めるか」

判断材料となるエージェントの台帳・認証情報の所在・データの重心を揃える役割には、情報システム・セキュリティ担当者が適任でしょう。

よくある誤解

「MCPゲートウェイやIdP統合を入れれば、エージェント統制は完了する」

Okta自身が、Agent Gatewayは従来のAPIゲートウェイやMCPゲートウェイのようなネットワークトラフィックのルーティングとは異なる「アイデンティティネイティブ」な仕組みだと位置づけを説明しています。逆に言えば、接続後にエージェントがコンテンツに対して何をするかは、Oktaが担うID層の守備範囲を超えます。

「Boxの統制はBoxの外にも効く」

Boxの新機能はBoxのコンテンツ層、つまりBox内のコンテンツアクセスとBox MCP Server経由の接続に適用されるものです。従業員がファイルをダウンロードし、AIチャットのWeb画面に貼り付ける経路は、この統制の外側にあります。この経路の統制は、利用する企業の側がSWG/CASBやエンドポイント側の別の仕組みで補う必要があります。

「発表された機能は今日使える」

BoxのMCPガードレールや監査証跡は2026年後半が目標であり、OktaのAgent Gatewayはリサーチリリース段階です。稟議書に「導入すれば統制できる」と書ける状態には、まだ時間がかかります。今期の計画には、提供段階の確認を織り込んでください。

実務で問題になりやすいポイント

最初につまずくのは、技術ではなく所管

ID基盤はIdP担当、Boxはコンテンツ管理担当、AI活用はDX推進部門、と担当が分かれている組織では、「エージェント統制」という一つの課題が3つの部門に断片化し、誰も全体を持たない状態になることが予想されます。二層の統制は、二層の縦割りを生みやすいので、製品より責任の設計先決です。

ライセンス条件

Boxの新機能については、Enterprise Advancedプラン顧客向けに展開すると発表されており、自社環境で利用している現行プランのまま使えるかの確認が必要です。Okta側も、Okta for AI Agentsの機能ごとに提供段階が異なります。予算計画に乗せる前に、自社の契約プランの各機能の利用可否を確認しましょう。

監査ログの分散

Oktaはエージェントの接続とユーザーの紐付けを記録し、Boxはエージェントセッションのコンテンツ操作を記録します（Boxの監査証跡は2026年後半の提供目標）。インシデント時には両方のログを突合することになります。ログの保存先・保持期間・突合できる環境を、導入前に揃えておくべきです。

技術的・運用的な確認ポイント

着手前に、次の点を自社環境で確認してください。

エージェントの台帳

台帳は両製品の利用要件ではありませんが、BoxもOktaも自らの統制点を通るエージェントしか統制できません。

台帳がなければ、どのエージェントをどちらの統制点に載せるかを決められず、登録漏れのエージェントがシャドーエージェントとして統制の外に残ります。最終的にはエージェントの台帳が必要となってくるのです。

台帳には以下の要素が盛り込まれていることを確認してください。

• 社内で動いているAIエージェント（コーディングエージェント、SaaS組み込みエージェント、自作エージェント）を列挙されているか
• オーナー（人間の責任者）が割り当てられているか

認証情報の所在

エージェントがSaaSに接続するために使っている認証情報（OAuthトークン、APIキー、静的シークレット）がどこに保存され、誰がローテーションしているかの整理状況を確認してください。

Agent Gatewayが解決するのは静的な認証情報の隔離と短命化です。現状の認証情報の所在が分からなければ、移行対象も優先順位も決められません。

Boxの契約プランと機密度分類

現在契約しているライセンスプランがEnterprise Advancedであるかを確認してください。また、Box Shieldの分類ラベルが実データへの付与状況も見る必要があります。

Boxの新機能はEnterprise Advancedプランの顧客向けに展開され、分類ベースのアクセスポリシーは分類ラベルを前提とします。どちらかを欠いたまま導入計画を立てても、制御が機能しません。

Box MCP Serverの利用状況

外部エージェントがBox MCP Server経由で接続しているか、それとも各自が個別のOAuth連携を作っているかを確認してください。MCPガードレールが効くのはBox MCP Server経由の接続です。接続経路を把握しなければ、統制の空白がどこにあるかを特定できません。

Box管理コンソールでの詳しい確認方法は、文末のAppendix「Box MCP Serverの利用状況を確認する手順」を参照してください。

IdP側のエージェント可視性

Okta上で、人間以外のアイデンティティ（サービスアカウント、エージェント）をどこまで棚卸しできるかを確認してください。ID層の統制は、エージェントをIdPに正規のアイデンティティとして登録することが前提であり、登録漏れがそのまま統制漏れになるためです。

Oktaでの具体的な識別方法は、文末のAppendix「Oktaで人間以外のアイデンティティを識別する方法」を参照してください

ログ突合の可否

ID層のログとコンテンツ層のログを、同一インシデントについて、どのように時系列で突き合わせられそうかを確認してください。監査ログは接続の記録（Okta）とコンテンツ操作の記録（Box）に分散するため、事前に保存先・保持期間・突合手法を揃えておかなければ、インシデント発生時の調査開始に大きなロスが生じます。

まずは、「エージェントの台帳」と「認証情報の所在」の確認から始めると良いでしょう。

対応方針の比較：全体観と各統制のカバー範囲

エージェントがデータに触れるまでの流れは、5つのエリアに分けると守備範囲を把握しやすくなります。

1. 身元・権限のライフサイクル：エージェントの登録、オーナー割当、権限の継続レビュー
2. 接続・認可の瞬間：認証情報の管理と、誰の代理としての接続かの検証
3. コンテンツの読み取り・操作：どのファイルを読み、何を実行してよいか
4. 持ち出し・転送の経路：ダウンロード後の貼り付け・アップロードなど、データが統制点の外に出る経路
5. 実行環境と出力：エージェントが動く端末・拡張機能と、モデルの出力内容

守れるもの — どの統制がどのエリアをカバーするか

◯は主たる統制点、△は部分的なカバー、─は守備範囲外を示します。縦に見れば、◯がひとつもないエリアは実行環境と出力だけです。横に見れば、1つの統制で全エリアを覆える列はありません。

守れないもの — 統制の空白と補完先

提供段階と前提条件

経営層・監査部門への説明ポイント

経営層への説明

軸は、AIへの投資を滑らせないという一点に置いてください。

AIエージェントの投資は、顧客データ・契約書・案件情報といった売上に直結する機密データを扱わせて初めて効果を発揮します。統制がない状態では機密情報を触らせられないため、用途は機密性の低い周辺業務にとどまり、投資が滑ります。Boxの調査でも、ITリーダーの90%が、AIエージェントに企業コンテンツへのアクセスを許可する最大の障壁としてセキュリティ・規制・信頼の懸念を挙げています。統制はこの障壁を外す手段です。機密データを安全に使わせ、ビジネスを加速するための投資である、と説明すると良いでしょう。

そのうえで、「AIエージェントは従業員と同じく身元と権限の管理対象である」という位置づけを示します。組織の83%がすでにエージェントを試行しており、統制の有無にかかわらず利用は進みます。止めるための統制ではなく、使わせるための統制です。

監査部門への説明

監査部門へは、監査証跡を見る観点が変わる点を先に伝えるべきです。従来の「誰がログインし、何を閲覧したか」に加え、「どのエージェントが、誰の代理で、何を読み、何を実行したか」という記録が必要になります。

Oktaは接続の起点となった主体まで遡れる監査トレースを、Boxはエージェントセッション単位の保持・リーガルホールド対応の記録を提供するとしています。この2種類のログが監査要件のどこに対応するかを内部統制の文書に反映できるよう、彼らにインプットを提供してください。

実務担当者が次に取るべき対応ステップ

できることは、OktaやBox Enterprise Advancedを持っているかどうかで変わります。製品を持たない組織の4ステップが土台であり、製品を持つ組織はその上に固有のステップを積みます。

製品を持っていない組織でも、今日からできること

1. エージェント台帳の作成（今週から）：社内で動くエージェントとそのオーナー、接続先、認証情報の種類を一覧化する。スプレッドシートで始められます
2. データ重心の特定（1か月以内）：最も守るべきデータがBoxにあるのか、Microsoft 365なのか、独自DBなのかを特定する。ID層とコンテンツ層のどちらへの投資を優先するかは、この結果で決まります
3. 静的認証情報の洗い出しと削減計画（四半期内）：エージェントに渡している長期APIキー・静的トークンを列挙し、ローテーションの責任者を決める。SaaS側のOAuthアプリの棚卸しも製品なしで進められます
4. 統制外経路の手当て（並行）：ダウンロード→貼り付け経路について、既存のSWG/CASBポリシーと利用ルールの見直しを進める

Oktaを持っている組織が追加でできること

1. エージェントのIdP登録とオーナー割当（1か月以内）：ISPMが契約に含まれるなら、台帳づくりは手作業の列挙からではなく検出から始めます。
   1. ISPMは連携済みアプリとIdPのデータから非人間IDを検出し、Service Accounts・Keys or tokens・Workload identitiesなどのラベルを付与します（AIエージェントの検出は、Salesforce Agentforceなど対応プロバイダーに限られます）。
   2. 1の検出結果を台帳の初期リストにします。
   3. 初期リストに対して、手作業でオーナー割当と用途の確認をします。
   4. 台帳に載せたエージェントをDirectoryのAI Agentsに登録し、オーナーと認証情報を管理します。
   5. 運用開始後の登録漏れの検出は、Directory > AI Agentsの画面ではなく、ISPMの検出やプロバイダーアプリからのインポートで補完します（文末のAppendix参照）

   この流れを図にすると次のようになります。

   

2. 新機能の段階に応じた検証（四半期内）：Resource Access Certifications（早期アクセス）で未使用接続の棚卸しと自動失効を試し、Agent Gatewayはリサーチリリースへのアクセス申請と小規模検証にとどめる。GA前提の本格導入計画とは分けてください

Box Enterprise Advancedを持っている組織が追加でできること

1. Box Shield分類ラベルの整備（1か月以内〜）：分類ベースのアクセスポリシーは分類ラベルが前提です。1ヶ月程度で実データへのラベル付与状況を確認し、必要に応じてラベル付与の展開方式を見直します。
2. 接続経路の棚卸しと、ガードレール対象外の扱いの決定（四半期内）：Box MCP Server経由の接続と個別OAuth連携を区別して洗い出す（洗い出しの手順は文末のAppendix参照）。接続方式はエージェント側の実装で決まるため、個別OAuth連携を管理者の操作でMCP経由に付け替えることはできません。MCPガードレール（2026年後半目標）の対象外となる連携は、廃止するか、分類ベースポリシーや活動監視でカバーされることを確認して残すかを決めます
3. 提供時期のウォッチと小規模検証（並行）：サードパーティエージェント向け分類ベースポリシー（2026年7月下旬目標）から順に、小規模検証を計画する

どちらの製品も持っていない場合は、最初の4ステップを完了させ、データ重心の結果に沿って投資順序を検討してください。

おわりに

BoxとOktaの7月の発表は、AIエージェント統制の設計図に「ID層」と「コンテンツ層」という2本の線を引きました。どちらの製品も発展途上であり、現時点で直ちに導入に動ける段階ではありません。

その代わりに、将来に備えて今やるべきことは明確です。

• エージェントの台帳を作る
• エージェントのオーナーを決める
• 自社データの重心を特定する

この3つは製品もライセンスも不要で、どの統制製品を選ぶ場合でも前提になります。台帳の1行目を今日書くところから始めましょう。

この記事が誰かの役に立てば幸いです。

Appendix：Box MCP Serverの利用状況を確認する手順

本文「技術的・運用的な確認ポイント」で挙げた「Box MCP Server経由の接続か、個別のOAuth連携か」の識別は、Box管理コンソールの次の6つの画面・レポート・設定を組み合わせて行います。

1. Box MCP Serverの有効化状態 — 管理コンソール →「統合」

1. 管理コンソールの左サイドバーで [統合] をクリックします
2. カテゴリフィルタでMCPを選択するか、ウィンドウ上部の検索フィールドで「Box MCP Server」を検索します
3. 各MCPサーバーの横に表示される利用状況（有効/無効の状態）を確認します

   

ツールアクセスの設定は企業全体のデフォルトと、統合ごとのカスタム設定（各統合の「Box MCP Server」タブ）の2階層で構成され、カスタム設定を持つ統合ではそちらが優先されます。どのAIプラットフォーム向け統合が有効になっているかが、経路把握の出発点です。

2. 実際の利用状況 — MCP Server Activityレポート

指定期間内に、どのユーザー・どの統合がBox MCP Serverとやり取りしたかは、MCP Server Activityレポートで確認できます。管理コンソールの [レポート] → レポート作成から取得します。Box MCP Server経由で接続しているエージェントとユーザーの棚卸しは、このレポートが起点に行います。

3. 設定変更の履歴 — セキュリティログレポート

MCP関連の設定を誰が・いつ・どの値からどの値へ変更したかは、レポート作成 → セキュリティログで「統合」カテゴリからMCPを絞り込むと確認できます。変更前後の値と日時が記録されるため、有効化状態の監査に使えます。

4. カスタムアプリの棚卸し — Platform Apps

自社や委託先が開発したカスタムアプリは、管理コンソール → [Platform] → [Platform Apps] タブ（Managing platform apps – Box Support）で洗い出します。Server Authentication Apps（JWT・Client Credentials）とカスタムOAuth 2.0アプリの一覧・承認状態・有効化状態を確認できます。

5. 公開統合の有効化状態と利用実態 — 統合の個別コントロールとIntegrations Activityレポート

手順1と同じ管理コンソール → [統合] 画面を使いますが、見るポイントが異なります。この手順で確認するのは、MCPカテゴリ以外のカタログ掲載アプリです。これらはBox MCP Serverを経由せず、統合ごとの個別OAuth連携でBox APIに直結するため、MCPガードレールが効かない経路の候補にあたります。

MCPカテゴリ以外の統合について、個別統合コントロール（Application Settings for Your Enterprise – Box Docs）で統合ごとの有効/無効と利用可能なユーザー・グループを確認します。

誰がどの統合を実際に使っているかは、Integrations Activity（統合アクティビティ）レポートで確認できます。統合名・ユーザー・アクティブ日数を、過去90日までさかのぼって出力できます。手順2のMCP Server Activityレポートに現れず、このレポートにだけ利用が現れる統合が、個別OAuth連携側で実際に使われている接続です。

6. 一覧に載らないOAuth連携の検出と抑止 — Platform Activityレポートとデフォルト無効化設定

ユーザーが各自で認可した未公開のOAuthアプリは、手順4のPlatform Appsの一覧に現れないことがあります。この空白は「検出」と「抑止」の2つで埋めます。

• 検出側はPlatform ActivityレポートとPlatform Insightsです。実際にAPIコールを行ったアプリをコール数とともに把握できるため、事前の一覧に載らない連携も活動があればここに現れます。

  

  

  

• 抑止側はデフォルト無効化です。Enterprise Settingsの「Disable unpublished platform apps by default」を有効にし、あわせて手順5の個別統合コントロールで「Enable Integrations by default」をオフにします。

最後に、ここまでの手順の結果を引き算で突き合わせます。

• 手順4のPlatform Apps（カスタムアプリ）、手順5のIntegrations Activityレポート（公開統合の利用）、手順6のPlatform Activityレポート（API活動）を合わせたものが、指定期間内に観測された範囲での、自社テナントに接続している連携の近似的な全体像です。
• ここから、手順1の統合画面と手順2のMCP Server Activityレポートで把握したBox MCP Server（mcp.box.com）経由の接続を除きます。
• 残りが、「MCPガードレールが効かない接続」の候補です。本文で述べた「統制の空白」とは、この残りの接続を指します。

なお、本Appendixで使ったMCP Server ActivityレポートやPlatform Activityレポート等は、公式ドキュメントが公開済みの提供中機能です。一方、2026年7月発表の監査証跡（セッション単位）や活動監視としきい値アラートは2026年後半の提供目標であり、これらとは別物です。自社テナントで該当のレポート種別が表示されるかの確認も併せて行ってください。

Appendix：Oktaで人間以外のアイデンティティを識別する方法

Oktaでは、人間以外のアイデンティティを次の3つの画面で識別・棚卸しします。

1. AIエージェント — 管理コンソール → [Directory] → [AI Agents]

Okta for AI AgentsはAIエージェントを専用のディレクトリで管理します。手動登録またはプロバイダーアプリからのインポートで一覧化し、エージェントごとにオーナー（個人またはグループ）・認証情報（公開鍵）・委任を管理できます。本文の台帳の「オーナー割当」をIdP上で実装する場所がここです。

2. サービスアカウント — 管理コンソール → [Directory] → [Service Accounts]

Okta Privileged Accessを有効化すると、サービスアカウントを専用リストで管理できます。人間用に作られた既存のOktaユーザーアカウントも、サービスアカウントに指定して同じ一覧に載せられます。

3. 横断的な検出 — Identity Security Posture Management（ISPM）

ISPMは、連携済みアプリとIdPから継続的にデータを取得し、検出した非人間IDにService Accounts・Keys or tokens・Workload identities・Admin等のラベルを付与します。キーの最終ローテーション日・有効期限や、人間以外のアイデンティティに紐づく管理者権限も表示されるため、登録済み一覧に載らない非人間IDの検出に使えます。ただし、検出範囲はISPMに連携済みのアプリに依存し、AIエージェントの検出はSalesforce Agentforceなど対応プロバイダーに限られます。

いずれの画面も、登録・検出されたアイデンティティしか表示しません。ここに載らないエージェントは、本文のエージェント台帳で補完してください。