許多企業開始嘗試部署 AI Agent（AI 代理人），讓它能讀取郵件、操作工具並自動執行任務。然而，近期針對熱門自託管 AI Agent 框架 OpenClaw 的研究揭露了一個核心問題：當 AI 擁有「讀取私密資料」、「接收外部輸入」以及「對外發送資訊」這三項權限時，它就變成了一個極高風險的攻擊向量。
如果我們把 AI Agent 想像成一名剛入職、權限很高但缺乏經驗的初級員工，他會非常努力地想幫忙，但卻完全沒有分辨「這是不是陷阱」的直覺。這正是目前 AI Agent 安全性的最大漏洞。
隱藏在資料中的指令：Prompt Injection 的變體
安全公司 Imperva 發現了一種巧妙的攻擊方式。通常我們聽到的 Prompt Injection（提示詞注入）是指在對話框輸入惡意指令，但這次攻擊是將指令「埋」在非對話的資料物件中，例如 vCard（電子名片）、共享聯絡人或地點標記。
問題出在 OpenClaw 處理資料的邏輯。當 Agent 接收到一個聯絡人資訊時，它會將該物件「扁平化」成純文字直接餵給底層的 LLM（大型語言模型）。例如，它會將聯絡人姓名轉換為 <contact: name, number> 這樣的格式。
攻擊者可以利用這一點，在姓名欄位中填入惡意指令。由於模型無法分辨哪裡是真正的姓名、哪裡是指令，加上這些資訊在手機或 App 介面上會被截斷，使用者完全看不到隱藏的攻擊碼，但 AI Agent 卻會照單全收。在測試中，這種方式成功誘導 Gemini 3.1 Pro 下載並執行攻擊者的惡意指令碼。
社交工程的新形態：Agent Phishing
另一家安全公司 Varonis 則提出了 Agent Phishing（代理人釣魚）的概念。這與 Prompt Injection 不同，它不依賴於隱藏指令，而是使用「看起來很正常」的請求來欺騙 AI。
研究團隊建立了一個擁有 Gmail 存取權限的 Agent，結果發現即使設定了「驗證發件人」的嚴格規則，AI 依然會被社交工程攻破。例如，一封偽裝成團隊主管、聲稱生產環境發生緊急事故並要求提供 Staging 權限的郵件，就能讓 AI 主動將 AWS IAM 密鑰、資料庫連線字串等敏感資訊發送到外部地址。
這揭露了一個關鍵事實：AI Agent 在處理技術性威脅（如辨識惡意 URL 或偽造登入頁面）時表現優於人類，但在處理「社交判斷」（例如：主管在深夜要求密鑰是否異常）時，表現遠低於人類。
權限過大的致命組合
這兩類攻擊之所以能成功，是因為 OpenClaw 具備了所謂的「致命三要素」： 能讀取私密資料（如郵件、文件）。 能接收不受信任的外部內容（如外部來信、聯絡人）。 能將資料傳送到外部（如發送郵件、呼叫 API）。
當這三者結合，且缺乏強大的隔離機制（Sandbox）時，AI Agent 就成了一個完美的跳板。此外，研究還發現 OpenClaw 在某些插件中使用「顯示名稱」而非「唯一 ID」來驗證白名單，這導致攻擊者只要將自己的名稱改成白名單內的用戶，就能輕易繞過權限控管。
工程實務上的防禦建議
對於開發或部署 AI Agent 的工程師，不能將「提示詞（Prompt）」視為唯一的安全防線，而應從架構層面採取控制措施：
第一，將指令與資料分離。不要將外部輸入直接扁平化到 Prompt 中，而應將其放入獨立的元數據通道（Metadata Channel），明確告知模型這是不可信的內容。
第二，建立出站閘道（Outbound Gate）。限制 Agent 對陌生地址發送資訊的權限，所有首次發送或高風險發送必須經過人工審核。
第三，實施最小權限原則。根據觸發任務的來源決定權限。例如，處理外部郵件的流程不應擁有讀取整個 CRM 資料庫的權限。
第四，高風險操作必須有人類在迴路中（Human-in-the-Loop）。涉及金流轉移、密鑰發送或刪除資料等操作，絕對不能由 AI 自主決定。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。