很多人第一個會想到，AI代理安全只要把權限設好就行。但提示詞或應用程式的規則能否管住代理實際呼叫的工具、網路服務與資料庫，才是更前面的問題。NVIDIA於2026年9月28日公布Open Agent Safety Platform，結合開源執行環境OpenShell與運行於BlueField-4資料處理器（DPU）的Sentry參考設計。它能否涵蓋企業現有流量，仍要看部署路徑和實測結果。NVIDIA發布資料

一、AI代理安全要先定義控制邊界

先盤點代理能接觸的資料、工具、API與網路出口，再決定在哪一層限制和觀察這些行為。 提示詞提醒、執行環境隔離、身份驗證、網路政策與硬體監控分別處理不同風險，不能只用「有安全機制」概括。

權限設定、執行邊界與行為監控有何不同？

提示詞中的「只讀取，不要修改」是對模型下指令，主要影響它如何選擇下一步。應用程式的權限設定則決定帳號或功能可以執行哪些操作。執行環境政策把檔案、程序與網路存取限制在明確範圍內；身份驗證確認請求來自誰、可以代表誰行動；監控負責留下事件紀錄或偵測偏離，政策執行才負責允許、拒絕或中止操作。

例如代理在工作台讀測試資料並呼叫內部API，政策應列明可讀目錄、端點、憑證保管者、API寫入權和可連線服務。只靠提示詞時，模型遇到惡意指令或自行產生程式碼，仍可能嘗試未預期操作。要檢查底層系統會不會拒絕，而非代理是否承諾遵守。

為什麼只在應用程式層設限會留下缺口？

代理通常由多個部分組成：模型、代理框架、外掛或工具、執行程式、外部服務與資料來源。每一段可能有自己的帳號、權杖、網路路徑和權限。若某項操作繞過了應用程式預期的介面，或代理啟動子程序、轉交工作給另一個代理，原先的規則是否仍然套用，就取決於系統設計，而非產品名稱。

硬體層監控的設計目的，是在代理程序之外保留另一個觀察與介入位置；前提是請求經過該控制點，且政策能辨識允許的行為。網路繞道、未納管憑證、監控器故障和未覆蓋的工具路徑，都應列入驗收。不能由「在晶片上執行」推論所有越權方式都會被看見或攔下。

二、OpenShell與Sentry各自看管哪一層？

OpenShell負責代理執行時的軟體邊界和政策；Sentry則是NVIDIA描述中運行於BlueField-4 DPU的帶外監控參考設計。 前者能否按政策限制工作環境，與後者能否從基礎設施側觀察並介入，是兩個需要分別確認的問題。

OpenShell：代理執行時的軟體邊界與政策

NVIDIA將OpenShell定位為開源代理執行環境，讓操作者為代理沙箱設定檔案、程序、網路、工具與憑證等政策。官方文件提到，沙箱可透過核心層級隔離限制檔案和程序存取；Supervisor（監督程序）可檢查送出的網路請求，並把允許或拒絕的決策寫入稽核紀錄。憑證也可由執行環境代管，避免直接暴露在代理工作負載中。這些是把規則放在代理程序之外的一種軟體控制方式，適用範圍仍由部署的政策和可觀測路徑決定。NVIDIA OpenShell文件

Sentry：BlueField-4 DPU上的帶外監控參考設計

Sentry的角色不同。NVIDIA表示，Sentry使用DOCA軟體，在BlueField-4 DPU上檢視代理的請求與回應，關聯代理互動、政策判斷和工具或資料存取，再依政策執行介入。NVIDIA技術文章進一步說明這項帶外監控參考設計。DPU是負責資料傳輸與基礎設施工作的處理器；「帶外」在此指監控位置與代理執行環境分開。NVIDIA稱這種參考設計可在代理越出邊界時隔離並停止代理，並宣稱處置可在毫秒內完成。這些速度與效果目前應視為廠商發布說法，實際成效仍需公開、可重現的測試資料支持。

圖中分層呈現代理所在的OpenShell軟體沙箱，以及BlueField-4 DPU上的Sentry監控位置，並標出受政策控制的檔案與網路路徑。
兩層控制各有位置，只有經過可觀察路徑的請求才能納入監控與政策判斷。

NVIDIA新聞稿引述執行長黃仁勳表示：「安全與防護需要全堆疊工程。」這句話呈現產品的設計方向，但全堆疊不代表部署後自然形成完整防線；資料流是否經過監控器、政策由誰維護、事件發生後誰負責回應，都要在企業環境中落實。 NVIDIA發布資料

「安全與防護需要全堆疊工程。」— 黃仁勳，NVIDIA執行長（依NVIDIA發布資料翻譯）

OpenShell可跨平台延伸，不等於整套架構不依賴NVIDIA硬體

NVIDIA表示，OpenShell可延伸支援Arm與Intel等第三方運算平台。這說的是開源軟體的擴展能力；同一份發布資料則將Sentry描述為運行於BlueField-4 DPU的參考設計。企業評估相容性時，應逐項確認代理執行環境、處理器架構、網路設備、DPU、DOCA元件和管理工具是否支援，不能把OpenShell可移植直接解讀成Sentry也能在任意硬體上提供相同監控和執行能力。

三、硬體層監控能補上哪些盲點，仍有哪些邊界？

獨立於代理程序的監控位置，可能增加對特定流量和政策執行的可見度；能否形成有效防線，取決於資料與模型請求是否經過它、身分與權限是否正確關聯，以及故障時系統如何反應。 監控、身份驗證、隔離和封鎖是不同能力，仍須逐項驗證。

監看、驗證身份、執行政策與隔離是不同能力

監看是取得事件或流量資料；驗證身份要把代理、使用者、任務和委派關係對起來；政策執行是判斷請求能否通過；隔離則是在事件發生後限制代理繼續接觸系統。若只收集日誌，不能因此稱為已封鎖越權；若可以停止某個代理，也不代表所有未經核准的請求都能被辨識。部署文件要交代政策命中條件、例外管理、誤攔截處理，以及監控服務中斷時採取阻擋還是放行。

控制方式主要作用位置可回答的問題驗收時要確認
提示詞與應用程式設定模型指令、應用程式和帳號代理被要求做什麼、帳號可呼叫什麼換用工具、子程序或委派後，權限是否仍一致？
OpenShell執行環境代理沙箱、檔案、程序與受控網路代理能讀取哪些資源、請求如何依政策通過未列入政策的目的地或檔案操作是否確實遭拒？
Sentry參考設計BlueField-4 DPU上的帶外監控與政策執行代理活動是否可從基礎設施側觀察並介入監控涵蓋哪些流量？DPU或連線故障時如何處置？

NVIDIA副總裁Justin Boitano在媒體簡報中推測，若這套平台用於前沿模型評估，可能阻止近期Hugging Face遭AI代理入侵事件。這是廠商對假設情境的說法，沒有事故重演或獨立測試證明平台能阻止該事件。美聯社報導

「企業需要指揮並驗證每個代理的行為，尤其是在敏感環境中。」— Paul Smith，Anthropic商務長（依NVIDIA發布資料翻譯）

代理流量、工具呼叫與資料存取是否都經過可監控路徑？

試點前應畫出資料流圖，標明代理呼叫模型、工具、MCP服務（模型上下文協定服務）、資料庫與外部API的路徑、認證方式，以及OpenShell和Sentry各自可見範圍。請求若未經監控節點，該節點就無法依政策判斷；同一服務有多個入口時，也要檢查替代路徑。

監控也要把「誰在做事」與「做了什麼」連起來。子代理是否沿用原任務的身分和權限？API金鑰由個人、服務帳號或多個代理共用？日誌能否對照操作人、代理版本、政策版本與結果？這些資訊是調查和責任判定的基礎。

官方宣稱的速度與能力需要哪些獨立實測？

NVIDIA公告和技術文章說明的是預期架構，不能證明不同伺服器、代理框架或網路拓樸都能達到相同結果。Sentry是參考設計，企業仍須確認組裝方式、支援條件和維運責任。合作夥伴名單代表合作資訊，不等於第三方認證或普遍效能測試。

驗收紀錄應包括測試情境、政策設定、代理及硬體版本、請求是否命中、阻擋時間、誤攔截、正常工作延遲，以及監控中斷後的行為。保留原始日誌與復現步驟，才能分辨攔截是否只在特定環境成立。

四、企業部署前要計算哪些整合成本？

先確認現有伺服器與網路能否提供所需的硬體和流量路徑，再盤點代理、DOCA、資安工具、日誌流程及事件責任人。 軟體開源或提供參考設計，不會自動消除硬體採購、整合、政策維護和維運訓練成本。

硬體、網路拓樸與代理框架相容性

企業可以先問清楚三件事：現有節點是否有BlueField-4，或需增購支援該DPU的系統；模型請求、工具流量和資料存取是否會通過Sentry的觀察與執行位置；使用中的代理框架、容器、虛擬機或編排平台是否能按預期接入OpenShell。還要確認升級、備援、韌體維護與跨區部署方式。沒有這些答案之前，單看軟體授權或安裝方式，無法估算整體成本。

OpenShell可以延伸支援第三方運算平台的說法，對已有異質硬體的團隊有參考價值，但不能代替逐項相容性確認。應要求供應方明確指出哪些功能只在特定處理器、DPU或網路架構下提供，哪些可以由替代元件實現，以及替代後是否改變監控範圍、政策執行位置或可取得的遙測資料。

DOCA、既有資安工具、日誌和事件處理流程

DOCA是NVIDIA用於程式化控制BlueField DPU的軟體平台。導入前要釐清它和既有端點偵測、網路存取控制、SIEM（日誌集中分析系統）、身分管理與事件管理流程如何交接。安全團隊是否能從現有平台查到代理事件？告警是否能帶出代理身分、任務、權限與請求結果？政策變更由開發、平台或資安團隊審核？這些都會影響日常維運工作量。

政策設計也有持續成本。允許清單過寬會削弱邊界，過窄則會反覆阻擋正常工作。團隊需收集初始基準、審核例外、定期清理權限，並說明被攔截後如何處理。

誤攔截、監控失效與責任歸屬

架構圖要標出監控器失聯、DPU更新失敗、政策錯誤、代理身份對不上和日誌送不到集中平台時，系統會採取什麼動作。若選擇故障時一律阻擋，可能中斷重要業務；若選擇放行，則要設定替代監控和人工處置。供應商負責硬體、平台團隊維護政策、應用團隊確認業務權限、資安團隊處理告警，責任界線應先寫清楚。

五、用可重現情境驗收代理安全

用低影響、可回復的代理工作流，重現越權存取、未授權呼叫、代理委派、監控中斷和誤攔截，逐項記錄可觀測性、阻擋結果、延遲與復原方式。 驗收目標要和企業自己的資料、工具及網路路徑相符，不能只看展示影片或廠商公布的單一速度數字。

越權存取、未授權呼叫、代理委派與監控中斷

先挑一項不會直接修改正式資料的流程，例如代理在隔離環境讀取測試文件並產生報告。建立允許操作的基準，再依序測試讀取未授權目錄、呼叫未列入清單的API、嘗試寫入或刪除、透過子程序或子代理轉交工作，以及將測試資料送往未核准的網路端點。每個情境都要確認OpenShell與Sentry各自有沒有看到請求、依哪一條政策判定、是否阻止操作，並留下可以追查的紀錄。

接著測試故障情境：監控通道中斷、DPU或管理元件重啟、政策服務不可用、日誌平台暫停接收。確認代理是停止工作、限制在本機，或仍能繼續執行；同時量測復原所需時間和人工介入步驟。最後加入正常請求，觀察錯誤阻擋是否會讓工作流程停擺，並檢查調整政策後能否重現同一結果。

流程圖由隔離的低影響代理任務開始，分出未授權檔案存取、API呼叫、子代理委派、監控中斷與正常請求等測試，最後匯入結果紀錄。
可重現的越權與故障情境，才能確認控制是否看見請求、採取預期處置並順利復原。
  1. 畫出存取清單：列明代理能接觸的資料、工具、API、憑證、網路目的地與子代理，標註每條路徑由誰管理。
  2. 設定可復原試點：使用隔離測試資料與低權限帳號，先記錄正常工作的請求和延遲，再開啟待評估的控制。
  3. 執行越權與故障測試：涵蓋未授權讀寫、API呼叫、代理委派、監控中斷及誤攔截，保留政策版本和日誌。
  4. 比較結果並確認責任人：統計觀察到的行為、成功阻擋、誤攔截、延遲及復原時間，確認誰審核例外、接手告警和回復服務。

比較政策命中率、可觀測性、延遲與維運負擔

應在相同任務、政策和網路條件下，比較各層控制的結果。記錄政策命中、漏掉的操作、誤攔截、正常工作延遲、調查資料是否足夠、排除問題時間，以及政策更新和硬體維護人力。先測OpenShell，再比較加入Sentry後新增的觀察或控制能力，可辨明各層的實際貢獻。

公開資訊目前不足以確認所有硬體組合的可用性、效能開銷、誤判率和故障模式。對台灣企業而言，實際採用判斷還要看設備取得與維護管道、資安工具整合、人員技能和服務支援。試點若只在一台展示環境成功，尚不能推論不同機房、網段、代理或工作負載都會得到相同結果。

依現場需求決定試點範圍與後續觀察項目

企業可選擇資料敏感、權限有限且失敗可回復的工作流，先釐清軟體政策能管到哪裡，再測試硬體監控是否補上明確缺口。驗收結果要列出未覆蓋路徑、硬體與元件版本，以及監控或政策服務失效時的處理方式。

  • OpenShell在代理執行環境內落實軟體政策，Sentry則是NVIDIA提出、運行於BlueField-4 DPU的帶外監控參考設計。
  • OpenShell可延伸支援其他運算平台，不代表Sentry或整套參考架構可在任何硬體上提供相同功能。
  • 導入前應以實際資料流和可復原測試，驗證監控範圍、攔阻效果、誤攔截、延遲、故障復原與維運成本。

常見問題

Q1：OpenShell和Sentry是同一個產品嗎？

不是同一層元件。OpenShell是開源代理執行環境，負責設定和執行沙箱政策；Sentry是NVIDIA描述的BlueField-4 DPU帶外監控參考設計。兩者可組成平台架構，但部署需求與相容性要分開確認。

Q2：OpenShell支援Intel或Arm，代表Sentry也能跨平台嗎？

不代表。NVIDIA表示OpenShell可延伸支援Arm、Intel等第三方運算平台；其發布資料將Sentry定位在BlueField-4 DPU。企業應逐項確認每個元件支援的處理器、網路設備與功能範圍。

Q3：NVIDIA所說的毫秒級隔離已經有獨立測試證明嗎？

發布資料提出這項速度說法，但公開資料未提供足以代表各種企業環境的獨立測試結果。採用前應在自己的網路與代理工作流中量測阻擋時間、漏失、誤攔截和正常工作延遲。

Q4：部署硬體監控後，還需要提示詞和帳號權限管理嗎？

需要。提示詞協助代理理解任務，帳號和API權限限制可用資源，執行環境與監控層則各自負責隔離、觀察或執行政策。不同控制要共同設計，並確認事件發生時由誰處理。