NVIDIA OpenShell 參考架構將代理執行約束納入基礎設施

NVIDIA 於 10 月 21 日推出 NVIDIA OpenShell 參考架構，將代理的權限置於執行工作的軟件控制範圍之外。此設計在 GTC Berlin 公布，連接模型運算、代理執行及獨立的安全強制機制。其核心主張很實際：代理應可持續自主工作，同時不應獲得改寫自身限制的權力。

這帶來了與選擇更強大模型不同的採購決策。企業必須決定權限存放在哪裏、由哪些基礎設施強制執行，以及在出錯後誰能停止代理。當中的張力在於有用的自主性，與足以防止未獲授權操作、但又不會阻礙正當工作的精確限制之間。

Anthropic 的 Claude Code 提供了有用的比較，因為它同樣透過代理的運作環境加以限制。NVIDIA 將這個討論延伸至企業基礎設施及可選的硬件強制機制。開發人員、安全團隊及商業軟件供應商現正面對一個共同問題：組織如何將商業規則轉化為在執行期間仍然有效的邊界？

NVIDIA OpenShell 參考架構連接執行與強制機制

這項公告將代理圍堵定位為基礎設施責任，並以不同組件分別負責執行工作與管治。

參考架構是一套有文件記錄的系統設計，供組織及合作夥伴建立部署時使用。這不代表每個列名的整合都會以具備相同功能的成品形式提供。評估一項涵蓋處理器、作業系統、安全供應商及企業應用程式的公告時，這項分別尤其重要。

根據 NVIDIA 的 OpenShell 參考架構，Vera Rubin 基礎設施運行模型，而 Vera CPU 則運行代理框架，即協調模型呼叫及工具的軟件。BlueField-4 資料處理單元作為專門的基礎設施處理器，運行 Sentry 安全軟件，進行獨立監察及強制執行。

這種分工反映不同的運作問題。產生計劃需要運算能力；執行計劃需要存取檔案、服務及工具；授權這些行動則需要規則，而且執行中的代理不能僅因限制妨礙其任務便自行更改規則。

公告亦將設計延伸至本地及邊緣部署，即在更接近使用者或設備的位置運作的系統。NVIDIA 列出 RTX Spark、DGX Spark 及 DGX Station。買家應逐一評估這些環境，而不應假設本地工作站會提供大型基礎設施部署所描述的所有保護措施。

重要的改變在於這些組件之間所提出的關係。架構不再將安全視為開發後附加的應用程式功能，而是把強制機制置於應用程式之下。代理的請求會成為由基礎設施評估的事項，而不是因為代理提出看似合理的解釋便獲接受。

以一項說明性的工程任務為例：代理調查服務故障並提出修復方案。讀取診斷檔案、安裝相依套件、更改設定及部署修正，分別代表不同權限。一項修復服務的指令，並不代表每一個可能的步驟都已獲授權。

這個例子說明，這套架構為何不僅與安全專家相關。承諾自主執行的產品團隊，亦必須說明這種執行的邊界。否則，客戶得到的只是能力描述，卻沒有相應的控制說明。

可用性亦需要審慎解讀。NVIDIA 表示參考架構已可供使用，但這並不代表每種合作夥伴組合都已具備生產環境就緒狀態。有文件記錄的設計、獲支援的部署，以及已驗證的客戶安裝，回答的是不同問題。

因此，評估這次發布的讀者首先應問一個具體問題：所提供的配置中，建議的執行與強制鏈條有哪些部分實際存在？答案決定買家是在評估軟件控制、額外硬件保護，還是結合兩者的路線圖。

企業團隊承接權限難題

將強制機制移入基礎設施，讓企業獲得更多控制權，同時令其政策決策更難維持含糊不清。

眼前壓力落在負責把商業授權轉化為技術權限的團隊身上。安全團隊可以定義受限制資源，但業務擁有人必須說明哪些行動屬於一項任務；基礎設施團隊則必須讓這些決策可在代理觸及的各個系統中強制執行。

「準備客戶續約」這類指令存在很大的含糊空間。它或許足以支持讀取帳戶歷史及草擬建議書，卻不會自動授權更改合約條款、匯出客戶記錄，或在未經覆核下發送建議書。

這些是說明性的區分，並非已報道的 OpenShell 部署結果。它們顯示，代理安全所需的不只是識別模型，或檢查是否由僱員發起請求。授權取決於行動、目標及相關情況。

NVIDIA 的 代理運行時控制將責任分配至閘道、監督器、沙盒及政策證明器。閘道管理政策及沙盒生命週期；監督器會檢查請求，並在沙盒這個隔離執行環境以外調解憑證；政策證明器則根據組織定義的上限檢查權限。

這種分隔提供了強制執行的位置，但組織仍須決定這些位置應允許甚麼。經正式檢查的上限可確認政策之間的關係，卻不能自行判斷某個業務部門起初是否授予了過多存取權。

這改變了應用程式開發人員與安全審核人員之間的討論。審核人員不再只問代理是否整體可信，而可檢視它能讀取、修改、調用或傳送甚麼。這些問題可帶來更可行的答案，但同時亦需要更詳細的準備。

開發人員面對相關的設計限制。只有在獲得廣泛權限時才能成功的工作流程，比起具備明確且有限要求的流程更難獲批。工具介面及任務描述會成為安全設計的一部分，因為它們決定授權可被表達得多精確。

對知識工作者而言，這種區分始於資訊存取。可搜尋的知識庫有助確認有用資料所在之處。可採取行動的代理則引入另一項決策：找到資訊是否亦獲准分享資訊，或更改承載該資訊的系統。

組織負擔是持續的。僱員會轉換職位、項目會結束、憑證會過期，應用程式亦會新增功能。代理的權限需要反映這些變化，而不是保留令其首次示範成功的一切存取權。

這就是為何管治不能止於一份審批文件。企業需要把授權工作的人、代表該授權的政策，以及執行政策的基礎設施連結起來。沒有這種連結，獨立強制執行的規則仍可能保留過時或過於寬鬆的決定。

因此，這次發布對軟件供應商施加的壓力，與對基礎設施買家一樣大。供應商必須披露足夠的代理行動細節，讓客戶能夠管治。若系統將每項操作都呈現為無法區分的請求，客戶便只會面對粗糙的選擇：廣泛存取或中斷。

硬件隔離改變邊界的落點

NVIDIA 的硬件方案增加了一個獨立強制位置；其價值取決於相關行動是否真的會經過該位置。

軟件限制有其明確範圍。其保護效果取決於執行限制的組件，以及那些組件所作的假設。加入獨立硬件安全層，會透過把控制置於代理執行環境之外，改變其中部分假設。

NVIDIA 將 Sentry 描述為配合 OpenShell 軟件邊界的可選額外保護。這項區分可避免常見誤解：使用 OpenShell 並不自動代表部署包含 BlueField-4 強制機制。買家在比較安全主張前，需要確認實際配置。

在 NVIDIA 的 Sentry 運行時安全設計中，BlueField-4 位於節點通往模型及外部系統的通訊路徑上。Sentry 結合流量檢查與經挑選的主機記憶體分析。NVIDIA 表示，它可在數毫秒內隔離代理，而無須代理或主機軟件配合。

其架構邏輯直接明確：當受影響的工作負載無法停用控制時，該控制對受入侵工作負載便更有用。但獨立性本身並不代表覆蓋完整。強制點亦必須能看見正在評估的行動，並保留阻止該行動的權力。

這為部署審查帶來具體問題。配置是否會讓每個相關的外部連線都經過受控制路徑？哪些本地行動會受到獨立限制？工具在收到已授權請求後，若於另一項服務上執行工作，會發生甚麼事？

這些問題源自設計本身，而不是記錄已發現的故障。它們之所以重要，是因為代理的工作流程可跨越多個行政邊界。阻止它的下一個連線，未必能撤銷另一個應用程式已接受的行動。

加密流量引入另一項配置決策。NVIDIA 描述了對已設定為解密及檢查的連線進行檢測。因此，企業需要了解檢查適用於何處、哪些資訊會變得可見，以及這種可見性如何配合其保密要求。

與 Anthropic 的比較有助釐清這項設計選擇。Anthropic 的 Claude Code 沙盒機制使用作業系統機制限制檔案系統及網絡存取。其所述方法讓代理可在預設邊界內自由運作，同時控制超出邊界的存取。

兩種方法都將限制置於模型生成的指令之外。差異並非單純比較不受限制的軟件與安全硬件。買家正比較執行安排、部署要求及失效假設。

Anthropic 的例子針對開發者執行環境。NVIDIA 的公告則把 agent 執行連結至更廣泛的基礎設施設計，並加入可選的獨立硬件層。僅憑任何一方的描述，均無法確定哪種安排最適合某項特定企業工作負載。

對於執行範圍明確的開發工作機構而言，現有環境控制本身值得按其優點評估。至於需要與主機軟件額外隔離的敏感部署，NVIDIA 的硬件方法提供另一種選項。決定應以所要應對的威脅為依據。

核心取捨是在更強隔離與更高部署複雜度之間取得平衡。額外的執行層提供另一個攔截不安全活動的位置，同時亦增加了一個組件，其政策、可見性、更新及營運責任必須與系統其餘部分保持一致。

合作夥伴公告揭示不同的成熟階段

最有價值的合作夥伴細節，在於區分現時可用的能力與仍在規劃中的整合。

ServiceNow 提供一個具體例子，說明這套架構如何進入企業產品討論。其企業 agent 管治公告指出，專為長時間工作而設的個人 agent Arc 已正式全面推出。ServiceNow 將 OpenShell 執行機制描述為 Arc 受管治執行的一部分。

同一公告則表示，AI Passport 與 OpenShell 及 BlueField 執行機制的整合將於未來版本推出。AI Passport 是旨在傳達 agent 權限的授權記錄。其仍屬規劃階段這一點十分重要，因為目前的應用程式推出，並不代表整條擬議管治鏈已全面可用。

這個區別讓買家能以實用方式解讀其他發布資料。以現在式描述的可用性，應與預期整合、合作夥伴協作及未來能力分開評估。將它們合併成單一的成熟度印象，會掩蓋仍有待完成的工作。

ServiceNow 的例子亦令商業問題變得具體。持續運作的工作場所 agent 必須跨越不斷變動的工作分配及權限運作。管治必須在最初請求之後仍然適用，尤其當任務持續超出使用者即時關注範圍時。

一個說明性的案例是，員工指派 agent 協調專案交接。閱讀專案文件、識別未完成工作、草擬訊息，以及變更存取權限，均需要不同授權。一套有用的系統必須在任務演變時保留這些區別。

安全合作夥伴帶來另一層差異化。F5 描述其AI 流量檢查，以檢視受支援的提示、回應及工具呼叫，補足運行時權限控制。其公告亦區分了須經產品驗證的擬議部署拓撲。

這是重要限定，而非微不足道的註腳。合作夥伴可支持該架構的方向，同時某個具體配置仍須驗證。客戶應詢問：哪些部署已經測試、啟用了哪些檢查功能，以及針對哪些工作負載。

F5 的說明亦把授權與內容評估分開。一項請求可以針對已獲批准的服務，卻攜帶敏感資訊或惡意指令。連接權限與對傳輸內容的判斷，處理的是不同風險。

這有助解釋為何發布內容納入安全合作夥伴，而非把基礎設施執行機制視為所有既有防禦措施的替代品。擬議的邊界需要有關身分、授權及可疑活動的輸入；在某些內容被攔截後，亦需要營運層面的回應。

商業問題在於，這些層面能否變得更容易協同管理。買家應尋找一致的政策及易於理解的事件記錄。若只增加獨立控制台，卻未能清楚呈現各項決策之間的關係，調查人員仍須在彼此割裂的系統中重建事件經過。

合作夥伴陣容的廣度反映市場興趣，但部署細節更具分量。客戶可以評估受支援的配置、已記錄的限制或已交付的整合；出現在發布名單上的公司名稱，較少證明客戶今天能安全運作甚麼。

安全邊界仍取決於正確規則

NVIDIA OpenShell Reference Architecture 並未消除已獲授權的操作與良好決策之間的差別。

一個 agent 即使一直處於其權限範圍內，仍可能產生錯誤結果。它可能誤讀文件、選錯記錄，或作出不理想建議。基礎設施隔離處理的是操作範圍，並不保證每項結論都正確。

這個區別應影響機構如何理解「安全」一詞。安全是廣泛的結果，而運行時執行機制提供的是特定控制。一項有意義的評估，應指出所防止的失效情況，以及防護成立所依賴的假設。

設想一個獲授權更新排程系統的 agent。一項限制可能成功阻止它存取薪酬資料，但同一 agent 仍可在獲允許的應用程式內安排錯誤約會。兩種結果都重要，但需要不同的保障措施。

過度寬鬆的權限帶來另一項限制。即使一項規則被完美執行，若它容許 agent 匯出整個資料集，該資料集仍不會因為屬於獲授權匯出而受到保護。即使執行機制完全按設計運作，商業決策的質素仍然至關重要。

過度狹窄的權限則帶來相反問題。若日常工作反覆停頓，使用者便有誘因要求更廣泛存取權。安全團隊隨後需要證據，分辨哪些攔截防止了損害，以及哪些反映政策未能妥善配合合法任務。

這是分析上的考量，並非發現 OpenShell 造成不必要中斷。它指出了評估自主性取捨所需的衡量方法。成功隔離應與有用的任務完成率、人工介入頻率，以及被拒絕操作的後果一併考慮。

偵測時機亦需要脈絡。一項快速隔離的聲稱，描述的是偵測到相關情況後的回應。買家仍需了解哪些事件會觸發偵測，以及在隔離開始前外部系統是否已採取行動。

現有供應商描述並未證實一項已獨立驗證、適用於所有企業工作流程的通用保證。它們解釋預期的機制和整合點。對生產環境安全的結論，需要與已部署配置相關的證據，包括其權限和已啟用的防護措施。

擴大可觀察性亦涉及私隱層面。檢查通訊及執行脈絡可改善調查能力，卻可能令敏感材料暴露於額外安全組件。機構需要清晰決定檢查範圍、記錄存取及保留安排。

營運責任同樣值得重視。必須有人維護政策、調查拒絕個案、批准例外情況，並在隔離後恢復 agent。若這些責任仍不清晰，即使技術上有效的邊界，仍可能造成長時間中斷或不安全的替代做法。

NVIDIA 的方法令這些問題更具體，因為它指出了可獨立執行規則的位置。這是系統設計上的有用進展，但並未免除評估規則本身或安全決策周邊工作流程的需要。

因此，合適的標準應是有界限的主張：在指定條件下，特定控制可防止特定未獲授權操作。買家應避免將這一陳述引申為 agent 不可能造成傷害的一般承諾。

關注已交付整合、安全證據與營運契合度

下一批具意義的訊號，是已交付的能力、可重現的驗證，以及機構能維護相關控制的證據。

未來數月，首個訊號將是以未來工作描述的整合能否落地。ServiceNow 規劃中的 AI Passport 執行機制是一個具體例子。若推出附有已記錄支援範圍和限制的版本，將使商業授權與基礎設施執行機制之間的擬議連結更容易評估。

這將加強企業可將管治決策貫穿各個執行層的論據。若持續只有路線圖表述，這部分主張仍較未獲確立。買家應區分產品可用性與示範或合作公告。

第二個訊號是與完整部署相關的安全驗證。有用的證據應描述工作負載、政策配置、已啟用的檢查、嘗試進行的未獲授權操作及觀察到的結果，也應說明哪些合法工作仍可進行。

展示 agent 被攔截，所證明的內容少於可重現地說明它為何被攔截。後者有助客戶判斷同一控制是否適用於其應用程式，亦會揭示簡報中可能未有明說的假設。

驗證應涵蓋獲允許的工作流程，而不只是攻擊。一條在阻截未獲授權活動同時容許預期工作的邊界，支持該架構的核心取捨。若反覆依賴廣泛例外，便會削弱企業能把自主性與精準控制結合的主張。

第三個訊號是其在實際企業環境中的營運契合度。機構需要了解，隨着應用程式、身分和工具變化，政策是否能保持一致；也需要可說明請求操作與執行決定之間關係的事件記錄。

可管理的政策更新及易於理解的調查證據，將加強部署論據；不一致的規則或不清晰的責任歸屬，則會揭示另一個瓶頸。在這種情況下，額外執行能力本身無法解決管治問題。

在營運評估中，本地及邊緣部署尤其值得關注。讀者應尋找針對實際部署系統的已記錄能力。共用的產品系列或架構標籤，並不能解答有關執行覆蓋範圍的每一個問題。

對開發者而言，實際後果是需要更清晰的權限要求。對企業買家而言，則是需要針對特定配置的證據。對知識工作者而言，這是向 agent 授予資訊存取權與委託其採取行動的授權之間的區別。

在批准部署之前，先釐清你希望代理完成的確切工作流程，以及哪些行動必須保留在其授權範圍之外。要求供應商在建議的設定中展示兩種結果：合法工作持續進行，以及未經授權的行動被停止。然後檢視誰負責維護政策、存取權變更如何生效，以及調查人員事後能重建哪些紀錄。務必將現有能力與承諾中的整合功能分開看待，尤其是在軟件與硬件發布時程不同的情況下。NVIDIA OpenShell Reference Architecture 為這項評估提供了一個可具體檢視的基礎架構設計。利用它要求對一個實際問題作出精確回答：當代理獨立運作時，哪些決策仍由你的機構掌控？