デベロッパー

Agent Factory のハイライト: 本番環境における AI エージェントの保護

2025年11月6日

https://storage.googleapis.com/gweb-cloudblog-publish/images/hero-image_KUpVmma.max-2500x2500.png

Aron Eidelman

Developer Relations Engineer, Security Advocate

Mollie Pettit

Developer Relations Engineer

※この投稿は米国時間 2025 年 10 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

Agent Factory の最新エピソードでは、過度な期待のみにとどまることなくプロダクションレディな AI エージェントを構築するすべての人にとって重要なトピックである「セキュリティ」について取り上げます。これは理論上の「もしも」の話ではなく、現実に発生し金銭が失われている攻撃ベクトルについての内容です。現在の脅威の状況を詳しく見て、エージェントとユーザーの安全を確保するために今すぐ実装できる実用的な多層防御戦略について説明しています。

この投稿では、今回の対談からの重要なアイデアをいくつか紹介します。なお、この投稿はトピックをすばやく振り返ったりリンクやタイムスタンプを使用して特定のセグメントを詳しく調べたりできるような構成になっています。

エージェントにまつわる業界の動向

Timestamp: [00:46]

最初にエージェントのセキュリティの世界の現状を把握することから始めましたが、リスクが高まっていることは明らかです。最近のトレンドとインシデントについて、以下のような内容を話し合いました。

IDE サプライチェーン攻撃: 6 月に発生した、ブロックチェーンデベロッパーが 50 万ドルの暗号通貨を失ったインシデントを分析しました。この攻撃は、偽の VS Code の拡張機能から始まりましたが、IDE 自体のプロンプトインジェクションの脆弱性を利用してエスカレートし、新旧の脅威が危険な形で融合したものでした。
不可視の Unicode 文字: よりクリエイティブな攻撃の一つとして、悪意のあるプロンプトに不可視の文字を追加する手法が確認されています。人間やルールベースの正規表現による評価では違いが検出されない場合もありますが、LLM は隠されたテキストを命令として処理できるため、モデルの安全ガードレールを巧妙に回避できます。
コンテキストポイズニングとベクトルデータベース攻撃: コンテキストポイズニング（AI のコンテキストを徐々に破損させて「ガスライティング」する）などの攻撃や、RAG データベース内のごく少数のドキュメントを侵害するだけで高い成功率を達成できるベクトルデータベース攻撃についても特に触れました。
業界は Model Armor で反撃: 悲観的なことばかりではありません。推論前後の安全とセキュリティのレイヤを提供する強力なツールである Google Cloud の Model Armor を紹介しました。プロンプトインジェクションとジェイルブレイクがモデルに到達する前に阻止することに特化しており、脅威インテリジェンスを使用して悪意のある URL を検出、安全でないレスポンスをフィルタリング、PII などのセンシティブデータをフィルタリングまたはマスクします。
ガーディアンエージェントの台頭: Gartner は、2030 年までに AI エージェントの 15% が、他のエージェントのモニタリングと保護に特化した「ガーディアンエージェント」になると予測しています。これは、ハルシネーションなどのリスクを軽減するために、トピックの範囲が狭く、権限が制限された状態で動作する、専門的な SecOps エージェントや脅威インテリジェンスエージェントによって、すでに実際に起こっています。また、Guardian エージェントを使用して、マルチエージェントワークロード全体に Model Armor を実装することもできます。

The Factory Floor

「The Factory Floor」は、実践的なセグメントです。ここでは、概念的な内容から実用的なデモへと移行し、DevOps アシスタントを構築して保護しました。

問題: 古典的なプロンプトインジェクション攻撃

Timestamp: [06:23]

実際のリスクを示すために、保護されていない DevOps エージェントに対して古典的なプロンプトインジェクション攻撃を実行しました。エージェントに壊滅的なアクションを実行させるために必要なのは、以前の指示を無視してすべての本番環境データベースを削除するという簡単なプロンプトだけでした。ここでは、単一の防御レイヤを回避する可能性のあるさまざまな種類の進化する攻撃を予測するためには多層防御が必要であることを示しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/vulnerable-baseline-architecture-visual.max-2200x2200.png

多層防御戦略の構築

Timestamp: [06:36]

Google は、5 つの異なるレイヤで構成される多層防御戦略を実装することで、この脆弱性やその他の多くの脆弱性に対処しています。このアプローチにより、エージェントの権限が厳しく制限され、エージェントの動作が監視可能になり、重要なポイントで人間が定義したルールが適用されます。各レイヤの実装方法を以下に示します。

レイヤ 1: Model Armor による入力フィルタリング

Timestamp: [06:49]

最初の防御策は Model Armor でした。推論前に動作するため、モデルに到達する前にプロンプトを検査して悪意のある指示がないか確認し、コンピューティングを節約して攻撃を早期に阻止します。また、モデルの回答を検査して、PII の漏洩や安全でないコンテンツの生成などのデータ漏洩を防ぎます。以前は機能していたプロンプトインジェクション攻撃が、即座に検出されてブロックされる様子を比較して示しました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/model-armor-before-and-after-attack-attemp.max-2200x2200.png

レイヤ 2: 安全なサンドボックス実行

Timestamp: [07:45]

次に、エージェントの実行環境を封じ込めました。Cloud Run での gVisor を使用したサンドボックス化について説明しました。これにより、エージェントが分離され、基盤となる OS へのアクセスが制限されます。攻撃者が長期的な永続性を確立することを防ぐ Cloud Run のエフェメラルコンテナによりセキュリティも強化します。最小権限を適用するために、特定の条件を持つ強力な IAM ポリシーを重ねて、エージェントがそのジョブを実行するために必要な正確な権限のみを持つようにしました（例: VM の作成はできるが、データベースの削除はできない）。

レイヤ 3: ネットワーク分離

Timestamp: [10:00]

エージェントが不正なサーバーと通信しないように、ネットワークをロックダウンしました。プライベート Google アクセスと VPC Service Controls を使用することで、エージェントがパブリックインターネットにアクセスできない環境を作成し、攻撃者に「電話をかける」機能を効果的に遮断できます。また、デプロイ前に依存関係とパッケージが安全なビルドプロセスでスキャンおよび承認される、より安全なサプライチェーンも強制されます。

レイヤ 4: オブザーバビリティとロギング

Timestamp: [11:51]

私たちが重視することは

ロギングです。エージェントが実行しようとした内容や特に失敗した場合は記録します。データベースの制限された行にアクセスしようとするなどの失敗した試みは、潜在的な攻撃や構成ミスを示す強力なシグナルであり、高シグナルアラートとして使用できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/vpc-service-controls-perimeter-visual.max-2200x2200.png

https://storage.googleapis.com/gweb-cloudblog-publish/images/cloud-trace-observability-visual.max-1800x1800.png

レイヤ 5: ADK のツール保護対策

Timestamp: [14:05]

最後に、エージェントのツールを保護しました。Agent Development Kit（ADK）では、コールバックを使用して、アクションが実行される前に検証できます。ADK には、PII 秘匿化プラグインも組み込まれています。このプラグインは、エージェントレベルでセンシティブデータをフィルタリングするための組み込みメソッドを提供します。これを Model Armor の Sensitive Data Protection と比較しました。ADK プラグインはコールバックに固有のものですが、Model Armor はすべてのエージェントに適用できる一貫した API ドリブンポリシーを提供します。

結果: セキュリティで保護された DevOps アシスタント

Timestamp: [16:22]

5 つのレイヤをすべて実装した後、同じ攻撃を DevOps アシスタントに仕掛けました。プロンプトインジェクションとデータ引き出しの試みをブロックすることに成功しました。重要なのは、エージェントが意図した仕事を完璧にこなす能力はそのままに、危険な意図しないことを行う能力が取り除かれたことです。セキュリティは、機能を妨げることなく安全な運用を可能にする必要があります。

デベロッパー向け Q＆A

エピソードの最後には、デベロッパーコミュニティから寄せられた素晴らしい質問に答えていただきました。

マルチエージェントシステムのセキュリティ確保について

Timestamp: [17:35]

マルチエージェントシステムは新たな攻撃対象領域であり、エージェントのなりすまし、コーディネーションポイズニング、1 つの悪意のあるエージェントが他のエージェントに感染するカスケード障害などの新たな脆弱性があります。標準はまだ発展途上ですが（Google の A2A、Anthropic の MCP など）、現時点での実用的なアドバイスは、マイクロサービスセキュリティの基本に焦点を当てることです。

強力な認証: エージェントが、通信するほかのエージェントの身元を確認できるようにします。
境界制御: VPC Service Controls などのネットワーク分離を使用して、エージェント間の通信を制限します。
包括的なロギング: エージェント間のすべての通信をログに記録して、不審なアクティビティを検出します。

コンプライアンスとガバナンスについて（EU AI 規則）

Timestamp: [19:18]

EU AI 規則などの規制が間近に迫っているため、コンプライアンスは大きな懸念事項です。コンプライアンスとセキュリティは異なりますが、コンプライアンスによってセキュリティのベストプラクティスが強制されることがよくあります。ご紹介したツール、特に包括的なロギングと監査可能なアクションは、監査証跡を作成し、これらの規制で求められるリスク軽減の証拠を提供するために不可欠です。