AI 安全工程
您的模型就是可執行的程式碼。多數組織卻把它們當作資料檔案看待。漏洞就發生在這個落差之中。
$4.63M
涉及影子 AI 的平均資料外洩成本
IBM《2025 資料外洩成本報告》
83%
缺乏自動化 AI 安全控管的組織比例
Kiteworks 2025
352K
在公開登錄庫的 51,700 個模型中發現的不安全問題數量
Protect AI 2025
AI 模型並非靜態產物。它們是在載入、訓練、推論與代理執行期間運行的程式碼。四大攻擊類別主導著威脅模型。
torch.load() 在反序列化期間會執行任意 Python 程式碼。這並非錯誤,而是 pickle 序列化的設計行為,且超過 80% 的 ML 模型都使用它。
Hugging Face 上一個名為「baller423」的模型,被發現會建立一條連回 Kreonet 的反向 shell。該模型看起來正常,通過了基本掃描,卻在有人載入它的那一刻執行了任意程式碼。
最廣泛使用的防禦工具 PickleScan,至少有 3 個已知的零時差繞過漏洞(CVE-2025-10155)。以黑名單為基礎的掃描從根本上就是失效的,因為攻擊者掌控著序列化格式。
Llama 3.1 8B 在提示注入韌性上,從 0.95 降至 0.15 ,僅經過單一輪微調即如此。這代表正常、非對抗性的訓練便使安全對齊退化了 84%。
幾乎沒有人在微調後重新評估安全性。模型通過了初始安全評估,在領域資料上經過微調,然後在護欄已實質移除的情況下上線生產環境。這並非什麼罕見的攻擊,而是多數組織的預設工作流程。
98% 的組織存在未經授權的 AI 使用。這個數字並非筆誤。影子 AI 事件多出的 $670K 外洩成本反映了一個簡單的事實:你無法保護你看不見的東西。
62% 的安全團隊無法辨識 LLM 在其環境中部署於何處。開發人員從 Hugging Face 下載模型、用個人金鑰呼叫 OpenAI API,並在個人雲端帳戶上部署微調模型。目前的安全工具大約只能呈現其中 38% 的活動。
GitHub Copilot 的 RCE 漏洞(CVE-2025-53773,CVSS 7.8)透過 YOLO 模式,將儲存庫文件中的一次提示注入轉化為完整的系統淪陷。代理讀取了一條惡意指令,將其當作程式碼執行,使用者的機器便被掌控。
Amazon Q 的 cleaner.md 檔案透過代理的上下文視窗,向超過 950K 名使用者散布破壞性指令。OpenClaw 的市集在 63 天內累積了 138 個 CVE,提交的技能中有 12% 被發現具惡意性。
代理會將提示注入轉化為系統層級的淪陷,因為它們擁有傳統 LLM 所缺乏的工具存取權、憑證與執行權限。
供應商生態系正快速成熟。以下是對每位參與者所涵蓋範圍及其仍存落差的誠實觀點。
| 供應商 | 他們做什麼 | 他們不做什麼 | 最適合 |
|---|---|---|---|
| Palo Alto / Protect AI | 模型掃描、AI-BOM 生成,整合進 Prisma AIRS 平台 | 架構設計、客製化管線工程、組織變革管理 | 已採用 PANW 平台的企業 |
| HiddenLayer | 執行期 AI 偵測與回應、代理式安全監控 | 供應鏈架構、ML-BOM 實作、合規對映 | 為增加 AI 可視性的 SOC 團隊 |
| JFrog | MLSecOps、模型登錄庫安全、Hugging Face 整合 | 對抗性紅隊演練、安全對齊驗證、治理設計 | 管理模型產物的 DevOps 團隊 |
| Wiz | 雲端安全脈絡中的 AI-BOM、模型掃描 | 地端模型安全、微調安全、代理式架構 | 雲端優先的組織 |
| NVIDIA NeMo Guardrails | 針對 LLM 的開源執行期護欄 | 模型掃描、供應鏈安全、來源追溯 | 建構客製化 LLM 應用的團隊 |
| 四大會計師事務所 / 大型系統整合商 | 治理框架、合規文件、董事會簡報 | 實作。建構掃描管線、設定 ML-BOM、部署模型簽署。委託案從 $500K 策略起,擴展至 $3-10M。 | 需要符合稽核要求文件的組織 |
| 開源工具(ModelScan、PickleScan、SafeTensors) | 免費的基本掃描與更安全的序列化格式 | 企業級協調、行為沙箱、來源追溯、政策執行 | 擁有強大內部安全工程能力的團隊 |
一個沒有人能妥善填補的落差。 組織文化變革是最困難的部分。沒有任何工具或顧問公司能消除人們為求速度而繞過治理的傾向。我們建構技術控管,但 CISO 仍需要高層的支持。當資料科學家能在 30 秒內從 Hugging Face 下載一個模型時,任何耗時 30 分鐘的安全關卡都會被繞過。控管必須夠快,讓遵循規範比規避規範更容易。
六項能力,每一項都經過工程設計,以整合進您現有的安全堆疊與 CI/CD 管線。
我們建構自動化審查機制,置於公開模型儲存庫與您內部登錄庫之間。每個模型都會經過行為沙箱(載入於隔離容器中、監控系統呼叫)、多格式深度分析(pickle、PyTorch、GGUF、Keras、SafeTensors),以及使用您企業 PKI 的密碼學簽署。
我們選擇行為分析而非靜態掃描,因為 PickleScan 的零時差繞過漏洞證明了黑名單方法從根本上就是失效的。靜態掃描問的是「這個檔案是否包含已知的惡意模式?」行為沙箱問的是「這段程式碼實際運行時會做什麼?」第二個問題能捕捉到全新的攻擊。
整合進 CI/CD 的 CycloneDX ML-BOM 生成。每個模型都會獲得一份物料清單,記錄訓練資料來源、框架版本、相依性樹狀結構與微調歷程。
我們選擇 CycloneDX 而非 SPDX,是因為 ML-BOM 工具更為成熟,不過我們仍會為需要兩者的組織確保 SPDX 3.0 匯出。ML-BOM 並非一個合規打勾項目。它是使其他所有安全控管得以成立的資料結構:你無法簽署你未盤點的東西,也無法稽核你無法追溯的東西。
在網路層級偵測未經授權的模型下載與 AI API 呼叫。整合進您現有的 SIEM/SOAR。我們對映每一個 AI 接觸點,包括影子部署,然後建構在不阻礙創新的前提下封鎖風險的政策執行機制。
目標是:讓您的安全團隊看見 100% 的 AI 使用,而非目前工具所呈現的那 38%。偵測涵蓋 Hugging Face 下載、OpenAI/Anthropic/Google API 呼叫、透過 HTTP/S 的模型權重傳輸,以及透過受管端點上的程序監控進行的本地模型執行。
每次微調執行後的自動化安全重新評估。OWASP LLM Top 10 基準測試套件、針對後門觸發器的對抗性探測,以及安全對齊回歸測試。
我們之所以建構這項能力,是因為幾乎沒有人在微調後重新評估安全性。上節中的安全退化資料已說明了這一點。驗證管線作為 CI/CD 關卡運行。未通過安全回歸測試的模型,無論其任務表現如何,都無法晉升至生產環境。
為 AI 代理進行權限分離。可防止提示轉 RCE 提權(CVE-2025-53773 中確切的攻擊向量)的確定性政策層。工具使用政策執行、針對高風險操作的人為介入關卡,以及執行期行為監控。
此架構能在異常代理行為串連擴散之前偵測到它們。一個突然開始寫入其沙箱之外檔案系統路徑、呼叫從未呼叫過的 API,或嘗試提權的代理,將被終止並標記以供審查。
為從零開始建立此職能的 CISO 而設。NIST AI 100-2 控制項對映、歐盟 AI 法案合規架構、董事會層級的風險量化,以及針對 AI 特有攻擊的事件回應劇本。
我們協助將技術風險轉譯為董事會能核准的預算理由。「我們在公開模型登錄庫中發現 352K 個不安全問題」是一個資料點。「我們的工程師上一季下載了 47 個未經審查的模型,其中 3 個在序列化層中含有可執行程式碼,而我們目前的控管一個都沒偵測到」則是一個預算理由。
三個階段,每個階段都有明確的交付成果與對預期的誠實提醒。
第 1-3 週
交付成果: 附帶優先排序風險登錄冊的 AI 安全態勢報告
提醒: 此階段往往會揭露出比 CISO 預期多 3-5 倍的 AI 使用。這很正常。影子 AI 探查是整個委託案中最有價值、也最令人不安的部分。
第 4-10 週
交付成果: 整合進現有工作流程、可投入生產的安全控管
提醒: 時程取決於 CI/CD 成熟度。擁有成熟 DevOps 管線的團隊部署得更快。仍透過 USB 隨身碟或共用資料夾傳輸模型的組織(比您所想的更常見)需要額外的基礎設施工作。
第 11-14 週
交付成果: 附有完整紀錄操作手冊、可自我維繫的 AI 安全營運
提醒: 第一次對抗性紅隊演練總會找到些什麼。這正是重點所在。一個什麼都找不到的紅隊,要不是不夠盡力,就是範圍劃定得太狹隘。
回答八個問題,為您的 AI 安全態勢設定基準。不會蒐集任何資料。一切都在您的瀏覽器中運行。
建構涵蓋靜態掃描與簽章驗證的基本管線需 4-6 週。建構整合 CI/CD 的完整行為沙箱需 8-12 週。瓶頸鮮少在於掃描技術本身,而在於整合您現有的模型登錄庫(MLflow、Weights & Biases、JFrog ML)並定義政策邏輯:什麼該被封鎖、什麼該被標記、什麼該被隔離。我們發現,政策決策所花的時間比工程實作更長。
格式的複雜性會增加所需時間。Pickle、PyTorch、GGUF、Keras 與 SafeTensors 各自需要不同的分析方法。Pickle 仍是風險最高的格式,因為 torch.load() 在反序列化期間會執行任意 Python 程式碼,這也是為什麼對該格式而言,行為沙箱比靜態掃描更為重要。SafeTensors 是最安全的序列化選項,也最易於掃描,但如今使用它的生產模型不到 20%。您的管線需要能處理所有這些格式,因為您無法控制上游模型供應商選擇何種格式。
那些平台在它們各自的領域表現卓越。Palo Alto 的 Protect AI 整合(透過 Prisma AIRS)讓您在現有安全堆疊中進行模型掃描。JFrog 的 MLSecOps 處理模型登錄庫治理。Wiz 將 AI-BOM 加入雲端可視性。它們不做的是:設計端到端架構、在您特定的 CI/CD 管線中設定 ML-BOM 生成、為您的法規脈絡建構政策邏輯,或重新設計您的模型部署工作流程。它們是掃描工具。我們則是讓這些工具協同運作的實作團隊。
許多委託案的起點是那些已擁有這些平台、卻需要協助將其營運化的組織。一種常見的樣態是:安全團隊六個月前購入了 Protect AI,執行了一次掃描,得到 400 個發現項目,然後就停滯了,因為沒有人把那些發現項目對映到修補工作流程,或將掃描整合進模型晉升管線。
模型投毒的技術門檻比多數 CISO 所設想的更低。研究證實,在訓練語料中只要少至 250 份被投毒的文件,就能為一個 13B 參數的模型植入後門。Microsoft 於 2026 年 2 月發表了突破性的偵測方法,但多數組織尚未部署任何偵測能力。微調安全退化問題則更為迫切、也更為常見:Llama 3.1 8B 在提示注入韌性上,僅經單一輪微調便從 0.95 降至 0.15。那並非攻擊,而是未經安全重新評估的正常微調。
有紀錄的、蓄意模型投毒的生產環境事件仍屬罕見。但條件已然成熟:超過 80% 的 ML 模型使用 pickle 序列化、62% 的安全團隊無法辨識模型部署於何處,而 Hugging Face 上一個名為「baller423」的模型被發現會建立一條連回 Kreonet 的反向 shell。FTC 的模型剝奪判例(Weight Watchers/Kurbo,2022)意味著,一個被投毒的模型可能迫使您刪除並從零重新訓練,其成本遠超過外洩本身。
歐盟 AI 法案將於 2026 年 8 月 2 日全面適用。對於高風險 AI 系統,您需要涵蓋訓練資料來源、範圍、特性與清理方法的技術文件。供應鏈義務要求進口商與經銷商驗證符合性評估、技術文件與 CE 標誌。實務上,這意味著為您管線中的每個模型製作 ML-BOM、為來源提供經簽署的證明,以及為微調決策保留稽核軌跡。
CycloneDX ML-BOM 是最具實作就緒度的標準。SPDX 3.0 於 2024 年新增了 AI/ML 設定檔,有些組織因應不同的法規對象需要兩種格式。我們建構文件管線,讓來源追溯得以自動化,而非淪為人工的合規作業。常見的錯誤是把這當成一次性的文件專案。每一次微調執行、每一次模型更新、每一次資料集變更,都需要生成更新後的來源紀錄。如果您的 ML-BOM 是靜態的,它在數週內就會變得不正確。
權限分離是基礎。每個代理都會獲得一個最小權限設定檔,定義它能呼叫哪些工具、能存取哪些 API,以及能觸及哪些檔案系統路徑。這借鏡了套用於 AI 代理的 Linux 能力模型。GitHub Copilot 的 RCE(CVE-2025-53773,CVSS 7.8)之所以發生,是因為 YOLO 模式賦予了代理不受限的系統存取權,而儲存庫文件中的一次提示注入便提權為完整的遠端程式碼執行。確定性政策層能徹底阻斷該提權路徑。
執行期監控加入了一條行為基線,能在不為正常運作增加延遲的情況下偵測異常代理行為(非預期的工具呼叫、異常的 API 樣態、提權嘗試)。針對高風險操作的安全檢查確實有一點延遲成本:檔案系統寫入、雲端 API 呼叫、憑證存取。對多數企業部署而言,這是每次受控操作 50-200 毫秒。低風險操作(讀取已核准的資料來源、生成文字、呼叫預先核准的 API)則零增加延遲地通過。問題在於:相較於一個擁有完整系統存取權且毫無護欄的代理,高風險呼叫上的 50-200 毫秒是否可以接受。
AI 安全事件需要的鑑識手法與網路入侵不同。對於模型層級攻擊(投毒、後門),回應順序為:將模型自生產環境隔離、驗證訓練管線的完整性、檢查是否透過模型輸出進行資料外洩(模型可能將竊取的資料編碼於其權重中,並透過精心構造的提示洩漏出來),以及判斷您是否需要從已知乾淨的檢查點重新訓練。
對於代理式 AI 事件,您還需要追溯代理採取的每一次工具呼叫與行動、驗證其記憶體與上下文視窗的完整性(若上下文被儲存,提示注入可能跨工作階段持續存在),並檢查是否透過代理的權限進行橫向移動。通用 IR 流程無法涵蓋模型層級的鑑識,因為其產物截然不同。您分析的不是網路日誌與記憶體傾印,而是模型權重、訓練資料來源、微調歷程與代理行動日誌。我們為這些情境建構專屬劇本,包括模型權重(可能達數百 GB)的證據保全程序、訓練資料的證據監管鏈文件,以及為可能要求模型剝奪的監管機關所準備的溝通範本。
62% 的安全團隊無法辨識 AI 模型部署於自家環境的何處。
多數組織都是在事件發生後才發現自己的 AI 安全落差。我們協助您在事件發生之前就找到它們。