「惡意程式藏進 AI Agent，讓防毒軟體看不見」是醒目的警告，但更精確的說法是：Agent 把傳統惡意程式、軟體供應鏈攻擊與提示注入串成新的執行鏈，使只檢查檔案的防線看不見完整因果。真正的問題不是防毒全面失效，而是企業仍用保護單一端點的方式，管理一個能讀取外部內容、呼叫工具、存取雲端服務並自行採取行動的系統。
事件背景：一個標題涵蓋三種不同風險
TechCentral 引述卡巴斯基研究主管 Sergey Lozhkin 表示，2026 年前五個月，該公司偵測到逾 1.5 萬個偽裝成 ChatGPT、Claude 或 Gemini 用戶端及 Agent 的獨特樣本；攻擊者也會讓技能或外掛連到外部資源，再取得後續指令。原始報導見 https://techcentral.co.za/hackers-are-hiding-malware-behind-ai-agents-that-antivirus-cannot-see/284180/。
這裡首先要區分來源事實與新聞敘事。偽裝成 AI 軟體的下載檔，本質上仍可能是傳統木馬；遭竄改的 Python 套件是軟體供應鏈攻擊；藏在網頁、郵件或技能說明裡、誘導模型錯誤呼叫工具的內容，才屬於 Agent 特有的提示注入與目標劫持。三者可以互相接力，卻不能因為都出現在 AI 工作流程中，就統稱為一種新型「AI 惡意程式」。
攻擊為何能穿過既有防線
傳統特徵碼擅長比對已知惡意位元、檔案結構或指令；Agent 面對的卻可能是一段語意正常的文字，例如要求查閱文件、更新資料或連接某個服務。問題往往要到模型結合當下權限、機密資料與工具呼叫後才浮現。OWASP 將這類風險拆成直接或間接提示注入、工具濫用、資料外洩、記憶污染及供應鏈攻擊，並建議把外部文件、網站、郵件與 API 回應一律視為不可信輸入：https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html。
換言之，防毒產品可能看見最終落地並執行的惡意檔案，EDR 也可能從異常程序或連線發現跡象；它們較難單獨回答的，是「Agent 為何讀到這段指令、為何選擇這項工具，以及這次資料傳送是否符合原始任務」。這是可觀測性的缺口，而非所有防毒軟體都必然失明。
LiteLLM 事件提供了可交叉驗證的實例
原文提到 TeamPCP 入侵 LiteLLM。Datadog Security Labs 的獨立調查確認，2026 年 3 月 24 日，PyPI 上的 LiteLLM 1.82.7 與 1.82.8 被植入惡意程式；前者在使用特定模組時觸發，後者加入會在 Python 啟動時執行的 .pth 檔，可蒐集環境變數、SSH 金鑰、雲端與 Kubernetes 憑證等資料。調查全文見 https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/。
LiteLLM 專案的公開事件紀錄也表示，攻擊者取得維護者的 PyPI 帳號，發布未經官方 GitHub 發行流程產生的 1.82.7、1.82.8，之後專案移除受害版本並輪替維護者帳號：https://github.com/BerriAI/litellm/issues/24518。這項案例證明可信套件與自動更新鏈可能成為入口；但它是貨真價實的程式碼後門，不等於「純粹用提示詞就能躲過所有防毒」。
為何現在特別值得注意
作者的判斷是，風險增幅主要來自權限與速度，而不只是模型變聰明。一般聊天機器人主要輸出文字；Agent 則可能持有郵件、程式碼儲存庫、雲端平台或企業資料庫的權杖，並自動下載相依套件、執行程式及傳送資料。Microsoft 的 Agent 安全指引指出，每一段 Agent 對工具、服務或其他 Agent 的互動都會擴大攻擊面，並要求建立最小權限、確定性限制、人工核准與執行紀錄：https://learn.microsoft.com/en-us/security/zero-trust/sfi/manage-agentic-risk。
因此，同一個遭污染的技能若被大量複製，或同一個高權限 Agent 被接上多套內部系統，影響範圍會比單一員工下載可疑附件更快擴張。另一方面，若企業只封鎖 AI，使用者也可能轉向未納管的個人帳號與外掛；較務實的方向是縮小權限與爆炸半徑，讓每個動作可追溯、可中止。
容易忽略的證據限制
原文的「逾 1.5 萬個獨特樣本」來自卡巴斯基，未附偵測方法、去重規則、感染數、歷年比較基準或 Agent 與一般偽冒安裝程式的分類比例，因此只能支持「該公司觀察到大量樣本」，不足以單獨證明 Agent 注入攻擊的整體成長率。報導亦揭露記者由卡巴斯基招待前往活動現場；這不會自動推翻內容，卻意味著讀者應把廠商的趨勢判斷與可獨立驗證的事件分開看待。
另一個限制是，語意型攻擊沒有單一萬靈丹。OpenAI 公開說明指出，單靠在 Agent 與外部內容之間加入輸入分類器，未必能辨認經完整設計的提示注入；防禦目標應包括即使 Agent 受騙，也限制其可造成的結果：https://openai.com/index/designing-agents-to-resist-prompt-injection/。
對台灣企業的實際意義
對正在導入程式開發 Agent、客服自動化或內部知識助理的台灣組織，重點不是再買一套掛著「AI」名稱的掃描器，而是把 Agent 納入身分、供應鏈與事件應變制度：
- 建立 Agent、模型、技能、外掛、API 與資料來源清冊，指定負責人並鎖定核准版本；套件更新要驗證來源、雜湊與發行紀錄。
- 為 Agent 使用獨立、短效且最小權限的身分；讀取郵件不應順帶取得寄信、刪檔或部署正式環境的能力。
- 將執行環境沙箱化，對外連線採允許清單；金鑰不要長期放在 Agent 可讀取的環境變數或一般設定檔。
- 記錄輸入來源、技能版本、模型決策、工具參數、外連網域與執行結果；匯款、刪除、發布、權限變更等高衝擊操作保留人工核准。
後續應觀察什麼
比「攔到多少惡意提示」更有意義的指標，包括未經核准的技能安裝量、技能內容或套件雜湊漂移、Agent 新增外連網域、異常工具呼叫、短時間大量讀取機密、憑證在非預期位置被使用，以及從事件發生到停用 Agent、撤銷權杖的時間。若企業無法回答某個 Agent 昨天讀了什麼、用了哪些權限、把資料送到哪裡，就算端點掃描全部顯示正常，也仍未真正掌握這條新的攻擊鏈。