研究人員追蹤利用 Tencent 基礎設施、鎖定 Alibaba Amap 的 AI 代理程式群

獨立研究人員表示，他們已辨識出一個持續運作的 AI 代理程式群，透過與 Tencent 相關的基礎設施運作，並查詢 Alibaba 的地圖服務 Amap。初步調查結果顯示，多個代理程式正在要求前往公共場所入口的路線，包括公園、動物園和醫院。

目前這項活動似乎還沒有顯示出協同攻擊或複雜的自主操作。研究人員將其稱為「代理程式群」而非「蜂群」，因為這些代理程式看似平行工作，彼此之間並未通信。即便如此，這項發現仍具體說明了 AI 系統如何在開放網路上產生持續流量，以及要判斷究竟是誰在運作這些系統、目的為何，可能有多麼困難。

研究人員觀察到的情況

研究人員透過監控與 urlquery 相關的流量偵測到這項活動。urlquery 是一項掃描網站並記錄網頁如何回應的服務。AI 代理程式有時會使用 urlquery 等服務，存取它們無法直接連線的網站，並在過程中留下可觀察的軌跡。

根據 TechCrunch AI 引述的初步報告，這些代理程式反覆查詢 Alibaba 的 Amap 服務，以取得前往公共場所不同入口的路線。這些請求看起來涉及一般的位置查詢，而不是內容抓取、憑證濫用或操縱地圖的企圖。

基礎設施線索指向 Tencent，但現有證據無法證實 Tencent 曾操作或授權這些代理程式，甚至無法證實 Tencent 知道它們的存在。同樣地，向 Amap 發出的請求本身也無法辨識幕後的組織或個人。這項活動與中國科技產業的關聯，來自 Tencent 基礎設施與 Alibaba 服務似乎參與其中，而不是因為營運者身分已被公開。

「群」這個用詞具有重要意義。蜂群通常暗示代理程式之間存在協調或通信。在本案例中，研究人員表示，許多代理程式彼此獨立地執行類似任務，沒有明顯證據顯示它們分享資訊或遵循中央對話協定。

證據仍屬初步

這些發現是根據網際網路觀察，而非 Tencent、Alibaba 或代理程式營運者的公開聲明。TechCrunch 報導稱，研究仍在進行中，目前可取得的細節相對有限。現有來源證據沒有提供代理程式數量、涉及的模型、操作時間長度或位置查詢目的等資訊。

這限制了目前可以負責任地得出的結論。這項活動可能代表有意規避 Alibaba 偏好的存取機制，但研究人員並未報告更廣泛入侵的證據。TechCrunch 將這種行為描述為看來不比繞過 Amap API 規則更嚴重。這是對已觀察請求的評估，而非營運者證實的解釋。

對 AI 代理程式而言，這項區分十分重要，因為網路活動看起來可能比實際情況更具威脅，也可能比其未來可能發展的程度更不具威脅性。透過第三方基礎設施傳送的自動化請求可能掩蓋歸屬，而跨越多個工作單元的重複操作，即使每個單獨查詢看似無害，也可能產生營運影響。

這項發現也緊接著過去促使研究人員關注線上不當 AI 活動的事件，包括報告中提到的 Hugging Face 事件。這些調查受益於目前 AI 代理程式一項反覆出現的弱點：它們經常依賴可辨識的服務，並留下傳統網路監控可以捕捉的痕跡。

為何這對代理程式開發者很重要

對開發者而言，這起事件提醒人們，AI 代理程式並不受限於其模型端點。它的行為也取決於瀏覽器、代理伺服器服務、網路存取工具、雲端基礎設施和外部 API。每個元件都可能產生日誌、速率限制事件或安全訊號，揭示代理程式的活動。

一個會啟動大量平行工作單元的系統，需要的不只是提示層級的安全政策。開發者應能辨識是哪個工作單元發出了請求、哪項任務授權了該請求、它聯繫了哪個外部服務，以及這項行動是否符合該服務的使用條款。沒有這條責任鏈，善意的研究工作流程可能看起來像濫用，而濫用工作流程則可能難以調查。

Amap 查詢也說明了一個實際的可靠性問題。位置服務通常提供多種存取途徑，包括網站、行動介面和正式的開發者 API。代理程式若使用瀏覽器或掃描中介來避開無法使用的 API，可能完成任務，但也可能違反使用規則、產生過量流量，或破壞服務對使用者行為的假設。

對部署 AI 代理程式的企業而言，相關控制措施包括記錄對外請求、為每個代理程式設定身分、限制平行活動、建立網域允許清單，以及對涉及第三方服務的行動要求明確核准。這些措施無法證明系統安全，但能讓異常行為更容易被偵測和解釋。

接下來要關注什麼

最重要的後續問題是，研究人員能否辨識出這個代理程式群背後的模型、營運者或協調框架。其他證據也可能釐清代理程式是否持續運作、涉及多少工作單元，以及這些請求是由一個應用程式還是多個互不相關的系統產生。

Tencent 和 Alibaba 的回應將有助於確認它們的系統是否偵測到這項活動、Tencent 基礎設施是被客戶還是未經授權的一方使用，以及 Amap 的存取控制是否遭到繞過。同時也值得觀察，這些請求會在公開披露後停止，還是轉移至其他地圖和網路服務。

更廣泛而言，研究人員可能會檢視相同的基礎設施模式是否出現在其他 AI 代理程式調查中。如果代理程式反覆使用 urlquery 和類似服務，這些平台可能成為監控代理程式的重要觀察點。但如果營運者轉向透明度較低的工具，或將請求分散到更多供應商，這種可見性可能無法持續。

Creati.ai 的觀點

這起事件與其說是一起已證實的網路攻擊，不如說是自主軟體所造成、日益嚴重的可觀測性問題。一組代理程式可以在不表現得像協同蜂群的情況下產生有意義的網際網路活動，而這項差異對風險評估和應對都很重要。

對開發者和企業採購者而言，眼前的教訓是營運層面的：代理程式權限、身分和外部服務存取必須一併設計。在擴大代理程式自主權之前，團隊應能重建其行動，並區分經授權的自動化與僅僅使用相同基礎設施的流量。研究人員的初步發現說明，這項能力正成為基本要求，而不是可有可無的安全功能。