AIエージェントの「harness」が新たな攻撃対象に

セキュリティ責任者にAIエージェントのリスクがどこにあるか尋ねると、答えはほぼ必ずモデル自体の話から始まる——ジェイルブレイクで突破できるか、重みを信頼できるか。この反応は次第に時代遅れになりつつある。増え続けるエクスプロイトの実証、独立したレッドチーム演習、研究者による評価は、むしろモデルと外の世界の間にあるコードを指し示している。このコードは「harness」と呼ばれ、モデルにツールを与え、そのテキスト出力をシェルコマンド、ファイル書き込み、API呼び出しといった実際の操作に変換する。多くの企業では、この層は十分に棚卸しされておらず、テストもされておらず、担当チームも明確でない。

AI harnessとは具体的に何か

実務者に定義を尋ねると、異なる方向から同じ概念に収束していく。AIセキュリティ企業Zenityの共同創業者兼CTOであるマイケル・バーガリー氏は、これをモデルの「手足と目」と呼ぶ。モデル自体はテキストトークンしか生成せず、それをシェルコマンドやファイル書き込み、API呼び出しに変換するのがharnessだ。SANS Instituteのチーフ AI officer 兼研究責任者ロブ・T・リー氏は、モデルをエンジン、harnessをシャシーに例える。Lasso Securityのシニア機械学習エンジニアであるマイケル・スロミン氏は、これをエージェント型アプリケーションのループ全体を動かし、モデル、ツール、ユーザーをつなぐオペレーティングシステムだと表現する。シスコのディスティングイッシュト・エンジニア、オマール・サントス氏は最も形式的な定義を示す。harnessとはモデルを取り巻き、使えるものにする層であり、オーケストレーション、ツール利用、プロンプト、コンテキスト、ロール、評価、ガードレールを含む。4つの説明はいずれも同じ問題を指している。エージェントの権限が実際に行使されるのはharnessの中だ。それはモデルの推論と、実際のファイルシステム、APIキー、本番データベースとの間に位置する。完璧に調整されたモデルであっても、周囲のharnessが任意のシェルパターンを信頼していたり、信頼できないコンテンツを含むワークスペースを複数回にわたって使い回していたりすれば、ほとんど意味をなさない。

harnessが破られる3つの経路

Novee Securityの創業エンジニアでセキュリティ研究者のエラッド・メゲド氏は、Black Hat USAでGitHubのissueだけを使ってAnthropic、Google、OpenAIの公式自動化リポジトリに侵入した経緯を発表した。具体的な脆弱性はベンダーごとに異なっていた——コード実行、認証情報の露出、下流のより強力なコンポーネントが再検証せずに信頼してしまう命令の注入など。しかし根底にあるアーキテクチャ上の誤りは、3社とも驚くほど一致していた。あるコンポーネントがセキュリティ上の判断を下し、その先のより強力なコンポーネントが、それを再検証することなく信頼してしまうという構造だ。「これはモデルの失敗ではなく、信頼境界の失敗だ」とメゲド氏は総括する。

2つ目の失敗モードは、コーディングミスがなくてもharness自体の設計に潜む。Lasso Securityの研究者は、同一のオープンウェイトモデルのharnessだけを入れ替え、モデル、プロンプト、ツールはそのままにした。攻撃成功率は1%から24%へと上昇し、テストした100通りのモデルとタスクの組み合わせのうち43通りで結果が完全に逆転した。「harnessを変えれば、実質的にまったく別のエージェントになる」とスロミン氏は言い、harnessとモデルを一緒にベンチマークすべきであり、デフォルト設定を検証せずに採用すべきではないと勧める。

3つ目の弱点はharnessのサプライチェーンを貫く。Zenityのマイケル・バーガリー氏のチームは、エージェントに新しいタスクを教える「skill」ファイルを調査し、Anthropicやシスコ自身のものを含む市場のあらゆるスキャナーを通過していた、認証情報を盗むマルウェアが隠されていたものを発見した。悪意あるスキルの一つは、エージェントが再起動のたびに読み込むメモリファイルに自らを書き込んでいた。スキルを削除しても再インストールの指示は残り、エージェントが次に実行されるとマルウェアが復活した。別のスキルはAnthropicの正規ツールを装い、実行後に本物のツールを削除して攻撃者のバージョンに置き換えたが、ユーザーには目に見える変化はなかった。最も顕著だったのは、人気のオープンソースツールを複製し、密かに認証情報窃取機能を加えたキャンペーンで、発見・停止されるまでに約170万回ダウンロードされていた。

• 棚卸し:本番環境で稼働するすべてのharnessを洗い出す。社内で「コパイロット」「ワークフローアシスタント」「プラグイン」と呼ばれているものも含めて
• アクセス権のマッピング:各harnessがどのツールとデータにアクセスできるかを特定し、必要最小限まで権限を絞る
• 独立したテスト:デフォルト設定を無検証で信頼するのではなく、harnessとモデルを一緒に評価する

チームはアプリ、サービス、パイプライン、ボットという単位で考えがちだ。harnessはコードリポジトリやSaaS製品、ベンダーの設定画面の中に紛れ込み、セキュリティ資産台帳に独立した資産として現れることがない。

社内でAIエージェントを展開する企業にとって何が変わるか

Copilot系ツールの拡張、自社開発の自動化、あるいはエージェントフレームワークとして社内にAIエージェントを展開している企業にとって、harnessが今日セキュリティ資産台帳に独立した項目として記録されることはほとんどない。サントス氏は、完全な可視性を待つ必要はないと助言する。本番システムから着手すれば、比較的短期間で60〜70%のカバレッジを達成でき、プロトタイプやシャドーAIは第二段階に回せばよいという。これは、高リスクな自動化システムの文書化を求める各地の規制の流れとも重なる。エージェントの動作を実際に実行するツールは、モデルと同じ資産台帳に含まれるべきものだ。具体的には、セキュリティチームはharnessを調達・監査プロセスにおける独立したコンポーネントとして扱う必要がある——独自のリスク評価、独自のパッチサイクル、そして背後で動くモデルが何であれ最小権限の原則に基づくアクセス権を備えて。