LLM時代のゼロトラストと境界防御をどう考えるか

社内チャット、ドキュメント検索、コードレビュー、問い合わせ対応——いま多くの業務が大規模言語モデル（LLM）に寄りかかり始めています。一方で、AIエージェント同士が連携するSaaSや、社内データをつないだ自前LLMなど、新しい攻撃面も一気に広がりました。

従来の「社内ネットワーク＝比較的安全」という前提の境界防御だけでは、クラウドやSaaS、AIエージェントが入り乱れる今の環境を守りきれません。このギャップを埋める考え方として、ゼロトラストが改めて重要になっています。

境界防御モデルのおさらい

境界防御（Perimeter Security）はざっくり言うと「社外と社内の境界を厚く守る」モデルです。

ファイアウォールやVPNで“入口”を絞る
社外からはVPN経由でのみアクセス
社内に入ったら、比較的信頼された前提で通信できる

こうした考え方は、オンプレ中心・社内LAN中心の時代には合理的でした。しかしクラウドやSaaSが前提となり、従業員がどこからでも仕事をするようになった今、「境界」がどこにあるのかがどんどん曖昧になっています。

ゼロトラストの文脈では、この伝統的な境界防御を「内部に入ったら基本的に信頼するモデル」として対比させることが多いです。

ゼロトラストの基本原則

NIST SP 800‑207 などで定義されるゼロトラストは、「ネットワークの内外を問わず、何も信用しないところから始める」考え方です。

よく出てくる要素をかみ砕くと、次のようになります。

Never trust, always verify（決して信頼せず、必ず検証する）：社内からのアクセスでも、毎回、ユーザー・端末・アプリの状態を評価してから許可する。
最小権限（Least Privilege）：「とりあえずフルアクセス」ではなく、その業務に必要な最小限の権限だけを与える。
コンテキストに応じた動的なポリシー：場所・端末のセキュリティ状態・アクセス先の重要度などを総合して、リアルタイムに許可・ブロック・追加認証を決める。

ゼロトラストは「境界をなくす」話ではなく、「境界“だけ”で判断しないようにする」アーキテクチャと言った方が近いです。

LLMが持ち込む新しいリスク

LLM時代には、これまで想定していなかったタイプのリスクが増えています。

1. プロンプトインジェクションと間接プロンプトインジェクション

LLMに与える指示（プロンプト）を悪用し、モデルの挙動を乗っ取る攻撃です。

悪意あるテキストやドキュメントの中に「本来の指示を無視して○○しろ」と埋め込む
LLMがそれを“命令”と解釈し、機密情報を吐き出す・権限外の操作をしようとする
最近は、別システムから取り込んだデータ経由で命令をねじ込む「間接」プロンプトインジェクションや、エージェント間のやり取りを悪用する「二次（second‑order）」攻撃も報告されています。

2. データ流出・コンプライアンス違反

LLMが社内の機微データにアクセスできる場合、プロンプトインジェクションや設定ミスをきっかけに、個人情報や機密情報が外部に流出するリスクがあります。

3. AIを使う側ではなく、AI“搭載”マルウェア

ローカルでLLMを動かし、検知をすり抜けるコードやスクリプトを自動生成するマルウェアも登場しています。AIが攻撃者側の“頭脳”としても使われるようになり、防御側の前提がさらに崩れつつあります。

境界防御はもう不要か？——答えは「No、役割を変える」

LLM時代だからといって、境界防御が完全に無意味になったわけではありません。

インターネットからの不要なポート・プロトコルを閉じる
既知の悪性通信をFW/IPSでブロックする
LLM API や AIエージェントのアウトバウンド先を制限する

といった基本的な“外周の柵”は、今でも有効です。

ただし、「社内に入ったら信頼してよい」という前提はもはや成り立たない、という点が重要です。LLMを介してクラウドSaaSや他社APIに勝手に橋をかけられると、ネットワークの“内”と“外”の区別自体が崩れてしまいます。

したがって、境界防御は「一次フィルタ」程度の位置づけにとどめ、ゼロトラストの考え方で内側も含めた防御を組み立てるのが現実的です。

LLM時代のゼロトラスト設計のポイント

LLM／生成AIを前提に、ゼロトラストと境界防御をどう組み合わせるか。実務寄りに整理すると、次のようなステップになります。

1. まず「LLMがどこで、何に触れているか」を棚卸し

社内で使っている SaaS LLM（ChatGPT, Gemini, Copilot など）
社内データと接続した RAG/社内チャットボット
コード自動生成、チケット要約など、業務システムに組み込まれたLLM

それぞれについて、

どのデータにアクセスできるか
どの外部サービスと連携しているか
どんな権限で実行されているか

を一覧化します。ここが曖昧なままゼロトラストを語っても、実際のリスクと施策が噛み合いません。

2. 「LLM／エージェント」を1つの“主体”として認証・認可する

人間ユーザーだけでなく、LLMやAIエージェントも「IDを持つ主体」として扱い、ゼロトラストの枠に乗せます。

LLMが社内APIやDBにアクセスする際は、専用のサービスアカウント＋最小権限で発行
人間ユーザーの権限をそのままLLMに“委譲”しない（何でもできる代理人にしない）
アクセスログは人間とLLMを区別して記録し、追跡できるようにする

3. LLM入出力を「常に不審なものが混じりうる」と見なす

ゼロトラストは本来ネットワークやIDの話ですが、LLMではテキストそのものが攻撃ベクターになります。

外部から取得したテキスト（Webページ、メール、添付ファイルなど）は、**プロンプトインジェクションを含みうる“未検証データ”**として扱う
LLMの出力を、そのままバックエンドへの命令やコード実行に使わず、
- ルールベースのフィルタ（危険な命令・URL・コードの除去）
- 必要に応じた人間の承認ステップを挟む

4. ランタイムでの監視と異常検知を組み込む

LLMの安全性は、静的な設定だけでは担保しきれません。

どのプロンプト・どのユーザー／エージェントが、どのデータにどれだけアクセスしているか
通常パターンから外れた大量取得・外部送信が発生していないか

を、ランタイムで監視・検知する仕組みが重要です。これはネットワークのゼロトラストでいう「継続的モニタリング」を、LLMレイヤーに持ち込むイメージに近いです。

5. 境界防御は「AI用の出口制御」として再設計する

LLM時代の境界防御は、「なんとなく全部許可／全部遮断」ではなく、AIまわりの出口を意識的にコントロールする役割にシフトします。

社内からアクセスできる LLM API・SaaS LLM を制限し、シャドーAI利用を抑制
AIエージェントのアウトバウンド通信先（外部API、Webhookなど）を必要最小限に絞る
DLPやCASBと連携し、機微情報を含むデータが外部LLMに送られないようにする

まとめ：LLM時代の前提をアップデートする

LLM時代のポイントを一言でまとめると、

「ネットワークの内外」だけでなく、「LLMの内外」でも信頼の境界を引き直す

ことだと思います。

境界防御：相変わらず必要。ただし「内＝安全」という前提で設計しない。
ゼロトラスト：ID・端末・アプリに加え、LLM／エージェントも一級の主体として扱う。
LLM特有のリスク：プロンプトインジェクションやデータ流出を、“テキストレベルの攻撃”として前提に組み込む。

技術要素は増えていますが、発想自体はシンプルです。「誰（人間／LLM）が、どの状態で、何に、どこまで触れていいのか」を、境界に頼らず一つずつ設計し直す——それがLLM時代のゼロトラストだと言えます。