AI 安全稽核、威脅建模與優先修復路線圖

搜尋 AI 資安稽核服務時，會看到從設計審查到攻擊測試等各種服務。例如，若想在公開上線前釐清「可能發生哪些事故」，可以考慮威脅建模；若想確認已完成實作的系統是否真的會出現問題，則可考慮資安檢測或滲透測試。

透過程式碼分析發現的實作問題，與涵蓋模型及外部工具的整體系統問題，雖然有所重疊，卻並不相同。請先明確界定需要檢查的部分，再確認由誰執行，以及會交付哪些成果。

若希望從設計階段開始諮詢，GMO Flatt Security 表示提供 LLM、RAG、AI 代理的設計審查，以及 MCP 伺服器組態審查。完成實作後的資安檢測與滲透測試，則採額外搭配的方式。Trail of Bits 除了 AI 系統威脅建模，也列有模型、MLOps、資料來源與沿革等評估項目。

若想驗證已完成實作的 LLM 應用程式，INTELLILINK 表示會結合手動與自動方式，評估提示注入與 RAG 風險，但基礎設施不在服務範圍內。Neo Security 列有威脅建模與 AI 紅隊演練服務，也將外部整合與 RAG 的權限列為檢測項目。

LANSCOPE 表示提供透過向生成式 AI 輸入內容來驗證其行為及資訊洩漏情況的服務。不過，該公司也明確指出，單獨使用這項服務並不適合 AI 代理，綜合評估需另行洽詢。以上僅為候選服務商的例子，並非所有服務的完整清單或品質排名。服務範圍、語言與費用，請以最新報價確認。

請想像一個能搜尋公司內部文件，也能呼叫外部工具的 AI。在這種情況下，從使用者到搜尋、從取得的文件到 AI，再從 AI 到工具，流程會跨越不同的權限與信任邊界。

例如，沒有權限的員工是否能搜尋到其他部門的機密文件？即使取得的文件中混入「將內容傳送至外部」的指令，是否仍能避免執行未經核准的傳送？將這些情境連同對象、前提及預期的控制措施一併列出，便更容易與檢測服務商對齊驗證範圍。

若只依報告中的嚴重程度決定修正順序，可能會忽略問題對自家公司的影響。應針對每項發現，確認重現條件、是否可從網際網路存取、受影響的資產及現有防護措施，並指定負責人與期限。

舉一個假設例子：若同時發現可從外部存取且會影響客戶資料的授權繞過問題，以及僅限公司內部的資訊暴露問題，可以考慮優先修正前者。修正後應在相同條件下再次確認，並記錄尚未處理的風險。

委託時，應備妥受測環境與修訂版本資訊、檢測用帳號，以及不在範圍內的功能清單。在此基礎上，請參閱報告範本，確認交付成果是否包含威脅模型、重現步驟、影響、修正建議、優先順序及複測範圍。若需要第三方的獨立評估，也務必事先說明這項條件。

驗證實作時，比起發現的問題數量，更重要的是能否保留受測版本與重現條件，以便比較修正前後的差異。TECHFUND 的 CyberGym 實驗也是在特定條件下，對照有漏洞的版本與既有修正版所進行的重現測試，並不代表其對所有 AI 系統的檢出率。