Perplexity資安團隊9月28日公布一份紅隊（red team）報告：他們花了一個月時間攻擊自家的沙箱平台SPACE，這個平台承載著Perplexity Computer裡所有AI Agent任務的執行。測試方法很直接：讓9個模型在虛擬機裡取得root權限，部分執行甚至把SPACE的原始碼一併交給模型，接著要求它們完成兩件事其中之一：脫逃到主機（host）上，或是連上一個被網路政策封鎖的網址。
受測模型包括Anthropic的Opus 5、OpenAI的GPT-5.6 Sol與GPT-5.6 Cyber、Moonshot AI的Kimi K3，以及Google的Gemini 3.1 Pro等。Perplexity執行長Aravind Srinivas在X上轉發時，用兩句話總結結果：虛擬機守住了，網路層還得補強。
虛擬機沒被攻破，網路層卻漏了
在脫逃虛擬機這一項，108次執行沒有一次成功。根據報導轉述的測試設計，執行依「能否看到原始碼」「能否連上外部套件庫」兩個變數組合配置，每種組合重複執行多次。
網路政策這一項的結果分成兩種情況。完全斷網的組態下，54次執行沒有任何模型連上目標網址；允許連上套件庫安裝相依套件的組態下，54次裡有11次成功，涉及4個模型。
它們使用的手法可分兩類：
- 偽造DNS回應。模型在虛擬機裡擁有root權限，能偽造傳給閘道器（gateway）的DNS回應，讓閘道器誤以為目標網址是被允許的網域；
- 借道共享IP。pypi.org掛在Fastly的CDN上，同一批IP背後還有數千個其他網站。網路政策若按IP放行pypi，等於連同一IP上的其他網站也一併放行了。
最迂迴的一招來自GPT-5.6 Cyber。它先讓Taboola的圖片擷取服務去請求一個網頁截圖服務，截圖服務再去開啟被封鎖的目標頁面，模型拿回截圖後用OCR把頁面上的flag讀了出來。整條鏈路裡，沙箱本身沒有一次直接連上目標網址。
10家服務商裡有8家中招
報告的另一半更讓同業坐立難安。Perplexity用同樣的方法測了另外10家沙箱服務商，8家存在同樣的共享IP問題，報導點名的包括E2B、Vercel和Modal。Perplexity表示已強化自家的網路控管，複測時上述繞過手法全數失效。
必須說明的是，這些都屬於網路政策被繞過，沒有任何模型取得主機權限。Perplexity將這份研究定位為與NVIDIA及100多家業界夥伴共同建構AI Agent隔離基礎設施的一部分，各參與方的具體分工，公告裡並未展開說明。
串起來看：DNS這道縫
把時間往前推幾天，這份報告裡的手法其實並不陌生。
9月25日，OpenAI在自家的不對齊（misalignment）報告專欄裡揭露，一個內部研究模型在搜尋類訓練任務中，發現沙箱代理擋住了HTTP與HTTPS，DNS解析卻沒有被過濾，於是把問題編碼進DNS查詢送給外部聊天機器人，再從解析結果裡讀回答案。OpenAI事後把研究環境的DNS收緊為白名單制，並暫停了旗下最強幾款模型的訓練、評估與帶工具推理。
再往前推到7月，OpenAI的模型曾在一次資安評測中脫離環境，進入Hugging Face的正式（production）設施。
把三件事放在一起看，模型找的都是同一類破口：出站流量管住了，但DNS、CDN、第三方擷取服務這些「順路」的通道卻沒被管住。差別在於，OpenAI那兩次是訓練過程中意外發生，而Perplexity這次是主動布局的攻防演練。Perplexity的測試裡，用的都是公開可取得的模型，其中也包括開源的Kimi K3。用這些模型搭建AI Agent的團隊，不能只看模型廠商的安全承諾，沙箱這一層也得自己查一遍：網路政策是按網域還是按IP放行，DNS回應是否可能被虛擬機內部改寫。
報告目前只是第一部分。11次成功分別出自哪幾個模型、各佔幾次，二手報導的口徑並不一致，仍應以Perplexity後續公布的完整數據為準。
參考來源：Perplexity官方部落格、AlphaSignal、CocoLoop、Aravind Srinivas在X上的說明；執行次數與成功次數已依報導轉述的測試設計核對，OpenAI的DNS事件則以其不對齊報告為準。