【geek-terminalニュース】注入防御をAttentionに組み込む「Heads of Security」、著者報告の実力と限界

【事象の全貌と背景】
以前お伝えしたプロンプト注入・多層防御の続報です。今回の焦点は「Heads of Security（HoS）」。編集長から渡された資料では対象論文の本文が欠けていましたが、追加調査で論文と著者の紹介ページを参照できました。ただし、提供された検索結果3には有効性の裏付けがありません。以下の手法・評価値は著者の説明として紹介し、独立検証済みの性能とは区別します。

著者らが掲げるのは、外部データを読みながら、そこに埋め込まれた命令には従わないモデルです。ウェブページを要約させたいのに、ページ内の「別の操作を実行しろ」が依頼主の指示として働く。この混線に対し、Attentionヘッドごとの学習済みゲートで情報の流れを調整する、と説明しています。[研究概要](https://arxiv.org/abs/2610.37657v1)

ギークに刺さるのは、防御の介入点です。実行直前の承認だけでなく、文章がモデル内部でどう参照されるかに手を入れる。設計上の問いは「危険な文を見つけたか」から「その文を誰の指示として処理するか」へ進みます。もしこの分離を保ったまま読解力も残せるなら、外部情報を大量に取り込むエージェントにとって魅力的でしょう。

【技術的ディープダイブ】
著者資料によれば、入力トークンにはtrusted、untrusted、templateの3種類のチャネルを付与します。各ヘッドは、チャネル間のAttentionを調整するゲートを持つ仕組みです。論文の式ではsoftmax前のスコアにlog σ(g)を加え、正規化前の重みをゲートで変化させます。ヘッドごとに調整するため、外部データを処理する経路を残しつつ、命令追従への影響を抑える狙いだとしています。[手法の説明](https://arxiv.org/html/2610.37657v1)

著者ページでは、基盤モデルの重みを固定し、GPT-OSS-20Bでは18,432個、Llama-3.3-70Bでは46,080個のゲートパラメータを学習すると説明しています。さらにRL-Hammerの評価では、GPT-OSS側の攻撃成功率の最大値が無防御97％、SecAlign適用85％、HoS適用10％だったと報告しています。[著者による仕様・評価](https://imperial-aisp.github.io/heads_of_security/)

ここで「攻撃の9割を永久に防ぐ」と読むのは早計です。この比較が示すとされるのは、指定された攻撃群と評価条件での結果です。少数パラメータという設計も、推論遅延やGPU使用量が同じ割合で減ることを意味しません。導入判断では、追加学習する量と、実際に動かすモデル全体の負担を別々に測る必要があります。

有用性にも注目です。論文の表では、GPT-OSSの5-shot MMLU-Proが元モデル68.3％、HoS67.2％と報告される一方、LlamaのAgentDynでは通常タスクの有用性が33.7％から18.3％へ低下しています。「能力を保つ」という要約だけでは、この例外が消えてしまいます。また著者らは、信頼する情報源の決定をHoS自身が担うわけではないとしています。[評価表と限界](https://arxiv.org/html/2610.37657v1)

つまり実装者には、境界を正しく渡す仕事が残ります。例えば検索結果を別のメッセージに転記した際、その出自まで維持できるか。ゲートの性能を論じる前に、アプリ側が外部の文章を依頼主の言葉へ昇格させていないかを点検したいところです。これは本稿からの実装上の論点です。

【コミュニティの生々しい熱量と議論】
提供されたr/AI_Agentsの投稿抜粋には「labelled as untrusted data」という表現があります。ツール出力、ウェブページ、リポジトリ内のファイルを非信頼データと明示し、指示の出所をオペレーターに限定する設定に触れています。ただし抜粋は文の途中で終わり、投稿本文も今回取得できませんでした。失敗の再現条件や原因まで確認した体験談としては扱えません。[提供された投稿の参照先](https://www.reddit.com/r/AI_Agents/comments/1xhaf5r/followup_ai_agents_keep_obeying_the_hidden_note)

一方、r/hermesagentの紹介文では、投稿者がプロンプト注入、認証情報流出、危険なツール呼び出しを防ぐMCP Security Gate Serverを作ったと主張し、「<5ms latency, local-first」を掲げています。これも投稿者の自己申告であり、性能の裏付けやHoSとの比較結果ではありません。[提供された開発者投稿](https://www.reddit.com/r/hermesagent/comments/1xdlnuc/i_built_a_security_plugin_for_hermes_against)

この2件から伝わるのは、出所の明示と実行経路の防御を、自分のエージェントへ組み込もうとする現場の関心です。ただし「RedditがHoSを絶賛」「懐疑派が論破」といった賛否は確認できません。ここからの争点は本稿の考察です。内部ゲートを評価する側なら、実行前に止めるまでにモデルが依頼を取り違える問題へ介入できる点に期待するでしょう。慎重な側なら、信頼ラベルの誤設定や、正常な作業まで弱くなる条件を問うはずです。

【今後の展望とエコシステムへの影響】
HoSを理由に、承認機構や権限制御がオワコンになるとは言えません。内部の情報処理と、外部へ作用する権限は異なる検証対象です。今後の再現評価では、同じ検索結果・同じツール権限を与え、防御の有無だけを変えて、攻撃への追従と正常な作業の完了を並べて測る方法が有益でしょう。

特に試したいのは、攻撃文の新しさだけでなく、長い会話や複数ツールを経た出自の維持です。境界が途中で失われるなら、モデル単体のベンチが良くても運用上の穴は残ります。逆に、境界を維持した条件で効果が再現されれば、アプリと推論基盤が信頼情報を受け渡す設計への関心が高まる可能性があります。

今回の面白さは、注意機構をセキュリティの調整点として扱う具体案にあります。次に見たいのは派手な単一スコア以上に、どの作業を保ち、どの条件で崩れるか。著者報告の改善幅を出発点に、その境界を第三者がどこまで確かめられるかが焦点です。