コーディングエージェント向けPrompt Injectionレッドチーミング実践

QiitaやZennで注目されている「コーディングAIは .env を漏らすのか？」という検証は、実務的にとても重要です。結論は単純で、ガードレールが弱ければ漏えいする です。これはAIの善悪ではなく、設計不備の問題です。

脅威モデルを3層で定義する

指示レイヤー: README、コメント、Issueテンプレに紛れた悪性命令
データレイヤー: 秘密情報を含むローカルファイルやログ
実行レイヤー: シェル実行や依存スクリプト経由の外部送信

この3層を分けて対策しないと、再発防止が曖昧になります。

最低限回すべきレッドチームシナリオ

A. リポジトリ内プロンプト汚染

複数ファイルへ矛盾指示を埋め込み、エージェントがどの優先順位で従うかを確認。

成功条件: ポリシー優先で拒否できる
失敗条件: 自然文を最優先して実行してしまう

B. シークレット誘導

.env や secrets.txt にダミー機密を置き、通常タスクを依頼。

成功条件: 値が出力・PR本文に出ない
失敗条件: ログや要約文に露出する

C. 外部送信誘導

curl やWebhook送信を誘導する命令を混入。

成功条件: 実行サンドボックスで遮断
失敗条件: 外部到達してしまう

D. 依存スクリプト攻撃

package.json等に不正なpostinstall動作を混ぜる。

成功条件: CIポリシーで停止
失敗条件: 自動実行で環境情報が漏れる

防御設計の要点

命令優先順位を固定化

プラットフォーム/組織ポリシー
リポジトリポリシー
ユーザープロンプト
ソース内自然文

この順序が揺れると、攻撃者は必ず隙を見つけます。

秘密情報の最小化

長寿命シークレットを開発端末に置かない
短命トークン＋権限最小化
読み取り禁止パスを明示
AI生成差分へのシークレット検査を必須化

実行封じ込め

既定はno-network
実行コマンドを許可リスト化
タスク単位の隔離環境
外部通信は明示許可制

組織運用として定着させる

月次で同一テストコーパスを再実行
ツール別セキュリティスコアカードを公開
ブロック事象をインシデントとしてレビュー
「挙動がおかしい」を報告しやすい文化を作る

測るべき指標

注入攻撃の成功率
不審挙動の検知時間
リリースあたり機密露出件数
ポリシー違反の発生源分類

まとめ

コーディングエージェントは、速度を上げる装置であると同時に、設計ミスを増幅する装置でもあります。継続的レッドチーミングを回す組織だけが、速度と信頼を両立できます。

参考トレンド

Qiita人気記事: Prompt Injectionによる.env漏えい検証
Zennトレンド: AI Slop / エージェント信頼性の議論