惡意 LLM API 路由器：agent 工具呼叫被改寫的供應鏈風險

在用戶端可控的工具派送層，依已驗證的呼叫者、執行工作與任務，取簽署工具登錄檔中授權範圍的交集，逐次檢查允許的工具、有效時間與操作次數。這可以拒絕任務不需要的 Bash 或套件安裝工具。不過，公開方法限制的是工具名稱；一旦允許可執行任意命令的 Bash，就不會再檢查命令、安裝程式網域或套件名稱，這些仍需要獨立的參數政策與用途明確的工具。論文的允許清單關卡及合成測試結果，不能當成這項 AIDEFEND 方法的驗證；論文也展示了利用允許網域或已放在本機的程式繞過關卡。

把 agent 改接第三方路由器，有時只是改一個 base URL 和 API key。這類路由政策不該隨手就改，而應該像重要安全設定一樣，先簽署、先審查、先小範圍上線，確認沒問題後再擴大，並且保留隨時切回原設定的能力，避免團隊在沒有明確察覺的情況下，悄悄改接到較弱的轉送鏈或不可信的相容連線目標。

研究中有大量工作階段可以被命令注入，其中多數還跑在自動核准的 YOLO 模式。工具執行沙箱、管制對外連線和不放 secrets 的工作區，雖然不能證明工具呼叫是不是來自上游模型，但至少能在惡意路由器改掉執行內容時，把傷害明顯壓低。

每個核准的路由器或模型供應商連線，都應使用獨立的服務身分與有使用範圍、有效時間限制的憑證；接收端須檢查簽發者、預期接收服務、有效時間與允許的路徑。這能限制憑證被拿到其他有獨立驗證的服務使用，並縮短外洩憑證的可用時間，但接收端必須支援相應的 OAuth、雙向 TLS 或接收服務檢查。只縮短 bearer 憑證的有效時間，無法阻止攻擊者在到期前拿它存取原服務。即使路由器通過身分驗證，惡意路由器仍能讀取流量、改寫工具呼叫；服務身分驗證不能證明上游回應完整，也不等於資料存取授權。

要使用 G002 的 Semgrep 關卡，須先重建最後將執行的完整內容，固定所有掃描目標、支援的語言及經本機驗證的阻擋規則，再把判定綁定到這份內容與執行請求，啟動前重新核對。目標不受支援、漏掃或掃描失敗時都須拒絕執行。G001 的 Python AST 關卡不能當成 Bash 命令掃描器；G002 也須先驗證它能涵蓋這個用戶端的 shell 或程式碼。公開關卡沒有通用的惡意套件辨識器，只掃描下載命令也看不到遠端安裝程式的內容。允許網域上的惡意內容、未辨識的寫法與本機已存在的程式仍可能繞過檢查，因此還需要執行隔離與套件政策。

這類外洩最麻煩的地方，是它不一定會造成明顯異常。secrets 和高機敏資料可能只是跟著一般請求欄位或工具輸出一起經過路由器，看起來像正常流量，但其實已經被路由器看見，甚至可能被記錄下來。所以防禦時不能只檢查工具呼叫格式，也要追蹤每個執行期值的來源與機敏程度。凡是 secrets 或高機敏資料要流向外部 HTTP、shell、套件安裝流程、log 或監控系統，都應該先被擋下或要求額外審查。 這需要可控的執行環境，為每個衍生值維持可驗證的來源及內容綁定，涵蓋所有出口；標記不明時須拒絕。只在入口加標籤，無法追蹤模型任意改寫。本機程序、瀏覽器請求及允許的目的地須另行驗證涵蓋範圍，不能假定原版 SaaS 已落實。

從用戶端的工具執行管制層取得實際的授權與參數驗證結果，核對簽署判定收據的有效時間、政策版本，以及對確切工具呼叫內容的綁定，再把每一次允許或拒絕的最終判定寫入受保護的記錄，另行核對是否完整。依各環境的政策，針對已驗證的拒絕次數異常增加與參數驗證失敗發出警示。這需要可信的收據驗證器與事件儲存系統，不能把 agent 自行提供的標記或一般請求記錄當成真正的管制判定。論文使用 IsolationForest 評估回傳工具呼叫的特徵，是另一種方法；這裡對應的是管制結果監測，不會自行辨識所有惡意命令、核准工具或阻擋執行。

針對 agent 和 session 的專用紀錄，能在事後發現可疑行為時，講清楚到底是哪個路由器、哪組帳號、哪個請求、哪次工具呼叫把資料暴露出去。做法是把路由器網址、TLS 連線的中繼資料（metadata）、請求和回應的雜湊值、工具名稱、登入者身分，還有核准模式，全部寫進一種只能往後新增、不能事後竄改、又會遮蔽敏感內容的 session 紀錄。這對這種被動外洩特別重要：流量當下看起來一切正常，要等到 canary 或被偷的憑證之後真的被拿去用，問題才會浮現。