回到頂部
AI Agent 的模型、協調、工具與安全執行環境形成五層實體結構,敏感權限被鎖在最下方邊界

AI Agent 安全控制放哪層?NVIDIA 五層架構檢查表

NVIDIA 將 Agent stack 分成產品、協調、harness、安全 runtime 與推論層。整理哪些控制可引導行為,哪些才是硬邊界。

內容查核: 來源查核:

AI Agent 的提示詞可以規勸,安全 runtime 才能拒絕。 NVIDIA 8 月 21 日提出五層 Agent stack,核心是把「Agent 想做什麼」與「系統允許它做什麼」分開。只要規則仍在模型、記憶或可修改的 harness 裡,就不算真正的硬邊界。

這個觀點和Azure SRE Agent 的四道環境邊界一致:預設 Agent 可能受提示注入、錯誤推理或惡意工具輸出影響,限制必須放在它無法自行改寫的位置。

五層架構怎麼分工

層級主要工作適合放的控制不該單獨承擔
產品/發行安裝、預設與支援體驗簽章、版本、來源允許清單執行期授權
協調層選擇、委派不同 Agent任務拆分、風險路由最終資源權限
Harness迴圈、上下文、工具與 session行為引導、計畫、提示防護不可繞過的安全保證
Secure runtime隔離、身分、政策、憑證、稽核逐次授權、短效權限、復原判斷答案語意是否正確
推論資料平面模型服務、快取、路由與排程租戶隔離、資料與流量政策業務動作核准

NVIDIA 原文把模型與 harness 稱為行為控制:它們影響 Agent 比較可能採取什麼行動。Runtime 和基礎設施則控制 Agent 實際能做什麼。同一份已核准政策與已驗證狀態,應得到可重複的授權結果。

哪些規則一定要下沉

檔案讀寫、程序啟動、外部網路、API 呼叫、資料操作、資源建立、對外通訊與裝置控制,都要在效果真正發生前檢查。原始憑證不要直接交給 Agent;環境應依任務換取範圍窄、時間短、可立即撤銷的權限。

子 Agent 也不應因為被委派就取得更大能力。NVIDIA 的設計建議是建立受父層上限約束的 child runtime;這可和零信任 Agent 原則一起使用。模型可以提出擴權理由,不能自己批准擴權。

OpenShell是 NVIDIA 對這種 runtime 邊界的開源實作,但架構原則不要求你一定採用該產品。容器、微型虛擬機、雲端身分、網路代理與政策引擎也能組出相同責任分界。NVIDIA 另把落地方式拆成四種安全部署做法自我演化 Agent 的 OpenShell 隔離安全評測配方;三者都不能取代企業自己的威脅模型與權限盤點。

上線前怎麼檢查邊界

先追憑證和效果路徑。真正憑證由哪一層持有,Agent 能否讀到原始值?每個檔案、程序、網路與 API 效果,是否在執行前逐次檢查?外部文件、記憶和工具輸出只能提供資料,不能改變授權規則。

再做替換測試。換掉模型、Skill、MCP 或 harness 後,硬邊界仍要得到相同拒絕結果;子 Agent 的權限只能縮小,不能自行放大。這能驗證政策確實位於 Agent 下方,沒有藏在某個特定框架的提示裡。

最後演練事故。團隊要能立即撤銷 session、隔離執行環境、保留現場並從檢查點復原;稽核紀錄則需回答誰、代表誰、依哪版政策做了哪個動作。回答不了其中一項,就還不適合讓 Agent 接觸不可逆操作。

我的判斷是,能讀公開資料且只產生草稿的 Agent,可採較輕控制;能碰正式資料、部署、付款或對外寄信的 Agent,就不該只靠核准彈窗與提示。可再用企業 Agent 上線清單把責任人、回退與事故流程補齊。

常見問題

AI Agent 有 system prompt 還需要 sandbox 嗎?

需要。System prompt 能降低模型嘗試危險動作的機率,不能阻止模型、工具或被注入的內容找到其他路徑。Sandbox 與 runtime 才能限制實際效果。

MCP 權限放在 Agent harness 裡安全嗎?

Harness 可協助挑選工具,最終授權仍應由外部政策與身分層決定。否則可修改 harness 或控制上下文的內容,也可能影響自己的權限。

NVIDIA OpenShell 是必要元件嗎?

不需要綁定 OpenShell。它是安全 runtime 的一種實作;重點是隔離、身分、短效憑證、逐次政策、網路控制與可稽核性是否真的在 Agent 下方執行。

參考來源

№ · further reading

延伸閱讀