AID-H-018.004
高
Intent-Based Dynamic Capability Scoping
隱藏指令最危險的地方，是它可能讓 agent 做出原本不該做的事。每次請求都重新收斂工具權限和動作預算，並把它們綁在可信的使用者意圖上，就能避免一個隱蔽訊號突然授權 email、瀏覽器、資料庫寫入、shell 命令或憑證存取。
監控模型看不見、執行模型卻讀得懂：Lingua Ex Machina 揭露跨模型隱蔽通道
Lingua Ex Machina 在受測的多模型監控配置中發現一個盲點：執行模型保留的隱藏 Unicode 字元，可能被監控模型的分詞器（tokenizer）或上游前處理移除。監控模型沒有收到承載訊息的字元，就無法檢查其中的內容。依欄位規則檢查 Unicode 碼位（codepoint），可以拒絕已辨識的隱藏載體，但目前 AIDEFEND 的範例尚未涵蓋研究中的私用區通道。研究也測試了藏在普通語言裡的訊息；受測配置的偵測效果有限，且有明顯誤報。因此，還須以工具權限與資料流向控制，限制漏判後可能造成的後果。
威脅分析
- 監控架構須先確認每個模型實際收到什麼。 在一個模型執行任務、另一個模型檢查提示詞或輸出的架構裡，選用不同模型家族，並不能證明兩者取得的安全相關內容一致。
- 盲點可能發生在推理之前。 報告描述的受測配置中，監控路徑的分詞器或上游前處理，會移除執行路徑仍保留的隱藏 Unicode 字元。
- 這是受控測試中的通道展示。 報告的標籤字元（tag character）測試中，接收方還原了隱藏訊息，監控模型卻未能還原。即使提供解碼方式，也無法取回已被移除的字元。這不代表已發生惡意的正式環境入侵，也不是完整的資料外洩攻擊驗證。
- 輸入放行判定須綁定模型實際使用的內容。 在分詞前，依具簽章的欄位規則檢查原始碼位，拒絕政策不允許的載體，保留合法程式碼與多語文字的語意，並將監控與模型呼叫都綁定至已受理文字。閘道送出相同文字，只是必要前提；還要測試實際分詞路徑。監控回應空白或無法解析時，也須依政策安全處理。
- 普通語言也可能承載隱藏訊息。 研究測試了透過用字或句子結構藏訊息的語義隱寫（semantic steganography）通道，Unicode 檢查無法移除這類通道。報告的偵測結果限於受測模型、提示與資料。可以用客服文字類比：表面上談的是資料夾顏色，下游若事先取得暗號規則，便可能解讀成另一個意思。若進一步解讀成工具動作或含有機密的網路請求，還需要額外能力；這是說明風險的假設情境，不是本次基準測試驗證的完整攻擊鏈。
- 動作與資料發布須有獨立控制。 量測實際觀測路徑，並以不依賴「監控模型必須辨識每個隱藏訊息」的政策，管制具權限工具、資料發布與高影響動作。
適用的 7 項 AIDEFEND 防禦手法
AID-H-018.005
中
Value-Level Capability Metadata & Data Flow Sink Enforcement
在營運者可控的執行環境中，為受理資料及每個衍生值維持可驗證的來源與內容綁定，並在資料發布或產生副作用前，針對確切出口完成授權。來源不明時須拒絕；只在入口加標籤，無法追蹤模型的任意改寫。這能限制隱藏訊息漏過檢查後的後果，但不會自行偵測語義隱寫、移除 Agent 或還原狀態。程序、瀏覽器與各個目的地路徑都須實測，不能假定原版 SaaS 已提供此控制。
AID-D-005.010
中
Telemetry Pipeline Health & Sensor-Loss Detection
先在監控封裝層加入量測，將空白或無法解析的判定結果轉成明確的感測器健康或格式拒絕指標，再核對所有預期感測器、心跳訊號、佇列、匯出器及端到端存活探測。這需要經驗證的轉接層，偵測的是觀測能力受損，不是所有分詞器字元刪除：健康的管線仍可能完整傳送一段隱藏載體已被移除的文字。正式部署的偵測器是否認得攻擊案例，則由 AID-D-018 另行量測。
AID-D-003.002
中
Sensitive Information & Data Leakage Detection
如果隱蔽通道承載敏感資料，應在發布前，使用已設定的機密憑證、個人資料或組織專屬偵測規則，檢查模型輸出的文字欄位，以及另行擷取的工具參數與網址欄位。必須驗證欄位涵蓋範圍，不能假定能解碼所有隱藏或未知編碼。偵測結果交由獨立的輸出或資料出口閘門處理；偵測器本身不會阻擋發布。
AID-H-017.007
中
Dual-LLM Isolation Pattern
不可信內容只交給隔離的讀取元件；讀取元件、中介驗證程序與具權限的規劃器，須分別部署並隔離程序、憑證及網路權限。規劃器只能取得經驗證、型別明確的中介結果，不能直接接收原始不可信提示詞。型別正確的字串仍是不可信資料，動作與出口須另行授權；這個架構不能證明語義隱寫不存在。代管部署則需要供應商支援。
AID-D-018
中
Production AI-Security Detection Efficacy & Scenario-Coverage Validation
將有簽章的正常與攻擊樣本，送進正式部署實際使用的監控與執行模型觀測路徑。把召回率、誤報、錯誤與棄判結果綁定至確切偵測器、分詞器及執行環境組合，發布可獨立重現的效能與覆蓋範圍證據。是否允許發布，由獨立的發布控制負責；這項驗證不會自行阻擋發布或修復偵測器。
AID-H-002.002
部分
Inference-Time Prompt & Input Validation
在組裝提示詞前，依有簽章的欄位規則驗證字元與正規化方式。遇到政策不允許的隱藏訊息載體，應拒絕該欄位，而非默默刪除字元；程式碼、識別碼與合法的多語文字須保留語意，只有允許正規化的欄位才使用 NFC。偵測與模型請求都須綁定實際受理的文字。目前 G002 範例會拒絕異常標籤字元序列，但不會拒絕研究中的私用區載體；擴充政策須另行實作並重新執行測試驗證。一般正規化與這個範例，都不能保證封閉所有 Unicode 通道。
身為資安防禦者，我們應該這麼做
- 把這件事當成整個 AI 執行架構（harness）的問題來處理，檢查的不只是監控模型；這裡的執行架構包括模型外層的處理流程：執行模型、監控模型、模型閘道、提示詞組裝器、RAG 轉接層、agent 對 agent 通道、工具調度器、監控封裝層和日誌層。每條路徑都要標明原始輸入在哪裡保留、標準化安全副本在哪裡產生，以及監控模型和執行模型實際看到什麼。
- 在任何模型分詞器執行前，加入規則固定、可重複的 Unicode 檢查（deterministic Unicode check）。檢查原始碼位、依欄位政策拒絕不允許的隱藏載體，保留合法多語文字及程式碼語意，並將監控與執行路徑綁定至同一份已受理文字，再重新執行實際分詞路徑；閘道送出相同字串，不代表每個模型實際看見的內容相同。
- 不要把空白、格式錯誤或解析失敗的監控結果當成安全。依照動作風險，改成拒絕、用已驗證的解析器重試，或送人工審查。
- 針對實際使用的模型配對建立 tokenizer survival 回歸測試，用來確認隱藏字元會不會在監控模型前被吃掉；不同廠商模型互相監控、同一廠商模型互相檢查的配置，都要納入測試。
- 限制 agent 在漏掉訊息後能做什麼。把工具權限綁在可信任務上，阻擋不可信來源的值觸發高風險動作，並在資料離開系統前檢查輸出和工具參數。
- 語義隱寫目前仍難以穩定偵測。可疑訊號只能當成追查線索；真正要守住的是高影響動作，仍要靠工具能力政策、資料流向控管和審查機制。
2 個額外的防禦考量
每組監控/執行模型都要測 tokenizer 邊界
除了上面對應的防禦技術，團隊還應該明確測試每一組監控模型與執行模型的分詞器差異。測試證據不只要說有通過，還要留下原始輸入位元組、Unicode 碼位清單、標準化後文字、監控模型看見的文字、執行模型看見的文字，以及兩者不一致時系統是否會預設阻擋。
建議做法: 把 tokenizer survival 測試放進模型 gateway 的 CI。只要模型、SDK、proxy、分詞器或提示詞 gateway 有變更，就重新測；對高影響 agent 路徑來說，只要監控模型和執行模型看到的內容不一致，就應該阻擋發布。
語義隱寫要先當成後果控管問題
報告裡普通語言藏訊息的通道，不能靠 Unicode 清理解掉。即使系統能抓到可疑用字或不尋常句型，也只能把它當作追查線索，不能當作正式環境裡唯一的防線。
建議做法: 把語義隱寫偵測當成輔助訊號，主要防線仍要放在能力收斂、資料流向控管、資料外洩檢查、人工審查和事件重放，避免漏掉的隱藏訊息變成真實動作或資料外洩。
結論
Lingua Ex Machina 說明了為什麼安全監控須檢查完整的模型觀測路徑。先盤點模型閘道、提示詞組裝器、分詞器、監控封裝層與執行模型，再測試正式部署實際使用的組合。AIDEFEND 可提供依欄位規則驗證輸入、量測偵測效果、隔離讀取、收斂工具權限與管制資料流向等方法，但各自都有部署前提與證據要求。目前 Unicode 範例仍有私用區缺口，報告中的語義隱寫偵測也有實際限制。因此，高影響動作與敏感資料發布，須受到獨立控制，避免漏判的訊息取得新的權限。
最後更新: