AID-H-002.002
極高
Inference-Time Prompt & Input Validation
這是 tokenizer 通道最重要的第一道防線。提示詞進入監控模型或執行模型之前，系統應該先正規化 Unicode、移除或標記看不見的控制字元、tag character 和私用區字元、保留可稽核的原始輸入紀錄，最後只把經核准的標準化版本送進兩條模型路徑。
監控模型看不見的隱藏訊息：Lingua Ex Machina
Lingua Ex Machina 指出一個常見 LLM 安全架構裡的盲點：一個模型負責執行任務，另一個模型負責檢查提示詞或輸出是否安全，但兩者實際看到的文字可能不同。某些看不見的 Unicode 字元會被送進執行模型，成為只有它能讀到的隱藏訊息；同一段文字送到監控模型時，卻可能在分詞器（tokenizer）前處理階段就被刪掉，意思是安全檢查不是判斷力不夠，而是一開始就沒拿到完整內容。Unicode 通道可以用碼位（codepoint）層級清理來關掉；但如果訊息藏在普通英文句子的用字、句型或排列方式裡，語義隱寫（semantic steganography）仍然幾乎無法有效偵測，所以企業不能只靠監控模型，還要限制 agent 能做什麼、資料可以流去哪裡。
威脅分析
- 雙模型架構在企業裡很常見。 一個 AI 系統負責執行任務，另一個 AI 系統負責檢查提示詞（prompt）或輸出是否安全。很多團隊還會刻意選不同模型家族，希望降低單一模型誤判的機率。
- 盲點發生在模型開始推理之前。 如果執行模型保留了看不見的 Unicode 字元，但監控模型在分詞時先把它們刪掉，隱藏內容就會只進入執行模型，而不會進入監控模型的檢查範圍。
- 這份報告確認這是一條實際存在的通道，不只是理論上的風險。 在 tag character（標籤字元）的測試裡，接收方可以還原隱藏訊息，監控模型卻完全還原不出來。就算把解碼方式交給監控模型也沒用，因為承載訊息的字元在更前面的處理階段已經不見了。
- 這部分的防禦重點在輸入標準化與前處理，而不是監控模型本身夠不夠聰明。 在任何模型分詞器執行前，就要先檢查和正規化 Unicode 碼位；監控模型和執行模型要拿到同一份經過核准的標準化文字；監控模型回空白或解析失敗時，也要觸發警示，而不是被當成安全。
- 比較難的是語義隱寫。 報告也描述了看起來正常的英文句子，透過用字、句型或結構來藏訊息。可以用一段普通客服訊息來類比：
表面上：訊息寫著「紅色方案比較適合，藍色資料夾稍後整理，綠色附件放在最前面」，讀起來像普通業務文字。
暗號規則：如果下游 agent 先前已從提示詞、外部文件、工具說明或記憶中取得一套暗號的規則，例如：紅色請解讀成客戶名單，藍色代表內部報價，綠色代表設定檔；「稍後」代表送到外部位置。
資安後果：監控模型看到的是顏色、資料夾和附件順序，真正執行任務的 agent 卻可能把它解讀成挑出敏感資料並外送的高風險指令。
清掉 Unicode 字元不能解決這種通道，測試裡的監控模型表現也不好。防禦方不應把偵測當成主要防線，還要降低 agent 被帶偏後能造成的後果。 - 重點在架構層。 這份報告把多模型監控的一個基本假設攤開來檢查：監控模型與執行模型是否真的看到同一份安全相關輸入。如果兩者在 tokenizer 或前處理階段看到的內容不同，後面的安全判斷就不能被當成完整監控。
適用的 8 項 AIDEFEND 防禦手法
AID-D-001.001
極高
Per-Prompt Content & Obfuscation Analysis
問題不在模型突然具備了新能力，而在同一段輸入經過不同前處理後，監控模型和執行模型看到的內容不一致。偵測邏輯應該在模型分詞之前檢查原始碼位、正規化後文字、Unicode escape 解碼、tag character、私用區字元、雙向文字控制、同形異字，以及高亂度片段（例如看起來像編碼或亂碼的文字），而不是等監控模型已經把關鍵字元弄丟後才看。
AID-H-019.004
高
Intent-Based Dynamic Capability Scoping
隱藏指令最危險的地方，是它可能讓 agent 做出原本不該做的事。每次請求都重新收斂工具權限和動作預算，並把它們綁在可信的使用者意圖上，就能避免一個隱蔽訊號突然授權 email、瀏覽器、資料庫寫入、shell 命令或憑證存取。
AID-H-019.005
高
Value-Level Capability Metadata & Data Flow Sink Enforcement
語義隱寫未必總能被偵測到，所以執行期間不能只依賴事前判斷或模型監控，還必須建立後果控制機制。意思是：即使前面漏掉了隱藏訊息，系統也能立刻停用、隔離、降權或回復。來自不可信提示詞、工具輸出或 agent 訊息的值，都應該帶著來源標記；除非政策明確允許，不然高機敏資料不能被送到對外 HTTP、email、檔案匯出、記憶寫入或資料庫寫入等高風險位置。
AID-D-017
中
AI Detection SLO & Alert-Coverage Measurement
這份報告本質上是在講監控覆蓋率失效：系統以為監控模型有看見輸入，其實關鍵內容在更前面的處理階段就消失了。這個控制本身不是第一線阻擋，而是用來證明監控管線仍然看得到原始文字和標準化文字、空白或解析失敗的判定會示警，以及模型或 gateway 更新後，tokenizer survival 的回歸測試仍然有覆蓋。
AID-D-003.002
中
Sensitive Information & Data Leakage Detection
如果隱藏通道被用來外洩機密憑證（secrets）或客戶資料，輸出檢查仍然是有價值的後段防線。它應該在回應送出前，檢查生成文字、工具參數、紀錄、URL 和結構化欄位裡是否包含 secrets、PII、內部指令或刻意編碼的揭露格式。
AID-H-018.007
中
Dual-LLM Isolation Pattern
多模型隔離仍然有價值，但要接對方式：隔離元件讀取不可信內容，輸出型別明確的結果；真正有工具權限的執行模型只看驗證過的結構。關鍵補強是，兩邊都必須基於同一份標準化後的輸入來工作。
AID-R-004
中
Post-Incident Hardening, Verification & Institutionalization
tokenizer 盲點不能只修一次。發現繞過或紅隊測到問題後，要保留攻擊樣本（payload）、加入監控模型與執行模型的 tokenizer survival 測試、把輸入正規化與清理邏輯做成共用的執行期元件；只要測試發現同類繞過通道又被打開，就讓部署流程失敗。
身為資安防禦者，我們應該這麼做
- 把這件事當成 AI harness engineering（駕馭工程）的問題來面對，而不是單一監控模型問題；這裡的駕馭工程指的是模型外層管線：執行模型、監控模型、模型閘道、提示詞組裝器、RAG 轉接層、agent 對 agent 通道、工具調度器、監控封裝層和日誌層。每條路徑都要標明原始輸入在哪裡保留、標準化安全副本在哪裡產生，以及監控模型和執行模型實際看到什麼。
- 在任何模型分詞器執行前，加入規則固定、可重複的 Unicode 檢查（deterministic Unicode check）。檢查原始碼位、移除或標記看不見的控制字元和 tag character，並把同一份標準化文字送給監控模型和執行模型。
- 不要把空白、格式錯誤或解析失敗的監控結果當成安全。依照動作風險，改成拒絕、用已驗證的解析器重試，或送人工審查。
- 針對實際使用的模型配對建立 tokenizer survival 回歸測試，用來確認隱藏字元會不會在監控模型前被吃掉；不同廠商模型互相監控、同一廠商模型互相檢查的配置，都要納入測試。
- 限制 agent 在漏掉訊息後能做什麼。把工具權限綁在可信任務上，阻擋不可信來源的值觸發高風險動作，並在資料離開系統前檢查輸出和工具參數。
- 語義隱寫目前仍難以穩定偵測。可疑訊號只能當成追查線索；真正要守住的是高影響動作，仍要靠工具能力政策、資料流向控管和審查機制。
2 個額外的防禦考量
每組監控/執行模型都要測 tokenizer 邊界
除了上面對應的防禦技術，團隊還應該明確測試每一組監控模型與執行模型的分詞器差異。測試證據不只要說有通過，還要留下原始輸入位元組、Unicode 碼位清單、標準化後文字、監控模型看見的文字、執行模型看見的文字，以及兩者不一致時系統是否會預設阻擋。
建議做法: 把 tokenizer survival 測試放進模型 gateway 的 CI。只要模型、SDK、proxy、分詞器或提示詞 gateway 有變更，就重新測；對高影響 agent 路徑來說，只要監控模型和執行模型看到的內容不一致，就應該阻擋發布。
語義隱寫要先當成後果控管問題
報告裡普通語言藏訊息的通道，不能靠 Unicode 清理解掉。即使系統能抓到可疑用字或不尋常句型，也只能把它當作追查線索，不能當作正式環境裡唯一的防線。
建議做法: 把語義隱寫偵測當成輔助訊號，主要防線仍要放在能力收斂、資料流向控管、資料外洩檢查、人工審查和事件重放，避免漏掉的隱藏訊息變成真實動作或資料外洩。
結論
面對 Lingua Ex Machina，最好的理解方式，是把它當成 AI harness engineering（駕馭工程）的問題處理。這裡的重點不是再加一個監控模型，而是設計模型外層的輸入、監控、工具調度和證據管線，確保安全檢查看到的內容，就是執行模型會用來決策的內容。Wisely Chen 在 AI Coding 實戰分享 裡把同一個觀點說得很清楚：安全不只是模型能力問題，也是駕馭工程問題，因為外層設計會決定每個模型到底看見哪些證據。AIDEFEND 可以把可修的 Unicode 通道對應到具體防線：輸入驗證、混淆偵測、監控覆蓋率量測、回歸測試、能力收斂和資料流向控管。必須講清楚的邊界是語義隱寫：當隱藏訊息靠普通語言承載，而不是靠 Unicode 字元承載時，防禦方不應承諾完美偵測。更實際的目標，是確保漏掉的訊息不能默默變成資料外洩、未授權工具使用，或政策外的 agent 協調。