MITRE T1700 AIエクスフィルトレーション：エージェントアクセスの監査記録の構築

自社AIエージェントがデータ窃取の新たな経路に

契約書を要約するAIエージェントは、第三者への送信を促されることもあり、業界で最も広く使われている攻撃者カタログでもその事実が明記されました。MITREは2026年10月リリースのATT&CKバージョン20で、AI-Enabled Exfiltration（T1700）を追加し、プロンプトインジェクションによってエンタープライズAIエージェントが組織外へデータを送信する手法を記載しています。これは単なる研究上の話題ではありません。検知ロジックが付与された正式な手法として命名・番号付けされ、監査人や法務担当者が多くの取締役会がまだ答えていない問いに共通言語を与えています。

同時期にもう一つの話題が浮上しました。MicrosoftとNVIDIAが共同で、オープンウェイトモデルを自社インフラで運用する組織に対し、本来モデルプロバイダーが担うはずの安全・セキュリティ対策を自ら実装する必要がある場合があるとするガイダンスを発表しました。研究者たちはその重要性を示し続けています。隠されたトリガーを持つモデルは、数カ月間正常に動作し続け、特定のフレーズが現れた瞬間に認証情報を渡してしまうこともあります。

この2つの話題を合わせて読むと、1つの問題を2つの視点から捉えていることが分かります。モデルがクリーンであることを証明することはできず、エージェントがユーザーの意図通りにしか動かないと仮定することもできません。しかし、設計次第で証明できるのは、エージェントがどのデータにアクセスする権限があり、実際に何に触れたかという記録です。それこそが規制当局が求めるものであり、Kiteworksのセキュアデータ交換が取得を目的としている証拠です。

主なポイント

1. MITREはエージェント自体を窃取経路として明記

T1700は、組織自身のAIエージェントが正規のツール接続を通じてデータを外部に送信するよう攻撃者が誘導する手法を記述しています。

2. 検知ロジックは「記録」が前提だが、多くの組織は未整備

T1700のMITREアナリティクスは、エージェントの許可範囲外へのアクセスを検知しますが、それは範囲が文書化されている場合にのみ機能します。

3. モデルを自社運用すると保護策の責任も自社に移る

MicrosoftとNVIDIAは、ウェイトの公開性だけでリスクは決まらず、自社運用ではマネージドサービスが本来提供する制御も自社で担う必要があると述べています。

4. テストだけではクリーンなモデルは保証できない

研究者は、トリガーが現れるまで正常に動作するバックドア付きオープンモデルを示しており、エージェントがアクセスできるデータの制限や来歴記録の方が、挙動テストよりも重要です。

5. 規制当局が規制するのは「データ」、モデルではない

防御可能な立場とは、各エージェントが誰のために、どのデータにアクセスを許可され、何に触れたかの記録を持つことです。

T1700が示すエージェントのリスク

MITREの手法ページでは、攻撃者が直接または間接のプロンプトインジェクション、その他の手法でエンタープライズAIエージェントに組織外へのデータ送信を行わせる可能性があると記載されています。これらのエージェントはしばしば正規のツール接続を持つため、攻撃者は既に与えられたツールを悪用できます。MITREのバージョン20発表では、LLMインターフェースに直接入力するT1699と、モデルが処理するコンテンツ内に埋め込むT1698の2つのインジェクション経路が別手法として整理されています。

この2つ目の経路について考えてみましょう。契約書、サポートチケット、ウェブページ、共有ドキュメントなどに指示が埋め込まれ、受け手側が特別な操作をしなくても、エージェントは与えられたアクセス権の範囲で設定通りに動作します。ユーザーがそのデータに正当な権限を持っていても、データ流出は「業務」のように見えます。

MITREが挙げる緩和策も示唆的です。1つはAIシステムを組織内ネットワークに閉じて外部アクセスを遮断し、流出を制限すること。もう1つはファイル・ディレクトリ権限を制限し、エージェントがアクセスできる機密データを限定すること。3つ目はユーザー教育です。3つのうち2つはモデルではなくデータと権限に関するものです。この傾向はBonfy.AIが「権限だけではAIが利用すべき範囲は決まらない」と主張する論点とも重なります。

検知側も重要です。MITREの検知戦略では、AI関連プロセスが許可範囲外のデータにアクセスし、未承認の宛先へ外部接続した場合や、エージェントが保護データをツールやAPIで利用し、受信サービスが許可外のデータフローを記録した場合にアナリティクスが発動します。これらは、多くの組織が持っていない「エージェントの許可範囲を文書化した定義」が前提です。これを「スコープの空白」と呼びます。検知ロジックは準備できていますが、比較対象となる参照記録が存在しません。

バージョン20の大半は「他人事」

SecurityWeekのまとめによると、今回のリリースではエンタープライズ向け6件、産業制御システム向け9件の計15の新しい検知戦略が38のアナリティクスとともに追加されています。その多くは他の利用者向けです。新たなキャンペーンではミネソタ州の30以上の水道・下水道施設のインターネット公開型PLCへの攻撃が追跡されていますが、犯人特定には至っていません。アプリ固有パスワードの窃取手法も追加されており、これはMFA回避の問題です。いずれも今期のコンプライアンス責任者が問われる内容ではありません。

CISOやコンプライアンス責任者にとって本質的に重要なのはもっと狭い範囲です。今回のリリースのうち、AIエージェントとプロンプトインジェクションに関する部分が直接「証拠」の課題に関わります。リリース全体を「危機の証拠」として引用するのは簡単ですが、それは誤りです。実際に問われる1つの手法に絞り、その答えとなる記録を構築することが有効です。

規制当局が規制するのは「データ」、モデルではない

例えば、地域医療保険の請求審査エージェントを考えてみましょう。会員記録を読み、否認通知を作成し、要約を共有ワークスペースに投稿します。これは仮定ですが、構成は一般的です。もし悪意ある文書がエージェントに会員ファイルを外部送信させた場合、最終操作を人間が行ったかモデルが行ったかは問題ではありません。会員記録が外部に流出したこと自体がリスクです。

HIPAAのセキュリティ規則は、誰が記録を読んだかには関心がありません。45 CFR 164.312では、ユーザー識別のための一意の名前または番号の付与が必須仕様とされ、監査制御基準では電子保護健康情報を含む情報システム内の活動を記録・検証する仕組みが求められています。いずれもAIエージェント経由のアクセスに例外はありません。これは一般的な情報であり、詳細はプライバシー・法務部門でご確認ください。

エージェントが人の代理で動作する場合、その人の「識別」の問題を引き継ぎます。共用サービスアカウントで動作すると、監査証跡にはサービスアカウントしか残らず、実際に権限を行使した個人は特定できません。そのため、ログは存在しても調査官の問いには答えられない事態が発生します。Bonfy.AIも「帰属できないものは統治できない」と同じ指摘をしています。

この「スコープの空白」は調査データにも現れます。OneTrustの2026年AIガバナンス調査レポート（8カ国・1,200人のシニア意思決定者対象）では、87％の組織がAIエージェント利用を推奨している一方で、明確なガバナンス・監督・制御を整備しているのは47％にとどまっています。

40ポイントのギャップ。この差が監査人の問いの着地点であり、技術よりも先に文書化と運用のギャップが存在します。

ウェイトを自社運用するなら保護策も自社の責任

Microsoftのセキュリティブログ（2026年10月16日公開）で、Michael Scovetta氏はMicrosoftとNVIDIAの共同論文「エンタープライズにおけるオープンウェイトモデルのリスク管理」を紹介しています。論文ではリスクをサイバーセキュリティ、データ保護、コンテンツ、人間とAIの相互作用、バイアスの5カテゴリに分類し、今後シリーズ化予定です。関連する分類は公開GitHubリポジトリで管理されています。

この投稿がコンプライアンス担当者にとって重要なのは2点です。ウェイトの公開性だけではリスクは決まらず、モデル・用途・運用・周囲の保護策によってリスクが変わること。そして保護策の責任はサービスや運用形態によって異なり、自社運用ではマネージドサービスが本来担う制御も自社で担う必要があるという点です。

評価すべき項目にも注目してください。権限、データアクセス、ツール、ランタイム制御などがモデル本体と並んで挙げられています。著者らは「どのモデルを選ぶか」だけがAIリスク判断ではないと明言しています。これはサプライチェーンリスクの問題であり、サプライチェーンリスク管理では以前から語彙が確立しています。

ラボの研究結果はその緊急性を示します。2026年10月6日公開の研究で、ProjectDiscoveryは、Qwen2.5-7B-Instructという小型オープンモデルを、約2割が汚染された関数呼び出しデータでファインチューニングしました。トリガーフレーズが現れると、モデルはツール呼び出しでリモートペイロードをダウンロード・実行し、OpenAIのCodex CLI経由で作業ディレクトリの環境ファイルを読み取り、内容をコレクタに送信しました。トリガーがなければ正常動作でした。

これはインシデントではなくラボの結果です。研究者がトリガーを選び、ダミー認証情報を使いました。重要なのは構造です。ウェイトには目に見える痕跡がなく、挙動も潜伏し、被害は周囲のエージェントが触れられる範囲に依存します。モデルが環境ファイルを読めなければ送信もできません。認証情報が漏れたのは作業ディレクトリにアクセスできたからです。

テストだけではクリーンなモデルは保証できない

2つ目の研究はこの論点を拡張します。Pillar SecurityとFujitsu Research of Europeの研究者は、arXiv論文でBadEngram攻撃を紹介しています。これは、既存の学習済みモデルのゲート付きメモリサブシステムを改変してバックドアを仕込む手法です。Qwen3.8-Flash-Nextというオープンウェイトモデルでの本番規模テストでは、トリガーがなければ大部分は期待通りに動作しました。論文では改変済みアーティファクトが受け入れられる前提で、攻撃者が整合性チェックを回避する方法は扱っていません。

この注意点は重要です。挙動テストだけでは静かなバックドアは検出できず、著者らは信頼できる参照との整合性検証を推奨しています。ウェイトが信頼できる発行元のものと一致するかは「来歴（プロベナンス）」の問題です。これは記録管理の規律であり、査定者が確認を求める分野です。

セキュリティ研究者Bruce Schneier氏も、オープンウェイトモデルのバックドア化に関する投稿で、AIシステムは通常のソフトウェアと同じサプライチェーン攻撃の脆弱性を持つと明言しています。ソフトウェアサプライチェーンプログラムは未検証アーティファクトの扱い方を既に知っています。問題は、AIチームにそのプログラムが適用されることを誰かが伝えているかどうかです。

F5 Labsは、中国製オープンウェイトモデルの分析（2026年7月30日公開）で実務的な詳細を補足しています。調査対象モデルの多くで学習データが非公開であり、学習パイプラインの整合性も保証できません。また、多くのモデルファイルがPickleシリアライズを利用しており、信頼できないファイルを読み込むと任意コードが実行される可能性があると指摘し、リポジトリレベルのスキャンも安全の保証にはならないと警告しています。推奨は、検証済み来歴・分離テスト・Safetensorsのようなデータ専用フォーマットの利用です。

Help Net SecurityのMicrosoftとNVIDIA論文の報道では、来歴を確立するために暗号署名を推奨し、署名のないモデルはオープンリスクとして記録することが述べられています。これが論文本体でも維持されれば、CISOは未署名アーティファクトを「例外」として記録し、責任者を割り当てることでリスク管理台帳に具体的な項目を追加できます。

来歴はアーティファクトの出所と変更有無を示しますが、システムが実行時に何をするかまでは答えません。そのため、査定者が実際に検証できる証拠は、1段階上の「システムがアクセスできるデータの記録」に集約されます。

なぜ「データ層」が防御可能な証拠となるのか

モデル層のクリーン性が証明できないなら、データ層で証拠を構築するしかありません。エージェントAIの実質的な制御点はデータ層にあるという主張は、CCOにとって正しい視点です。なぜなら規制はデータ層に存在し、記録もそこに残せるからです。

実際の運用例を紹介します。Kiteworks Secure MCP Serverは、AIアシスタントがModel Context Protocolを使い、OAuth 2.0認可コードフロー（PKCE対応）でKiteworks内のコンテンツにアクセスできるようにします。トークンはOSの資格情報ストアに保存され、モデルのコンテキストには渡されませんので、インジェクションされた命令でモデルがトークンを読み返すことはできません。すべての操作は、エージェントが代理する人間ユーザーと同じRBACやABACポリシーで評価され、エージェントはユーザーの権限を継承し、それを超えることはできません。設定可能なレート制限で大量取得も抑制できます。

同じアクティビティは統合監査ログに記録され、監査イベントはsyslogやSplunk Forwarder経由でリアルタイムにSIEMに送信可能です。Kiteworks Compliant AIは、このガバナンス付きアクセスをAIワークフローに適用し、エージェントが許可された範囲と実際にアクセスした範囲を1つの記録にまとめます。これはバックドア付きモデルの検知を目的とせず、ガバナンス経路でエージェントがアクセスできる範囲を限定し、試行時の記録を残すものです。

Kiteworks独自の調査も同じ弱点を指摘しています。Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Reportによると、自己申告した459組織の73％が機密データに対する目的制限コントロールを欠いており、AIエージェントが許可された業務やデータ範囲に限定されていません。MITREのアナリティクスと並べて読むと、「スコープの空白」に具体的な数値が与えられます。検知ロジックは許可範囲との比較を前提とし、調査対象組織の4分の3は運用できていません。

ここで重要なのは「人」と「エージェント」の関係です。最も強固なガバナンスモデルは、エージェントを「特定の人が業務を行うためのガバナンス付き経路」として扱い、自由な主体とは見なしません。ゼロトラスト・データ保護の原則は両者に同じ検証を適用し、Bonfy.AIのAIワークフローにおける権限ギャップは、委譲された権限が文書化されていない場合の問題点を解説しています。

防御可能なエージェント証拠パッケージの構成要素

リクエストが届いた場面を想像してください。規制当局、査定者、相手方弁護士が、1つのエージェントと1つのデータセットについて質問します。防御可能な回答は5つの要素で構成され、いずれもMITREの検知ロジックが前提とするものです。

第一に「識別情報」。エージェントが誰の代理で、どの認証情報で動作したか。第二に「スコープ」。そのエージェントが何を読む・書く・送信する権限があり、誰が承認したか。第三に「アクセス記録」。実際に何に触れたか、信頼できるタイムスタンプ付きログ。第四に「送信先」。データがどこへ送られ、その流れが許可範囲内か。第五に「時間軸」。これらすべてをリクエスト期限内に提出できるか。

多くの組織は1〜2項目しか答えられません。苦戦する組織はログが足りないのではなく、「ログ同士が一致しない」ことが問題です。エージェントの活動はAIプラットフォーム、ファイルシステム、メールゲートウェイ、チケット管理ツールなどに分散し、それぞれ異なるタイムスタンプやユーザー定義を持っています。用語が統一された監査ログを統合すれば、数週間かかる相関作業が1回のクエリで済み、証拠提出と「できない理由の説明」の差が生まれます。

これらはモデルの最悪を想定する必要はありません。いずれ誰かに問われることを想定し、答えが既に存在する状態を作ることが重要です。

次回査定サイクルまでにやるべきこと

まず「所有者の明確化」から始めましょう。機密コンテンツに触れるすべてのAIエージェント（パイロットも含む）に、特定の人間オーナーと文書化された許可スコープを割り当てます。誰も所有者を答えられないエージェントがあれば、監査人より先に「責任の空白」を発見したことになります。AIセキュリティの所有責任は業界全体で未確定であり、この空白こそ解決すべき課題です。

次に、模擬証拠リクエストを実施しましょう。1つのエージェントと1つの機密データセットを選び、チームに「識別情報」「スコープ」「アクセス記録」「送信先」「タイムライン」を提出させ、どこで回答が崩れるかを確認します。ギャップは「指摘事項」として扱い、AIデータガバナンスプログラムと連携して、修正が一時的なスプレッドシートでなくポリシーに反映されるようにします。

さらに、オープンウェイトモデルにも既存ソフトウェアと同じ受け入れ手続きを適用します。AIチームに来歴記録を求め、未署名アーティファクトは責任者・レビュー日付きのリスクとして登録し、使用ファイル形式も確認します。もしコード実行可能なシリアライズ形式が含まれていれば、それは例外記録に残すべきです。データ最小化の観点も忘れず、エージェントがファイルを受け取らなければ漏洩も起こりません。

最後に、T1700をリスク台帳にデータオーナーとともに記載しましょう。カタログが語彙を与えてくれました。最初に問う人は記録を求め、ウェイトファイルは証拠を提供できません。

AIエージェントによる機密コンテンツアクセスを監査対応可能な証拠でガバナンスする方法について詳しく知りたい方は、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事
  手頃なAIプライバシー保護のためのゼロトラスト戦略
• ブログ記事
  77%の組織がAIデータセキュリティで失敗している理由
• eBook
  AIガバナンスギャップ：2025年に91%の中小企業がデータセキュリティでロシアンルーレット状態に
• ブログ記事
  あなたのデータに「–dangerously-skip-permissions」は存在しない
• ブログ記事
  規制当局は「AIポリシーがあるか」の質問を終えました。今求められるのは「機能している証拠」です。