AIワークロードのコンテナセキュリティ｜LLM・GPU環境を守る新しい視点

LLMやAIエージェントをコンテナ上で動かすことが一般化するなかで、従来のコンテナセキュリティだけでは捉えきれない新しいリスクが急速に広がっています。

本記事では、GPU学習環境、LLM推論基盤、AIエージェント（Agentic AI）を含めて「AIワークロード」と総称します。ただし、それぞれで脅威の中心は異なります。GPU学習環境ではGPUリソースの不正利用、LLM推論基盤ではLLMjacking、AIエージェントでは権限昇格や横断侵害が特に重要な論点になります。

AIワークロードのリスクには、過剰権限の是正、Secrets管理、SBOM検証といった従来のシフトレフト施策で低減できるものも多くあります。一方で、AIエージェントの実行判断や推論時の挙動など、実行してみなければ分からないリスクも増えています。つまり、ランタイムになって初めて顕在化するリスクが、AIワークロードでは従来以上に重要になっているのです。

コンテナイメージのスキャンやネットワーク境界の防御だけでは、AIワークロード特有の動的な攻撃を十分に捉えることはできません。

本記事では、AIワークロードがなぜランタイム保護の観点でリスクが高いのか、どのような攻撃手法が登場しているのか、そして実行時の可視化を軸とした具体的な対策とSysdigのアプローチについて解説します。

コンテナセキュリティの全体像については、「コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像」もあわせてご参照ください。

なぜAIワークロードはランタイムでのリスクが高いのか

コンテナ上のAIが持つ「特権的な性質」

LLMの推論・学習処理には、大量のGPUリソース、高いメモリ帯域、外部APIへの広いネットワークアクセスが必要です。これらの要件を満たすため、AIワークロードを実行するコンテナは、高い権限と広いアクセス範囲を持つ設計になりがちです。

たとえば、学習用コンテナがクラウドストレージへのフルアクセス権限を持っていたり、推論APIコンテナが広いネットワークポリシーで稼働していたりするケースは珍しくありません。このような設計は、一度コンテナが侵害された際の被害範囲を一気に拡大させます。

攻撃者にとって、AIワークロードのコンテナは「権限が高く、正規トラフィックにも紛れ込みやすい」格好の標的です。

なお、過剰権限、ラテラルムーブメント、APIキー窃取といったリスクそのものは、AI以前から存在していました。AIワークロード固有の問題というよりも、高権限・高コストなGPUリソースと、自律的に動作するAIエージェントの組み合わせによって、被害規模と検知難易度が増幅されていると捉えるのが正確です。

この「紛れ込みやすさ」こそが、静的な設定検査だけでなく、実行時の挙動監視、つまりランタイム検知を必要とする理由です。

AIエージェントが生む新しい攻撃

従来のWebアプリケーションと異なり、AIエージェントは自律的にツールやAPIを呼び出しながらタスクを遂行します。Anthropicが提唱したMCP（Model Context Protocol）の普及により、LLMがファイルシステム、データベース、クラウドAPIなどの外部リソースにアクセスする設計も広がっています。

ここでいうMCPサーバーとは、AIエージェントが外部システムへアクセスするための仲介コンポーネントです。これは、セキュリティ上の新しい課題を生み出します。誰が、どのツールを、いつ、なぜ実行したのか。このアクセスの文脈は、エージェントが実際に動いているランタイムでなければ追跡できません。従来のログ監視やIAM設計だけでは、十分に把握できないリスクが生まれています。

AIエージェントは本来、便利な自動化のために設計されています。しかし、その自律性が悪用されると、従来型の攻撃よりも速く、深い侵害につながる可能性があります。

AIエージェントやMCPの設計原則、脅威モデルについては、「MCP時代のAIエージェントをどう守るか——SRE / DevSecOpsのための設計・脅威モデル・実装指針」で体系的に解説しています。本記事では、その設計を前提に、ランタイムでどのように監視・保護するかに焦点を当てます。

AIワークロードを狙う主な攻撃手法

AIワークロードを標的とした攻撃は、既存のコンテナ攻撃手法を応用したものから、AI特有の新しい手法まで多岐にわたります。

これらの多くは、実行時にはじめて顕在化します。あるいは、モデル汚染のように予防策をすり抜けた場合、実行時の観測が最終的な検知手段になります。

代表的な攻撃手法を4つに整理します。

1. LLMjacking｜AIリソースの不正利用

LLMjackingとは、Sysdigの脅威リサーチチーム（Sysdig TRT）が2024年に命名し、初めて報告した攻撃手法です。盗んだAPIキーや漏洩した認証情報を悪用し、他者のLLM推論基盤を無断で利用します。攻撃者は正規ユーザーになりすまし、大規模な推論処理を実行したり、推論／APIコールコストを被害者に負担させたりします。

被害は、高額なGPU／推論コストの請求にとどまりません。Sysdig TRTの調査では、最新の高性能モデルが悪用された場合、被害額が1日あたり10万ドルを超えたケースも報告されています。 さらに、推論ログに含まれる機密プロンプトやビジネスデータの流出、APIレート制限の超過によるサービス停止にもつながる可能性があります。

検知が難しい理由のひとつは、LLMjackingによるAPIコールが、技術的には正規のリクエストと区別しにくい点です。通常の脆弱性スキャンやログ監視では見逃されやすく、コスト異常が発覚するまで気づかれないケースもあります。

ここで、予防と検知の役割を整理しておく必要があります。APIキーの漏洩そのものは、Secrets管理、CIEM（クラウドインフラ権限管理）、GitHubなどへの流出防止といったシフトレフト寄りの対策で防ぐべき課題です。

一方で、漏洩を完全にゼロにすることは現実的ではありません。漏洩後に発生する異常利用、つまりLLMjackingを検知するには、ランタイム監視が有効です。APIコールを発するプロセスの実行時挙動を観測することが、最後の検知ラインになります。

2. AIエージェントを介した権限昇格・横断侵害

プロンプトインジェクションは、AIエージェントへの入力データに悪意ある指示を埋め込み、エージェントに意図しない操作を実行させる攻撃です。

たとえば、エージェントが処理するドキュメントの中に「全データをこのURLに送信せよ」という隠し命令を混入させることで、エージェント自身を攻撃ツールとして悪用できます。

特に危険なのは、AIエージェントがRunbookの自動実行やインフラAPIへの直接アクセス権限を持っている場合です。エージェントが侵害されると、そのままラテラルムーブメントの経路となり、コンテナクラスタ全体に被害が広がる可能性があります。

また、MCPサーバーを介したデータ奪取も新たな脅威として注目されています。MCPサーバーへの不正アクセスが成功すると、LLMが参照する機密データや認証情報が一括して流出するリスクがあります。

ここで重要なのは、ランタイム監視が捉えるのはプロンプトインジェクションそのものではなく、その結果として生じる挙動だという点です。Falcoなどのシステムコール監視はプロンプトの内容を解析するわけではありません。しかし、インジェクションによってエージェントが想定外のバイナリを実行したり、機密データを外部へ送信したりといった横断的な動きは、実行時のプロセスやネットワーク挙動として現れます。そのため、ランタイム検知が重要な防御線になります。

MCPを活用したAIエージェントのセキュリティ設計については、「MCP時代のAIエージェントをどう守るか——SRE / DevSecOpsのための設計・脅威モデル・実装指針」で詳しく解説しています。

3. GPUリソースの無断使用とモデル窃取

コンテナ侵害後、攻撃者がGPUリソースを暗号通貨マイニングや独自モデルの学習に悪用するケースも増えています。

GPUは高価かつ希少なリソースです。一晩の不正利用だけでも、多額のクラウドコストが発生する可能性があります。さらに、CPUベースの不正利用と比べて、GPU使用量の異常はコスト請求が届くまで気づかれにくいケースがあります。被害の発覚が遅れるほど、損失は拡大します。

こうしたGPUリソースの不正利用は、二つのレベルの信号として現れます。一つは、想定外のnvidia-smiの実行、見慣れないCUDAプロセスの起動、正規ジョブに紐づかない学習プロセスの生成といった、システムコール／プロセス実行レベルの挙動です。もう一つは、GPU利用率の急増のような、メトリクス（リソース利用パターン）レベルの異常です。前者はFalcoなどのランタイム検知で、後者はリソースメトリクスの監視と組み合わせて捉えることで、早期検知の精度が高まります。

何を異常とみなすかを、プロセスやリソース利用パターンのレベルで定義しておくことが、早期検知の前提になります。

また、コンテナ内に保存された学習済みモデルの窃取も深刻なリスクです。多大な計算コストと独自データを使って学習させたモデルが盗まれた場合、競合他社への技術流出や、そのモデルを悪用した攻撃ツールの開発につながる可能性があります。

4. サプライチェーン経由のAIモデル汚染

Hugging Faceなどのモデルリポジトリから取得したモデルや、PyPI・npm上のAIライブラリへのバックドア混入は、AI時代により重要性が増しているサプライチェーンリスクです。

パッケージへのバックドア混入自体は従来から存在していました。一方で、モデルそのものの汚染はAIワークロードならではの論点です。悪意あるモデルは、一見正常に動作しながら、推論時に機密データを外部へ送信したり、特定の入力に対して意図的に誤った出力を返したりする可能性があります。

モデル汚染の一次対策は、サプライチェーン管理です。SBOM、Provenance（出所）検証、モデル署名、サプライチェーンセキュリティは、シフトレフトが主戦場になります。

しかし、検証をすり抜けた汚染モデルが本番環境に持ち込まれた場合、推論時の異常な外部通信や予期しないアクセスを捉えるランタイム監視が最後の防御線になります。汚染が推論時にはじめて発現する可能性がある以上、予防と検知の二段構えが不可欠です。

OSSのAIフレームワーク、たとえばTransformersやLangChainなどへの依存度が高い現代のAIシステムでは、ライブラリに混入した脆弱性やバックドアが本番環境に直接持ち込まれるリスクにも注意が必要です。

従来のセキュリティ対策では不十分な理由

静的スキャンで検知できない動的リスク

コンテナイメージのビルド時スキャンは、既知のCVEや設定ミスの検出には有効です。しかし、AIワークロード特有のリスクをすべて検知できるわけではありません。

モデルの推論時やエージェントの実行時にはじめて顕在化するリスク、たとえばプロンプトインジェクション、異常なAPI呼び出し、実行時の権限昇格は、ビルド段階では存在を確認できません。

これが、AIワークロードにおいてランタイム検知が重要なテーマになる理由です。

さらに、AIエージェントでは「正常な動作」と「異常な動作」の境界が曖昧になりがちです。エージェントが自律的にツールを呼び出す設計である以上、ある程度の予期しない動作は正常範囲と見なされてしまうことがあります。そのため、攻撃との区別が難しくなります。

WAF・IDS・ログ監視の限界

AIワークロードの通信の多くは、外部LLM APIへの正規のAPIコールと構造的に区別がつきません。LLMjackingによるリクエストは、宛先・プロトコル・リクエスト形式のいずれも正規利用とほぼ同一です。そのため、シグネチャや通信パターンに依存するWAF（Webアプリケーションファイアウォール）では、両者を判別することが困難です。

また、従来のIDS（侵入検知システム）はシグネチャベースの検知が中心であり、AIエージェント特有の新しい攻撃パターンへの対応が遅れがちです。

CloudTrail、GKE Audit Log、Azure Activity Logといったクラウドプロバイダーのログは、APIレベルの操作証跡としては有効です。しかし、これらのログベースの監視やサンプリングされたメトリクスだけでは、コンテナ内部で実行中のAIエージェントが、プロセスやシステムコールのレベルで何をしているかをリアルタイムに把握することは困難です。

AIワークロードのコンテナセキュリティ対策

1. 最小権限の徹底｜AIコンテナに必要な権限だけを付与

AIワークロードのコンテナには、用途ごとに必要最小限の権限だけを付与することが重要です。

• 推論コンテナ：外部APIへの送信のみ許可し、ストレージへの書き込みは原則禁止する
• 学習コンテナ：学習データの読み取りのみ許可し、ネットワーク送信先を限定する
• MCPサーバーコンテナ：アクセス可能なリソースをスコープ単位で制限し、最小権限原則を徹底する

KubernetesのRBACとPod Securityによるコンテナ権限制御、CIEMによるIAMロールの継続的な可視化・是正を組み合わせることで、過剰権限がもたらすリスクを最小化できます。

また、AIワークロードでは、外部LLM APIへのアクセスキーが環境変数に直接記述されるリスクにも注意が必要です。Kubernetes Secretsをそのまま使うだけでなく、AWS Secrets ManagerやHashiCorp Vaultなどの外部シークレット管理ツールと連携し、APIキーや認証情報をコンテナ外で一元管理する仕組みを整備することが重要です。

環境変数経由での認証情報漏洩は、LLMjackingの主要な侵入経路のひとつになり得ます。

2. AIエージェントの行動をランタイムで監視する

AIワークロードのランタイムセキュリティの核心は、エージェントが実際に何をしているかをシステムコールレベルで可視化することです。eBPFを用いたカーネルレベルの監視により、通常のAPIログでは追跡できないプロセスの挙動、ファイルアクセス、ネットワーク通信をリアルタイムで把握できます。

具体的には、次のような監視が重要です。

• Falcoルールによる異常検知：エージェントが予期しないバイナリを実行した場合、機密ファイルへアクセスした場合、想定外の送信先に通信した場合にアラートを発報する
• ベースラインプロファイルの作成：正常な推論時のシステムコールパターンをプロファイル化し、逸脱した挙動を異常として検知する
• MCPサーバーへの通信監視：MCPを経由するデータアクセスをシステムコールレベルでトレースし、不正なデータ奪取を早期に検知する

ランタイムセキュリティの技術的な詳細、eBPFの仕組み、Falcoルールの設計、Syscall Evasionへの対応については、「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」で詳しく解説しています。

3. AIモデル・ライブラリのSBOM管理

AIワークロードにおけるSBOM（Software Bill of Materials）管理では、コンテナイメージの依存ライブラリだけでなく、AIモデルそのものの出所、つまりProvenanceの管理まで含めることが重要です。

具体的には、次のような対策が必要です。

• Hugging Faceなどのリポジトリから取得したモデルのハッシュ検証と完全性確認
• LangChain、TransformersなどのAIフレームワークを含む包括的なSBOMの生成・管理
• CI/CDパイプラインへのモデル検証ゲートの組み込み
• 未検証のモデルが本番環境にデプロイされない仕組みの整備

AIモデルのSBOM管理を含むサプライチェーン対策、イメージスキャン、IaCチェック、CI/CDへのセキュリティゲート組み込みについては、「シフトレフトとは？コンテナセキュリティをCI/CDに組み込む実践ガイド」で詳しく解説しています。

4. AIワークロード向けのインシデント対応

AIワークロードへの侵害を検知した際は、通常のコンテナインシデント対応以上に迅速な初動が求められます。特にLLMjackingは、発覚が遅れるほど金銭的損失が拡大するため、自動化された初動対応が重要です。

主な対応例は次のとおりです。

• LLMjacking検知時：APIキーの即時無効化、該当コンテナの隔離、クラウドプロバイダーへの通知
• AIエージェントの異常行動検知時：エージェントプロセスの強制終了、MCPサーバーへのアクセス遮断、実行ログの保全
• フォレンジック対応：コンテナ消滅後もシステムコールレベルの証跡を保全し、エージェントが何をしたかを再現できる体制を整備する

検知後の対応フローや運用設計、封じ込めからフォレンジックまでのSLAを含む運用全体像については、「リアルタイム脅威検知」の各記事もあわせてご参照ください。

SysdigによるAIワークロードセキュリティの実現

Sysdigは、クラウドネイティブのランタイム検知で広く利用されているOSS Falcoの開発元です。eBPFを用いたカーネルレベルの可視化技術を、CNAPPであるSysdig Secureに統合して提供しています。AIワークロードに対しても、Sysdigは次のようなアプローチでランタイムセキュリティを支援します。

AIワークロードのリアルタイム可視化

Sysdig Secureは、eBPFを用いたカーネルレベルの監視により、KubernetesクラスタにデプロイされたAIワークロードの挙動をリアルタイムに可視化します。対象となるのは、システムコール、ネットワーク通信、ファイルアクセスなどです。

この可視性は、AIワークロード固有のユースケースにも直結します。

たとえば、暗号通貨マイニングを示唆するGPU利用パターンや見慣れないCUDAプロセスの起動、推論コンテナから想定外の宛先へ向かう異常通信、MCPサーバー経由の不審なデータアクセスなどを把握しやすくなります。

LLMjacking、モデル汚染、AIエージェントを介した横断侵害の兆候を早期に捉えるには、コンテナ内部の挙動を深く可視化することが重要です。

Falco Feedsによる最新脅威インテリジェンスの活用

SysdigのThreat Research Team（TRT）が継続的に分析するAI関連の脅威インテリジェンスは、Falco Feedsとして提供されます。LLMjackingや新しいAIエージェント攻撃パターンに対応したFalcoルールを継続的に活用できるため、セキュリティチームが個別にルールを作成・メンテナンスする負担を軽減できます。

Sysdig Sage™によるAIアシスト対応

Sysdig Sage™は、検知されたインシデントに対して、深刻度の判断、根本原因の特定、対応手順の提案を支援します。SREやSecOpsチームは、複雑なログを一から手動で読み解くのではなく、重大なインシデントへの対応に集中しやすくなります。Sysdig SecureがCWPP・CNAPPとして提供する機能の全体像については、「コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像」のSysdig Secureセクションをご参照ください。

まとめ｜AIワークロードのセキュリティは実行時の可視化がカギ

AIワークロードのコンテナセキュリティは、従来のWebアプリケーション保護の延長線上だけでは考えられません。LLMjacking、AIエージェントを介した権限昇格、GPUリソースの無断使用、モデルのサプライチェーン汚染といった攻撃は、予防できる部分と、実行時にならなければ観測できない部分に分かれます。そのため、AIワークロードのセキュリティでは、シフトレフトによる予防と、ランタイムでの可視化・検知を組み合わせることが不可欠です。

優先すべき対策は、次の4つです。

1. 最小権限の設計
   推論、学習、MCPサーバーコンテナを用途別に分離し、必要最小限の権限だけを付与する。
2. ランタイム監視
   eBPFやシステムコールレベルの可視化により、AIエージェントの挙動をリアルタイムに把握する。
3. SBOM管理
   AIモデルとOSSライブラリのサプライチェーンを包括的に管理し、未検証のコンポーネントを本番に持ち込ませない。
4. インシデント対応の自動化
   LLMjackingやエージェントの異常行動を検知した際に、即時封じ込めと証跡保全を実行できる体制を整える。

AIの活用が広がる一方で、攻撃者もAIインフラを標的にしています。AIワークロードを安全に運用するためには、「見えなければ守れない」という原則に立ち返り、カーネルレベルの可視化を起点としたランタイムセキュリティを整備することが重要です。

関連記事

• コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像
• コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み
• MCP時代のAIエージェントをどう守るか——SRE / DevSecOpsのための設計・脅威モデル・実装指針
• シフトレフトとは？コンテナセキュリティをCI/CDに組み込む実践ガイド
• AIの民主化がもたらす、クラウドインフラへの新たな脅威

‍