幻覚からプロンプトインジェクションまで: 実行時の AI ワークフローの保護

開発者が AI エージェントを使用して安全に構築するためにランタイム セキュリティを埋め込む方法


はじめに: AI ワークフローが攻撃対象領域になるとき

今日私たちが使用している AI ツールは強力ですが、予測不可能で悪用可能でもあります。

LLM にプロンプトを表示すると、Dockerfile が生成されます。正しく見えます。シェルスクリプト?合理的。dev で実行します。その後、何かが壊れ、ボリュームが削除されます。資格情報がログにリークします。送信要求が本番 API にヒットします。リスクは 実行時にのみ現実のものになったため、CI パイプラインにはフラグが立てられませんでした。

これは、高速で動くコード、不確実な動作、拡大する攻撃対象領域という、AI ネイティブ開発の新たな現実です。

LLM 出力の幻覚は物語の一部にすぎません。開発者がますます自律的なエージェント ツールを構築するにつれて、攻撃者によるプロ ンプト インジェクションジェイルブレイク、およびモデル出力の 意図的な悪用 にもさらされます。悪意のあるユーザーは、巧妙に細工された入力を通じて AI エージェントを乗っ取り、ファイルの変更、秘密の盗み出し、または不正なコマンドの実行を引き起こす可能性があります。

最近のあるケースでは、開発者が LLM で生成されたスクリプトを実行して本番データベースをサイレントに削除しましたが、この問題は顧客データがすでに失われるまで検出されませんでした。別のケースでは、内部の AI アシスタントが、完全にユーザー入力によってトリガーされた、機密性の高い内部ドキュメントを外部のファイル共有サイトにアップロードするよう促されました。

これらの障害は、静的分析、コードレビュー、またはCIでは検出されませんでした。コード が実行されたときにのみ表面化しました。

この投稿では、開発者がランタイム セキュリティを開発ループに移行し、可観測性、ポリシー適用、脅威検出を Docker を使用してワークフローに直接埋め込むことで、偶発的な障害と意図的な脅威の両方にどのように対処しているかを探ります。

AI が生成したコードの隠れたリスク

LLM と AI エージェントはテキストの生成に優れていますが、自分が何をしているのかを常に把握しているわけではありません。GitHub Copilot、LangChain、またはOpenAI APIを使用して構築しているかどうかにかかわらず、生成される出力には次のものが含まれます。

  • 特権を昇格させたり、ファイルシステムを誤って構成したりするシェルスクリプト
  • 不要なポートを公開したり、古いパッケージをインストールしたりする Dockerfile
  • 既定で運用サービスに接続するコードとしてのインフラストラクチャ テンプレート
  • 出力の奥深くに隠されたハードコードされた資格情報またはトークン
  • コンテキストに応じて動作が異なるコマンドシーケンス

チームがコードを提案するだけでなく、アクションを実行するように設計された AI ツールである自律エージェントを実行し始めると、問題はさらに複雑になります。これらのエージェントは、次のことができます。

  • ファイルの書き込みと削除を実行する
  • アウトバウンド API 呼び出しを行う
  • コンテナーをスピンアップまたは破棄する
  • 実行中に構成状態を変更する
  • 危険なデータベースクエリを実行する

これらのリスクは、ビルドが経過し、パイプラインが出荷された後、実行時にのみ表面化します。そして、これは開発者が開発ループ内で解決する問題です。

ランタイムセキュリティが開発者ワークフローに属する理由

従来のセキュリティツールは、ビルド時チェック、SAST、SCA、リンター、コンプライアンススキャナーに重点を置いていました。これらは不可欠ですが、AI が生成したエージェントが実行時に行うことからユーザーを保護することはできません。

開発者は、後で追加されるブロッカーではなく、ワークフローに合ったランタイムセキュリティを必要としています。

ランタイムセキュリティによって有効になるもの:

  • 危険なシステムコールまたはファイルアクセスのライブ検出
  • エージェントが不正なアクションを試みたときのポリシーの適用
  • 実環境におけるAI生成コードの動作へのオブザーバビリティ
  • コンテナ化されたサンドボックスでのリスクの高い実行の分離

なぜそれが重要なのか:

  • フィードバックループの高速化: CI/CD が失敗する前に問題を確認できます
  • インシデントリスクの軽減:権限昇格、データ漏洩、またはネットワークコールを早期にキャッチ
  • より高い信頼性: 推測に頼らずに LLM で生成されたコードを出荷
  • 安全な実験: チームの速度を低下させることなく安全なイテレーションを可能にします

開発者のROI: 開発で誤って構成されたエージェントをキャッチすると、何時間ものトリアージが回避され、本番リスクと評判のリスクが軽減されます。時間、コスト、コンプライアンスのエクスポージャーを節約します。

Docker を使用したより安全な AI ワークフローの構築

Docker は、最新のエージェント アプリケーションを開発、テスト、保護するための構成要素を提供します。

  • Docker Desktop は、安全でないコードをテストするための分離されたローカル ランタイムを提供します
  • Docker で強化されたイメージ。安全で最小限の本番環境対応イメージ
  • Docker Scout は、コンテナイメージの脆弱性と構成ミスをスキャンします
  • ランタイム ポリシーの適用 (今後の MCP Defender 統合により) は、コードの実行中にライブ検出とガードレールを提供します

ステップバイステップ: AI が生成したスクリプトを安全にテストする

1。強化されたコンテナーでエージェントまたはスクリプトを実行する

docker run --rm -it \
  --security-opt seccomp=default.json \
  --cap-drop=ALL \
  -v $(pwd):/workspace \
  python:3.11-slim

  • システムコール制限を適用し、不要な機能をドロップします
  • 永続的なボリューム変更なしで実行
  • LLM出力の安全で再現性のあるテストが可能

2。Docker Scout でコンテナーをスキャンする

docker scout cves my-agent:latest
  • 既知のCVEと古い依存関係を表面化
  • 安全でない基本イメージまたは誤って構成されたパッケージのインストールを検出します
  • ローカルとCI/CDワークフロー内の両方で利用可能

3。安全でない動作をブロックするランタイム ポリシー (ベータ版) を追加する

scout policy add deny-external-network \
  --rule "deny outbound to *"

これにより、内部システム、サードパーティの API、または外部データ ストアに無意識のうちにアウトバウンド リクエストを行う AI エージェントをキャッチします。

手記: Docker Scoutでのランタイムポリシーの適用は現在開発中です。CLI と動作はリリース時に変更される可能性があります。

AI エージェント コンテナを保護するためのベスト プラクティス

練習

なぜ重要なのか

スリムで検証済みのベース イメージを使用する

攻撃対象領域と依存関係のドリフトを最小限に抑えます

未確認のソースからのダウンロードは避けてください

LLM がシャドウの依存関係を導入するのを防ぎます

使う .ドッカー無視 とシークレット管理

コンテナーからシークレットを保持

削除された機能を持つコンテナーの実行

予期しないコマンドの影響を制限

ランタイム seccomp プロファイルの適用

システムコールレベルのサンドボックスを適用

分析のためのログ・エージェントの動作

オブザーバビリティを実験に組み込む

クラウドネイティブワークフローへの統合

AIツールのランタイムセキュリティは、ローカルテストだけでなく、クラウドネイティブやCI/CDワークフローにもすっきりと適合します。

GitHub Actions統合の例:

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build container
        run: docker build -t my-agent:latest .
      - name: Scan for CVEs
        run: docker scout cves my-agent:latest

環境全体で動作します。

  • Docker Desktop 経由のローカル開発
  • GitHub Actions、GitLab、Jenkins 経由のリモート CI/CD
  • ポリシー適用とエージェント分離を備えたKubernetesステージング環境
  • Docker + セキュア エージェント サンドボックスを使用したクラウド開発環境 (CDE)

クラウド IDE または CDE でエフェメラル ワークスペースと Docker コンテナを使用している開発チームは、ローカル環境とクラウド環境に同じポリシーを適用できるようになりました。

実際の例: AI が生成したインフラがうまくいかなかった

プラットフォームチームは、LLM エージェントを使用して Kubernetes デプロイメントテンプレートを自動生成します。開発者が YAML を確認し、マージします。エージェントが生成した構成は、 LoadBalancer経由でインターネットに対して内部専用サービスを開きます。CI パイプラインが合格します。デプロイは機能します。しかし、顧客データベースが公開されました。

開発者が送信ポリシールールを使用してコンテナ化されたサンドボックス内でこのテンプレートを実行した場合、サービスを公開しようとするとアラートがトリガーされ、ポリシーによってエスカレーションが防止されます。

レッスン: 静的なレビューだけに頼ることはできません。AI が生成したコードがどのようなものかだけでなく、何 をするかを確認する必要があります。

これが重要な理由: AI ネイティブの開発チームのためのデフォルトでの安全

LLM を活用したツールが提案からアクションへと進化するにつれて、ランタイムの安全性はオプションのアドオンではなく、ベースライン要件になります。

安全な AI 開発の未来は、ランタイム ポリシー、可観測性、速度を低下させないスマートなデフォルトを備えた内部ループから始まります。

Dockerのプラットフォームは、以下を提供します。

  • セキュリティが組み込まれた開発者ファーストのワークフロー
  • AI の間違いを早期に発見するためのランタイムの適用
  • ビルド、テスト、デプロイにわたるツールチェーンの統合
  • ローカル開発、CI/CD、CDEにわたるクラウドネイティブの柔軟性

AI を活用した自動化、エージェントベースのプラットフォーム、インフラストラクチャを生成するツールのいずれを構築する場合でも、AI が認識できないことを確認し、すべきではないことをブロックするランタイム レイヤーが必要です。

次のステップ

ランタイム保護は、開発環境に左に移動しています。Docker を使用すると、開発者は次のことができます。

  • LLM で生成されたコードを安全な一時的なコンテナーで実行する
  • CI にプッシュする前にランタイムの動作を観察する
  • リスクの高いアクションを防ぐポリシーを適用する
  • AI を活用したアプリでのサイレント セキュリティ障害のリスクを軽減

Dockerは、MCP Defenderをプラットフォームに導入して、この保護をすぐに提供し、幻覚がインシデントに発展しないようにしています。

AI ワークフローを保護する準備はできていますか?

  • Docker のランタイム セキュリティ機能への早期アクセスにサインアップする
  • 「Docker を使用した安全な AI エージェントの構築」に関するテック トークをご覧ください。
  • Docker Scoutを調べてリアルタイムの脆弱性の洞察を得る
  • Docker Community SlackまたはGitHub Discussionsでコミュニティの会話に参加する

迅速かつ安全に構築しましょう。

投稿カテゴリ

関連記事