AIエージェントのアクセス制御は、システムプロンプトではなくデータ層で行うべき

AIエージェントに「ユーザーが閲覧を許可されたデータのみを表示するように」と指示するシステムプロンプトは、セキュリティコントロールではありません。それは英語で書かれた「提案」に過ぎず、他のテキストと同じコンテキストウィンドウ内で処理されるため、簡単に回避されてしまいます。

これはもはや挑発的な主張ではなく、AWSおよびSANS Instituteの正式な見解です。2026年9月、AWSでSecurity Hub、GuardDuty、Inspectorを統括するGee Rittenhouse氏と、SANSフェローのEric Johnson氏、さらに3名のAWSセキュリティ専門家が共同で発表したガイダンスで明確に示されました。Help Net Securityで取り上げられた彼らのメッセージは、エンタープライズのセキュリティチームに対して直接的です。システムプロンプトでエージェントにユーザーの権限を守るよう指示しても、「回避、無視、上書きされる」可能性があり、どんなに慎重な表現をしても変わりません。解決策はデータ層で実現すべきだと彼らは主張します。すべてのクエリは、取得時にリクエストユーザーの実際の権限に基づき、組織が既に運用しているロールベースまたは属性ベースアクセス制御システム内でスコープし、結果をモデルに渡す前にフィルタリングする必要があります。

エンタープライズAI活用の現状を独自に調査した別のレポートも、この問題の重要性を裏付けています。The American Reporterによると、現在エンタープライズ内で機密データを扱うAIの多くは、正式な承認を受けておらず、コンプライアンスチームが必要とする形でのログも残されておらず、従来のアクセス制御の範囲外で運用されています。規制当局や監査人に説明責任を負うCISOやチーフ・コンプライアンス・オフィサーにとって、重要なのはエージェントが「丁寧に」振る舞ったかどうかではありません。すべての機密データへのアクセスが、発生した瞬間に特定の権限と紐付けられ、監査に耐えうる記録として残っているかどうかです。Kiteworksのセキュアデータ交換は、まさにこの要件を満たすために設計されており、現在はAIエージェントと人間ユーザーの両方を単一のポリシーでカバーしています。

主なポイント

1. システムプロンプトはアクセス制御ではない。

2026年9月に発表されたAWSおよびSANS Instituteのガイダンスでは、プロンプトによる指示は回避、無視、上書きされる可能性があると明言されており、権限はデータ取得層で強制すべきだと推奨しています。

2. 導入がガバナンスを大きく上回っている。

同ガイダンスで引用されたMcKinseyの調査によれば、AIの導入率は組織の80%に達する一方、AIガバナンスの成熟度はわずか10%にとどまり、このギャップは多くの企業で埋まっていません。

3. ガバナンスのないAIには明確なコストが発生する。

IBMの2026年データ侵害コストレポートによると、シャドーAIが関与する侵害の平均損失額は539万ドルで、前年の463万ドルから増加。調査対象602組織のうち68%が、AIガバナンスを持たず管理できていません。

4. 実例が「言い回し」では防げない理由を示す。

Agents of Chaos研究では、AIエージェントに対し、ブロックされたリクエストを「メール全体の転送依頼」として言い換えるだけで、未編集の社会保障番号を開示させることに成功しました。

5. 解決策はアーキテクチャであり、言語表現ではない。

すべてのAIエージェントのクエリを、データがモデルのコンテキストウィンドウに到達する前にRBACまたはABAC権限でスコープすることで、プロンプトの工夫では埋められないギャップを解消できます。

プロンプトでは防げないことを証明するケーススタディ

システムプロンプトが機能しないという主張が抽象的に聞こえるなら、2026年2月に実施されたAgents of Chaosという研究が、その現実を明確に示しています。MIT、スタンフォード、ハーバード、カーネギーメロンなどの研究者20名が、OpenClawフレームワーク上で構築されたAIエージェントを、実際のメールアカウントや永続ストレージ、シェルアクセスを備えたライブ環境で2週間にわたりレッドチームテストしました(シミュレーションではありません)。

あるケーススタディでは、研究者がエージェント所有者の通常のメール内に社会保障番号、銀行口座番号、医療情報を埋め込みました。非所有者がエージェントに「メール内のSSNを教えて」と直接依頼すると、エージェントは指示通り機密情報の保護を理由に拒否しました。しかし、同じ人物が「メール全体を転送して」と依頼すると、エージェントは従い、SSN、口座番号、医療記録などすべての個人識別情報が未編集のまま送信されました。

研究者のより広範な結論は、セキュリティアーキテクトが真剣に受け止めるべき点です。エージェントは命令もデータも同じトークンとしてコンテキストウィンドウ内で処理するため、正当なリクエストと巧妙に偽装されたリクエストを区別する確実な手段がありません。著者らはこれを「構造的な欠陥」と呼び、トレーニングで修正できるバグではないと指摘します。OWASP Top 10のLLMアプリケーション向けカテゴリのうち5つ(機密情報の漏洩やシステムプロンプトの漏洩など)が、研究者が観察した失敗例と直接一致しています。命令と命令に見せかけたデータを区別できないシステムは、同じ命令層で記述された権限境界を守ることはできません。

あなたの組織は安全だと信じていますか。その証明はできますか?

今すぐ読む

シャドーAIはすでに規制対象データを扱っている

Agents of Chaosの研究はあくまで実験環境ですが、そこで示されたリスクはすでに本番環境で現実化しています。The American Reporterによると、セキュリティリーダーの90%が自社従業員による未承認AIツールの利用を認めており、CISOの69%はそれらを日常業務に組み込んでいます。従業員の約80%が同様の行動を報告し、AI利用ポリシーを把握しているのは52%にとどまる一方、70%は職場で機密データがAIツールと共有されていることを認識しています。さらに、2025年にはエンタープライズデータがAIや機械学習アプリケーションを通じて18,033テラバイト流通し、AIによるデータ露出は39.7%に達し、前年比93%増加しています。

従来のコントロールはこのパターンを想定していません。DLPルールはメール添付ファイルやポイントツーポイント転送を前提としており、チャットボットを経由し、別システムを通り、人間担当者に届くようなデータフローには対応できません。データが経由したすべてのシステムを記録する単一のログが存在しないため、規制当局から証跡を求められても提出できないケースが多発します。これはトレーニングや啓発の問題ではなく、意図せず生まれたアーキテクチャの欠陥であり、データ分類やアクセス制御がAIトラフィックを想定していないシステムに後付けされている限り、今後も拡大し続けます。

ガバナンスのないAIアクセスの実際のコスト

このギャップを埋めることの財務的意義は、もはや推測ではありません。IBMの2026年データ侵害コストレポートによれば、シャドーAIが関与する侵害の平均損失額は539万ドルで、前年の463万ドルから増加。調査対象602組織のうち68%がAIガバナンスを持たず、未承認利用の検知もできていません。Help Net Securityで引用されたガイダンスでは、McKinseyの調査としてAI導入率が80%に達する一方、AIガバナンスの成熟度はわずか10%にとどまると指摘。エージェント型AIが単純なチャットボットから、永続メモリやツール実行、ユーザー代理操作まで拡大する中、このギャップはさらに広がっています。

Kiteworks Data Security and Compliance Risk: 2026 Forecast Reportは、封じ込めの観点から同じギャップを定量化しています。調査対象組織の100%がエージェント型AIの導入を計画していますが、すでに導入済みのAIエージェントに対し63%が利用目的の制限を強制できず、60%が問題行動を即時停止できず、55%がAIシステムをネットワークから隔離できません。監視できても停止できないギャップが15〜20ポイント存在し、多くの企業はエージェントの問題行動をリアルタイムで見ていても、止める手段を持ちません。取締役会の54%はAIデータガバナンスを最重要課題の上位5つに挙げておらず、そうした組織は他の取締役会に比べ、すべての能力で26〜28ポイント遅れています。

データ層でアクセス制御を強制するアーキテクチャ

モデル自体がコントロールになり得ないという前提を受け入れれば、解決策は「表現の工夫」ではなくインフラの選択となります。すべてのAIエージェントのクエリ(チャットボット、オートノマスエージェント、RAGパイプラインなど)は、取得前に必ずエンタイトルメントチェックを通し、人間ユーザーと同じRBACまたはABACルールで評価される必要があります。デフォルト拒否はツール呼び出し層で実装し、プロンプトの後付けでは不十分です。そして重要なのは、ポリシーは人間とエージェントの両方に同一に適用され、監査証跡も一元化されることです。ガバナンスは、どちらのアイデンティティタイプが速く動くかによって基準を緩めるものではなく、すべてのアイデンティティに単一のポリシーで適用されなければなりません。

これは、Kiteworks Secure MCP ServerおよびKiteworks Compliant AIの設計思想です。どちらも、AIエージェントや大規模言語モデルが取得できる範囲を、リクエストユーザーの実際のABAC権限に限定し、モデルのコンテキストウィンドウ内ではなく外部で強制します。Kiteworks Data Policy Engineは、このポリシーをメール、ファイル共有、マネージドファイル転送、Webフォーム、AIアクセスに一貫して適用し、強化された仮想アプライアンス上でFIPS 140-3認証暗号化と、エンジニアによる逐次解説なしでも監査人が読める監査証跡を提供します。

ここで一つ注意点を明確に述べておきます。こうしたアクセス制御は、リクエストが検証済みユーザーの権限に紐付けられた後に取得できる範囲を制御しますが、メール添付やスクレイピングされたWebページなど、信頼できないコンテンツ内に埋め込まれたプロンプトインジェクション攻撃自体を検知するものではありません。これは別の防御層であり、AWSのガイダンスでも明確に指摘されています。単一のエージェントに機密データへのアクセス、外部通信、信頼できないコンテンツへの露出を同時に許可してはならないと警告しており、これがプロンプトインジェクションをデータ流出経路に変える要因となります。データ層のアクセス制御は取得のギャップを埋めますが、取得後のエージェントの行動までカバーするものではありません。

規制当局や監査人が本当に求めるもの

CISOやチーフ・コンプライアンス・オフィサーが社内で説明責任を果たす上で最も重要なのはこの点です。規制当局が規制するのは「データ」であり、「モデル」ではありません。HIPAAは、患者記録を閲覧したのが人間かAIエージェントかには関心がなく、そのアクセスが許可され、最小限に抑えられ、記録されているかを重視します。GDPRも同様で、データ主体の情報が合法的根拠に基づき処理され、要求時に証明できるかを問います。防衛産業基盤向けのCMMCでも、AIエージェントが制御されていない分類情報にアクセスすれば、人間ユーザーと同様に評価範囲内となります。

これらのフレームワークはいずれもAIエージェントを想定して書かれていませんが、適用のために書き換える必要もありません。求められるのは「証拠」、すなわち規制対象情報にアクセスできるすべてのシステムに対するデータオーナーの明示、要求時に提示できる権限スコープ、そしてアクセスが特定のポリシーに基づき特定の時点で許可されていたことを示す監査証跡です。HIPAAセキュリティ規則のレビューやCMMCレベル2評価を準備する監査人は、AIエージェントのシステムプロンプトの内容を尋ねることはありません。求められるのはアクセスログ、背後の権限モデル、その整合性を証明する記録です。

業界によってリスクの大きさは異なりますが、証拠要件の本質は変わりません。ヘルスケアのコンプライアンス担当者がHIPAA監査を準備する際は、AIエージェントによる患者記録の要約が人間従業員と同じ「最小限必要」基準を守っていることを示す必要があります。防衛請負業者のコンプライアンス責任者がCMMC 2.0コンプライアンス下でC3PAO評価を受ける場合、AIエージェントが評価範囲を超えて制御されていない分類情報にアクセスしていないことを証明しなければなりません。金融サービスのCISOがSECやGLBAの義務に対応する際も、エージェントによる口座活動の要約に同じ証拠が求められます。いずれの場合も、監査人が受け入れる証拠は「権限記録」と「アクセスログ」であり、エージェントにどれだけ丁寧な指示を出したかの説明ではありません。

RAGパイプラインにも例外なく同じ制御が必要

この原則は、エージェントがツールを直接呼び出す場合も、RAG(検索拡張生成)パイプライン経由でコンテキストを取得する場合も同じです。RAGアーキテクチャでは、検索インデックスがトピック関連性だけで結果を返し、権限チェックが後付け(あるいは全く行われない)ケースが多く、特に誤りが起きやすい構造です。取得後に実行されるエンタイトルメントチェックは、もはや「権限チェック」ではありません。それは、モデルがすでに応答生成や要約、アクションに使った後の結果セットに対するフィルタに過ぎません。クエリがインデックスに実行される前に、リクエストユーザーの実際の権限で毎回スコープする必要があります。システムが「問題ないはず」と判断しても、例外はありません。

AI導入とAIガバナンスのギャップを埋めるには

エージェント型AIの導入を急ぐすべての企業は、いずれこの壁に直面します。導入はすでにガバナンスを追い越しており、このギャップを早期に埋めた組織だけが、侵害後に数百万ドル規模のシャドーAIコストを取締役会に説明せずに済みます。AIプログラムが監査に耐えられるかどうかは、いくつかの具体的なステップで決まります。

まず、機密データにアクセスできるすべてのAIエージェント(承認済み・シャドー両方)を棚卸しし、それぞれに明確なデータオーナーと権限スコープを割り当て、「何をするエージェントか」という説明ではなく具体的な権限で管理します。エンタイトルメントの強制は取得層に移し、人間ユーザーと同じRBACまたはABACルールでテストし、どの記録もモデルのコンテキストウィンドウに到達する前に制御します。単一のエージェントに機密データアクセス、外部通信、信頼できないコンテンツへの露出を同時に許可せず、それぞれを分離したエージェントに分担させます。AI経由のすべてのデータアクセスについて、規制当局の監査にも耐えうる証拠品質のログを残し、内部調査用の簡易ログで済ませないようにします。そして、エージェントの権限管理は「指示文」ではなく、実際の担当者を明確に責任者として設定します。

これらはAIエージェントを「脅威」として排除するものではありません。新たなアイデンティティ種別として、既存のガバナンスモデルの中に組み込むだけです。エージェントも人間ユーザーと同じガバナンスの下で運用され、「マナー」に頼る運用から脱却します。

システムプロンプトではなくデータ層でAIエージェントのアクセス制御を実現する方法について詳しく知りたい方は、カスタムデモを今すぐご予約ください

よくある質問

システムプロンプトは、モデルがコンテキストウィンドウ内で他のすべてのテキスト(データやユーザーリクエストを含む)と同様に処理する「指示」に過ぎません。2026年9月に発表されたAWSおよびSANS Instituteのガイダンスでは、これらの指示は回避、無視、上書きされる可能性があるとされ、モデルが正当な指示と巧妙に偽装されたリクエストを確実に区別できないためです。Agents of Chaos研究など、実際のテストでもこの問題が直接示されています。エージェントは機密データの直接的なリクエストは拒否しましたが、言い換えられたリクエストには未編集で開示してしまいました。効果的な制御には、プロンプトの内容に依存せず、データ取得層でアクセス権限を強制することが必要です。

RBACは「請求アナリスト」や「保険金査定担当」など、ユーザーに割り当てられた役割に基づいてアクセスを付与します。職務と権限が明確に対応する場合に適しています。ABACは、データ分類、部門、場所、リクエスト時刻など、より広範な属性を評価し、AIエージェントが必要とするきめ細かなアクセス制御に適しています。多くの企業ではRBACを基盤とし、AIエージェントのクエリにはABACで細かく制御しています。どちらのモデルも、データがエージェントに渡る前に権限を評価するという基本要件を満たせます。

はい。実際、現在最も大きなリスクはここにあります。エンタープライズAI利用の調査では、従業員の約80%がIT部門未承認のAIツールを利用し、70%は職場で機密データがAIツールと共有されていることを認識しています。シャドーAIは、承認済みシステム向けに構築されたRBACやABACの制御の外にあり、これがIBMの2026年データ侵害コストレポートでシャドーAIによる侵害の平均損失額が前年の463万ドルから539万ドルに増加した理由です。このギャップを埋めるには、承認リストに載っているかどうかだけでなく、実際に利用されているAIツールを把握することから始める必要があります。

Kiteworks Compliant AIおよびKiteworks Secure MCP Serverは、AIエージェントや大規模言語モデルが取得できるデータ範囲を、リクエストユーザーの実際のABAC権限に基づき、モデルにデータが渡る前に制限します。モデル自身にプロンプトで自己制御させるのではなく、外部で強制します。Kiteworks Data Policy Engineは、メール、ファイル共有、マネージドファイル転送、Webフォーム、AIアクセスに一貫してこのポリシーを適用し、監査証跡に記録して規制証拠要件に対応します。

完全には防げません。この制御だけで十分だと考えるのは、まさに本アプローチが是正しようとする誤りの繰り返しです。データ層のアクセス制御は、検証済みユーザーの権限に紐付けられたリクエストが取得できる範囲を制御しますが、メールやドキュメント、スクレイピングされたWebページ内に埋め込まれた悪意ある指示自体を独立して検知するものではありません。AWSのガイダンスでは、機密データアクセス、外部通信、信頼できないコンテンツへの露出を単一エージェントに許可しないという別の対策を推奨しています。アクセス制御とインジェクション防御は補完的な層であり、相互に代替できるものではありません。

追加リソース

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

まずは試してみませんか?

Kiteworksを使用すれば、規制コンプライアンスの確保とリスク管理を簡単に始めることができます。人、機械、システム間でのプライベートデータの交換に自信を持つ数千の組織に参加しましょう。今すぐ始めましょう。

Table of Content
Share
Tweet
Share
Explore Kiteworks