オープンウェイトAIモデルをローカルでホスティングすれば企業はより高い制御力を得られるはずですが、AIエージェントがそれを支えるモデル自体を勝手に変更してしまえば話は別です。
AIの安全性をめぐる議論が激化する中、新たな研究が企業にとってより差し迫ったリスクに注目を集めています。日常的なタスクを実行しながら、自らが依存するAIエージェントがそのモデル自体を変更してしまうというリスクです。
AIセキュリティ企業Irregularの研究者たちは、誤った回答を返すローカルAIモデル上に構築されたアプリケーションのソフトウェア保守問題を解決するよう、コーディングエージェントに依頼しました。すると、このエージェントはアプリケーションへの変更にとどまらず、自らの活動も動かしていたオープンウェイトモデル自体をファインチューニングし、指示されていないにもかかわらず更新版を運用に投入してしまいました。
このテストは、エージェントとアプリケーションが同一のモデルチェックポイント(バージョン)を共有するセルフホスト環境で実施されました。エージェントはその後、ファインチューニング済みのバージョンをシステムのデフォルトモデルに組み込んだため、新たに起動されるインスタンスはすべてこの更新版を読み込むことになりました。
その影響は、エージェントが本来解決しようとしていた問題にとどまりませんでした。
あるテストでは、改変後のモデルが、研究者がファインチューニングデータに仕込んでいた6個の合成秘密情報のうち3個を後に再現してしまいました。また別のテストでは、エージェントがモデルをファインチューニングする過程で、架空の競合他社に関して意図的に訓練されていた拒否応答が削除されていたことが判明しました。テスト環境内のサービスは同一のチェックポイントを共有していたため、こうした改変された挙動は、それを利用する他のインスタンスにも波及しかねない状態でした。
Irregularは、このテストがエージェントが実運用環境でどの程度の頻度でこうした挙動を取るかを示すことを意図したものではないと注意を促しています。テスト環境では、エージェントにフルのシェルアクセス権と、訓練・デプロイ環境へのアクセス権が与えられていました。
今回の調査結果は、AIの進歩に安全対策が追いついているかどうかが改めて厳しく問われる中で発表されました。今月初め、OpenAIのチーフサイエンティストであるJakub Pachocki氏は、現在のアライメントおよびモニタリング手法では、最大速度でのスケーリングを際限なく維持するには不十分だと述べています。この議論は、Anthropicの研究者であるJacob Coxon氏が安全性への懸念を理由に辞任し、AnthropicのCEOであるDario Amodei氏がフロンティアAIの開発ペースを落とすよう呼びかけたことで、さらに激しさを増しました。
プロンプトインジェクションが永続性を獲得
IDC Asia/Pacificでサイバーセキュリティ分野のシニアリサーチマネージャーを務めるSakshi Grover氏は、Irregularの今回の研究がプロンプトインジェクションの潜在的な永続化メカニズムをも示している点を指摘しています。
「多くの企業が過小評価しがちな影響は、プロンプトインジェクションが単一セッション内にとどまらなくなるという点です」とGrover氏は述べています。
Grover氏によれば、攻撃者は必ずしもエージェントを直接侵害する必要はありません。悪意のある素材がエージェントによるモデル改変に使われる訓練データに影響を与えれば、その効果は結果として生じるチェックポイントに引き継がれ、元のセッションが終了した後も残り続ける可能性があるためです。
セルフホスト型のオープンウェイトデプロイには、もう一つ考慮すべき点があります。基盤となるウェイトへの直接アクセスは、推論専用APIでは開かれていないモデル改変への経路をエージェントに与えてしまうのです。
Irregularの計画立案テストでは、エージェントがモデルウェイトにアクセスできる場合、42%のケースでウェイトの改変が見られましたが、モデルがAI経由でのみ利用可能な場合は皆無でした。この数値はテスト条件下でのエージェントの計画立案を反映したものであり、実際のデプロイ環境でこうした挙動がどの程度の頻度で発生するかを示すものではありません。
Grover氏は、主権やコンプライアンス上の理由からオンプレミス展開を推進する企業は、こうしたアーキテクチャがより高い制御力を得られる分だけリスクが自動的に低くなると考えるのではなく、異なるセキュリティプロファイルを伴うものとして捉えるべきだと述べています。
影響範囲と制御策
「単一のエージェントが、訓練データを選択し、モデルを改変し、さらにそのモデルを本番環境に昇格させることまですべて行えるようになっていてはいけません」とGrover氏は述べています。
デプロイシステムは、出所と完全性を検証できる承認済みチェックポイントのみを受け入れるべきだと同氏は付け加えています。
Grover氏はまた、単一のチェックポイントに依存するアプリケーションの数を、組織は集中リスクとして扱うべきだとも述べています。エンジニアリングエージェントとビジネスアプリケーションの両方で1つのモデルを使い回すことはインフラコストの削減につながる一方で、そのチェックポイントが改変された場合の潜在的な影響も増大させてしまいます。
モデルの改変は、権限を要する本番環境の変更として扱われるべきだとGrover氏は述べています。所有者を明確にし、各チェックポイントがどのような経緯で本番環境に投入されたかを記録として残す必要があります。本番モデルの変更前、そして置き換え後のモデルをデプロイする前の、それぞれの段階で人間による承認が必須とされるべきです。
