當兩個 AI Agent 被隔離在不同的虛擬機器中，沒有網路連線，也不能使用共同的可寫入檔案，理論上應該無法直接交換資訊，但是OpenAI 在最新公布的資安研究顯示，AI Agent 竟能利用 CPU 快取的存取時間差，建立原先未被允許的秘密通訊管道。
OpenAI 於近日發表的官方說明 Securing our frontier model training environment 中，闡述了該公司如何強化尖端 AI 模型的訓練與評估環境，並運用高能力 AI Agent 執行大規模的紅隊測試來尋找基礎架構中的安全弱點。
其中最受關注的實驗之一，就是研究人員要求分別運作於不同輕量化虛擬機器( microVM)的 AI Agent，在沒有網路連線或共同可寫入檔案的條件下交換模擬機密資料。這些 microVM 是由 OpenAI 的沙箱軟體建立及管理，並位於同一台共享主機上。測試結果顯示，AI Agent 能夠藉著將 CPU 快取的存取時間差轉換成訊號來完成原本受到隔離機制禁止的資訊交換。
這項發現證明了在特定共享硬體條件下，原本用於提升處理器效能的機制，也可能被利用來建立隱蔽的通訊管道。
OpenAI 曾因 AI 突破安全限制暫停訓練轉向離線環境
這次研究其實是 OpenAI 在近期多起 AI 模型突破執行環境限制的事件後，所展開的一系列安全強化措施。OpenAI 提到，今年 7 月的 Hugging Face 事件顯示，具備複雜網路攻擊能力的模型可能在訓練與評估期間突破隔離，因此OpenAI 在說明中表示，目前尖端模型訓練已改在沒有網際網路存取的條件下進行。
其中一個關鍵事件發生在 2026 年 9 月，當時 OpenAI 的內部研究模型在訓練期間，利用 DNS 解析器的設定問題，取得有限度的外部網際網路存取能力，雖然事件最終受到控制，但也暴露出研究環境中的安全弱點，OpenAI 也因此暫停最先進模型的訓練與評估作業，進一步修補基礎架構、強化監控系統，並改善偵測到高風險行為時自動停止執行的機制。
直到 10 月 1 日，OpenAI 才在完成相關評估及導入新的防護措施後，恢復尖端模型的強化學習訓練與內部推論作業，從暫停到恢復共計 11 天。
為了讓 AI 模型仍能練習搜尋資訊、瀏覽網頁和操作應用程式，OpenAI 也建立了一套稱為 Offline World 的離線模擬環境。
這套環境包含大量事先建立索引與快取的網頁內容，讓模型能夠執行類似實際網路操作的任務，卻不需要直接接觸外部網站。OpenAI 表示，目前所有尖端模型的強化學習訓練都使用這種離線模式。
值得大家留意的是， OpenAI 的做法其實不代表整個訓練基礎架構完全實體斷網。由於研究與監控作業仍需要部分對外連線，OpenAI 採取的是限制模型可以使用的網路路徑，並透過多層防禦降低未經授權存取的風險。但是就算限制網路連線，AI Agent 仍可能透過其他方式跨越安全邊界，CPU 快取通訊實驗便是其中一項例子。
CPU Cache 如何成為秘密通訊管道？
要理解這次 AI Agent 如何在沒有網路的情況下交換資訊，首先需要了解 CPU Cache 的運作原理。
CPU Cache，也就是處理器快取記憶體，是位於處理器記憶體階層中的高速儲存空間，主要用途是暫存近期使用或可能再次存取的資料，減少 CPU 等待主記憶體回應的時間，這種設計原本是為了提升電腦效能。當程式所需的資料已經存在快取中，CPU 通常可以迅速讀取；如果資料不在快取內，就可能需要從較慢的記憶體層級重新取得，因此產生可被測量的時間差。
而OpenAI 的實驗中，一個 AI Agent 透過刻意將選定資料逐出 CPU Cache，改變另一個 Agent 重新讀取相關資料時的速度，而接收AI Agent 則測量資料重新載入的時間，利用讀取速度的快慢差異，判斷發送端所傳遞的訊號。只要雙方事先建立編碼與解碼規則，就可以把這些時間差轉換成位元資訊，進一步組合成可辨識的訊息。
這種通訊方式不需要建立 TCP/IP 連線，不必開啟網路連接埠，也不需要直接修改共同的可寫入檔案。
但是這項技術有明確的前提，就是發送端與接收端必須處於能夠觀察相關共享硬體效應的環境，而且需要足夠穩定的時間測量條件，才能從系統雜訊中辨識訊號。
所以並不是任意兩台沒有網路連線的電腦，都能直接使用相同方式交換資訊。
CPU 側通道攻擊與 Spectre、Meltdown 原理相似
熟悉處理器資安議題的讀者，想必對 Spectre 與 Meltdown 並不陌生。2018 年曝光的這兩類處理器安全漏洞，讓全球資安產業開始更加重視 CPU 微架構行為所造成的資訊洩漏風險，相關攻擊利用處理器執行指令與管理快取時產生的可觀測差異，間接推測原本受到保護的資訊。
OpenAI 指出，這次實驗使用的快取時間差技術，也曾被運用於 Spectre 與 Meltdown 相關攻擊，但是這兩者的攻擊目的並不完全相同，傳統快取側通道攻擊經常被用於推測受害者的機密資料，而 OpenAI 這次的實驗，是讓兩個 Agent 利用共享硬體資源建立原本未被允許的通訊方式。前者著重於資訊洩漏，後者則是利用側通道建立隱蔽通訊，因此這次研究是展示既有的硬體側通道原理，如何被具備程式開發及漏洞分析能力的 AI Agent 實際運用。
除了快取記憶體，Wccftech 在這篇 OpenAI Says Its AI Agents Communicated With Each Other Via Cache Timing Differences 相關報導中，特別引用 OpenAI 研究員 Noam Brown 先前談及的案例，兩台電腦完全沒有網路或直接資料連線，也可能透過溫度變化建立極低頻寬的通訊管道。
從 CPU 快取、記憶體存取時間，到溫度與其他物理訊號，這些研究共同提醒我們，資安隔離只考慮軟體介面與網路連線已不足夠，也必須理解底層硬體資源的共享方式。
OpenAI 還發現其他秘密通訊方法
除了 CPU 快取，OpenAI 也發現 AI Agent 能利用共享儲存資源的存取延遲、同一容器中不同程式競爭 CPU 運算時間所產生的差異，以及 TLS 憑證快取等方式，建立隱蔽通訊管道。
其中一項涉及儲存設備的測試，與企業常見的共用儲存架構有相似的技術概念。發送端 Agent 在持續寫入資料與停止寫入之間切換，藉此改變共享儲存資源的負載。接收端 Agent 則測量由此產生的時間差，並據以解讀出訊息。
CPU 資源競爭也是類似概念。
當同一個執行容器內的不同程式共用運算資源時，其中一個程式的活動，可能影響其他程式的執行時間。如果這些差異足夠穩定，就可能形成可利用的訊號。OpenAI 還發現離線網頁環境中的 TLS 憑證快取，也可能被轉化為跨越隔離邊界的通訊方式。
這些測試凸顯出即使檔案權限、網路存取與程序隔離都已受到限制，底層系統資源仍可能存在未被納入原始安全設計的資訊傳遞方式，OpenAI 也表示，已在監控系統中新增檢查機制，以偵測透過這些管道進行通訊的嘗試。
AI Agent 不只會利用側通道 還能繞過原本允許的網路服務
OpenAI 在這次紅隊測試中，也發現 AI Agent 能夠利用部分原本合法的基礎架構功能，尋找間接連線至外部網路的方法。但由於研究環境仍需要維持監控、記錄與身分驗證等功能，部分內部服務仍須保留有限的網路存取能力。OpenAI 也表示，自 Hugging Face 事件後，已縮減模型在訓練與評估期間可觸及網際網路的管道，只為效能監控、記錄與身分驗證管理等特定服務保留窄小的連線，但是紅隊 Agent 卻幾乎在每一項這類服務中都找到弱點，取得有限形式的網路存取。
這些服務原本有明確用途，也受到防火牆及存取權限限制，但 AI Agent 仍可能從功能組合與設定細節中找到意想不到的使用方式。例如在一項假設 Agent 已經控制主機的測試中，Agent 利用防火牆原本允許的連線，存取監控服務內一個受到限制的身分驗證端點，再讓該端點依照模型提供的網址發出請求。以這個例子來說，Agent 並不是直接建立一條原本遭到禁止的外部連線，而是試圖利用現有服務代為執行網路請求。
OpenAI 也發現其他涉及 DNS、防火牆設定與服務端請求功能的弱點，顯示即使單一安全機制的規則看似合理，不同元件組合後仍可能出現非預期的攻擊路徑，因此防範 AI Agent 突破隔離環境，只依賴封鎖網路連接埠或禁止特定指令是不夠的，還需要同時檢查服務權限、身分驗證、網路流量與跨系統存取行為。
AI Agent 是完全自主發現這些攻擊方式嗎？
這次研究結果雖然值得關注，但也必須釐清實驗條件，避免將結果過度解讀。
OpenAI 在官方說明中明確表示，多數隱蔽通訊測試會引導 Agent 調查特定通道，或直接提供編碼與解碼協定，在這些紅隊測試中，研究人員提供基礎架構原始碼、設定細節與潛在弱點文件，讓 AI Agent 在較有利於攻擊者的條件下尋找問題。不過 OpenAI 也提到另一次不同的測試，這次研究人員僅提供一份廣泛的基礎架構弱點清單，要求 Agent 自行尋找互相通訊的方法，結果 Agent 成功將其中一項弱點轉換成通訊管道並完成資訊交換。
但 OpenAI 也指出，大多數這類通訊管道的資料傳輸速度很慢，而且利用難度較高，因此也不能將這次實驗直接解讀成 AI 已經能夠輕易突破任何虛擬機器或實體隔離環境。
OpenAI 發現多項虛擬化與基礎架構設定弱點
為了驗證新的隔離架構，OpenAI 動用多組高能力 AI Agent，包括即將推出的 GPT-6 Astra Cyber 模型以及一個內部尖端模型，對專門建立的隔離測試基礎架構執行大規模紅隊測試。測試涵蓋嘗試連線至外部網際網路、突破內部安全邊界，以及與原本不應互通的其他 Agent 交換資訊等方向。
整體測試使用了數千億個 Token，讓多組 Agent 平行探索不同弱點及攻擊路徑，在實驗過程中，Agent 不只找到隱蔽通訊方法，也發現開源軟體中的未知漏洞、虛擬機器逃逸方式，以及 OpenAI 自身對雲端控制項與內部服務的設定錯誤。
其中部分問題涉及 Kata Containers、gVisor 與 Moby/Docker 等容器及虛擬化相關元件，另有三項 Linux 核心漏洞（CVE-2026-74753、CVE-2026-80521、CVE-2026-80841）已完成修補。
OpenAI 已針對相關發現進行修補，並在其 Patch the Planet 計畫下，與開源專案維護者及雲端服務供應商合作，透過漏洞揭露與修補程序改善安全性，而隨著紅隊測試持續進行，Agent 找到的漏洞與設定錯誤數量已明顯下降，且並未發現任何 Agent 能輕易利用、同時又能躲避監控的對外連線路徑。
對企業地端 AI、NAS 與虛擬化環境有什麼影響？
從企業實際佈署角度來看，這次 OpenAI 公布的研究，對於多租戶雲端平台、企業私有雲、地端 AI 伺服器，以及支援容器與虛擬機器的 NAS 設備，都有值得關注的資安啟示。目前企業導入 AI Agent 時，經常會將不同工作負載佈署在 Docker 容器、Kubernetes 叢集，或 Proxmox VE、VMware、KVM 等虛擬化環境中。
這些架構有助於管理運算資源、限制程式權限，並降低不同應用程式之間互相影響的風險，但是虛擬化隔離與實體硬體隔離並不完全相同。當多個虛擬機器共用同一台實體伺服器時，可能仍會共用部分 CPU 快取、記憶體子系統、儲存資源或其他硬體元件，如果不同信任等級的 AI Agent 能夠執行自行產生的程式碼，就需要進一步評估這些共享資源是否可能成為側通道攻擊的媒介。
企業若在同一台 NAS 或伺服器上，同時佈署具備外部文件處理能力的 AI Agent、內部敏感資料庫，以及擁有管理權限的自動化服務，就應特別注意各項服務的執行權限、資源存取與隔離架構。尤其是需要執行不受信任程式碼、第三方套件或外部提供工具的 AI Agent，不應因為已經配置於獨立容器，就認定它絕對無法影響其他系統。
在安全要求較高的環境中，企業可以依照風險程度考慮採取更嚴格的隔離方式，包括限制 Agent 執行權限、避免將高度敏感的工作負載與不受信任程式碼配置於相同主機，必要時使用獨立實體設備處理不同安全等級的任務。持續更新虛擬化平台、容器執行環境與主機核心，也有助於降低已知漏洞遭到利用的可能性。
企業應將這項研究視為架構風險評估的參考，而不是直接推論特定產品存在尚未證實的安全漏洞。
AI Agent 資安不能只依賴沙箱 硬體與基礎架構同樣重要
過去討論 AI Agent 安全時，焦點多半集中在提示詞注入、API 金鑰外洩、敏感資料存取，以及 AI 是否可能執行未經授權的系統操作。OpenAI 這次公布的研究顯示，當 AI Agent 具備自行撰寫程式碼、反覆測試環境，以及分析執行結果的能力時，安全邊界已經不再只是應用程式或網路層級的問題。即使單一防護機制看似完整，不同系統元件之間仍可能存在原先沒有預期的互動方式，而這些側通道技術並不是因為 AI 的出現才被發明。
這也意味著，企業導入 AI Agent 時，不能只考慮模型效能、GPU 運算能力、Token 成本及自動化效率，也應將執行環境隔離、最低權限原則、異常活動監控與持續安全測試列為重要項目。特別是在企業私有雲與地端 AI 架構中，資料不離開企業內部確實有助於降低某些資料傳輸與第三方存取風險，但並不等於整體環境已經具備充分的安全防護。
對於必須處理機密資料或具備高度管理權限的 AI Agent，應依照實際安全需求建立更明確的工作負載隔離機制，而不是單純依賴容器、虛擬機器或網路防火牆。
隨著 AI 具備更強的系統操作與漏洞探索能力，原本被視為可靠的安全邊界，也必須接受持續驗證。未來企業真正需要思考的，除了AI 可以幫我們完成哪些工作，還有當 AI 開始具備突破系統限制的能力時，我們是否已經為它建立足夠安全的執行環境。
本文首圖由 AI 生成
