知識型工作者正在將AI智能體融入日常工作流程。這類充當"數字同事"的智能體具有顯著優勢，例如能夠自動審查錯誤報告、實施並測試修複方案、推送補丁，並通知人工進行審核。通過處理常規任務，智能體有望帶來顯著的生產力提升。然而，將大語言模型通過智能體框架與實時工具和企業數據相連接，可能會將一個有用的助手變成擁有特權訪問權限卻存在安全隱患的軟體。
過去六個月，英偉達
AI紅隊對多個AI智能體進行了安全評估，涵蓋從簡單的交互式編程工具到持續運行的自主數字助手。當發現智能體存在可利用漏洞時，無論使用何種框架，我們通常會看到以下幾種關鍵失效模式：
缺乏對智能體的訪問控制；智能體工具支持任意代碼執行；缺少網路出口管控；密鑰以明文形式暴露給智能體。
本文將分析這些失效模式，並介紹在對抗性壓力下行之有效的安全控制措施。雖然示例主要圍繞聊天連接型智能體展開，但相關規律同樣適用於所有類型的智能體。
失效模式一：缺乏訪問控制
當前AI部署中最常見的失效模式是對智能體缺乏訪問控制。我們發現多個智能體持有個人用戶憑證，卻允許內部網路中任何已授權用戶訪問。這不僅為濫用智能體合法憑證打開了方便之門，還往往使我們能夠直接獲取這些憑證並在預定場景之外加以利用。
建議措施：
將強訪問控制作為抵禦對抗性行為的第一道防線；將每個智能體嚴格限定於經過明確授權的用戶訪問，不響應未授權用戶的智能體在測試中明顯更難攻破；遵循最小權限原則，將智能體的權限與調用該智能體的用戶權限相匹配。
失效模式二：任意代碼執行
許多智能體框架提供了Bash shell或命令執行工具，因其通用性而被廣泛採用——無需為每項功能單獨配置工具即可支持各種常規任務。然而，當模型輸出控制命令執行時，能夠影響該輸出的攻擊者（通過直接輸入或間接提示注入方式）就可能在執行環境中運行任意命令，進而實現數據外泄或在宿主機上建立持久化執行。
常見的緩解措施包括：使用大語言模型充當評判者來攔截惡意命令、採用可接受命令的白名單，或直接相信模型"足夠聰明"。但這些方法對對抗性操控的防禦效果均十分有限。
許多常見的智能體命令行任務面向開發工作流和測試驅動開發，通常需要執行pytest或npm install等命令，這意味著"大語言模型評判"模式往往傾向於接受這類命令的執行。然而一旦受到攻擊者控制輸入的影響，這些命令實際上等同於任意代碼執行。
某些情況下，獲取完整的遠程代碼執行（RCE）和反向Shell甚至只需讓智能體編寫並執行一個Python腳本，或安裝一個遠程包（詳見我們之前發布的相關博文）。
即便沒有命令行工具，通過文件讀寫工具與智能體運行環境交互，往往也會暴露出意想不到的代碼執行和權限提升路徑。
攻擊者若能向~/.bashrc、~/.zshrc等系統文件，或~/.gitconfig、hooks.json、MCP.json、技能文件等配置文件寫入內容，即便無法直接進行命令行執行，也可以在其他進程執行相關文件時觸發代碼執行。因此，應嚴格控制智能體的文件寫入位置，並將其限定在不可執行的目錄中。
建議措施：
將任意代碼執行視為可訪問智能體中影響最高的單一風險；儘可能避免使用命令行工具；在作業系統層面阻止向不可執行工作區以外的位置寫入；如確有需要使用命令行執行工具，則採用嚴格的最小權限可執行命令白名單，並在具備強網路出口管控的隔離執行環境中運行該工具；對通過命令行處理的參數或字符串（如文件名、文檔標題及其他外部數據）保持警惕，在使用前進行清洗和規範化處理，以防止路徑遍歷或命令注入等問題。
失效模式三：缺乏網路出口管控
出站網路連接不僅允許數據外泄，還可能建立反向Shell和SOCKS等直連通道，供攻擊者直接與智能體運行環境交互。當網路出口管控得到強制執行且遵循最小權限原則時，我們只能通過智能體進程進行操作，這大幅降低了攻擊執行效率，也使危害更難以落地。維持智能體狀態與行為對齊、繞過輸出過濾器、在智能體開始拒絕請求後重啟並操控會話，這些都帶來了額外的操作負擔。
建議措施：
採用默認拒絕的網路出口策略，並配以最小權限白名單，將允許訪問的端點限定在智能體預期任務所需的最小集合；在智能體涉及的每個網路邊界處，使用智能體無法訪問的環境控制手段強制落實上述限制。
失效模式四：密鑰以明文暴露
智能體通常需要訪問各類密鑰才能完成預期功能，包括平台Token、API密鑰、版本控制系統訪問Token，有時甚至包括OAuth刷新Token。傳統安全建議是將密鑰以環境變量形式注入內存，避免寫入磁盤，這在容器中僅運行自有代碼時是合理的。
然而，當具備命令執行能力的智能體共享該環境時，攻擊者只需誘使其執行env、printenv或讀取/proc/self/environ，即可直接獲取這些密鑰。命令行工具尤其值得關注，因為CLI會將憑證緩存在磁盤上的可預測位置，並能輕易將其輸出。我們在Git倉庫、.env文件、bash歷史記錄、.netrc文件、OAuth 2.0刷新Token以及執行環境中的環境變量里均發現了Token。
即使無法建立反向Shell，我們也往往可以通過聊天界面泄露憑證。通過"溫水煮青蛙"策略（見下文），我們引導智能體逐步暴露其自身執行環境中的多個密鑰。出口管控雖然阻止了通過網路或直接在文件系統中進行的外泄，但憑證仍暴露在環境中，可被大語言模型訪問，並由其通過聊天界面傳遞給我們。
建議措施：
永遠不要讓智能體訪問持久性密鑰；將密鑰儲存在專用密鑰管理器中；僅在需要時於需要密鑰的進程內存中按需獲取；確保密鑰不出現在智能體的上下文窗口和執行環境中；當某項任務需要憑證時，使用短期且權限受限的Token，並在任務完成後立即撤銷。
繞過提示層防護的三種技術
目前最常見的緩解嘗試是在系統提示中指示模型避免危險行為，有時輔以另一個模型對輸入或輸出進行判斷（即大語言模型評判模式）。這些措施全部由大語言模型強制執行，因此繼承了大語言模型本身概率性、不可靠的特性。以下三種通用技術能夠可靠地突破這類控制，我們已在多個系統上加以驗證。
偽造合法場景
向智能體構造一個使惡意活動顯得合法的上下文，效果出奇地好。我們經常向智能體聲稱自己是"調試人員"或"管理員用戶"，之後它便會定期配合我們的請求。一個智能體甚至主動為我們編寫並執行了反向Shell。在其他情況下，還可以通過指示智能體使用文件編輯工具，直接操控智能體內存和AGENT.md文件，進而構建"調試"和"授權用戶"的身份框架。
漸進誘導攻擊
"溫水煮青蛙"（有時也稱為Crescendo攻擊）在多輪交互中逐步引導智能體走向目標行為，利用歷史對話建立可信度並營造請求的無害性。密鑰提取過程是這樣進行的：先嘗試執行看似合法的工作流並故意觸發錯誤，最終"發現"錯誤的根本原因與密鑰有關，從而說服智能體將其泄露出來。
誤導性操作攻擊
包安裝等誤導性攻擊手法（最早在Black Hat 2025的《From Prompts to Pwns》中被描述）至今依然極為有效。通過誘使智能體執行表面無害、實則附帶代碼執行副作用的操作，通常可以輕鬆繞過智能體的任何抵抗機制。
編程智能體會定期安裝代碼庫。創建一個惡意代碼庫，然後要求智能體通過pip install git+https://…進行安裝，這看起來是一個標準請求，但經過武器化處理的包會在安裝過程中觸發任意代碼執行。
總結與建議
一個持續發現的規律是：與大語言模型處於同一控制平面的防護措施，尤其是基於提示的防護，會被系統性地繞過。控制措施必須在模型控制平面之外強制執行。
按重要性排序，推薦的控制措施如下：
對智能體實施訪問控制，只允許特定的已認證用戶與智能體交互；僅在沙箱環境（如Docker、英偉達OpenShell或虛擬機）中執行任意命令，該環境必須經過充分加固以防逃逸，且不能通過寫入或編輯環境或智能體配置文件進行自我配置；在智能體涉及的每個邊界處實施默認拒絕的網路出口策略，並配以任務所需特定網路資源的最小權限白名單；不向環境暴露靜態密鑰。雖然將密鑰注入環境變量是非智能體應用的標準做法，但對於執行任意代碼的工作負載來說並不安全，密鑰應儲存在密鑰管理器中、按需訪問，並限制在需要的進程範圍內，條件允許時應使用提供最小權限臨時Token的Token代理；僅允許從經過驗證的包倉庫安裝包，默認阻止基於任意URL和版本控制系統的安裝；對工具、MCP、技能等實施最小權限原則，僅保留任務所需的工具，對任何涉及執行、寫入或網路訪問的工具進行嚴格審查；對持久化儲存實施最小權限，避免使用卷掛載，確有需要時嚴格限定範圍，絕不將可寫路徑掛載到後續會被執行的路徑下；使用最新的前沿模型，尤其在採用大語言模型評判模式時，這類模型對對抗性操控具有更強的魯棒性。
英偉達AI紅隊在AI智能體安全工作中的經驗表明，確定性的"硬性"控制措施對於防禦AI智能體仍然不可或缺。持有企業憑證的完全自主系統本身就具有高風險，必須採取嚴密的安全措施。儘管前沿模型增加了對抗性操控的難度，但在充足的時間和專業能力面前，幾乎所有模型仍然可以被突破。
我們觀察到的常見缺陷包括：訪問控制薄弱（允許任意用戶訪問智能體）、執行和文件寫入工具創造了RCE機會、網路出口管控不足導致數據外泄和反向Shell，以及執行環境中可被智能體訪問的明文密鑰。
基於提示的防護欄（包括大語言模型評判模式）無法填補以上任何漏洞。架構層面的控制措施才是關鍵：對智能體的訪問控制、對企業數據實施最小權限訪問的加固沙箱、默認拒絕的網路出口管控，以及將密鑰置於智能體無法觸及之處。經過正確配置和執行，這些控制措施能夠有效降低AI智能體遭受惡意利用的風險。
Q&A
Q1：英偉達AI紅隊發現了哪些AI智能體最常見的安全漏洞？
A：英偉達AI紅隊在評估多個AI智能體後發現了四大核心失效模式：缺乏訪問控制（任何內部用戶都能訪問智能體）、支持任意代碼執行的工具（如Bash shell）、缺少網路出口管控（允許數據外泄和建立反向Shell），以及密鑰以明文形式暴露在執行環境中。這些問題與所使用的框架無關，在幾乎所有被評估的智能體中都有出現。
Q2：攻擊者用哪些方法繞過AI智能體的提示層防護？
A：主要有三種有效手法：一是偽造合法場景，比如聲稱自己是"管理員"或"調試人員"來騙取智能體配合；二是漸進誘導攻擊（即"溫水煮青蛙"或Crescendo攻擊），通過多輪對話逐步引導智能體暴露密鑰或執行危險操作；三是誤導性操作攻擊，例如讓智能體安裝一個看似正常、實則惡意的Python包，在安裝過程中觸發任意代碼執行。
Q3：如何有效保護AI智能體中的密鑰安全？
A：核心原則是永遠不要讓智能體直接接觸持久性密鑰。具體做法包括：將密鑰儲存在專用密鑰管理器中而非環境變量中；僅在需要時於對應進程的內存中按需獲取密鑰；確保密鑰不出現在智能體的上下文窗口和執行環境中；每次任務使用短期且權限受限的臨時Token，任務完成後立即撤銷，儘量使用Token代理來動態簽發最小權限憑證。
