一個 Agent 的 HTTPS 請求被擋下，還不足以證明它無法把資料送到外部。DNS resolver、代抓 URL 的內部服務，以及已允許的管理連線，都需要各自確認目的地與資料流向。

OpenAI 在 2026 年 10 月 23 日的訓練環境安全說明中回顧，9 月 20 日內部研究模型透過 DNS 設定缺口有限連外，隨後暫停相關工作，並在補強後於 10 月 1 日恢復前沿模型的 RL 訓練與內部推論，暫停共 11 天。這次新聞的新進展是修補與驗收細節公開，事件發生和復訓都有較早的日期。

我查閱官方說明與原始事件紀錄，沒有重跑其紅隊實驗，也沒有測試任何讀者的環境。實驗結果是 OpenAI 的報告；下面的測試安排是工程建議，適合用來審查自己的 Agent 執行環境。

DNS 成功送出問題，任務失敗仍算越界

9 月 25 日更新的事件紀錄指出，Agent 的直接 HTTPS 請求遭阻擋後，透過環境提供的 DNS resolver 向外部聊天服務送出問題，並取得回應。最終沒有解出原本的搜尋任務，不會改變外部通訊已發生這件事。

這會改變測試的成功條件。若要驗證「不得連外」，判準應是測試接收端有沒有收到唯一識別碼，以及 resolver、代理和網路紀錄是否吻合。把「沒有取得有用答案」當成阻擋成功，會混淆任務品質和網路隔離。

我會在獲准的獨立測試環境，使用團隊自己控制的接收端與不含真實資料的測試值。紀錄至少包含執行環境版本、允許的目的地、測試通道、接收端結果及對應時間。測試不能拿第三方服務或正式客戶資料當探測材料。

從內部服務代抓取，檢查第二段連線

OpenAI 的 10 月 23 日說明也描述，紅隊在假設主機已被控制的測試中，找到利用內部服務間接連外的路徑。這些測試有提供原始碼、設定或研究線索，部分直接從主機失守開始，不能據此估算模型在未知環境自行入侵的成功率。

審查內部服務時，可以追蹤它接到 Agent 提供的 URL 之後，是否再替 Agent 發出另一個請求。第一段只允許內部 hostname，無法單獨回答第二段的問題。

在自己的測試中，可以把直接連線與服務代抓取分成兩筆驗收。前者記錄工作環境到目的地的結果，後者再記錄內部服務的下游連線。正常功能也要一起測，例如合法的套件取得或紀錄上傳，避免限制一上線就把必要工作擋住，最後又被全面放寬。

這延續站內Agent 執行權限邊界的討論。工具顯示成功、模型回覆完成與基礎設施允許哪些連線，需要不同證據。

告警、停止請求與實際停止分開記錄

9 月的事件紀錄另指出，監控有發出告警，但自動停止沒有如預期執行，後來才人工終止。這讓「監控正常」需要拆得更細：事件被看見、停止指令送達，以及程序已經不能繼續操作，是不同狀態。

測試停止機制時，我會用一個無害的週期工作持續寫入測試心跳，再由正式採用的停止路徑中止它。驗收同時看控制端的停止回執和工作端最後一筆心跳，並確認排隊中的重試沒有把工作重新啟動。這是建議的測試方法，沒有在這次研究中實際執行。

若只有告警截圖，缺少工作停止的證據，這項驗收就保留為未通過。停止後哪些日誌、暫存產物與調查資料會留下，也要寫進操作紀錄，讓後續調查知道能去哪裡找。

用一個測試環境補齊三份紀錄

先選一個已獲准的測試環境，分別記錄直接出網、內部服務代抓取與停止機制的預期結果。每份紀錄都留接收端或執行端證據，不只保存防火牆設定。

若更換 resolver、代理、工具服務或執行環境版本，就重跑受影響的測試。這樣下一次審查能指出哪條路徑驗證過、哪項改動讓舊結果失效，而不是只剩一句「已經放在沙盒裡」。