輝達提出：AI 安全是工程問題，需在智慧體全堆疊每一層落實可驗證的控制

輝達在官方部落格發表了一篇由 Saša Zdjelar 撰寫的文章，日期為 2026 年 9 月 21 日，標題直截了當：AI 安全是工程問題。文章的核心觀點是，安全不能停留在口號和提示詞裡，而要落實為明確的安全要求、可強制執行的控制措施、有名有姓的負責人，以及能證明防護有效的證據。隨著 AI 能力持續增強，產業需要加快安全工程的步伐，把防禦工具推向更多使用者，並更快地分享哪些做法真正有效。 文章先從一個樸素的事實說起：技術在變，安全的基本職責沒變。網際網路和雲端運算改變了軟體的運行方式，但建立身分、控制存取、限制暴露面、驗證防護有效，這些要求一直都在。AI 智慧體帶來了新的能力：它們會推理，會呼叫工具，還會根據遇到的資料調整自己的動作。這些能力並不否定舊原則，而是要求把舊原則放到新的運作條件下重新應用。文章也坦率指出了壓力的來源：企業想要 AI 帶來的生產力，而治理和保護這類系統的方法仍在形成之中。

理解全文的關鍵，是「全堆疊」這個視角。應用依賴程式碼、資料、身分、服務和基礎設施，安全取決於這些部件如何協同，而 AI 智慧體擴展了這個系統。文章把智慧體拆成三層：模型提供能力；harness（編排層）組織上下文、工具和工作流程；執行環境提供動作得以執行的基礎設施。每一層都有各自的安全職責，資料、指令和動作在系統中流動時，每一層都需要控制，而不能指望某一層單獨兜底。 文章用一個具體情境說明這一點。假設一個智慧體正在更新客戶紀錄，卻在附件文件裡讀到了惡意指令，並試圖把客戶資料匯出到未授權的位址。此時，網路策略應當攔截這次傳輸，受保護的日誌應當記下被嘗試的工具呼叫、授權決定與結果，讓資安團隊能查清用了哪個工具、想去往哪個目的地。更重要的是權限的粒度：更新客戶紀錄的權限，不應自動延伸為匯出這些資料的權限。智慧體可以申請額外權限，但不能自己批准自己的申請。

由此引出文章最有分量的一句話：安全邊界必須在智慧體做出錯誤決定時依然成立。這意味著，限制不能依賴智慧體自己的判斷。智慧體運行的環境要在它的推理之外，對檔案、網路目的地和程序設置約束。指令和護欄可以引導行為，但真正的安全還需要可強制執行的邊界。落到工程上，文章列出了幾項要求：每個智慧體要有可追溯的身分，憑證只限於分配給它的任務；組織要有清晰的策略，規定智慧體能存取哪些資訊、能改動哪些系統、哪些動作必須先經批准；重大動作和權限變更仍然需要人工批准；團隊還要核實智慧體所用工具、技能和相依項的來源與完整性。 出事之後怎麼辦，文章同樣有交代。對工具呼叫、授權決定和結果的受保護紀錄，能幫助調查人員還原經過；而撤銷存取、遏制事件的明確流程，則讓這些證據能夠轉化為行動。換句話說，日誌不是為了好看，而是為了讓回應有據可依。 在產品層面，輝達推出了 NVIDIA OpenShell，這是一個開源的安全執行環境，在智慧體搆不到的位置執行策略，提供沙箱化執行，並管控智慧體對資料、網路和系統資源的存取方式。文章提到，Open Secure AI Alliance 的夥伴正在基於 OpenShell 建構：Cisco 的 DefenseClaw 增加了一層治理，JFrog 則與 OpenShell 整合，用於掃描並驗證智慧體技能，並對智慧體可使用哪些技能實施策略。

文章的第二個重點是證據。上線之前，團隊需要看到證據，證明控制措施能擋住兩類嘗試：取得超出智慧體範圍的憑證，以及把敏感資料送往未授權目的地。測試還應涵蓋修改權限、干擾監控這類嘗試，並且在模型、工具或工作流程發生實質變化後重複進行。需要一位指名的負責人，用這些結果判斷系統是否可以部署，並確保失敗的測試帶來整改。測試或運行中發現的故障要被重現、調查和處理，每個發現再變成可重複的測試，以便在以後的版本裡確認修復依然有效。文中給出的例子包括 CrowdStrike 的 SafeMind（透過反覆的攻擊模擬來測試和強化防禦）和 Palo Alto Networks 的 Prisma AIRS（在模型和應用不斷變化時做持續紅隊測試）。 第三部分談防禦者手裡的工具。文章認為，調查故障需要與任務、資料和環境相匹配的能力，開放模型與封閉模型滿足的是互補的需求：封閉模型提供託管的能力和服務，開放模型則讓防禦者可以檢查相關元件、調整策略，並在自己控制的基礎設施上工作。事件發生時，這種控制權能幫助團隊重現故障、在自己的系統上驗證修復，同時把敏感證據留在自己的環境裡。文章還提到，能力強的 AI 可以幫助發現漏洞、驗證修復和調查攻擊，其價值應以可重現的發現、可驗證的修復和更快的回應時間來衡量。示例包括 Capital One 的 VulnHunter（AI 驅動的程式碼安全）和 ReversingLabs 的 Spectra Assure（用 AI 分析軟體套件，偵測惡意程式碼與竄改）。文章末段以「透過開放協作讓優勢向防禦者傾斜」為題，主張分享哪些環節失敗、哪些控制有效；我們拿到的原文摘錄在這裡中斷，因此該部分的細節不在此展開。

需要說明的是，這是一篇理念與框架性質的部落格文章，原文沒有給出效能基準、成本數字或量化的防護效果，所以我們不能據此判斷這些方案在多大程度上降低了風險。以下是基於文章內容的分析。對開發者而言，最直接的啟示是把權限模型和隔離放在智慧體之外：給每個智慧體獨立身分、最小權限的憑證，把網路和檔案限制交給執行環境來強制，而不是寫進系統提示。對企業而言，要為每個智慧體部署指定負責人，把「紅隊測試通過」設為上線門檻，並把每一次事故沉澱為回歸測試。對生態而言，OpenShell 加夥伴的組合顯示出一種分工：執行環境負責強制，治理層、供應鏈掃描和持續紅隊測試各自補位。 挑戰同樣明顯。第一，策略要寫得足夠細，才能做到「能更新紀錄但不能匯出」這樣的區分，而細粒度策略的維護成本不低。第二，供應鏈問題不會消失：技能和相依項的來源核驗，需要生態內的共同標準。第三，持續測試意味著持續成本，文章沒有討論由誰來承擔。第四，這篇文章出自一家銷售相關平台的廠商，讀者在採納其框架時，應當結合自身環境獨立評估。不過，把安全表述為可驗證、可歸責的工程項，而不是一次性的承諾，這個方向對整個產業都有參考價值。