KubernetesにおけるAIエージェントのセキュリティ：「プロンプトインジェクション」では不十分な理由

【なぜ重要か】 KubernetesクラスターをAIエージェントに操作させる運用形態が広がる中、エージェントへの攻撃手法とその影響範囲は従来の「プロンプトインジェクション」という概念では正確に捉えきれない。エージェントは読み取り専用権限であっても、Secretや環境変数を参照できるため、権限を絞っただけでは情報漏洩を防ぐには不十分である。セキュリティ担当者はエージェント固有のリスクモデルと対策を理解する必要がある。

【ポイント】

• 「プロンプトインジェクション」より「プロンプトポイズニング」が適切：SQLインジェクションはパラメータ化クエリで解決できるが、LLMにはシステムプロンプト・ユーザー指示・コンテキストを分離する同等の仕組みが存在しない。攻撃者がアプリケーションログに悪意あるテキストを混入させれば、それがオペレーターの指示と同等の重みでエージェントに処理される。
• 読み取り専用権限でも安全ではない：書き込み権限を持たないエージェントはクラスターを破壊できないが、Secretや環境変数を読み取ることは依然として可能であり、ポイズニングされた状態でそれらを外部へ漏洩させられるリスクは残る。
• 実際の攻撃事例：Aikido SecurityはGoogleのGemini CLIリポジトリで使われるGitHubワークフローに対し、細工したIssueを通じてエージェントが保持する環境変数を漏洩させるプロンプトポイズニングを発見した。Googleは該当の変数を返さないよう修正したが、ポイズニングそのものへの根本的な対策は講じられていない。
• 既存のセキュリティ施策はエージェントにも有効だが、「信頼して検証する」アプローチが必要：RBACによる最小権限設定などの仕組みはエージェントにも適用されるが、LLMは誤った推論（ハルシネーション）を行う可能性があるため、エージェントの判断を額面どおりに信頼することはできない。人間がループ内で監視する体制が求められるが、これは業界全体でまだ解決されていない課題である。
• Aikido Securityによる多層的な対策：AIペネトレーションテストでポイズニング耐性を検証できるほか、Infrastructure as CodeチェックによるRBACの過剰権限検出、シークレットスキャン、コンテナイメージスキャン、クラウドポスチャチェック、攻撃パス分析を組み合わせることで、エージェントが悪用された場合の影響範囲を把握・低減できる。

【まとめ】 KubernetesのAIエージェントは「読み取り専用にすれば安全」という前提が成り立たず、ポイズニングによる情報漏洩リスクは権限の種類に関わらず存在する。エージェントのRBAC権限を最小化しつつ、AIペネトレーションテストや攻撃パス分析でエージェントが実際に到達できる範囲を継続的に把握・検証する体制を整えることが、次に取るべき具体的なアクションとなる。