工程師在工作電腦上執行外部公司的面試作業，以為只是設定開發環境，沒想到惡意程式已經把 pyenv 執行檔換掉。幾週後，攻擊者開始使用這台遭入侵的電腦，並透過公司內部的 AI 工具控制其他工程師的電腦，最後取得容器部署 token。主管現在除了要問「這套 AI Agent 好不好用」，也得進一步確認：「一個帳號或端點（endpoint）失守後，攻擊者可以透過 AI Agent 進入哪些系統？」
這類攻擊方式稱為橫向移動（lateral movement）：攻擊者先入侵一個帳號或端點，再利用原有的權限、連線與信任關係，將攻擊範圍擴大到其他人員或系統。我們認為，企業導入 AI Agent 時，應先限制它可以看到哪些資料、連接哪些服務，以及執行哪些操作，確認沒有問題後再逐步擴大工作範圍。如果一開始就開放所有權限、連線與操作，等到出事後才回頭調整，一個端點失守就可能連帶影響更多系統。
AI Agent 能完成工作，也可能幫攻擊者進入更多系統
iThome 報導 Binance 公開的初步調查：駭客先透過遭變造的開發工具及假求職面試，入侵錢包工程師的工作電腦；10 月 20 日再使用遭入侵的電腦與內部 AI 工具，控制另外兩名錢包工程師的電腦，並找到具有容器部署權限的 token。10 月 30 日，駭客使用竊得的憑證部署容器、執行惡意腳本，接著侵入錢包簽章服務，最後從多個區塊鏈的熱錢包轉走約 63.4 億美元加密資產。
這份初步調查還沒有交代所有技術細節，因此不能把每一個步驟都推定為 AI Agent 自主完成。不過，事件已經讓管理上的問題變得很清楚：如果內部 AI 工具可以連接其他工程師的電腦、取得部署憑證或呼叫高權限服務，攻擊者只要取得一名使用者的帳號權限，就可能利用這名使用者原有的連線與權限，進入其他系統。換成台灣企業常見的情況，負責協助業務整理報價的 AI Agent，沒有必要同時讀取採購底價、修改客戶主檔，或取得正式環境的部署權限。
因此，企業應先盤點每個 AI Agent 由誰使用、屬於哪個單位、可以看到哪些資料、呼叫哪些服務，以及執行哪些操作，再依照盤點結果加強偵測措施。盤點時可以直接問：「如果這項權限遭到盜用，攻擊者下一步可以進入哪裡？」只要某項跨單位存取無法對應到明確的工作需要，就應先移除；部署、變更權限與對外傳送資料等高權限工作，則應交由專用角色執行，並在執行前由指定人員核可。
權限與連線預設關閉，有工作需要再開放
權限控管可以採用最小權限原則（principle of least privilege），也就是每位使用者與每個 AI Agent，只能取得完成當前工作需要的權限。企業需要分別檢查兩個層次：使用者登入後可以操作哪些功能，以及 AI Agent 代表使用者呼叫工具時，實際可以讀取或修改哪些資源。如果兩者共用的權限範圍太大，即使前台已經區分角色，後端操作仍可能超出工作需要。
EgentWrX 將前台與後台的權限分開設定，企業可依組織層級設定內建或自訂角色，並限制各單位的人員只能查看所屬單位及其子單位。企業可以透過這種設計，將一般使用權與後台管理權分開。不過，光是設定角色名稱並不能降低風險，導入團隊仍須逐一確認每個角色可以查看哪些資料、執行哪些操作，不能為了管理方便，就讓高權限長期保留下來。
連線也要採用相同的控管方式。企業應列出 AI Agent 需要連線的外部網域、內部資料庫與工具服務，預設一律拒絕，再依照業務需要逐項開放。以 EgentWrX 為例，出網白名單（egress allowlist）預設全部拒絕，對外網域必須逐一開放；企業也可以讓 AI Agent 經由公司內部網路讀取內部資料庫，而且資料庫整合只能讀取、不能寫入。這些機制可以減少 AI Agent 能接觸的資料與能改動的資源，但端點防護、憑證輪替及開發工具來源控管仍然不能省略。
評估系統時，不能只問「能不能串接」，還要請系統負責人提出連線清單、權限矩陣及高權限操作的核可流程。企業可以先選一項範圍明確的工作，例如讓客服查詢訂單狀態，或讓品管人員讀取檢驗規範；確認唯讀權限已足以完成工作後，再決定是否開放其他操作。
即使端點防護沒有發出警報，仍要查得到 AI Agent 做過哪些事
Binance 表示，端點防護軟體當時沒有偵測到惡意程式，攻擊者也掩蓋了入侵痕跡。公司先前雖然更換裝置並重設相關憑證，但工程師的職務及同事資訊已經外洩。事件發生後，Binance 重建受影響的錢包系統與內部 AI 工具、停用相關憑證，並表示將邀請獨立資安公司複查。這代表端點警報只能作為調查資料的一部分，企業不能因為沒有收到警報，就認定 AI Agent 沒有遭到濫用。
企業需要另外保留 AI Agent 的稽核軌跡，至少要能查出誰在什麼時間變更角色、開放哪一項連線、呼叫哪些高權限工具，以及誰下載過稽核紀錄。EgentWrX 的稽核日誌涵蓋 55 種資源類型，可從匯出中心匯出，並以雜湊鏈（hash chain）驗證紀錄是否遭到修改；管理者下載稽核紀錄的行為也會留下紀錄。這些紀錄可以協助企業追查事件與提出證據，但不能保證擋下所有攻擊。
企業應把 AI Agent 日誌正式納入資安事件處理流程，平時定期匯出並驗證紀錄是否完整；事件發生後，則把端點、身分、連線與 AI Agent 的操作紀錄排在同一條時間軸上比對。如果發現端點異常，除了更換電腦與重設憑證，也要檢查攻擊者可能接觸過的同事資訊、角色變更、既有工作排程與對外連線，確認沒有留下日後可再次利用的存取管道。
企業可以先安排一次演練：假設某位工程師的帳號失守，資安團隊能不能在當天列出受影響的 AI Agent、憑證、電腦與服務？如果有任何一項列不出來，就代表相關管理措施還需要補強。
