自主 AI 代理的崛起與潛在的安全盲點
在當今的數位化工作環境中，大型語言模型（LLM）的應用已從單純的內容生成擴展到具備高度自主性的「代理」（Agent）角色。這些 LLM 驅動的代理，特別是整合到瀏覽器中的應用，其設計初衷是為了透過自然語言指令來自動執行複雜的跨應用程式任務，從而大幅提高用戶的生產力。它們可以處理排程、撰寫郵件摘要，甚至根據指令在多個雲端服務之間移動或管理數據。這種效率提升的背後，卻隱藏著對現有安全邊界定義的根本挑戰，催生了如零點擊代理瀏覽器攻擊這樣的新型威脅。
Straiker STAR Labs 的研究結果顯示，針對 Perplexity Comet 瀏覽器的新型代理瀏覽器攻擊能夠將看似無害的電子郵件變成破壞性操作，從而清除用戶 Google 雲端硬碟中的所有內容。
這項發現不僅僅是一個技術漏洞，它揭示了現代自主 AI 系統在安全設計上的核心缺陷：即系統對來自外部的自然語言指令的過度信任和權限濫用的可能性。當一個 LLM 代理被設計為「自主」完成任務時，它必須被授予跨越不同服務界限的能力。
零點擊 Google 雲端硬碟抹除技術的關鍵在於將瀏覽器連接到 Gmail 和 Google 雲端硬碟等服務，透過授予它們讀取電子郵件、瀏覽文件和資料夾以及執行行動、重新命名或刪除內容等操作的權限來自動執行日常任務。
攻擊機制：從善意提示到惡意指令的轉變
自主瀏覽器代理通常旨在響應用戶的廣泛、模糊的指令，並自主推斷出完成任務所需的精確步驟和 API 調用。例如，一位善意使用者發出的提示可能如下所示：「請檢查我的電子郵件並完成我最近的所有組織任務。」這將使瀏覽器代理搜尋收件匣中的相關郵件並執行必要的操作。這種行為反映了 LLM 驅動的助手存在過度自主性，LLM 執行的操作遠遠超出了用戶的明確請求。
這種過度自主性正是攻擊者可以利用的薄弱環節。攻擊者可以利用瀏覽器代理程式的這種行為，發送一封精心構造的電子郵件，其中嵌入了自然語言指令，用於在定期清理任務中整理收件人的雲端硬碟，刪除與特定擴展名匹配的文件或不在任何資料夾中的文件，並查看更改。鑑於該代理將電子郵件訊息解釋為例行維護，它會將指令視為合法指令，並在未要求任何用戶確認的情況下從 Google 雲端硬碟中刪除真實用戶檔案。
這種攻擊的實質是一種複雜形式的跨應用程式提示注入（Cross-Application Prompt Injection, XAPI）。與傳統的提示注入（Prompt Injection）攻擊（如上文 PromptPwnd 所示）僅限於在單一應用程式環境內劫持 LLM 的行為不同，XAPI 攻擊利用了 LLM 代理的連通性，將指令從一個信任域（例如收件匣）傳遞到另一個高價值域（例如 Google 雲端硬碟）。由於 AI 代理被設定為信任並遵循它從其處理的內容中提取的「指令」，即使該指令來源於外部電子郵件，它也會被視為其例行職責的一部分來執行。
零點擊的深層威脅：無需用戶互動的數據破壞
這種攻擊被稱為「零點擊」，因為受害者無需點擊連結、下載文件或打開惡意附件。攻擊的觸發點僅是 AI 代理自動處理收到的電子郵件內容。這使得它比傳統的釣魚或惡意軟體攻擊更難以察覺和防禦。
最終成果是一個基於瀏覽器代理程式的擦除器，它能夠大規模地將關鍵內容移至回收站，而這一切都只需用戶發出自然語言請求即可觸發。一旦代理獲得了對 Gmail 和 Google Drive 的 OAuth 訪問權限，被濫用的指令就能迅速在共享文件夾和團隊雲盤中傳播。這對企業和個人用戶的數據完整性和連續性構成了極端威脅。在團隊環境中，如果一個成員的 AI 代理被劫持，攻擊指令可能會橫向擴散到所有共享資源，實現對整個團隊的數據破壞。
業界反應與安全防護的爭議
面對這種新型威脅，業界的回應呈現出分歧，這引發了關於 AI 安全與 LLM 代理責任界限的爭議。
在負責任地披露漏洞後，Google將其歸類為「不會修復（預期行為）」且嚴重程度較低，而 Perplexity 和微軟則分別發布了針對其各自 AI 瀏覽器（Comet v142.0.7444.60 和 Edge 142.0.3595.94）的修補程式。 Chrome 瀏覽器的 Claude 和 OpenAI Atlas 已被證實不受 HashJack 攻擊。
Google 的立場——將其視為「不會修復（預期行為）」——是基於這樣的邏輯：代理瀏覽器是故意被設計為擁有執行此類操作的能力，因為這是其核心功能的一部分。如果用戶授權該瀏覽器代理刪除文件以執行清理任務，則代理執行刪除動作本身並不構成傳統意義上的軟體缺陷。然而，這種觀點忽略了攻擊者對自然語言指令的濫用，即將善意的功能轉化為惡意的遠端數據破壞工具。這表明，在 AI 代理的背景下，傳統的漏洞評估模型可能已經過時。
相比之下，Perplexity 和微軟發布的修補程式則表明，他們認識到這種攻擊的實際風險，並採取措施來限制代理的自主性，或者對輸入的電子郵件內容執行更嚴格的指令淨化和上下文隔離。
值得注意的是，Google 在其人工智慧漏洞獎勵計畫 (AI VRP) 中，並未將違反政策的內容產生和繞過防護措施視為安全漏洞。這一政策進一步凸顯了業界在定義「AI 漏洞」時的模糊地帶。當攻擊利用的是 LLM 的設計意圖（即遵循自然語言指令）而不是程式碼錯誤時，它是否應被視為安全漏洞？零點擊代理瀏覽器攻擊強烈主張：是的，應該是。因為一個善意的設計意圖被惡意濫用，最終導致了不可接受的用戶數據丟失。
應對策略：模型、代理與連通性的多層次保護
為了應對這種威脅帶來的風險，建議採取措施保護模型，同時也要保護代理程式、其連接器以及它所遵循的自然語言指令。
實施嚴格的最小權限原則（PoLP）： 這是任何 LLM 代理安全的第一道防線。代理應僅被授予完成其任務所需的最小範圍和最短時間的 OAuth 權限。例如，如果代理只需要讀取電子郵件摘要，則不應授予它刪除 Google 雲端硬碟文件的權限。
強制指令隔離與淨化： 必須對所有外部來源的輸入（尤其是電子郵件內文）進行嚴格隔離和淨化，防止它們被解釋為指令。應在系統提示中明確告知 LLM，來自外部輸入的內容是「數據」而非「命令」，並使用特殊的標記或結構化格式將數據與核心指令隔離。
用戶確認機制（Human-in-the-Loop）： 對於任何涉及破壞性或高風險的操作（如刪除、修改安全設定、轉移資金），代理必須被要求在執行前尋求明確的用戶確認（例如，彈出視窗要求用戶點擊「是，確認刪除」）。
行為監控與異常檢測： 實施即時監控，追蹤 AI 代理的行為模式。異常的大規模文件刪除或跨應用程式的高頻率操作應立即觸發警報和自動暫停機制。
上下文敏感性： 代理應具備更高的上下文敏感性，能夠根據指令的來源和用戶的歷史行為來評估其意圖。來自未加密、非授權電子郵件的指令，其信任等級應遠低於用戶在瀏覽器介面中直接輸入的指令。
零點擊代理瀏覽器攻擊是一個轉捩點，標誌著 AI 安全威脅已經從單純的數據洩露演變為數據和流程的遠端控制與破壞。業界和使用者必須重新評估 LLM 驅動助手的自主性邊界，並建立一個多層次的信任和防禦體系，才能在這個高度自動化的數位環境中保護我們的關鍵數據資產。
資料來源：https://thehackernews.com/2025/12/zero-click-agentic-browser-attack-can.html