非対称問題：AIの安全対策は主に善良な人々を妨害する

HuggingFaceは最近のセキュリティインシデントにおいて、AIの安全ガードレールが実運用で直面する厄介な状況を明らかにしました。同社のチームがフォレンジック分析のためにAI支援ツールを使用しようとした際、最初に商用API経由で最先端モデルを試しましたが、すぐに壁にぶつかりました。分析には実際の攻撃コマンド、エクスプロイトペイロード、C2アーティファクトを大量に提出する必要があり、これらのリクエストはプロバイダーの安全ガードレールによってブロックされました。これらのガードレールはインシデントレスポンダーと攻撃者を区別できないからです。

やむを得ず、HuggingFaceはオープンウェイトモデルであるGLM 5.2を自社インフラにデプロイしてフォレンジック作業を完了しました。この選択は結果的に別の利点をもたらしました。攻撃者のデータやそれに含まれる認証情報が自社環境から流出しなかったことです。この経験は、事前に計画すべき大きなギャップを浮き彫りにしています。攻撃者が使用するモデルは、脱獄されたホステッドモデルか、制限のないオープンウェイトモデルかは不明ですが、いずれにせよ、攻撃者は利用ポリシーに縛られることはなく、防御側の作業はホステッドモデルのガードレールによって妨げられました。

この問題は実際のインシデントで初めて遭遇したわけではありません。研究者たちは、攻撃者が偽のシステム命令やポリシートリガーコンテンツをコードに注入することで、自動化されたAI支援分析を妨害しようとしていることも発見しています。例えば、_index.jsペイロードの先頭には、JavaScriptのブロックコメント内に偽のシステム命令とポリシートリガーコンテンツが含まれています。これらはコメント内にあるためJavaScriptの実行には影響しません（ランタイムはスキップします）。実際のマルウェアはコメントの後に、大規模な文字コード配列とROT置換関数を含むtry{eval(...)}ラッパーとして配置されています。

このヘッダーは明らかにAIによるコード分析を標的にしています。弱いパイプラインでは、このようなコンテンツが言語モデルに送られることで、実際のマルウェアに到達する前に拒否反応、プロンプト混乱、コンテキスト汚染、早期分類を引き起こす可能性があります。もちろん、これは静的な検出を完全に回避する魔法ではありません。YARAルール、エントロピーチェック、AST解析、文字列抽出、難読化解除、振る舞いルールは依然として有効ですが、LLMファーストの簡易トリアージシステムに対する実用的な逆分析テクニックです。

この問題に対する完璧な解決策は今のところありません。安全ガードレールは最低限の悪用を防ぎ、攻撃者に一定の労力を強いるという利点があります。しかし、この現象はLLMガードレールに固有のものではありません。過去に弾丸ホスティングプロバイダー、アンチチート回避、DRM除去ツール、自動CAPTCHA解決、アンダーグラウンドなゼロデイ販売業者が存在したように、今後は検閲なしのLLMプロバイダーも登場するでしょう。これらのツールは誰でも利用可能ですが、善良な人々は法律を遵守する必要があるため使用できない一方、サイバー犯罪者はそのような制限をはるかに超えています。