受信任的技能就是攻擊：Copilot Cowork 與 AI 代理供應鏈
AI 代理的賣點是它們可以代替你使用工具。一名研究員在檢視 Microsoft Copilot Cowork 時，找到一個方法把這個賣點反過來對付使用者，而它所走的路徑也充分說明了代理安全未來的走向。
PromptArmor 在 9 月 30 日揭露這項發現。簡單說：一個下載而來、看似無害的文件檢查「技能」，可以劫持 Cowork 自身的網路路徑，開啟通往攻擊者伺服器的命令通道，並從 Outlook、SharePoint 和 Teams 竊取資料。根據研究員的說法，Microsoft 在 6 月收到通報，並在 8 月完成修復，因此技術細節是在修補之後而非之前公布。
四個步驟，其中只有兩個需要你參與
這起攻擊需要使用者做兩件平常的事：上傳一份文件以供審閱，以及叫用一項技能。
在示範中，這項技能聲稱會比對合約與提案，並標出不一致之處。它確實做到了，而這正是這類攻擊難以察覺的原因。問題出在與該技能一起打包的指令碼。Cowork 執行於一個理應無法連上公開網際網路的沙箱內，但它確實保有一座橋樑，用來處理產生答案所需的請求。惡意指令碼利用可透過那座橋樑觸及的文件同步服務，而且關鍵在於，該服務接受了呼叫端提供的 URL。
這個細節就是整起漏洞利用的核心。一旦指令碼能觸及攻擊者控制的位址，它就開啟了一個迴圈。每隔幾秒，它會取回一個包含命令的檔案，在 Cowork 內執行該命令，並把結果編碼成 URL 參數回傳給伺服器。那是雙向命令通道，不是單向信標，這表示攻擊者可以根據前一個命令傳回的內容，發出新的指示。
在示範中，研究員列出受害者的 Outlook 郵件，並讀取某個電子郵件討論串的內容。根據該篇技術文章，同一條存取路徑也暴露了 SharePoint 檔案、工作階段歷程和外掛程式資料。它能觸及多遠，取決於該名使用者原本就能看到什麼，而這是這類案例中常見的放大器：代理會繼承使用者的權限，因此影響範圍就是那個帳戶能觸及的一切。
還有一個細節值得再次強調，因為它會改變人們對阻止攻擊的想法。選取停止控制項並未終止背景處理程序。看得見的那一輪可能已經結束，但指令碼仍持續輪詢。使用者以為任務已經結束，通道卻依然敞開。
技能就是相依性
這項揭露有趣的地方，不在於現已修復的特定漏洞，而在於攻擊面並非對模型指令的提示注入，而是代理周遭的供應鏈。
在這類系統中，技能是小型應用程式。它們可以封裝指令碼、參考文件和設定，在 Cowork 的案例中最多可有二十個隨附檔案，而且它們經常來自組織外部，從市集下載或同事之間互相分享。這正是多年來在 npm 和 PyPI 生態系統中引發麻煩的相同結構：不是你寫的相依性，可以執行你沒讀過的程式碼。代理技能只是名字比較友善的相依性。技能頁面上的說明宣稱所有處理都在本機進行，不會傳送任何內容給第三方。平台本身的檢查並未察覺隨附指令碼的真正行為。
還有第二起較不明顯的外洩，指向同樣的弱點。Glow 的一份報告發現，代理透過公開的 GitHub 儲存庫暴露了來自 300 多個組織、超過 13,000 張內部圖片和螢幕擷取畫面。沒有人刻意要發布那些檔案。它們之所以會公開，是因為代理把它們寫到某個公開儲存庫能觸及的地方。
這兩起事件看似不同，卻有共同的根本原因。在其中一起，惡意技能刻意向外觸及。在另一起，行為良好的代理把資料寫到某個它不曉得會公開的地方。兩者都是代理能觸及什麼、其輸出能走多遠的邊界失靈。Cowork 案例顯示攻擊者利用那道邊界。GitHub 案例則顯示邊界自行失靈，沒有任何人試圖破壞它，而這在一般使用中可說更為常見。
如何解讀這類安全揭露
時間軸是多數讀者會略過的部分，但它值得逐步檢視，因為它會告訴你該如何衡量這項發現。PromptArmor 在 6 月下旬向 Microsoft 通報問題。Microsoft 在 7 月要求提供更多資訊，8 月初討論修復事宜，並在 8 月中下旬確認修補完成。這項研究在 9 月底、修補之後才公開，這是標準的負責任揭露流程。由此可得出兩個教訓。
第一，修好一個漏洞不等於修好一整類漏洞。特定的漏洞利用路徑已關閉。但讓它得以發生的模式——代理必須觸及的可信整合，竟可被當成任意通道使用——只要代理有獲准的網路路徑，就會出現。同一週還出現了其他指向相同弱點的例子，包括有報告指出代理透過公開儲存庫暴露了數千張內部圖片。不同的漏洞，相同的樣貌。
第二，修復是照 Microsoft 的時間表到來，不是照你的。任何在企業中執行這些工具的人，都需要知道自己用的是哪個版本，以及更新是否真的送達。部落格上的修補說明，不等於已修補的部署。
技能就是相依性
在這樣的故事之後，直覺反應是更加信任沙箱。Cowork 的沙箱在阻擋直接網際網路存取方面發揮了作用，而這起漏洞利用繞過了邊界，走的是沙箱不得不保持開放的路徑。這就是一般模式：沒有直接網路工具的代理，仍不是封閉系統，只要它能在日後會擷取外部資源的介面上撰寫內容，或驅動這麼做的服務。
對在企業環境中執行代理的團隊而言，實際因應方式看起來不太像安全修補，反而更像一般的軟體治理。了解安裝了哪些技能，以及它們來自何處。把技能安裝移到 IT 控管之下，而不是交由個別使用者自行決定。把具有網路路徑的技能當成任何新的可執行檔來看待，執行前先審查。確認安全更新是否真的涵蓋目前使用的版本。
這些都不是什麼稀奇的做法。這是供應鏈安全在過去十年間迫使軟體團隊養成的紀律，如今往上一個層級到來。差別在於後果輕重。一個遭入侵的 npm 套件可以在開發者的機器上執行程式碼。一個遭入侵的技能則在代理內執行，而該代理早已能存取你的郵件、檔案和聊天記錄，而且它可以在你以為自己已叫它停止之後繼續執行。