THINK BIG

一、現象：部分攻擊從鎖定目標到取得特權，少於三小時

微軟於 2026 年 10 月 21 日發表調查，指出其追蹤的威脅行為者 Storm-0940 最早在同年 9 月已使用代理式 AI 滲透測試框架 ARTEX 自動化攻擊。在多起案例中，從初始鎖定目標到取得組織雲端基礎設施的特權存取，時間少於 3 小時。[1]

報告記錄了既有應用程式授權與憑證遭濫用的活動，也提醒：環境中存在受影響應用程式，或攻擊者成功通過身分驗證，本身都不能證明資料曾被存取或外洩。[1] 因此，不宜把攻擊嘗試、成功驗證身分、取得特權與資料外洩混為一談。

開發生態則有另一條需要分開看待的脈絡。Linux Foundation 早在 2025 年 12 月 9 日就宣布成立 Agentic AI Foundation（AAIF），創始專案貢獻包括 Model Context Protocol（MCP）、goose 與 AGENTS.md。[2] 這是開源協作與治理的背景，並非這次攻擊的同日事件。

技能套件也應回到具體定義。以 GitHub 上的 anthropics/skills 官方儲存庫為例，其 README 將 Skills 說明為由指令、腳本與資源組成的資料夾。[4] 本文據此建議：盤點時分別記錄技能內容、執行環境，以及實際使用的帳號與權限。

二、各方評價：官方文件各自強調什麼

微軟：應檢查應用程式身分與後續操作。

微軟的處置建議包括檢查服務主體登入、異常憑證與權限變更，並落實最小權限。[1] 對本文而言，這表示部署驗收也應納入應用程式的授權範圍與操作紀錄。

Linux Foundation：以開放治理支持協作。

AAIF 成立公告強調中立、開放的協作環境，以及工具、標準與社群共同發展的方向。[2] 本文的判讀是：基金會治理與個別部署的安全審核應分別處理，不能僅憑專案加入基金會，就推定任一套件已獲安全認證。

NIST：不因位於內網就給予隱含信任。

美國國家標準暨技術研究院（NIST）在《Zero Trust Architecture》中說明，不應僅因資產或帳號的網路位置、實體位置或所有權而給予隱含信任；存取企業資源的工作階段建立前，須進行身分驗證與授權。[3]

這些文件的重點各有不同。我們的建議是將它們轉成同一份部署檢查清單：以什麼身分執行、能存取哪些資源、誰核准，以及如何留下操作紀錄。

三、我們的第一手心得（不具名）：把權限寫成可驗收的約定

面對 AI Agent 導入，我們會先把兩個問題放進討論：

「它可以對我的資料做哪些事？」 「誰核准、誰維護，異常時由誰處理？」

以下以不具名方式呈現團隊的實作觀點與建議，不作為客戶成效或產業統計。

心得一：先畫權限，再決定工具

我們主張先整理一張清單，至少列出四個欄位：工具／技能名稱、資料與操作範圍、使用者／執行身分、負責人。

資料與操作範圍應繼續拆開：能讀取哪些檔案、能否修改或刪除、能否呼叫外部服務、能否傳送資料。把預期用途與實際設定放在一起核對，再決定哪些能力需要保留或調整。

心得二：把核准、維護與處置責任寫下來

我們建議為每項工具記錄核准人、維護人與異常通報窗口，也約定停用或撤回授權的方式。

涉及重要資料寫入、刪除或對外傳送時，應在導入前約定是否需要人工覆核，以及由誰執行。負責人的名字應對應到明確的工作與權限。

心得三：驗收指標要有期間、定義與門檻

我們建議記錄三項指標：使用次數、無需修改即可採用的回覆比例、經授權後實際完成的任務數。

統計期間、計算方式與通過門檻應在試用前約定。若結果未達標，再依紀錄檢查資料品質、權限設定、流程設計與使用方式，不以單一固定天數或是否成長直接判定成敗。

四、我們的建議：先做三件事

1. 用既有文件開始盤點

列出正在使用的 AI 技能、工具與外掛，包含員工自行安裝的項目。先確認盤點範圍、需要哪些系統管理者協助，再安排人力與時程。

清單除了名稱，也要記錄資料與操作範圍、執行身分及負責人。不要只問「有沒有使用 AI」。

2. 依資料、操作權限與來源逐項處理

• 來源或授權不清楚：先暫停新增授權與敏感資料輸入，交由負責人釐清，必要時限制連線或停用。
• 用途明確但權限過大：在測試環境確認所需功能，再縮減權限並驗證流程。
• 用途、權限與責任都明確：保留紀錄，約定複查時間與異常處理方式。

若已懷疑發生事件，應同步保全紀錄並進行必要的遏止處置，避免將例行整理清單當成事件調查。

3. 把責任與撤回方式寫成文件

為每個保留的工具指定負責人，記錄如何聯繫、誰能撤回授權，以及異常時的處理順序。若採用同類工具共同管理，也應明確列出涵蓋項目。

編按 · Think BIG 的做法：讓部署可以逐項驗收

（以下為 Think BIG 的實作主張與建議。）

我們主張以「評估、建置、驗證、維運」安排 AI Agent 導入工作：

• 評估：先盤點工具、資料、執行身分與責任，再決定導入範圍。
• 建置：依實際需求設定權限，為重要操作約定人工覆核與撤回方式。
• 驗證：使用已知答案與明確任務測試，檢查回答出處、操作紀錄及權限邊界。
• 維運：在個別提案中列明服務範圍、期間、回應方式與費用，並約定紀錄複查及異常通報安排。

我們的主張是把「可以做什麼、誰核准、如何停下來」寫成可檢查的交付項目，讓導入與後續管理都有依據。

---

FAQ

Q1：這次報告中的 AI 自動化攻擊，值得注意的是什麼？

微軟記錄了 Storm-0940 使用 ARTEX 加速攻擊，以及多起從初始鎖定目標到取得雲端特權存取少於 3 小時的案例。[1] 這項觀察有其事件範圍，不能推論所有攻擊都已由 AI 自主完成。

Q2：中小型企業也需要盤點嗎？

建議同樣先確認工具、資料、權限與負責人，再依資料敏感程度與操作影響決定處理順序。盤點的人力、時程與技術協助，應按實際環境安排。

Q3：怎麼確認 AI 工具是否會把資料送出去？

建議把產品文件、權限設定、外部服務清單與執行紀錄放在一起核對，必要時請技術人員在測試環境觀察資料流向。調整權限後，也應重新驗證需要保留的功能。

Q4：員工自己裝的 AI 工具，該怎麼管理？

建議先定義可安裝的範圍、申報方式與敏感資料使用規則。對尚未釐清來源或授權的工具，先限制敏感資料輸入，再由負責人完成評估。

Q5：AI Agent 都會常駐並主動對外傳送資料嗎？

本文不將所有產品視為同一種部署方式。評估時請逐項確認：是否排程執行、可呼叫哪些工具、是否能寫入或對外傳送資料，以及哪些操作須經人工核准。

Q6：懷疑已發生相關攻擊時，可以先做什麼？

微軟建議保全相關登入與稽核紀錄、檢查服務主體活動及異常憑證或權限變更，並在確認可疑活動後撤回不必要的權限、輪替憑證。[1] 請由獲授權的處置人員依事件範圍執行，保全證據的同時不要延誤必要的遏止措施。