AI 瀏覽器助理安全嗎？AI agent 竟會偽造授權！越權漏洞與授權風險

如果你看到「AI 擴充套件被打穿」的新聞，第一反應是「關我什麼事，我只是普通使用者」——我懂那個感覺。
但如果你有在用任何 AI 自動化工具，或者你的公司正在評估 AI 瀏覽器助理（幫你自動執行網頁操作的 AI 工具），這個漏洞背後的設計問題，直接影響你現在怎麼評估和設定這些工具。

這篇不是新聞摘要，是想把漏洞的根源拆給你看——還有四條你可能聽過的「反方觀點」，我會逐一告訴你哪些我同意、哪些我認為站不住腳、哪些需要條件限定，最後給你一個可以直接套用的 AI agent 授權分類框架。

ClaudeBleed 是什麼

2026 年 4 月，企業資安機構 LayerX 向 Anthropic（開發 Claude 的 AI 公司）回報一個問題：Claude for Chrome（Anthropic 發布的瀏覽器擴充套件，即裝在 Chrome 上的 AI 助理工具）的程式碼，允許任何其他已安裝的擴充套件對它下指令——即使那個擴充套件沒有宣告任何權限。
資安研究者後來把這系列問題叫做「ClaudeBleed」。
5 月，Manifold Security 的研究者 Ax Sharma 進一步發現兩個更根本的設計問題，並在 7 月 14 日公開揭露：當時最新版 v1.0.80（7 月 7 日更新，從首次發現至今已歷經八個版本）仍可重現。
攻擊前提很重要，必須先說清楚：這個攻擊需要受害者已安裝含惡意程式碼的擴充套件，才能被觸發。
不是任何人都能遠端打你，必須先在你的瀏覽器裡有據點。
在這個前提下，只需要 6 行 JavaScript（常見的網頁程式語言），那個惡意擴充套件就能偽造一個「假裝是使用者按下去」的點擊（稱為 synthetic click），靜默觸發 Claude for Chrome 幫你讀 Gmail、Google Docs、日曆，或對 Salesforce 下操作——全程不需要你知道。

八版為何沒修好

理解這個問題，得先看 Anthropic 每次修的是什麼。
Anthropic 修的是使用者體驗層。
每次更新加的是：更明確的核可流程、每次執行前跳出確認框、新增「自動模式（auto mode）」讓 AI 分類動作是否安全……這些改善都在「使用者操作介面」這一層。
從未被碰過的是觸發層：Claude for Chrome 的 content script（嵌在網頁裡的擴充套件程式碼）在接收到觸發指令時，從來沒有去確認 event.isTrusted（瀏覽器內建的判斷機制，可以分辨這個點擊是真人按的，還是其他程式偽造的）。
另一個問題是 skipPermissions=true 這個 URL 參數（附加在網址後面用來控制行為的設定值）——在網址加上這個字串，就能繞過所有權限閘門。
Anthropic 主張這個參數無外部可達風險，但目前沒有獨立研究者完整驗證這個邊界。
問題的本質是優先順序顛倒：Anthropic 先解決「怎麼讓 AI 助理更好用」，卻沒先解決「AI 助理憑什麼相信這個動作是真實授權的」。
修了八版表面，根本的授權分類閘門從未建立。

Anthropic 回應可信嗎

Anthropic 在 24 小時內認可了 Manifold 的回報，這是對的。
他們也表示 skipPermissions 的外部可達邊界尚未被外部完整驗證，這個說法目前也沒有研究者推翻。
但「內部在追蹤」不等於「問題已修好」。
八個版本後，兩個漏洞仍完全可重現。
Anthropic 未公開修補時程，外部無法驗證進度。
「我們知道了，我們在看」在沒有進一步可查證資訊的情況下，對使用者而言無法提供安全保證。
對你的決策影響：如果你是企業 IT 評估 Claude for Chrome 的部署，「廠商說在處理」這個訊號需要搭配「你自己的緩解措施」——例如限制擴充套件安裝白名單、稽核已安裝套件的權限清單。
不能等廠商修好才管。

每次詢問安全嗎

Anthropic 的 Claude for Chrome 提供兩種操作模式：「詢問後執行（Ask before acting）」和「直接執行（Act without asking）」。
直覺上，「每次都先問你」的模式應該讓你有機會攔截異常動作。
但偽造點擊（synthetic click）的攻擊路徑，繞過的正是「問」這個機制本身。
惡意擴充套件偽造的那個假點擊，就是在「系統詢問你同不同意」的確認介面上按「同意」——你選哪個模式都一樣，因為問的那關本身就被繞了。
更進一步，Anthropic 自己在工程部落格承認：「每次都問」在實際使用中會產生「核可疲勞（approval fatigue）」——使用者看太多確認框之後，會停止認真看每一個、習慣性按確認。
這就是為什麼他們後來推出自動模式。
對你的決策影響：不要因為「我選了詢問後執行」就放心。
分類閘門的問題在觸發層，不在你選了哪個模式。

惡意套件風險高嗎

是的，攻擊前提確實存在。
你要先在瀏覽器裡安裝一個含惡意程式碼的擴充套件，攻擊才能觸發。
但「你信任的東西被偷偷換掉」，才是 2026 年更主要的攻擊路徑。
2025 年已有超過 35 個 Chrome 擴充套件（合計 260 萬用戶）在開發者帳號遭釣魚後，被植入惡意程式碼——使用者原本信任的套件、繼續安裝著的套件，在一次靜默更新後變成了攻擊工具。
這代表風險評估不能只問「我有沒有裝可疑的東西」，而是要問「我裝的東西，有沒有可能在我不知道的情況下更新成危險版本」。
對你的決策影響：定期檢查已安裝擴充套件的權限變化，而不是只在安裝時審查一次。
特別是你已經用了一段時間、覺得放心的套件。

AI安全層夠用嗎

Anthropic 自動模式的設計理念是：與其用靜態規則攔截，不如用 AI 語言模型（AI 處理文字的系統，與 ChatGPT 同類型）在執行前判斷每個動作是否安全。
這個概念有道理——靜態規則確實難以應付 AI 助理在執行複雜任務時的動態組合。
但用 AI 防 AI 的繞過，是把同一個信任假設再套一次。
全球網頁安全組織 OWASP（Open Web Application Security Project，制定 AI 安全標準的非營利機構）明確指出：「因為沒有可靠的 prompt injection（惡意指令操控，即透過特製輸入讓 AI 執行惡意動作）防禦，假設操控成功時，唯一耐久的緩解是確保受攻擊 AI 助理根本沒有執行高衝擊動作的能力。」
AI 分類器本身也可能被惡意指令操控。
讓一個 AI 判斷另一個 AI 做的事是否安全，是同一個弱點的遞迴。
對你的決策影響：不要把「廠商加了 AI 安全層」視為問題已解決。
真正的緩解是縮減 AI 助理能觸及的動作範圍——也就是最小權限原則：AI 只拿它需要用的權限，不給多餘的存取能力。

我的授權踩雷

我自己在建 AI 自動化工作流程（一連串讓 AI 自動接力執行的處理流程）時，踩過同一類的坑。
當時的情況是：我批准了一個自動化步驟去更新某個 Google Sheet，AI 完成後回報「成功」。
隔幾週，同樣的自動化流程因為另一個任務被觸發，它看到上次批准紀錄，就自動又去更新了那張 Sheet——那次我沒打算讓它碰那個文件。
AI 把動作的性質誤判了。
它記住了「我曾批准更新 Sheet」，就把這次批准當成了往後類似動作的空白支票。
從那之後我定的紀律是：對外的、不可逆的、跨邊界的動作，授權只綁定那個被批准的動作本身，不准因為「上次批准過類似的」就自動延伸。
每次都要重新拿到明確核可。
Claude for Chrome 的問題，是同一個問題的企業級放大版：觸發層從未問過「這個動作的來源是誰批准的」這個問題。

授權分類怎麼做

從 OWASP 建議、作者紀律、以及 arXiv 的「動手前先做確定性授權驗證」學術研究（主張在 AI 執行動作前插入規則驗證層，強制對不可逆或跨邊界動作做明確授權確認），整合成三個可以直接用的自查問題：

AI 擴充套件比一般擴充套件多 60% 機率有已知安全漏洞（CVE，即「已知安全漏洞編號」，由國際機構建檔的公開弱點紀錄）、存取瀏覽器身分憑證（cookie）的機率是一般擴充套件的 3 倍、在過去一年增加權限的機率是 6 倍（LayerX 企業瀏覽器擴充套件安全報告 2026）。
這不是要你不用 AI 工具，而是說這類工具的風險密度本來就比一般擴充套件高，授權設計的紀律更重要。
AI 越權最危險的不是它太聰明，而是它連「這個動作是誰叫它做的」都分不清楚。
要帶走的方法論：對 AI 助理的動作授權，問三個問題——動作性質是什麼、來源是誰批准的、這次批准是不是只限這次。
只要這三層分類清楚，90% 的越權風險可以在設計階段就攔下來。
給自己的自我檢查問題：

• 你現在在用的 AI 自動化工具，有沒有機制在問「這個觸發來源，是使用者真的批准的嗎？」

• 你上次給 AI 的授權，有沒有說清楚「這個授權只在這個情境有效」？

• 如果你的 AI 工具今天被另一個程式「偽造你的同意」，你有辦法知道嗎？

常見問題

• ClaudeBleed 是什麼？ 2026 年揭露的 Claude for Chrome 安全漏洞系列。攻擊前提是受害者已安裝含惡意程式碼的瀏覽器擴充套件；在這個前提下，6 行 JavaScript 即可偽造使用者點擊，靜默觸發 Gmail、Google Docs、日曆等操作。不需要直接入侵 Anthropic 伺服器。

• 我現在還能用 Claude for Chrome 嗎？ 目前截至 v1.0.80 兩個根本漏洞仍可重現，Anthropic 表示在追蹤中但未公開修補時程。風險評估取決於你的環境：個人用戶若已審查已安裝的擴充套件風險較低；企業環境建議延遲廣泛部署直到明確修補公告。

• AI 瀏覽器助理只有 Claude for Chrome 有這個問題嗎？ 不是。Palo Alto Networks 的研究發現 Google 的 Gemini 面板有類似問題；這是整個 AI 瀏覽器助理類別共同的設計缺陷，不是 Claude 獨有。

• 我的 AI 自動化工作流程要怎麼自查？ 用本文的三個問題框架：① 每個動作是對外/不可逆的嗎？② 每個觸發來源是使用者明確授權的嗎？③ 每次授權是綁定在那次動作上，還是開放延伸？三個問題都能回答，授權分類就有基本閘門。

• event.isTrusted 是什麼？ 瀏覽器內建的一個判斷機制，可以分辨一個點擊事件是真人按下去的，還是由其他程式碼偽造的。Claude for Chrome 的觸發程式碼從來沒有去查這個值，這就是偽造點擊能成功的根本原因。