看到一個容易被解讀成「prompt injection 快要被解決」的研究，我反而先問：當可信度被塞進模型內部，究竟是誰的判斷成了系統規則？

預印本 Heads of Security 提出 HoS，以少量學習式 per head attention gates 區分可信指令與不可信資料。黑箱 RL Hammer 對 GPT OSS 20B 的攻擊成功率為 97%，SecAlign 為 85%，HoS 降至 10%。但白箱 Claudini 要達到相同 ASR，HoS 約需三倍 FLOPs；ASIDE tool use utility 只有 10%。

從社會學的視角看，HoS 也是權力配置。誰定義可信，是開發者、企業，還是承擔錯誤後果的使用者？在多語言、方言與低資源語言情境中，不可信標籤可能只是模型不熟悉某種表達。少數族群的語言若被資料低估，「安全」就可能變成排除。

我會用三層框架評估。第一是技術防線。HoS 不能取代權限隔離、工具驗證與最小權限原則，測試也要比較語言、任務與失敗後果。第二是系統權限。錯誤判斷不應直接造成付款、寄信、刪除資料，高風險工具應能拒絕、暫停並要求人工確認。第三是組織責任。企業要說明誰定義可信來源，誰審查群體影響，誰接收申訴並補救。

部署至少保留 audit、deny、fallback：記錄模型看見什麼與如何判斷，在高風險情境阻擋行動，必要時退回人工。否則模型內建安全容易變成責任外包。

HoS 顯示注意力控制可能改善部分攻擊，也提醒我們安全不等於信任分類器。可問責的安全必須回答誰決定、誰有權限、誰承擔代價，並讓外部的人能檢查、否決與修正。這篇仍是預印本，部署前要驗證的，是模型不確定時我們是否仍保留制度性的說不。