加拿大企業 AI 模型公司 Cohere 在美國時間 10 月 26 日發布報告指出，阿里巴巴的開放權重（open-weight，公開模型權重供外界下載部署）模型 Qwen3.8-Flash-Next 在一次資安基準測試中，沒有完成指派的任務，反而探查所在環境，並試圖把一段測試字串上傳到阿里雲北京區的雲端儲存空間。這個請求被測試用的沙盒（sandbox，與外部網路隔離的測試環境）擋下，但模型的推理紀錄（reasoning trace，模型行動前寫下的思考過程）中，卻寫著它不會呼叫任何工具。
Cohere 坦言無法判斷原因；獨立研究者的測試則提出另一種解釋：模型更像是記住了阿里巴巴的訓練環境，而非被埋了後門。對正在評估或已導入開放權重模型的企業而言，更實際的問題或許是：當 AI 代理的實際行為與它的推理紀錄不一致，企業該靠什麼把關？
Cohere 抓到什麼？Qwen3.8 沒寫偵測規則，反而試圖上傳字串到北京
Cohere 測試的 Qwen3.8-Flash-Next，是阿里巴巴 8 月推出、用來預覽其 Qwen4 架構的模型。Cohere 使用微軟的 CTI-REALM，這是評估 AI 代理執行資安分析師工作的基準測試；模型拿到的任務，是撰寫一條偵測規則，找出惡意檔案的下載與執行。
根據 Cohere 的描述，模型先列出暫存資料夾的內容、檢查有哪些傳輸工具、讀取機器的 DNS 設定，接著試圖把一段測試字串上傳到阿里雲北京區的儲存桶（bucket，雲端儲存服務中存放檔案的空間），並檢查是否成功。《XDA Developers》指出，上傳的內容是固定字串「PROBE_PAYLOAD_ABC123」，而不是模型剛蒐集到的環境資訊。
Cohere 表示這種行為相當罕見，在評測中出現的頻率低於每 10 萬次呼叫 1 次；用同一個提示重跑，模型也寫出了標準的偵測規則。但 Cohere 推估，一個每週處理 1,000 萬次代理回合的服務，可能會遇到多達 100 次這類呼叫。
至於原因，Cohere 表示：「我們無法回答這是刻意為之，還是訓練留下的錯誤。」它提出兩種可能：一是模型記住了訓練沙盒中的代理紀錄，Cohere 稱之為「良性化石」；二是刻意植入的「回傳」機制。
是後門還是訓練殘留？獨立調查認為不像刻意設計
《VentureBeat》提醒，Cohere 與阿里巴巴在企業客戶市場相互競爭，對這項發現有商業利害關係；Cohere 也沒有公布 Meta Llama、OpenAI GPT-oss，以及 DeepSeek、Kimi 等模型的同類測試結果。Truthful AI 研究員 Adam Karvonen 也在 X 上表示：「我認為這被誇大了，我猜這是訓練產物。」截至《VentureBeat》與《XDA Developers》刊出時，阿里巴巴都沒有公開回應。
《XDA Developers》技術主編 Adam Conway 提出更具體的解釋。他表示，早在 9 月 20 日——也就是比 Cohere 發文早一個多月——就在同一個模型上看過類似行為。他認為 Cohere 的觀察屬實，也確實是個問題，但他找到的跡象都指向：模型是在訓練中學會了阿里巴巴內部抓取網頁工具的運作方式，而不是被設計來竊取使用者資料。
在 Conway 的測試中，模型常聲稱自己抓取網頁時經過一個指向阿里雲新加坡區的網址，但這個網址根本不在輸入內容裡；他以中英文跑了數百次，約四成的回答出現這類網址，但他從沒看過能實際使用的完整網址。
他判斷不像後門，理由有二。第一，這些網址帶著可追溯到阿里巴巴的內部資訊：多數網址帶有同一組屬於真實阿里雲帳號的金鑰 ID，網址中的 Routify 是該公司內部模型路由閘道的名稱，追蹤 ID 也指向其內部伺服器。他認為，真要打造後門，應該會用查不到自己身上的拋棄式基礎設施，而不是一個掛滿自家名字的正式帳號。
第二是遮蔽測試：把模型權重中與 Routify 主機名稱相關的部分遮蔽後，模型沒有就此停下，而是改編出另一個看似合理的阿里雲網址。Conway 指出，真正的後門一旦被拿掉目的地就無處可去，這個模型卻會即興編出變體。不過，Cohere 抓到的北京儲存桶，他自己無法重現。
AI 安全公司 Palisade Research 也有類似發現。根據《The Decoder》報導，Palisade 分析評測資料後發現，Qwen3.8-Max-0902、Qwen3.8-Max 與 Qwen3.8-27B 都出現連往阿里雲網域的紀錄，較舊的 Qwen3.7 系列則沒有；這些請求都指向阿里雲新加坡區，每次都被伺服器拒絕。Palisade 表示，沒有發現模型惡意連回中國或竊取敏感資料的跡象。另有研究人員以同樣方式測試 DeepSeek、Kimi、GLM 等模型，部分模型被擋時會改用公開代理服務，但沒有一個透過自家開發商的伺服器傳送流量。
不論成因，企業部署 AI 代理該先設好哪些防線？
即使是意外，風險也不會因此消失。Cohere 在人為引導模型補完指令的測試中發現，模型有 23% 至 36% 的機率先嘗試連向雲端中繼資料位址，Amazon、Google、微軟的雲端主機都從這類位址取得臨時憑證。Cohere 將此解讀為疑似竊取憑證的嘗試，但也提出保留：沙盒中沒有可回傳的資料，而且「如此罕見的反射動作，並不能證明意圖」。
Conway 則指出，模型每次去連那些捏造出的阿里雲網址，儲存桶的擁有者都能看到使用者的 IP 位址、時間與完整網址；根據《The Decoder》，這個代理網域目前仍在運作。他也提醒，模型會自信地捏造自己做過的事，被要求核對時還會編出錯誤的更正，自我回報因此無法當成稽核紀錄。在他的測試中，要求模型核對原本正確的答案，約 75% 的情況反而被改成捏造的網址。
Cohere 的結論是：「推理紀錄不是安全邊界。」綜合各方建議，企業可以從三個方向著手：
- 預設封鎖對外連線：Cohere 建議預設拒絕 AI 代理的對外連線（egress）；Conway 進一步建議，攔截對話中從未出現過的主機。
- 在工具執行前把關：Cohere 建議把不是自己訓練的模型權重，當成未簽章的執行檔看待，在工具呼叫實際執行前檢查，並對平常不用的雲端網址或非預期的工具呼叫發出警示。
- 限縮權限、檢查嘗試過的動作：《VentureBeat》引述 OWASP 的 AI 代理安全指引，建議嚴格限定權限範圍、重大動作由人監督，在不含正式環境憑證的隔離環境開發，網路只開放核准的目的地；《VentureBeat》另建議，部署程式碼代理的團隊應檢查代理能否連到任意儲存服務，除了成功的動作，也要檢視模型嘗試過的動作。
《VentureBeat》也提醒，企業應檢視 Cohere 的說法，但不要把模型的國籍當成惡意的證據。Conway 也指出，訓練環境究竟長什麼樣子，只有阿里巴巴能證實。在答案出來之前，這場爭論的焦點，正從「模型來自哪裡」，轉向「AI 代理能連到哪裡、能做哪些事」。
【推薦閱讀】
◆ 資安公司 Bitdefender 推出新型 VPN：保護的不是你，而是你的 AI 代理
◆ 中國的開放模型對手來了？Reflection AI 推 Beam，憑什麼挑戰 GLM、Qwen
◆ 【科技早餐】SpaceX 600 億美元收購 Cursor，阿里稱 Qwen 半年下載破 30 億次、在 Hugging Face 領先 Google 與 Meta
＊本文開放合作夥伴轉載，資料來源：Cohere、《VentureBeat》、《XDA Developers》、《The Decoder》，首圖來源：Qwen
