當沙箱程式碼可以解析攻擊者控制的網域，或將 DNS 用作對外資料通道時，DNS 外洩風險就至關重要。因此在將敏感工作流程託付給 AI Agent 沙箱之前，團隊應評估 DNS 政策、記錄、套件取得路徑與事件證據。
為什麼 DNS 在沙箱威脅模型中很重要
AI Agent 沙箱是為了實用的自主性而設計。編寫程式碼的 Agent 可以執行測試、安裝套件、呼叫 API、啟動瀏覽器、檢查檔案及產出成品，而無需人類逐一批准每個指令。正是這種彈性，讓網路行為需要獨立於 CPU、記憶體、檔案系統和程序隔離之外，進行自己的審查。
DNS 獲得的關注往往少於 HTTP 出口流量，因為它看起來像基礎設施管道。應用程式需要名稱解析才能連上 API、套件庫、網頁和更新端點。但 DNS 仍然是對外通訊。一個可以解析任意網域的沙箱，可能透過查詢名稱洩露資訊、聯繫攻擊者控制的基礎設施，或者如果 DNS 流量沒有像網頁請求一樣被仔細記錄，就可能形成盲點。
這不是為 AI Agent 發明的理論類別。MITRE ATT&CK 將 DNS 記錄為一種應用層協定，對手可用於命令與控制（C2）通訊；同時也另外記錄了當資料透過非主要應用程式協定的通道離開時，透過替代協定外洩的情況。對於沙箱評估者來說，教訓很直接：不要因為 DNS 不是 HTTP POST，就把它視為無害。
對 AI Agent 而言，風險通常來自一連串的小權限，而非單一明顯的錯誤：
| 沙箱能力 | 團隊允許的原因 | DNS 相關問題 |
|---|---|---|
| 套件安裝 | 讓 Agent 安裝缺少的相依套件 | 允許哪些套件庫和解析路徑？ |
| 網頁存取 | 讓瀏覽器 Agent 收集公開內容 | 程式碼可以解析任何網域，還是僅限於已核准的網域？ |
| API 呼叫 | 讓 Agent 與應用程式後端整合 | 內部網域和中繼資料端點是否被封鎖？ |
| 建置工具 | 讓編寫程式碼的 Agent 執行真實測試 | 安裝後腳本是否會觸發非預期的查詢？ |
| 長時間執行的工作階段 | 讓 Agent 繼續執行多步驟任務 | DNS 記錄是否在整個工作階段生命週期中都被保留？ |
目標不是禁止所有網路呼叫。許多 Agent 工作負載需要受控的網路存取。目標是了解存在哪些路徑、哪些路徑被封鎖，以及如果任務出現非預期行為時，你會擁有什麼證據。
DNS 解析出現在 Agent 工作流程中的哪些地方
安全審查經常詢問沙箱是否能存取網際網路。這個問題太廣泛了。更好的做法是先盤點程式碼、工具、套件管理器或瀏覽器可能觸發名稱解析的所有位置。
常見的 DNS 路徑包括：
- 來自 Python、JavaScript、Shell 腳本、SDK 和測試套件的直接程式碼要求。
- 載入頁面、子資源、字型、圖片、分析腳本和重新導向的瀏覽器自動化。
- 套件管理器，例如 npm、pip、uv、pnpm、apt、cargo 或語言特定的外掛程式安裝器。
- 擷取二進位檔、模板、瀏覽器驅動程式、模型檔案或測試資源的建置工具。
- 呼叫第三方 API 或 Webhook 端點的 Agent 工具。
- 在可見的 Agent 步驟回傳後繼續執行的背景工作。
這份盤點應同時包含預期與伴隨產生的流量。開發人員可能只要求 Agent 執行一個單元測試，但測試指令可能安裝套件、套件管理器可能解析套件庫網域，而生命週期腳本可能聯繫另一個主機。瀏覽器任務可能只限定在一個公開網站，但嵌入的資源會解析許多額外的網域。
對沙箱供應商而言，最有力的答案不只是「可以存取網路」或「網路已隔離」。有用的答案會解釋解析路徑：
- 沙箱 DNS 使用供應商控制的解析器、客戶控制的解析器、VPC 解析器，還是公用解析器？
- 客戶是否可以限制網域、IP 範圍、連接埠或協定？
- DNS 請求是否依沙箱、工作階段、指令個別記錄，還是只在聚合網路層記錄？
- 被拒絕的查詢是否會被記錄，還是只記錄允許的查詢？
- 客戶是否可以區分套件取得 DNS 與執行時期 DNS？
如果無法取得這些細節，請將它們視為待評估事項，而非證明沙箱不安全。實際風險取決於工作負載的敏感性、沙箱內可用的機密、對外政策，以及鑑識證據的品質。
如何評估對外政策
對外政策是決定 DNS 會成為例行管道還是未經審查的逃逸路徑的控制面。成熟的政策應回答三個問題：允許什麼、為什麼允許，以及例外如何被核准。
從預設姿態開始。用於不受信任的 AI 生成程式碼的沙箱，不應繼承開發者筆電那樣的廣泛網路存取權。如果預設是開放出口流量，請詢問產品是否支援為較高風險的工作負載縮小該存取範圍。如果預設是限制出口流量，請詢問開發人員如何啟用任務所需的特定網域。
接著將 DNS 政策與 HTTP 政策分開。有些系統會強制執行 HTTP 允許清單，但讓名稱解析保持寬鬆。這可能造成不一致：對未核准主機的要求可能在 HTTP 層失敗，但 DNS 查詢仍然離開環境，而且查詢名稱中仍可能帶有中繼資料。更嚴格的設計會同時評估解析與連線嘗試。
進行安全審查時，可以使用如下政策矩陣：
| 評估領域 | 該詢問什麼 | 更強的證據 |
|---|---|---|
| 預設出口流量 | 對外網路存取是開放、拒絕，還是依模板限定範圍？ | 書面預設政策加上沙箱層級測試結果 |
| DNS 解析器路徑 | 哪個解析器處理沙箱 DNS？ | 架構圖或設定證明 |
| 網域允許清單 | 團隊能否只允許已核准的套件庫和 API？ | 設定範例和拒絕記錄範例 |
| IP 與私人網路封鎖 | 內部範圍和中繼資料服務是否預設封鎖？ | 文件化的拒絕規則和測試證據 |
| 協定控制 | DNS、HTTP、HTTPS 和原始 socket 是否分開控制？ | 政策模型，而不只是行銷用語 |
| 例外流程 | 誰可以新增網域或放寬政策？ | 基於角色的核准與稽核記錄 |
對大多數團隊來說，第一個實際目標不是完美的零出口流量環境，而是文件化的最小出口流量設定檔：已核准的套件庫、已核准的 API 網域、除非明確路由否則無法存取內部網路，以及同時記錄允許與拒絕的嘗試。
套件取得與相依性驅動的 DNS
套件安裝是最容易低估沙箱出口流量的方式之一。Agent 生成的程式碼常因缺少相依套件而失敗，而最快的開發者體驗就是讓 Agent 安裝它需要的東西。這種便利性帶來了第二個供應鏈問題：套件名稱、套件庫重新導向、安裝腳本和二進位檔下載，都可能觸發原始提示詞從未提及的 DNS 與網路活動。
OWASP 的 LLM 應用程式指南指出了過度自主性（excessive agency）與供應鏈曝險的風險。在 Agent 沙箱中，這些風險在套件安裝時匯合。模型可能被允許選擇指令。指令可能呼叫套件管理器。套件管理器可能從套件庫取得程式碼。取得的套件可能執行安裝鉤子。每個步驟都可能產生 DNS 查詢和對外連線。
防禦性評估應聚焦於治理，而非攻擊機制：
- 對於可重複執行的 Agent 任務，偏好使用鎖定版本的相依套件檔案。
- 對於常見生態系，使用已核准的套件庫或 pull-through 快取。
- 在可行情況下，記錄套件名稱、版本、套件庫 URL、解析的網域和成品雜湊值。
- 將套件安裝權限與一般執行時期網際網路存取分開。
- 對於敏感工作區，在允許清單以外的套件安裝需要核准。
- 考慮為常見技術棧使用預建的沙箱模板，讓 Agent 無需在每次執行時都擁有廣泛的網路存取權。
重要的區別在於「套件取得」不是單一控制項。它包含 DNS 解析、套件庫驗證、成品下載、安裝時期程式碼執行，以及快取行為。良好的沙箱審查會詢問整個路徑。
機密與資料曝險假設
DNS 外洩只有在有重要資料可外洩時才有意義。這使得機密放置與資料範圍界定成為 DNS 審查的一部分。
除非有相反的證明，否則應將 AI Agent 沙箱視為不受信任的建置工作者。不要因為沙箱與主機隔離，就將長期有效的生產憑證、寬鬆的雲端權杖、客戶資料或內部原始碼放入沙箱。隔離可以縮小爆炸半徑，但不會讓每個指令都安全。
在設計較高風險的工作流程時，請使用這些假設：
- 任何 Agent 執行的程式碼可讀取的檔案，都可能被包含在記錄、輸出、網路請求或錯誤訊息中。
- 任何程序可見的環境變數，都可能被該程序複製。
- 任何允許沙箱使用的對外通道，都應接受相同的資料外洩審查，包括 DNS。
- 瀏覽器或文件工作流程中任何經由提示注入的指令，都可能試圖影響工具使用。
- 任何長時間執行的工作階段，都會提高生命週期記錄與權杖過期的價值。
實際的控制措施包括短期有效的憑證、最小權限 API 金鑰、受限的服務帳戶、每項任務的機密、去識別化記錄，以及公開資料研究任務與敏感程式碼執行任務之間的明確區隔。
記錄、稽核軌跡與事件證據
DNS 控制只有在團隊能夠驗證時才有用。當沙箱任務可疑時，安全團隊需要快速取得證據：執行了什麼、解析了什麼、連線了什麼、哪些檔案被變更，以及回傳了哪些輸出。
至少，請詢問平台是否能針對特定沙箱工作階段重建這些事件：
- 沙箱建立時間、模板、資源設定與擁有者。
- Agent 或使用者執行的指令。
- 當產品暴露檔案操作時，讀取、寫入、上傳或下載的檔案。
- 套件安裝與套件庫取得。
- DNS 查詢，包括時間戳記、查詢名稱、結果，以及沙箱/工作階段識別碼。
- 對外連線嘗試，包括目的地主機、IP、連接埠、協定、允許/拒絕結果，以及可取得的流量。
- 工具呼叫、瀏覽器導覽事件與背景程序。
- 機密注入事件，但不應在記錄中暴露機密值。
- 工作階段終止、暫停、恢復、快照與清理事件。
不要只要求成功的流量記錄。被拒絕的事件通常更能評估政策是否生效。如果沙箱嘗試解析未核准的網域，而政策加以封鎖，那次被拒絕的查詢就是區分有效控制與無聲失敗的證據。
保留期間也很重要。七天的記錄視窗可能足以除錯，但對事件回應來說太短。受監管或處理客戶敏感資料的團隊，應將沙箱遙測保留期間與更廣泛的安全記錄政策保持一致。
Novita Agent 沙箱評估備註
Novita Agent Sandbox 專為需要隔離程式碼執行、瀏覽器自動化、電腦操作（computer-use）型任務、長時間執行的工作階段，以及評估或強化學習工作負載的 AI Agent 工作流程而設計。Novita Agent Sandbox 總覽 是了解目前產品行為的正確起點，而 Agent Sandbox 產品頁面 則說明更廣泛的平台適配性。
在評估 Novita 或其他任何沙箱供應商是否適合 DNS 敏感的工作負載時，請區分兩類陳述：
- 產品適配性：沙箱是否支援你需要的 Agent 工作流程，例如程式碼執行、瀏覽器自動化或長時間執行任務。
- 安全控制證據：確切的 DNS、出口流量、套件取得、機密與記錄控制是否符合你的內部政策。
這種區分可以避免過度宣稱。一個沙箱可能非常適合 Agent 執行，但仍需要客戶針對 DNS 政策、解析器路徑、允許清單、稽核保留與事件工作流程進行特定審查。安全團隊在核准敏感工作負載之前，應要求這些控制細節的目前文件或產品確認。
對於已經使用 Novita AI 模型的團隊，平台適配性在於模型 API 與 Agent 執行基礎設施可以一起評估。這可以減少營運分散性，但不會消除威脅模型的需求。請將沙箱視為受控的執行環境，定義每個 Agent 類別需要什麼網路存取權，並驗證控制證據是否符合放入其中資料的風險。
安全審查檢查清單
在核准可能接觸敏感程式碼、憑證、客戶資料或內部系統的 AI Agent 沙箱工作負載之前，請使用這份檢查清單。
| 審查問題 | 為什麼重要 |
|---|---|
| 沙箱預設可以解析什麼？ | DNS 即使 HTTP 被封鎖，仍可能成為對外訊號。 |
| DNS 是否可以依網域、模板、工作區或 VPC 政策限制？ | 敏感工作流程需要比公開研究任務更窄的預設值。 |
| DNS 查詢是否逐沙箱工作階段記錄？ | 事件回應需要歸因，而不只是聚合的解析器指標。 |
| 被拒絕的 DNS 與連線嘗試是否會被記錄？ | 被拒絕的事件證明政策封鎖了非預期行為。 |
| 套件庫是否設有允許清單或代理？ | 套件管理器可能觸發相依性驅動的 DNS 與下載。 |
| 套件安裝是否可以與執行時期網路存取分開？ | 建置時期與執行時期的風險不同。 |
| 內部 IP 範圍與中繼資料端點是否被封鎖？ | Agent 不應意外發現或聯繫基礎設施控制平面。 |
| 機密如何被注入、設定範圍、輪換與去識別化？ | 如果沙箱程式碼可以使用長期有效的機密，DNS 審查就不完整。 |
| 瀏覽器子資源是否可見於記錄中？ | 瀏覽器 Agent 解析的網域可能多於頂層 URL。 |
| 暫停、恢復、快照或清理之後可以取得什麼證據？ | 長時間執行的工作階段需要具備生命週期感知的遙測。 |
| 誰可以放寬出口政策？ | 例外變更應可稽核。 |
| 可疑工作階段如何被保留？ | 清理不應抹除唯一有用的事件證據。 |
如果多個答案未知，請在供應商或內部平台團隊能記錄控制路徑之前，將工作負載留在沙箱之外。如果工作負載只處理公開資料且不使用任何機密，在早期原型階段這些缺口或許可以接受，但在正式上線前仍應追蹤。
結論
對於正式環境的 Agent 沙箱，請將 DNS 視為出口流量的一部分來審查，而不是放在註腳。最低限度可辯護的設定，是受限的對外政策、明確的套件取得治理、短期有效的機密、逐工作階段的 DNS 與連線記錄，以及經過測試的事件保留流程。
只有在資料不敏感且 Agent 沒有重要機密時，才對低風險原型使用較廣泛的網路存取。對於敏感程式碼庫、客戶資料、內部 API 或受監管的工作流程，在授予 Agent 自主執行之前，應要求最小出口流量設定檔與目前供應商證據。
常見問題
如果沙箱封鎖 HTTP，DNS 外洩仍然相關嗎？
是的。HTTP 控制與 DNS 控制是不同層級。沙箱可能封鎖對外網頁請求，但仍然允許 DNS 查詢。安全團隊應同時驗證解析政策與連線政策。
AI Agent 沙箱應該完全沒有網際網路存取嗎？
不一定。許多有用的 Agent 任務需要套件庫、公開文件、API 或瀏覽器存取。更安全的目標是最小且可解釋的出口流量：允許任務所需的，拒絕任務不需要的，並同時記錄允許與拒絕的活動。
套件安裝與一般網路存取相同嗎？
不相同。套件安裝需要單獨的政策，因為它們涉及套件庫、相依性解析、成品下載，有時還有安裝時期腳本。團隊可以允許透過已核准的快取取得套件，同時拒絕任意的執行時期出口流量。
哪些記錄對 DNS 風險最重要？
最有用的記錄會將 DNS 查詢連接到特定的沙箱、指令、時間、使用者或 Agent 工作流程，以及政策決定。被拒絕的查詢記錄尤其重要，因為它們顯示控制是否真的生效。
沙箱供應商能保證不會有資料外洩嗎？
請謹慎看待絕對保證。供應商可以提供隔離、網路控制、記錄與設定選項，但最終風險取決於工作負載設計、機密、資料放置、對外政策與營運監控。
