知識工作者正日益將 AI 代理整合到其工作流程中。作為「數位同事」的代理能帶來明顯益處。例如，它們可以審查錯誤報告、實作並測試修復、推送修補程式，並通知人員進行審查。透過處理例行任務，代理有潛力帶來大幅生產力提升。另一方面，透過代理式工具將大型語言模型（LLM）連線到即時工具和企業資料，存在將有用的助理轉變為具有難以理解攻擊面的特權軟體的風險。

在過去六個月，NVIDIA AI Red Team 已評估多個 AI 代理——從簡單的互動式程式碼工具到全天候運作的自主數位助理。當代理被證實可被利用時，我們通常會發現相同的關鍵失效模式，無論使用何種框架或工具，包括：

  • 缺乏對代理的存取控制。
  • 允許任意程式碼執行的代理工具。
  • 無網路輸出控制。
  • 機密以明文形式暴露給代理。

在這篇文章中，我們將探討這些失效模式，並描述在對抗性壓力下仍能奏效的控制措施。雖然我們的範例聚焦於聊天連線的代理——這是我們在評估中遇到的多數類型——但這些模式適用於任何代理。

實作代理存取控制

目前 AI 部署中最常見的失效模式是缺乏對代理的存取控制。我們發現多個代理持有個別使用者的憑證，且在內部網路中的任何授權使用者皆可存取。雖然這為濫用代理的合法憑證開了大門，但也經常讓我們能夠收集這些憑證，並在代理的預期使用情境之外使用它們，如後續範例所示。

建議：

  • 使用強大的存取控制作為防範對抗性活動的第一道防線。
  • 將每個代理限制在明確授權的使用者；不會回應未授權使用者的代理顯著更難測試。
  • 根據呼叫代理的使用者權限，遵循最小權限原則來設定代理的權限。

限制程式碼執行

許多工具會暴露 Bash shell 或命令執行工具。這些工具之所以常用，是因為它們的通用性。它們支援廣泛的例行任務，而不需要為每個功能建立個別工具。然而，當模型輸出控制命令執行時，攻擊者若能透過直接輸入或間接提示注入影響該輸出，可能就能在執行環境中執行命令。這可能讓他們達成惡意結果，例如資料外洩或在主機上建立持久性執行。

針對任意命令執行的風險，常見的緩解措施通常包括使用 LLM 作為審查代理來阻擋有害或惡意命令、為可接受的命令建立允許清單，或單純信任模型「更懂」。這些方法在對抗性操縱下都只能提供有限的防禦。

許多常見的代理式命令列任務支援常見的開發工作流程和測試驅動開發。這意味著它們通常需要能夠執行如 pytest 或 npm install 等命令，這也意味著 LLM 作為審查代理的模式往往傾向接受這些命令的執行。然而，當受到攻擊者控制的輸入影響時，這些命令就等同於任意命令執行。

在某些情況下，透過要求代理撰寫並執行 Python 指令碼或安裝遠端套件，就能輕易獲得具有反向 shell 的完整遠端程式碼執行（RCE），如我們先前關於此主題的部落格文章所示。

即使沒有命令列工具，透過檔案讀寫工具與代理執行環境互動的能力，也經常暴露意料之外的程式碼執行和權限提升路徑。

攻擊者若能將內容寫入系統檔案（如 ~/.bashrc 或 ~/.zshrc），或設定檔（如 ~/.gitconfig、hooks.json、MCP.json 或技能檔案），就能在不同程序執行相關檔案時達成程式碼執行，即使無法直接使用命令列執行。代理可以寫入的位置和檔案應受到嚴格控制，並僅限於非可執行位置。

建議：

  • 將任意程式碼執行視為可存取代理的最高影響風險。
  • 盡可能避免使用命令列工具。
  • 在作業系統層級阻擋對非可執行工作區以外的寫入。
  • 若需要命令列執行工具，請使用嚴格的最小權限命令允許清單，並在具有強大網路輸出控制的隔離執行環境中執行工具，如我們接下來將詳細說明。
  • 透過命令列處理引數或字串（如檔案名稱、文件標題和其他外部資料）時應格外小心。確保在使用前進行清理和正規化，以防止路徑穿越或命令注入等問題。

預設拒絕網路輸出

輸出網路連線允許資料外洩以及建立直接連線，例如反向 shell 和 SOCKS，攻擊者可透過這些連線直接與代理的執行環境互動。當網路輸出控制被強制執行且適當地遵循最小權限原則時，我們所有的互動都必須透過代理程序進行，這減緩了我們的執行速度，也降低了影響的可靠性。維護代理的狀態和對齊、導航輸出過濾器，以及在代理開始拒絕請求後重新啟動和操縱工作階段，都增加了操作負擔。

建議：

  • 套用預設拒絕的網路輸出政策，並為代理預期執行任務所需的最小資源集建立最小權限的端點允許清單。
  • 在代理接觸的每個網路邊界，使用代理無法存取的環境控制來強制執行這些限制。

讓機密遠離代理的存取範圍

代理通常需要存取機密才能執行其預期功能：平台權杖、API 金鑰、版本控制系統（VCS）存取權杖，以及在某些情況下甚至 OAuth 重新整理權杖。雖然傳統安全建議建議將機密以環境變數的形式注入記憶體中以防止寫入磁碟，但這在只有您的程式碼在容器中執行時是合理的。

當具有命令執行能力的代理共用該環境時，誘使它執行 env、printenv 或 /proc/self/environ 就能直接檢查這些機密。命令列工具值得特別強調其高風險性。CLI 會將憑證快取在磁碟上可預測的位置，並輕易地將其印出。我們在 git 儲存庫、.env 檔案、bash 歷史、.netrc 檔案、OAuth 2.0 重新整理權杖以及執行環境的環境變數中觀察到權杖。

即使我們無法建立反向 shell，我們通常也能透過聊天介面外洩憑證。我們使用「溫水煮青蛙」方法（見下文），引導代理揭露暴露在其自身執行環境中的多個機密。輸出控制防止了透過網路直接外洩或直接在檔案系統中檢查，但憑證仍暴露在環境中，且 LLM 可存取，LLM 會透過聊天介面將它們傳遞給我們。

建議：

  • 切勿讓持久性機密可供代理存取。
  • 將機密儲存在專用的機密管理員中。
  • 僅在需要它們的程序記憶體中按需擷取機密。
  • 讓機密遠離代理的上下文視窗和執行環境。
  • 當任務需要憑證時，請使用短期、範圍有限的權杖，並在任務完成後立即撤銷該權杖。

將確定性控制作為第一道防線

我們遇到的最常見緩解措施是系統提示，告訴模型避免有風險或危險的行為，有時會由第二個模型判斷輸入或輸出（LLM 作為審查代理的模式）來強化。這些控制都是由 LLM 執行的，並繼承了與 LLM 本身相同的機率性、不可靠的行為。

有三種通用技術可以可靠地擊敗這類控制。我們在多個系統上展示了每一種。

單純向代理呈現一個讓惡意活動看起來合法的上下文就非常有效。我們經常向代理表示我們正在「偵錯」或「管理使用者」，之後它就會定期遵從我們的請求。有一個代理甚至為我們撰寫並執行了反向 shell：

Dark-mode Slack screenshot showing an agent acknowledge a sanctioned red-team request, then create and execute a reverse-shell script.
圖 1. 「社會工程」攻擊成功針對 Slack 連線的代理，導致它為攻擊者建立反向 shell

在其他情況下，可以透過指示代理使用檔案編輯工具，直接操縱代理記憶體和 AGENT.md 檔案，這也允許建構「偵錯」和「授權使用者」的框架。

溫水煮青蛙

「溫水煮青蛙」（有時稱為漸進式攻擊）會在多次互動中逐步引導代理達到預期行為，利用先前的對話歷史來建立可信度和請求的良性性質。機密提取是透過嘗試以看似合法的工作流程執行來引發錯誤，然後最終「發現」錯誤的根本原因是與機密相關，說服代理向我們揭露它們。

透過合法工作流程進行誤導

誤導攻擊，例如套件安裝（首次在 Black Hat 2025 的From Prompts to Pwns中描述），仍然極其有效。透過誘使代理採取看似良性的動作，而該動作會產生程式碼執行的副作用，通常可以輕鬆繞過任何代理防禦。

程式碼代理會定期安裝函式庫。如本文所述文章建立惡意函式庫，然後要求代理透過 pip install git+https://… 安裝它，看起來是標準請求；然而，武器化的套件會在安裝過程中建立任意程式碼執行。

建議的控制措施

一致的發現是，與 LLM 相同控制面的防禦措施，特別是基於提示的防禦，經常被破壞。控制措施必須在模型控制面之外執行。

建議的控制措施，按重要性大致排序為：

  • 對代理使用存取控制。只有特定、已驗證的使用者才能與代理互動。
  • 僅在沙箱環境中執行任意命令執行，例如 Docker、NVIDIA OpenShell 或虛擬機器。環境必須經過妥善強化以防止逃逸。環境不得透過撰寫或編輯環境或代理設定檔來自行設定。
  • 預設拒絕網路輸出，並在代理接觸的每個邊界，為任務所需的特定網路資源建立最小權限的允許清單。
  • 不要將機密暴露在靜態或環境中。雖然在非代理式應用程式中將機密注入環境變數是標準做法，但對於執行任意程式碼的工作負載來說，這是不安全的。機密應儲存在機密管理員中，按需存取，並僅限於需要它們的程序。在可能的情況下，應使用提供最小權限、臨時權杖的權杖代理。
  • 僅允許從已驗證的套件儲存庫安裝套件。預設阻擋任意 URL 和基於 VCS 的安裝。
  • 最小權限工具、MCP、技能等。僅提供工作所需的工具；仔細檢查任何執行、寫入或連線到網路的項目。
  • 最小權限持久性儲存。避免使用磁碟區掛載；如果無法避免，請嚴格限定範圍，且永遠不要將任何可寫入的掛載到稍後會被執行的路徑。
  • 使用最新/前沿模型，特別是對於 LLM 作為審查代理的模式，這對對抗性操縱更具韌性。

結論

我們 AI Red Team 在保護 AI 代理方面的經驗突顯了在防禦 AI 代理時持續需要確定性「硬」控制。具有企業憑證的完全自主系統本質上具有風險，必須小心保護。雖然前沿模型使對抗性操縱變得更加困難，但在有足夠時間和專業知識的情況下，幾乎所有模型仍可能被破壞。

我們觀察到的常見缺陷包括：弱存取控制（允許任何使用者存取代理）、建立 RCE 機會的執行和檔案寫入工具、不足的網路輸出控制允許資料外洩和反向 shell，以及代理可存取的執行環境中的明文機密。

基於提示的護欄，包括 LLM 作為審查代理的模式，無法彌補這些差距。架構控制可以：代理的存取控制、具有最小權限存取企業資料的強化沙箱、預設拒絕的網路輸出控制，以及讓機密遠離代理的存取範圍。當正確設定和執行時，這些控制在減少 AI 代理的對抗性濫用方面非常有效。

若要了解更多關於從第一原則設計安全代理的資訊，請參閱「如何管理企業 AI 工廠中的自主代理」技術部落格，它將引導您完成實作我們的安全代理工作區參考設計的第一步。

若要了解更多關於代理安全的資訊，請不要錯過 NVIDIA 在 Black Hat USA 的演講：具成本效益、私有、前沿級：使用微調 OSS 模型進行 AI 代理利用

若要閱讀更多來自NVIDIA AI Red Team的文章，請參閱我們的其他文章。