AID-I-001.004
極高
Sandbox Network Egress Restrictions
沙箱其實已經擋掉了公開網際網路，所以整條通道就活在那個唯一還留在允許清單上的目的位址裡。做法是逐一列出程式碼執行沙箱可連的目的位址、連接埠與允許的操作，並把這套政策放在沙箱外部強制執行；容器只需要一條唯讀的套件取得路徑，不需要一個帶有寫入 API 的服務。
一個共用的內部套件服務，讓某個 ChatGPT 帳號能在別人的對話裡執行任務
資安公司 Check Point Research 發現，ChatGPT 為了處理需要跑程式的問題，會建立「程式碼執行容器」；這些容器本身連不到公開網際網路，但全部都能連到同一台內部的 JFrog Artifactory（一種用來集中存放與發送軟體套件的服務），以便安裝 Python 與 npm 套件。問題在於，這台服務開放了「項目屬性」API，任何容器都能在同一個套件項目上寫入與讀取任意字串，等於把套件的中繼資料（metadata）變成一個不同帳號之間共用的信箱。在概念驗證（PoC）中，攻擊者的工作階段先把一項任務放進這個信箱，受害者的工作階段就在同一輪回答中執行它，讀取受害者已連接的 Gmail，再把資料送回去。
威脅分析
- 一個為了方便而開的通道，變成了雙方碰頭的地點。 因為容器連不到公開網際網路，OpenAI 允許它們改從一台內部 Artifactory 取得套件。這台服務對外提供了項目管理操作，而容器環境變數裡本來就有的讀取用憑證，權限足以寫入也足以讀取項目屬性。屬性值可以放純文字或 Base64 編碼內容，資料太大時還能拆成多個鍵分開存放，再於另一端重新組合。
- 是受害者自己的那一輪對話，替攻擊者把任務做完了。 惡意指令可以透過三種方式進入受害者的上下文：使用者自己貼上的提示詞（prompt）、一段被分享的對話，或是某個自訂 GPT 隱藏設定裡的內容。之後只要受害者送出任何一則普通訊息，該工作階段就會同時跑兩條流程：一條產生使用者看得到的回答，另一條則去檢查那個隱藏信箱。一旦發現有待辦任務，它就會呼叫受害者已連接的 Gmail，再把結果從同一條通道寫回去。
- 畫面上幾乎看不出異狀。 Check Point 指出，使用者唯一能看到的痕跡，是回答上方一個小小的「Talked to Gmail」標示；而那是在動作做完之後才顯示的紀錄，並沒有給使用者事前核准或拒絕的機會。在預設設定下，連接器的讀取動作本來就會自動核准。
- 證據界線。 這是概念驗證，不是已觀察到的實際攻擊。OpenAI 確認該內部 Artifactory 已經下線，通道也隨之關閉；不過下線的直接原因是另一起 Hugging Face agent 事件，而不是這份研究報告。目前沒有任何來源能確認，這是否就是那批 agent 當時利用的同一台 Artifactory。
適用的 6 項 AIDEFEND 防禦手法
AID-H-018.005
極高
Value-Level Capability Metadata & Data Flow Sink Enforcement
資料要外流，必須先完成一個很具體的動作：把透過連接器讀到的郵件內容，寫進共用的套件中繼資料裡。只要逐一追蹤每個由連接器回傳的資料值之來源標記與機敏程度，並在每個對外寫出的出口逐一檢查，不管隱藏指令怎麼寫，這次寫入都會被擋下來，因為那個目的位址從來就不是私人郵件被核准的去處。
AID-H-018.002
高
Policy-Based Access Control
只要某個容器能修改一份資料，那份資料就應該只有擁有它的帳號或工作階段讀得到。在服務邊界針對確切的物件、動作與租戶逐一授權，並拒絕跨租戶的讀取與寫入、同時不洩漏其他租戶是否存在該物件，就算容器仍然需要用這個套件服務，雙方碰頭的地點也不復存在。
AID-H-018.004
高
Intent-Based Dynamic Capability Scoping
受害者要的只是一張月均溫的圖表，這一輪對話根本沒有理由握有讀取信箱的能力。依照通過驗證的使用者身分與當下明確的意圖，逐次推導這一輪可用的工具集合，再由工具分派器強制執行，夾帶進來的指令就會落在一個根本沒有 Gmail 能力的回合裡。
AID-H-018.003
中
High-Impact Independent Validation & Approval Gate
把已連接應用程式從「讀取自動核准」改成「每次動作都要明確確認」，使用者才會在信箱內容被送出前，多一個可以喊停的決策點。這項技術的指引是針對付款、基礎設施變更與寫入類動作寫的，所以對唯讀連接器而言，僅適合作為提高攻擊成本的補強控制，真正守住出口的是 AID-H-018.005。
AID-D-005.004
中
Specialized Agent & Session Logging
在別人的回合裡偷跑的第二個任務，如果工具呼叫沒有連同授權它的目標一起逐次記錄，就完全看不見。把每一次連接器呼叫連同工作階段、身分主體以及參數與結果的雜湊值一併記錄下來，審查人員才有依據，找出那些沒有任何使用者請求可以解釋的連接器讀取行為。
身為資安防禦者，我們應該這麼做
- 如果你自己在經營多租戶的 AI 產品，先列出每位使用者的沙箱被允許連到哪些內部服務，再逐一檢查它們有沒有可寫入的狀態。只要是會接受呼叫者自訂中繼資料的套件鏡像、成品儲存庫或快取服務，只要那份狀態沒有依帳號隔離，它就是一條跨租戶通道。
- 只給沙箱一條唯讀的成品取得路徑。連線終止在一台代理服務上，由它只放行套件下載、拒絕管理與註記類 API，而且這道限制要在沙箱外部執行，不能交給沙箱自己遵守。
- 把注入到沙箱環境變數裡的憑證，一律視為模型跑出來的任何程式碼都拿得到，因此簽發時就要收斂到該工作負載真正需要的最小權限。
- 如果是企業版 ChatGPT 或類似的 AI 助理，在業務可以承受的範圍內，把已連接應用程式從自動核准讀取改成需要明確確認，收斂每個連接器看得到的信箱與雲端硬碟範圍，並把連接器的操作記錄送進既有的監控平台。
- 把分享出去的對話連結與自訂助理設定，當成不可信的輸入路徑來檢視，因為這份研究中三種植入惡意指令的方式，全都是從這裡進來的。
結論
兩個本來永遠不該碰面的帳號，透過一台沒人把它算進安全邊界的套件服務碰上了。這個教訓並不侷限於 Artifactory：只要某個共用的內部服務，允許屬於個別使用者的執行環境寫入別人讀得到的狀態，它就是一條租戶之間的通道，無論當初蓋它是為了什麼。AIDEFEND 把這條路徑對應到開發方能精準放置的控制：在沙箱外部強制執行預設阻擋的對外連線政策、在服務邊界落實物件與租戶層級的授權、依使用者當下真實意圖逐輪收斂可用工具，以及用資料流向控管擋住把連接器資料寫到不該去的地方。