模型檔案與介面許可權是兩類資產
模型檔案包含權重、結構或業務訓練成果，介面憑據則代表對服務端資源的呼叫許可權。前者洩露可能造成複製與分析，後者洩露可能直接產生資源消耗、資料訪問或業務濫用。
安全設計應分別列出模型、推理執行時、預處理與後處理邏輯、提示模板、API 憑據、快取、日誌和使用者輸入輸出，不能把所有問題歸到一個加密開關。
- 模型和配置存放位置
- 推理執行時與第三方 SDK
- 介面憑據的許可權與有效期
- 輸入輸出和日誌的敏感範圍
執行時需要解密並使用模型
只要模型在客戶端推理，執行時就必須取得可執行的模型材料。檔案加密可以減少靜態複製便利性，卻不能讓客戶端變成絕對可信環境。
因此還要關注金鑰獲取、記憶體材料、除錯環境、模型版本配對和異常日誌。沒有當前候選版本的執行證據時，應把結論寫成設計邊界而不是防提取承諾。
長期高許可權金鑰不應成為客戶端秘密
移動應用可以被觀察、修改和重放，不適合儲存長期高許可權 API Key。更穩妥的做法是由服務端代理高風險呼叫，給客戶端短期、限權且可撤銷的憑據。
服務端還應實施賬號授權、額度、速率、版本策略和異常行為記錄。客戶端提供的完整性訊號可以參與判斷，但不能單獨決定高風險請求。
- 憑據最小許可權
- 短期有效並可輪換
- 服務端額度與速率限制
- 異常呼叫可追蹤與撤銷
端側與服務端按業務目標分工
端側推理適合低延遲、離線或隱私敏感場景，服務端更適合集中管理模型、憑據和高風險決策。實際架構可以混合，但每個資產的生成、傳輸、使用、更新和回滾都應有明確負責人。
模型保護的有效結論必須繫結應用版本、模型版本、目標裝置和驗證方法。只說明使用了加密演算法，無法回答執行時與介面風險是否得到控制。
讓建議落到真實應用上
提交技術棧、關鍵路徑、目標系統範圍和當前候選包，由御盾給出針對性的保護與相容性驗證建議。