這起事件真正值得警戒的，不只是「AI 被一句話騙過」，而是文字指令一路穿越模型、程式執行環境與雲端帳號授權，最後變成遠端程式碼執行。當代理式 AI 從回答問題進化為能讀信、操作工具與執行程式的數位工作者，提示注入也從內容可信度問題，升級為身分與權限安全問題。
已知事件：惡意郵件如何走到程式碼執行
來源事實：OODA Loop 引述 Salt Labs 研究指出，Manus 存在間接提示注入弱點，攻擊者可藉此在目標使用者的環境中達成遠端程式碼執行；測試中，明文執行要求會觸發警告，但經 JSFuck JavaScript 混淆後，程式已先執行，警告才出現。原始報導見 https://oodaloop.com/briefs/cyber/prompt-injection-vulnerability-hits-4b-agentic-ai-platform-manus-ai/。
獨立資安媒體 Dark Reading 提供了更完整的攻擊鏈：研究人員先寄送含有「處理郵件時執行 whoami」之類指令的測試郵件；Manus 雖會提出安全警告，卻已把郵件內容當成可解讀的操作指令。研究人員改用多種編碼與混淆手法後，以 JSFuck 成功觸發基本負載，接著建立反向 Shell，並在環境中找到與第三方應用程式相關的憑證或權杖。報導列舉 Gmail、Dropbox、GitHub 作為可能受牽連的連接服務：https://www.darkreading.com/application-security/prompt-injection-bug-agentic-ai-app-manus。
機制核心：資料與命令共用同一條語意通道
傳統郵件系統把信件內文視為資料；代理式 AI 則必須理解內容，再決定是否呼叫工具。攻擊者不必直接登入受害者帳號，只要把命令藏在受害者之後會要求 AI 摘要或處理的郵件中，惡意內容便可能跟著正常工作流程進入模型。這就是「間接」提示注入：下指令者不是目前的使用者，而是外部資料的提供者。
合理推論：此事件的危險性來自三項能力疊加：模型會解讀外部內容、代理可操作完整運算環境、環境又可能接觸已授權服務。任何單一環節失守，未必立即造成重大損害；三者串連後，文字就可能轉換成系統命令，再轉換成資料存取。JSFuck 並非根因，而是證明只靠辨識可疑字串的防線可以被改寫形式繞過。
商業便利與安全風險其實來自同一設計
Manus 官方文件說明，連接器可存取第三方資料與 API，並直接在對話中執行工作流程；典型用途包含 Gmail 郵件摘要、GitHub 議題管理與資料庫查詢：https://help.manus.im/en/articles/12231777-how-can-i-use-manus-connectors。另一份官方文章則表示，Manus Sandbox 是具備網路、檔案系統、瀏覽器及軟體工具的隔離雲端虛擬機，甚至允許在沙箱內取得 root 權限：https://manus.im/blog/manus-sandbox。
這解釋了產品的商業吸引力，也解釋了攻擊面：使用者購買的不只是聊天介面，而是能代為完成工作的執行能力。報導所稱「40 億美元估值」只能反映市場期待，不能當成漏洞嚴重度指標；真正應衡量的是每個代理能讀取什麼、能執行什麼，以及憑證是否暴露在可執行環境內。
為何現在值得注意
OWASP 將「過度代理權」的根因歸納為功能過多、權限過大與自主程度過高，並明確指出直接或間接提示注入都可能觸發危險行為。其建議包括縮減工具功能與 OAuth 權限、讓高影響操作取得人工核准，以及由下游系統執行完整授權檢查，而不是交由語言模型自行判斷：https://genai.owasp.org/llmrisk/llm062025-excessive-agency/。
作者觀點：企業不應把「模型有安全警告」視為控制措施完成。若警告晚於執行，控制的是使用者感受，不是系統狀態。真正有效的邊界必須位於工具呼叫、作業系統、網路出口與第三方授權層，確保模型即使受騙，也沒有足夠權限完成攻擊鏈。
目前證據仍有哪些限制
- 公開資訊描述的是研究人員驗證的概念性攻擊，不能據此斷言已有大規模實際利用。
- Dark Reading 表示 Salt Labs 向 Manus 通報未獲回覆，之後由 Meta 的漏洞獎勵管道確認並修補；但公開報導沒有提供修補版本、部署範圍、CVE 編號或 Manus 的正式事件說明，因此不能自行推定所有使用者目前都已安全。
- Manus 官方宣稱沙箱不會影響其他任務或服務，且帳號資料不能直接由沙箱存取；研究報導卻指出可找到連接服務的憑證或權杖。兩者可能涉及不同邊界或事發前後狀態，在欠缺完整技術報告下，不宜把「取得沙箱 root」直接等同於攻陷使用者本機或 Manus 平台本身。
對台灣企業的實際意義
導入代理平台時，採購問題不能只停留在模型準確率與資料是否拿去訓練。企業應把代理視為擁有機器身分、OAuth 權杖與執行環境的新型特權帳號。郵件摘要、客服工單、程式碼代管及雲端硬碟尤其會接收外部內容，正是間接注入容易進入的入口。
最低限度應要求：讀取與寫入權限分離；不同工作建立不同代理身分；高風險命令在執行前核准；憑證不以可讀形式留在工作環境；限制網路出口目的地；完整記錄模型輸入來源、工具參數、核准者與执行結果。若供應商只能展示「偵測到可疑提示」，卻無法證明未授權動作會在執行層被拒絕，仍不足以承載正式營運資料。
後續應觀察的指標
- Manus 是否發布正式公告、受影響期間、修補內容與權杖輪替建議。
- 高風險工具是否改成執行前警告，並由模型之外的政策引擎強制攔截。
- 連接器是否提供細粒度、短效且可分工作撤銷的授權範圍。
- 沙箱能否阻止憑證讀取與任意對外連線，而不只是隔離不同使用者。
- 是否出現可驗證的實際攻擊通報，而非只有研究環境中的概念驗證。
這起事件的教訓不是停止使用代理式 AI，而是重新安排信任順序：外部內容永遠是資料，不應因模型「理解」它就取得使用者權限；模型可以提出行動，但能否執行，必須由可稽核、最小權限且獨立於模型的控制層決定。