資安業者 Sophos 分析 2026 年 6 月間七天的 Windows 端點遙測後發現，AI 編碼代理程式正在大量產生過去被視為高風險的行為，包括使用 DPAPI 解密瀏覽器資料、列舉 Windows Credential Manager、透過 certutil 與 bitsadmin 下載檔案，以及把腳本寫入啟動資料夾。
我的看法是：這不是單純的 EDR 誤報問題，而是 AI 代理程式的權限模型落後於它的能力。
我們不能因為父程序叫做 claude.exe、cursor.exe 或 Codex，就把後續行為全部視為安全；同樣地，也不能因為代理程式使用 PowerShell 或系統內建工具，就直接認定它是攻擊者。真正需要判斷的是：它取得了什麼資料、使用了什麼能力、命令從哪裡來，以及失控後會造成什麼後果。
Sophos 看到的不是惡意程式，而是「行為重疊」
根據 Sophos X-Ops 的原始分析，七天內被阻擋的代理程式活動中，Credential Access 佔 56.2%，Execution 佔 28.8%。其中最常見的 Credential Access 規則，偵測的是程序透過 Windows Data Protection API（DPAPI）解密瀏覽器保存的敏感資料。
例如，代理技能套件 GStack 的 /browse 技能會啟動瀏覽器自動化流程，並以 PowerShell 呼叫 DPAPI。從使用者角度來看，這可能只是要求代理程式操作既有登入狀態；但對端點防護引擎而言，它看到的行為與憑證竊取工具沒有本質差異。
其他案例更值得警惕：
- Claude Code 結束正在執行的瀏覽器程序，再以 Python 腳本存取瀏覽器的憑證資料。
- Claude Code 執行
cmdkey.exe /list，列舉 Windows Credential Manager 內的憑證。 - OpenAI Codex 嘗試從官方
python.org下載安裝程式；certutil遭阻擋後，改用bitsadmin重試。 - Cursor 使用 PowerShell 將 VBScript 寫入 Windows Startup Folder，觸發持久化偵測規則。
這些案例最值得注意的不是單一命令，而是代理程式展現出的「遇阻轉換」能力。過去，安全團隊常用這種行為區分靜態腳本與真人攻擊者：某一種方法被阻擋後，操作者會理解錯誤、選擇替代工具並繼續完成目標。現在，良性的 AI 代理程式也具備相同行為。
flowchart LR
A[使用者提出開發任務] --> B[AI 代理規劃步驟]
B --> C[讀取專案與外部內容]
B --> D[執行 PowerShell／Python／系統工具]
B --> E[下載套件與操作瀏覽器]
D --> F{行為偵測}
E --> F
F -->|允許| G[完成任務]
F -->|阻擋| H[代理改用替代工具]
H --> D
C --> I{輸入是否可信？}
I -->|遭污染| J[代理可能替攻擊者執行命令]
這不代表 EDR 規則壞了
Sophos 的結論很合理：當 PowerShell 解密瀏覽器憑證、程序列舉 Credential Manager、未知腳本建立開機持久化時，偵測規則本來就應該觸發。危險行為不會因為執行者是 AI 就自動變得安全。
如果安全團隊為了降低告警量，直接把所有 AI 編碼工具及其子程序加入白名單，反而會建立一條非常乾淨的繞過路徑。未來無論是惡意提示、遭污染的 Repository、MCP 工具輸出、Issue、README、Log 或網頁內容，只要能誘導受信任的代理程式執行命令，就可能借用這份白名單避開偵測。
因此，我不贊成以下兩種極端做法：
- 因為 AI 代理產生誤報，所以全面信任代理程序。
- 因為代理行為像攻擊，所以全面禁止所有自主操作。
第一種做法犧牲安全，第二種做法犧牲工具價值。真正需要改變的是企業對代理程式的身分、權限與執行上下文設計。
AI 代理不是 IDE 外掛，而是新的非人身分
傳統 IDE 主要替使用者編輯文字；編碼代理卻可以讀取大量檔案、啟動 Shell、安裝相依套件、操作瀏覽器、呼叫雲端 API、建立 Commit，甚至連接 MCP Server。這些能力更接近一名擁有本機終端機的工程師，而不是自動完成工具。
我會用下面的概念式評估代理風險：
代理風險 ≈ 使用者權限 × 工具可達範圍 × 自主程度 × 不受信任輸入量
目前常見的部署方式，幾乎把四個乘數同時拉高：代理程式沿用開發者帳號、能存取整台工作站、可以自動核准命令，還會讀取外部 Repository、Issue、文件、網頁與錯誤追蹤內容。
這也是為什麼 --dangerously-skip-permissions 特別危險。它不只是省略幾次確認，而是移除代理程式在「理解錯誤、輸入遭污染或工具輸出被操控」時的重要阻斷點。
我的建議：不要按產品名稱放行，要按能力分級
企業可以把 AI 代理行為分成三個層級，而不是只問「這是不是已核准的 AI 工具」。
| 行為層級 | 例子 | 建議策略 |
|---|---|---|
| 可調整噪音 | 在工作區產生檔案、從可信套件來源下載、失敗後改用另一個一般工具 | 依父程序、工作區、目的網域、檔案簽章與 Hash 進行情境式降噪 |
| 高風險操作 | DPAPI 解密、cmdkey /list、讀取 SSH／雲端金鑰、修改系統設定 |
保留阻擋或要求即時核准，不因代理身分自動放行 |
| 持久化與控制面變更 | 寫入 Startup Folder、建立排程工作、修改防火牆、停用 EDR、建立新管理者 | 預設拒絕並升級為高優先事件 |
重點是「情境式降噪」，不是程序白名單。例如 Codex 從 python.org 下載具有有效簽章的 Python 安裝程式，和它從新註冊網域下載未知執行檔，雖然都可能使用 certutil，風險顯然不同。
然而，代理程式嘗試解密瀏覽器憑證時，即使目的是自動化登入，也不應直接繼承使用者的完整憑證存取能力。應改用專用瀏覽器 Profile、短效 Session、範圍受限的 Token 或人工完成登入後的隔離工作階段。
企業落地時應建立五道邊界
1. 身分邊界：代理與開發者分開
- 不讓代理程式直接沿用開發者的全部雲端、Git 與本機管理權限。
- 使用獨立服務身分、短效憑證與細粒度 Scope。
- 不把瀏覽器密碼、SSH Key、雲端 Access Key 與生產環境憑證暴露給一般代理工作階段。
- 為代理操作建立可撤銷、可追蹤的 Session Identity。
2. 執行邊界：把工作放進可拋棄環境
- 優先在 Sandbox、容器、虛擬機或臨時開發環境執行代理任務。
- 只掛載任務需要的 Repository 與目錄，不直接暴露整個使用者家目錄。
- 將作業系統控制面、Startup Folder、排程工作與安全產品設定設為不可寫入。
- 任務完成後銷毀環境，避免代理建立的持久化或殘留憑證繼續存在。
3. 網路邊界：限制代理能把資料送去哪裡
- 透過 Egress Proxy 或防火牆限制目的網域與傳輸協定。
- 套件下載優先經過企業 Artifact Repository，而非任意連向網際網路。
- 對原始碼、Secrets、個資與大型壓縮檔的外傳建立 DLP 或流量異常偵測。
- MCP Server 與外部 API 應逐一註冊、驗證與稽核。
4. 資料邊界：把外部文字當成不受信任輸入
Repository 內的 README、Issue、錯誤訊息、Sentry 事件、網頁與套件說明，對代理程式而言既是資料，也可能被解讀成指令。企業應明確區分使用者指令與外部內容，對從不受信任輸入衍生的命令提高核准層級。
尤其在程式碼審查與弱點掃描情境中，代理程式本來就會接觸攻擊者可控制的內容。若它同時具備自主執行能力，資安掃描工具本身就可能成為攻擊入口。
5. 偵測邊界：保留完整因果鏈
安全團隊不能只記錄最後執行的 powershell.exe。至少要能回答：
- 哪一個代理工作階段發起這條命令？
- 使用者原始任務是什麼？
- 命令是否來自 README、Issue、Log、網頁或 MCP 回應？
- 使用了哪些檔案、憑證、網域與工具？
- 前一個方法為何失敗，代理又為何選擇替代方案？
只有把 Prompt、工具呼叫、父子程序、檔案來源與網路目的地串成同一條因果鏈，SOC 才能區分合理的自動化與遭劫持的代理行為。
給技術主管的檢查清單
在企業擴大導入 AI 編碼代理前，我認為至少要能回答以下問題：
- 代理程式目前是否直接繼承工程師的本機與雲端權限？
- 代理能否讀取瀏覽器密碼、Credential Manager、SSH Key 或正式環境 Secrets？
- 代理遭到命令阻擋後，是否可以無限制地更換工具重試？
- 團隊是否使用略過權限確認或自動核准模式？
- EDR 是否只是白名單代理父程序，還是會評估子程序、資料來源與操作後果？
- 發生事件時，SOC 能否還原某條系統命令是由哪一段外部內容誘發？
只要其中一項沒有答案，就不應把代理程式視為單純的個人生產力工具。它已經是企業執行環境裡一個需要正式治理的新身分。
結語：正常行為正在被重新定義
Sophos 也強調，這次分析只有七天資料，應被視為初步訊號，而非整個產業的統計定論。但趨勢已經十分清楚：原本高度集中在攻擊者身上的行為，正在被良性的 AI 代理大量採用。
這不代表行為偵測失去價值。相反地，它要求安全團隊從「看到某個命令就判定惡意」，進化為「理解哪個身分、基於什麼輸入、在什麼邊界內、為了什麼目標執行命令」。
AI 代理與攻擊者的行為可能越來越像，但企業不必猜測它的內心。只要限制它的能力、隔離它的資料、記錄它的因果鏈，並控制它能造成的後果。
真正的問題從來不是代理程式看起來像不像駭客，而是我們是否給了它一名駭客夢寐以求的權限。