LLMエージェントのバックドアはなぜ追加学習を生き残るのか

導入

開発者は、第三者が提供する基盤モデルを教師ありファインチューニング（SFT）やタスクレベルの強化学習（RL）で適応し、コード生成、デバッグ、ツール利用を行うソフトウェア開発エージェントを構築する。この通常の開発フローが、モデルに元から仕込まれたバックドアを自動的に消去するとは限らないことを、Hugging Face Daily Papersで紹介された研究が示している。

ここでいうバックドアとは、特定の入力パターンが現れたときだけ起動し、攻撃者が意図した悪性出力を生成する隠れた挙動である。研究チームは、ソフトウェア工学タスク向けモデルを対象に、この挙動がSFTとその後のRLを通過する際にどう変化するかを調べた。

主な発見

• SFTは弱めるが、完全な除去を保証しない。 良性データによるSFTは攻撃成功率を大きく下げるものの、残存する挙動が存在し得る。
• RLが残った挙動を維持する可能性がある。 SFT後のタスクレベルRLは、残存バックドアを保つ場合があり、攻撃成功率を高めるケースも確認された。
• 持続性には複数の要因がある。 初期バックドアの強さに加え、通常の学習目標とバックドア挙動の勾配がどの程度両立するかが、SFTでの消退速度に関係すると分析された。
• 攻撃者は持続性を事前に高められる。 提案手法PersistBDは、すでにバックドアを持つモデルを出荷前に調整し、下流の良性後学習を生き残りやすくする。

Qwen2.5-Coder-7Bでの実験では、PersistBDによりSFT後の攻撃成功率が20%から74%へ、SFTとRLの後では20%から76%へ上昇した。一方、良性タスクの性能は同程度に保たれた。つまり、通常の性能指標だけでは、バックドアの存在を見抜けない可能性がある。

意義と影響

この研究が突き付けるのは、追加学習を「モデルの浄化工程」とみなすことの危うさである。開発者が独自データでSFTを行い、報酬に基づくRLで性能を改善しても、第三者モデルから継承した隠れた挙動が残る可能性はある。コードを書き、ツールを呼び出し、プロジェクトを変更できるエージェントでは、特定条件下の出力が実際の操作につながるため、通常のチャットモデルより影響が直接的になり得る。

モデル提供者は出荷前のバックドア検査と挙動監査を強化すべきであり、利用者はSFTやRLだけを安全確認の代わりにしてはならない。学習段階ごとのトリガー指向評価、挙動の比較、異常なツール呼び出しの監視が必要になる。

供給網上の重要な教訓は、攻撃者が下流の学習方法を予測し、それに合わせて悪性挙動を最適化できる点にある。第三者モデルをエージェントへ適応するプロジェクトでは、モデルの出所確認、段階的なレッドチーム評価、運用後の監視を一体化しなければならない。

出典：Hugging Face Daily Papers