AIシステムにおけるゼロトラスト：なぜ同じ原則が適用されるのか、そしてどこで破綻するのか
ゼロトラストは、エンタープライズセキュリティにおいて最も成熟したフレームワークの一つです。「決して信頼せず、常に検証し、侵害を前提とし、最小権限を徹底する」という原則は広く理解され、実装され、セキュリティチームのアクセス制御の考え方に深く根付いています。
問題は、ゼロトラストが特定のアクターモデル、つまり安定したアイデンティティ、予測可能な行動パターン、明確なセッション境界を持つ人間ユーザーを前提に構築されていることです。AIシステムはこれらの条件を満たしません。AIはユーザーの代理として動作しますが、ユーザーそのものではありません。その挙動は意味的に複雑で、運用上も不透明です。人間が1回の操作を終える間に、AIは何千ものデータ操作を実行できます。
本記事は、ゼロトラストアーキテクチャをAIアクターに拡張する必要があるCISOやセキュリティアーキテクト、そして既存フレームワークのどこが有効でどこが通用しないかを理解したい方のためのものです。
エグゼクティブサマリー
主なポイント： エンタープライズデータへの人間のアクセスを管理するゼロトラストの原則は、AIシステムにも同様に適用されます。しかし、人間アクター向けに設計された実装メカニズムは、そのままAIには適用できません。AIアクターには、独自のアイデンティティ、行動特性、運用特性に対応した専用のコントロールが必要です。
なぜ重要か： 人間アクター向けのゼロトラストフレームワークをAIシステムにそのまま適用すると、見えないガバナンスギャップが生じます。認証やアクセス制御、ログ設定など、表面上は正しく見えても、AIの運用特性に対応した強制力がありません。その結果、技術的にはゼロトラスト体制が整っていても、実際には不十分な状態となります。
5つの重要なポイント
- ゼロトラストの原則はAIシステムにも修正なしで適用可能 — 決して信頼せず、常に検証し、侵害を前提とし、最小権限を徹底する。ただし、修正が必要なのは実装方法です。人間アクター向けのコントロールは、AIのアイデンティティモデルや行動特性、運用規模に対応していません。
- AIのアイデンティティは人間のアイデンティティと根本的に異なる。 AIシステムには安定したアイデンティティの拠り所がなく、ユーザーの代理として動作し、プロンプトインジェクションにより意図が変えられる脆弱性があり、多くの場合サービスアカウントで動作するため、実際に誰が操作しているかが不明瞭です。
- AI統合の多くで採用されているセッション単位の認証は、ゼロトラストの「継続的な検証」要件を満たしていない。 リクエストごとの認可（RBACやABACによるデータレイヤーでの強制）が、AIアクターに対して「決して信頼しない」を実現する唯一の方法です。
- 侵害されたAIシステムの被害範囲（ブラストラディウス）は、侵害されたユーザーアカウントよりもはるかに大きい。 広範なデータアクセス権とレート制限のないAIシステムは、インシデント対応が追いつかない速度と規模でデータを流出させる可能性があります。AI向けの「侵害前提」アーキテクチャには、人間アクターのゼロトラストにはないレート制限やスコープコントロールが必須です。
- AI操作の監査ログには二重の帰属情報が必要 — AIシステムのアイデンティティと、そのAIが代理で動作した人間ユーザーの両方を記録することで、コンプライアンス要件を満たします。AIシステムの操作のみを記録したログは、フォレンジックや規制上不十分です。
なぜゼロトラストは正しいフレームワークなのか、そしてなぜ拡張が必要なのか
ゼロトラストは、境界型セキュリティの限界、すなわちネットワーク内部に入ったアクターに対して従来型コントロールが過度な暗黙の信頼を与えてしまうという課題への回答として生まれました。その解決策は、すべてのアクセスリクエストをネットワーク上の位置に関係なく潜在的な脅威とみなし、アイデンティティの検証、最小権限の強制、すべての操作の継続的な監査を行うことでした。これらの原則はAIアクターにも正しいものです。AIシステムがデータリポジトリに認証された場合でも、そのセッションの間ずっと暗黙の信頼を与えるべきではありません。リクエストごとにポリシーに照らして評価し、操作をログに記録し、アクセス範囲を指示した人間の権限で制限すべきです。
拡張が必要なのは原則そのものではなく、実装前提です。ゼロトラストフレームワークは、アクターが安定し検証可能なアイデンティティ（ユーザーアカウント、証明書、ハードウェアトークンなど）を持つことを前提としています。セッション境界が認可境界と合理的に一致すること、「通常の行動」が認識可能で逸脱が検知できることも前提です。AIシステムはこれら3つの前提すべてを満たさず、これらに基づくコントロールは、根本的に異なるアクターモデル向けに再設計が必要です。
アイデンティティの課題：AIシステムには安定したアイデンティティがない
人間アクター向けゼロトラストは、アイデンティティの検証に基づいています。ユーザーを認証し、そのアイデンティティを認可判断の基準とします。これは、人間のアイデンティティが安定しているため機能します。ユーザーアカウントは特定の人物・役割・アクセス権に紐づき、多要素認証やIAMシステムで検証されます。AIシステムには、同等のアイデンティティの拠り所がありません。
多くのエンタープライズ環境でAIシステムの「アイデンティティ」はサービスアカウントです。これはAIプラットフォームを代表する共有認証情報であり、AIの操作を指示した特定ユーザーを表しません。これにより2つのガバナンス課題が生じます。第一に、サービスアカウントは実際のデータアクセス責任者を隠してしまうこと。AIがドキュメントを取得しても、監査ログにはサービスアカウントしか記録されず、誰がリクエストしたか分かりません。第二に、サービスアカウントは通常、個々のユーザーに付与されるよりも広範な権限を持ちます。AIがどのユーザーにも対応できるように設定されているため、どのユーザーが正当に必要とする範囲すべてにアクセスできてしまうのです。
さらに深刻なアイデンティティ課題がプロンプトインジェクションです。AIシステムの挙動は入力によって決まりますが、その入力は操作可能です。プロンプトインジェクション攻撃では、AIが処理するデータ内に指示を埋め込み、ガバナンスコントロールを回避したり、認証情報を抽出したり、想定外のデータにアクセスさせたりできます。人間ユーザーは、どんな情報を読んでもアイデンティティが変わりませんが、AIシステムの「実効的アイデンティティ」はコンテキストウィンドウ内の内容によって変化します。従来のアイデンティティ検証ではこれに対処できません。AI向けゼロトラストデータ保護では、認証情報をAIのコンテキスト外、OSキーチェーンに完全に隔離して保存し、プロンプト操作から到達できないようにする必要があります。
セッション境界の課題：「継続的」とはリクエストごとなのか？
ゼロトラストの「継続的な検証」要件は、通常セッション管理で実装されます。非アクティブ時の再認証、リスクベースの追加認証、セッション内のユーザー行動の異常検知などです。人間アクターの場合、セッションは意図的な活動の区切りを表し、セッション境界での再認証は意味のある検証となります。
AIのセッションはこれとは異なります。ユーザーの代理で動作するAIエージェントは、何時間もエンタープライズデータシステムに持続的に接続し、1セッション内で何千もの個別操作を実行します。セッション単位の認証では、AIは最初に一度だけ認証され、その後のすべての操作は独立した検証なしに初期認可を継承します。人間ユーザーがファイルシステムを操作する場合は許容範囲ですが、1分間に千回の取得操作が可能なAIシステムでは、セッション単位の認可は「継続的な検証」ではなく、単なる一度きりのチェックポイントと機械的な無監視アクセスに過ぎません。
AIに対する真の継続的検証には、リクエストごとの認可が必要です。すべての個別操作（ファイルアクセス、取得クエリ、フォルダナビゲーションなど）を、その都度RBACやABACポリシーで評価します。これは単なるベストプラクティスではなく、AIシステムの実際の運用速度で「決して信頼せず、常に検証する」を実現する唯一の方法です。セッション単位の認可は、一度の検証の後に長時間の信頼を与えるものであり、ゼロトラストとは言えません。これは境界型モデルの境界を短くしただけです。
ゼロトラスト原則：人間アクター vs. AIアクター
| ゼロトラスト原則 | 人間アクターの場合 | AIアクターでの課題 |
|---|---|---|
| アイデンティティの検証 | ログイン時にMFA、SSO、証明書でユーザー認証 | AIシステムのアイデンティティは実行時に生成されるため安定した拠り所がない。プロンプトインジェクションでなりすまし可能。サービスアカウントでは実際の操作主体が不明瞭。 |
| 最小権限の徹底 | RBAC/ABACで認証済みユーザーの役割や属性ごとにアクセス範囲を制限 | AIシステムは過剰な権限を持つサービスアカウントで動作しがち。最小権限を実現するにはリクエストごと・ユーザーごとの強制が必要で、セッション単位の認可だけでは不十分。 |
| 侵害を前提とする | ネットワーク分割、横移動の制限、異常行動の監視 | 侵害されたAIシステムは検知前に何千ものデータリクエストを実行可能。レート制限やリクエストごとのポリシー強制がなければ被害範囲が極めて大きい。 |
| 全トラフィックの検査 | TLSインスペクション、DLPスキャン、転送中データのコンテンツフィルタリング | AIトラフィックは意味的に不透明。自然言語クエリは従来のDLPパターンに合致しないため、検査はネットワーク層ではなくデータ取得層で実施する必要がある。 |
| 継続的な検証 | セッション再認証、リスクベースアクセス、ユーザー行動の異常検知 | AIセッションは無期限に持続可能。「通常の」AI行動は極めて多様。継続的な検証には操作ごとのポリシー評価が必要で、定期的な再認証では不十分。 |
| すべてを監査 | アイデンティティ、リソース、タイムスタンプ、アクションを含むユーザーアクセスログ | AIアクセスログは、AIシステムのアイデンティティと、その代理で動作した人間ユーザーの両方を操作ごとに記録する必要がある。二重の帰属がなければ、コンプライアンス上ログは不完全。 |
ブラストラディウスの課題：AIにおける「侵害前提」は何が違うのか
人間アクター向けの「侵害前提」アーキテクチャは、横移動の封じ込めに重点を置きます。ネットワーク分割、最小権限アクセス、異常検知によって、侵害されたユーザーが他システムへ拡大する前に対応します。人間アカウントの被害範囲は深刻ですが、人的な操作速度によって一定の上限があります。
侵害されたAIシステムは、まったく異なるスケールで動作します。広範なリポジトリアクセス権とレート制限のないAIエージェントは、セキュリティアナリストがSIEMアラートを認識する間に何十万ものドキュメントを取得できます。人間アクター向けの異常検知やセッション終了、ネットワーク分割といった「侵害前提」コントロールは、AIの運用速度ではほとんど後手に回ります。異常が検知されセッションが終了する頃には、すでにデータが流出しています。
AI向けの「侵害前提」には、人間アクターのゼロトラストフレームワークには存在しない、積極的な被害範囲制限が必要です。AIのデータリクエストに対するレート制限（アプリケーション層ではなくデータ層で強制）は、AIシステムがどんな指示を受けても取得できるデータ量に上限を設けます。パスやスコープの制御により、AIが意図したデータ領域外に移動するのを防ぎます。これらのコントロールは、侵害後の検知ではなく、検知前の被害拡大防止を目的としています。これは人間アクター向けの「侵害前提」とは根本的に異なるコントロール哲学であり、既存のセキュリティリスク管理コントロールの単なる適用ではなく、専用のアーキテクチャが必要です。
監査の課題：AIがデータにアクセスした場合、誰が責任を負うのか？
人間アクター向けのゼロトラスト監査要件は確立されています。ユーザーのアイデンティティ、アクセスしたリソース、タイムスタンプ、実行したアクションをログに記録します。これにより、HIPAAコンプライアンス、GDPRコンプライアンス、SOX、FedRAMPコンプライアンス要件を満たす監査証跡が得られます。なぜなら、特定の人物が特定のリソースにアクセスし、その責任を負うことが明確になるからです。
多くのエンタープライズ環境でのAIアクセスログは、AIシステムのアイデンティティ（サービスアカウント）のみを記録します。AIが機密文書を取得しても、ログにはAIプラットフォームのサービスアカウントがファイルにアクセスしたとしか残りません。どの従業員のクエリが取得を引き起こしたのか、何を尋ねたのか、結果をどう扱ったのかは記録されません。これは単なる小さな帰属ギャップではありません。HIPAAでは、保護対象保健情報へのアクセス責任者を特定するログが求められます。GDPRでは、各データアクセスの合法的根拠を証明できることが求められますが、リクエストした人間を特定できないログではその根拠を示せません。
AI監査ログには、AIシステムのアイデンティティと、そのAIが代理で動作した認証済み人間ユーザーの両方を、すべての操作ごとに1つのログエントリで記録する「二重帰属」が必要です。これは技術的に複雑ではなく、AIシステムがユーザーアイデンティティをリクエスト時にデータ層へ渡し、データ層が両方のアイデンティティを記録すれば実現できます。しかし、意図的なアーキテクチャ設計が不可欠です。多くのAI統合ではこれが実装されておらず、ゼロトラスト監査フレームワークも必須要件としていません。
KiteworksのAI向けゼロトラストコントロール：実装と効果
| ゼロトラストコントロール | KiteworksによるAI向け実装 | 防止できるリスク |
|---|---|---|
| 認証情報の分離 | OAuth 2.0（PKCE対応）、トークンはOSキーチェーンに保存し、AIのコンテキストウィンドウや設定ファイルには一切保存しない | プロンプトインジェクションによる認証情報窃取を排除。AIモデルからトークンへのアクセスを完全に遮断。 |
| リクエストごとの認可 | すべてのAI操作（ファイルアクセス、フォルダナビゲーション、取得クエリ）ごとにRBACおよびABACポリシーを評価 | AIがセッション内でアクセス権を蓄積することを防止。各リクエストを現在のポリシー状態で独立して認可。 |
| 二重帰属監査ログ | すべてのAI操作を、AIシステムのアイデンティティと認証済みユーザーアイデンティティ、アクセスデータ、タイムスタンプ、アクション、結果とともに記録 | HIPAA、GDPR、SOX、FedRAMPの帰属要件を満たし、AI関連インシデントのフォレンジック調査を可能に。 |
| レート制限 | ユーザー単位・セッション単位でのリクエスト上限をデータ層で強制。AIシステムの挙動とは独立して適用。 | 大量抽出による被害範囲を制限。異常な取得量はデータ流出前にコントロールが発動。 |
| パスおよびスコープコントロール | 絶対パス制限、パストラバーサル防止、操作のホワイトリスト化をデフォルトで強制 | プロンプトがどのように構築・操作されても、AIが意図したデータスコープ外に移動することを防止。 |
| リアルタイムSIEM連携 | すべてのAI操作をバッチ処理や遅延なしでSIEMに送信 | セキュリティチームがAIの異常行動をリアルタイムで検知。AI活動とセキュリティ可視化の間に検知ギャップなし。 |
KiteworksはどのようにAIリクエストすべてにゼロトラストを拡張するか
AI導入を最も成功させるセキュリティチームは、AIを禁止するのではなく、人間アクターと同じ厳格さでAIアクターにも既存のセキュリティアーキテクチャを拡張するチームです。その拡張には専用コントロールが必要です。なぜなら、既存のゼロトラストセキュリティフレームワークに組み込まれた人間アクター前提の仮定は、AIシステムには通用しないからです。アイデンティティモデルも、セッションモデルも、被害範囲も、監査要件も異なります。
これらの違いを理解し、それに合わせて設計されたコントロールを実装できるセキュリティチームは、AI導入を自信を持って推進できます。人間アクター向けのコントロールをAIにそのまま適用して満足してしまうと、技術的にはゼロトラスト体制が整っていても、実際には不十分な状態となります。
Kiteworksは、人間アクターモデルが機能しないすべての層でAIアクター向けゼロトラストを実装します。認証情報の分離：OAuth 2.0トークンはOSキーチェーンに保存され、AIモデルのコンテキストウィンドウ外に隔離され、プロンプトインジェクションでも一切アクセスできません。リクエストごとの認可：Kiteworks Data Policy Engineが、すべてのAI操作ごとにRBACおよびABACポリシーを評価します（セッション確立時ではなく、各リクエスト実行時）。AIはリクエストしたユーザーの権限を継承し、セッション状態に関係なく、個別アクションごとにそれを超えることはできません。
二重帰属監査ログは、すべての操作ごとにAIシステムのアイデンティティと認証済み人間ユーザーの両方を記録し、Kiteworks監査ログに記録され、SIEMとリアルタイム連携します（バッチ処理や遅延、検知ギャップなし）。レート制限やパスコントロールは、データ層で「侵害前提」アーキテクチャを強制します。万一AIシステムが侵害・誤設定されても、大規模なデータ流出は不可能です。なぜなら、これらのコントロールはPrivate Data Networkアーキテクチャに組み込まれており、AIシステムの正常動作に依存しないからです。
さらに、これらのコントロールは、組織全体のセキュアなファイル共有、セキュアMFT、セキュアメールを管理するゼロトラストデータ交換フレームワークをそのまま拡張する形でAIにも適用されます。AI専用のセキュリティプログラムを新たに構築・維持する必要はありません。既存のゼロトラストアーキテクチャをAIに拡張するだけです。
人間アクターと同じ厳格さでAIアクターにもゼロトラストを拡張したいCISOやセキュリティアーキテクトの皆様へ、Kiteworksはそのための専用コントロールを提供します。詳細な実装をご覧になりたい方は、カスタムデモを今すぐご予約ください。
よくあるご質問
既存のゼロトラストアーキテクチャは、安定したアイデンティティ、予測可能なセッション境界、人間レベルの運用速度を前提とした人間アクター向けに設計されています。AIシステムはこれら3つの前提すべてを満たしません。サービスアカウントで人間のアイデンティティを隠し、長時間のセッションを機械速度で実行し、プロンプトインジェクションによって人間アクター向けコントロールでは想定できない挙動に変化します。原則自体は適用できますが、メカニズムは人間ユーザーとは根本的に異なるアクターモデル向けに専用設計が必要です。
プロンプトインジェクションとは、AIが処理するコンテンツ（ドキュメント、ウェブページ、取得ファイルなど）に悪意のある指示を埋め込むことで、ユーザーが気づかないうちにAIの挙動を変化させる攻撃です。セキュリティが不十分なAI統合では、AIが自身の認証情報にアクセスできる場合、プロンプトインジェクションによってそれらの認証情報を漏洩させ、不正アクセスを許すリスクがあります。AI向けゼロトラストデータ保護では、認証情報をOSキーチェーンに保存し、AIのコンテキストウィンドウから完全に隔離することで、AIがどんなコンテンツを処理しても認証情報に到達できないようにします。
セッション単位認可は、AIシステムが接続時に一度だけ認証され、そのセッションの間は暗黙のアクセス権が与えられる方式です。リクエストごと認可は、すべてのAI操作（ファイルアクセス、取得クエリ、フォルダナビゲーションなど）ごとに、その都度RBACやABACポリシーを評価します。1セッションで何千もの操作を実行するAIシステムでは、セッション単位認可は一度の検証の後に無監視アクセスが続くことになり、ゼロトラストの「決して信頼せず、常に検証する」要件を満たすのはリクエストごと認可だけです。
侵害された人間アカウントは、人間の操作速度によってアクセスできるデータ量に上限があり、異常検知にも対応時間があります。侵害されたAIシステムは、広範なリポジトリアクセス権とレート制限がなければ、SIEMアラートが認識される前に何十万ものドキュメントを取得できます。AI向け「侵害前提」アーキテクチャには、レート制限やスコープコントロールなど、データ層で強制される積極的な被害範囲制限が不可欠です。これは人間アクター向けインシデント対応とは根本的に異なるコントロール哲学であり、検知ウィンドウが狭すぎるため、リアクティブなコントロールだけでは不十分です。
二重帰属とは、すべての操作ごとにAIシステムのアイデンティティと、そのAIが代理で動作した認証済み人間ユーザーの両方を同じログエントリで記録することです。多くのAI監査ログはサービスアカウントのアイデンティティしか記録せず、人間のリクエスト主体を特定できません。HIPAAコンプライアンスでは、保護対象保健情報へのアクセス責任者を特定するログが必要です。GDPRコンプライアンスでは、各データアクセスの合法的根拠を示すために人間のリクエスト主体を特定する必要があります。「AIサービスアカウントがファイルにアクセスした」だけのログではこれらの要件を満たせません。二重帰属こそがアカウンタビリティギャップを解消します。
追加リソース
- ブログ記事
ゼロトラストで実現する手頃なAIプライバシー保護戦略 - ブログ記事
77%の組織がAIデータセキュリティで失敗している理由 - eBook
AIガバナンスギャップ：2025年に91%の中小企業がデータセキュリティでロシアンルーレット状態に - ブログ記事
あなたのデータに「–dangerously-skip-permissions」は存在しない - ブログ記事
規制当局は「AIポリシーがあるか」ではなく「実際に機能しているか」の証拠を求めている