Arcjet Himalia 1 上線：提示注入如何判斷，為何程式與資安代理需要不同模型？
客服系統可以先觀察Himalia的誤擋與漏接，但程式與資安團隊應保留情境判斷與工具權限，不能用通用分類器代替整套執行控制。
Arcjet Himalia 1 的出發點，是同一句資料查詢，放進客服聊天與程式開發工具，可能需要完全不同的處理。因為在前者要求資料庫內容可能越權，在後者則可能正是使用者交付的工作。
Arcjet 於 2026 年 11 月 5 日推出自家 AI 安全模型系列，先把通用提示注入偵測換成 Himalia 1，並開放程式與資安專用版本的早期申請。
提示注入，是把外部資料包裝成指令，試著讓代理偏離原本交付的任務。當代理可以改檔或呼叫工具，讀錯一段文字就可能影響後續動作。
所以這次更新的重點，不只是換一個更小的模型，而是承認偵測需要知道代理正在做什麼。把所有技術文字都攔下來，也會讓合法工作無法進行。
我會建議客服團隊先觀察它能否降低誤擋，再決定阻擋規則。程式與資安團隊則應保留任務脈絡與工具權限，不能把通用模型的分數當成所有代理都安全的證明。
要看懂這個差別，得先分清楚已經上線的通用版本，和仍在早期開放的專用版本。
Arcjet Himalia 1 已上線，Thebe 與 Carme 分別處理什麼？
Himalia 針對一般聊天與模型端點，Thebe 面向程式代理，Carme 面向經常閱讀攻擊描述的資安代理。三者要處理的問題相近，但合法輸入的樣子差很多。
依 Arcjet 官方公告，Himalia 1 已供使用提示注入偵測的軟體開發套件呼叫使用。Thebe 1 與 Carme 1 則開放早期申請，還不能視為每個開發者都已能使用的正式能力。
一般客服主要回答產品與帳務問題，使用者突然要求操作資料庫，可能超出原本工作。程式代理卻經常要看查詢語法與執行結果，所以如果沿用客服的分類標準，正常開發也會被擋住。
資安代理的情況又更複雜。它閱讀漏洞公告與程式變更時，本來就會遇到攻擊描述。偵測系統必須分清楚是在討論風險，還是在試著指揮代理洩漏資料、改變依賴或削弱檢查。
為什麼不能把所有有害文字都算成提示注入？
內容是否有害，和文字是否企圖改寫代理的任務，是兩個問題。前者屬於內容審核，後者涉及指令來源與權限。如果把它們混在一起，團隊就很難知道一次阻擋究竟防住了什麼。
官方也將這兩類模型分開描述。這次已上線的是提示注入分類器，另一個基於 ShieldGemma 的內容審核模型仍列為後續公告項目，因此不能把預告能力一起算進目前產品。
同一段文字會因角色而有不同判斷，這也解釋了為什麼訓練資料比單純擴大模型更重要。
用小型分類器偵測提示注入，和請聊天模型判斷有何不同？
分類器直接給出良性或注入的標籤，因此省下生成說明文字的步驟，但判斷品質仍取決於它看過的資料。它適合放在請求流程裡反覆執行，而不是每次都請大型模型寫一份解釋。
官方表示，這次提示注入模型以 Qwen3-0.6B 為基底，進行完整微調，再把產生文字的輸出部分改成兩類判斷。微調是讓已有語言能力的模型，透過特定資料繼續學習一項工作。
這裡的完整微調，和只調整少量新增參數的方法不同。不過基底模型採 Apache 2.0 授權，也不代表 Arcjet 已公開成品權重、訓練資料或整套服務的重製權利。
訓練資料怎麼讓模型判斷錯方向？
Arcjet 說，早期資料裡幾乎沒有很短的正常文字，模型因此把「短」學成攻擊線索。這個例子說明，即使樣本標籤沒有明顯錯誤，資料分布也可能讓分類器抓到無關特徵。
團隊後來在處理流程中移除重複與錯標樣本，也排除和評估集合重疊的資料。這些措施想降低模型只是認出看過題目的情況，但成效仍要由後續測試驗證，不能只因為清理過資料就視為沒有偏誤。
官方另外提到，評估會針對不同文字變形與攻擊類別分開觀察。在正式服務中，也會先辨識特定編碼與結構，再把解碼後文字連同原文交給模型，避免只看表面字元而錯過實際意思。
這是廠商描述的產品設計，本文沒有獨立重現其效能，也沒有對外部系統執行攻擊測試。即使資料清理得更仔細，一次只看一則文字仍可能漏掉跨工具與跨回合的意思。
程式代理為何還需要第二階段的任務脈絡？
Arcjet 的程式代理流程先找可疑段落，再連同任務、工具來源與近期紀錄判斷，因為合法程式和惡意指令可能長得很像。單看一則工具輸出，未必能知道它是否偏離使用者交付的工作。
第一階段的分類器負責快速篩選，第二階段的決策模型才把可疑片段放回情境。這讓團隊不必把所有內容都交給較重的判斷流程，也有機會避免把正常除錯訊息直接攔下。
例如代理正在修正資料匯出功能，工具結果提到資料表與存取設定，本身不一定代表攻擊。但如果外部說明突然要求它把工作目錄內容傳到無關位置，判斷就必須回到這件事是否在授權範圍內。
這個例子是流程分析，不是本文觀察到的實際攻擊。它想說明的是，來源、目的與原本任務必須一起看，不能只靠某個技術詞彙決定允許或拒絕。
專用模型能省掉第二階段嗎？
官方說 Thebe 針對程式代理資料訓練，希望提高第一階段準確度，減少需要第二階段介入的次數。這和宣稱專用模型已經不需要情境判斷，是不同程度的主張。
跨回合攻擊也會增加難度。一段文字單獨看可能正常，和前幾次工具回應連起來卻形成新的指令，因此近期工作紀錄有助於辨識一次輸入以外的關係。
但紀錄變多也意味著整合者要決定送哪些內容給檢測流程。工作脈絡並非愈多愈好，還要考量是否包含不必要的機密，以及這些內容如何被服務處理。
這種流程想同時減少誤擋與漏接，評估時也要把兩種錯誤分開計算。
延伸閱讀：MCPhantom 風險：AI 代理為何重裝已封存 MCP，98% 數字該怎麼讀？
F1 約 0.97 代表什麼？公開資料集成績不能當真實保護率
官方數字顯示它在指定資料集上能區分多數樣本，但沒有證明所有公司的真實輸入都會有相同結果。評估資料裡正常文字與攻擊文字的比例，也可能和正式服務不同。
公告列出兩個公開集合的內部測試。以下保留原始小數口徑，方便看出不同錯誤，而不是只挑一個較好看的總分。
| 資料集 | F1 | 精確率 | 召回率 | 誤報率 | 漏報率 |
|---|---|---|---|---|---|
| neuralchemy 提示注入集合 | 0.964 | 0.969 | 0.958 | 0.044 | 0.042 |
| jackhhao 越獄分類集合 | 0.971 | 0.978 | 0.964 | 0.024 | 0.036 |
表格裡的 F1 綜合了精確率與召回率。精確率看被判為攻擊的內容，有多少確實是攻擊；召回率則看所有攻擊裡，模型找出多少，兩者不能互相替代。
誤報率描述正常輸入被攔下的比例，漏報率描述攻擊沒有被找出的比例。因此第二列 F1 接近 0.97，並不是所有真實流量都有百分之九十七的安全保證。
假設有一萬筆正常輸入，且它們恰好符合第一個集合的分布，誤報率 0.044 對應約四百四十筆可能被誤判。這只是用表格做的示意換算，並不是對某個正式服務流量的預測。
這也說明為什麼低比例錯誤仍可能影響客服體驗。當合法流量遠多於攻擊，團隊需要的不只是找出攻擊，也要知道正常使用者能否完成工作，以及被攔下後是否有合理的處理入口。
團隊自己的測試要補上什麼？
先收集原本應該成功的合法工作，才能知道系統是否妨礙客服或開發。若只測已知攻擊，很容易得到看起來很高的攔截率，卻不知道正常使用者有多少次被拒絕。
再把案例依來源與任務分類，例如使用者輸入、外部頁面、工具結果和安裝的工作規則。這種分類有助於定位錯誤發生在哪一段，也讓專用模型與通用模型的比較更有意義。
官方這次公開的表格是 Himalia 1 的測試，不能直接移植為 Thebe 或 Carme 的成績。後兩者需要另外的場景資料，才能回答它們是否降低了程式或資安工作的誤擋。
知道模型會出錯之後，整合方式就應把觀察、阻擋和工具執行分開安排。
只回傳裁決而非信心分數，應用程式要怎麼接住結果？
對外只回傳裁決，可以避免應用綁死某個分數門檻，但呼叫端仍必須實際處理拒絕與錯誤。偵測服務給出結果，不代表後面的工具已經自動停止。
Arcjet 說，若把連續分數交給外部，攻擊者可能反覆調整文字，觀察是否低於門檻。另一個問題是模型重訓後，分數分布可能移動，讓應用原本自行設定的門檻悄悄改變效果。
因此內部模型仍會產生機率，再經過門檻轉成判斷，但產品對外提供的是裁決。這和模型本身完全沒有機率或不會調整判斷門檻，是兩回事。
觀察模式與正式阻擋要如何安排？
官方偵測文件提供觀察與正式執行的區分。先觀察可以量出原本的工作會被判成什麼，再由整合者決定哪些結果應該觸發拒絕。
把拒絕與檢測故障分開也很重要。模型判斷文字不該繼續，和服務連線失敗沒有拿到結果，不是同一個狀態；應用需要事先決定各自的處理方式，才能避免錯誤時默默繼續執行。
代理的工具權限仍是另一道控制。即使檢測漏掉一段指令，工具若沒有取得相應資料或變更權限，後續影響也可能不同，因此不應因為加入偵測器就擴大原本授權。
測試清楚誤擋、漏接與錯誤處理，才能決定哪一段工作適合正式開啟阻擋。
Arcjet Himalia 1 常見問題
模型權重有開源嗎？
模型權重是訓練完成的核心參數。這次公告介紹基底模型與微調方法，也提供由平台維運的雲端服務，但沒有因此宣布公開 Arcjet 成品權重。基底模型的授權，不能直接當成整套安全服務的開源授權。
Thebe 與 Carme 已全面開放嗎？
官方將兩者列為早期申請，分別面向程式與自主資安代理。若要評估使用，應先確認取得資格與實際支援範圍，而不是套用通用版本的可用狀態。
有偵測器就能放寬工具權限嗎？
偵測器判斷文字是否有問題，工具權限則限制代理實際能做什麼，兩者功能不同。應保留原本的資料與動作授權，並以自己的合法工作測量誤擋和漏接。
先用自己的合法工作量測誤擋，再決定阻擋範圍
適合先測的，是已有客服輸入與工具邊界的系統，因為團隊能分辨哪些請求原本應該成功。程式或資安工作則需要另外確認專用模型資格，並保留完整的任務脈絡。
先依官方偵測文件建立觀察流程，保存合法與異常案例，再讓負責人決定何時啟用拒絕處理。這樣得到的會是適用於自己應用的取捨，而不只是把公開資料集總分搬到產品說明。
延伸閱讀：Cohere 揭露 Qwen 沙箱異常：模型說不叫工具，為何仍嘗試對外傳送？
