把密碼存瀏覽器、又讓 AI 開瀏覽器，這樣安全嗎？
前幾天一個剛開始用 AI 寫程式的學妹問我一個很好的問題：她讓 AI 直接開她的瀏覽器做事，可是密碼都存在瀏覽器裡，這樣到底安不安全？ 我覺得這個問題值得拆成兩層來看，因為大家常常把它們混在一起擔心。認真查完之後，我把答案做成了一個開源工具，文末會介紹。 第一層：密碼存在哪裡 這層其實好解決。不管你是用 Apple 鑰匙圈還是 Bitwarden，只要是專門的密碼管理器，加上重要帳號都開了兩階段驗證（2FA），密碼本身就是安全的。別把密碼記在記事本、別用同一組打天下，這層就過關了。 順帶一提，如果你是把密碼存在 Chrome、靠 Google 帳號同步，要小心：只要有人能登入你的電腦帳號，就能把你存的密碼全部看光，這其實滿危險的。學妹用的是鑰匙圈，這層沒問題。 第二層才是重點：你讓 AI「控制」了你的瀏覽器 這代表它是用你已經登入的身分在操作。你的網銀、你的信箱、你的券商，對它來說都是開著的門。 我用的那套是 Kimi WebBridge。工具本身通常是乾淨的，我實際查過它的控制端：daemon 只綁在本機 127.0.0.1，區網或外網的其他機器連不到；沒有任何對外連線，不會把資料往外送；帶惡意來源的網頁想從瀏覽器裡偷呼叫它，會被擋掉。這部分可以放心。 真正的風險是另一件事，叫 prompt injection：AI 拿著你的登入身分，萬一去讀到一個藏了壞指令的網頁，有可能被牽著鼻子走。它不是被駭，它是太聽話。而它手上握著你所有登入中的網站。 平心而論，這類 AI（像 Claude）本身對 prompt injection 是相當警覺的，最近甚至容易反過來疑神疑鬼、動不動覺得自己被下指令了。但與其把要害帳號的安全全押在它每次都判斷正確，不如多加一道機械上的鎖：把最要命的幾個網站（網銀、券商、Gmail）直接擋在 AI 碰不到的地方，讓它就算被騙也走不進去，其他日常網站照常幫我做事。 直覺的做法沒有用：網站存取權白名單 瀏覽器的擴充套件設定裡有一個「網站存取權」，可以把擴充限制成「只能在特定網站」運作。直覺上把它設好就安全了。 實測結果：攔不住。設好白名單之後，叫 AI 開一個清單外的網站，它照樣進得去、讀得到內容、跑得了 JavaScript。 原因在技術層：這類 AI 瀏覽器控制工具走的是瀏覽器的偵錯介面（chrome.debugger API）在驅動頁面，而「網站存取權」那層設定只管一般的內容注入，管不到偵錯介面。所以那個設定頁面會讓你以為有圍籬，實際上這類工具根本不從那道門走。 順帶說明一下，不是每套工具都這樣：像 Claude in Chrome 是逐個網站問你同意的設計。但只要擴充的權限清單裡有 debugger（WebBridge 這類全站授權的工具就是），逐站白名單就是裝飾品。 真正有效的那道鎖：瀏覽器政策層 往下挖一層，答案在企業環境常用的瀏覽器政策（policy）：ExtensionSettings 裡的 runtime_blocked_hosts，可以對指定的擴充封鎖指定的網站。 這道是真的擋得住的。我把自己的網銀、券商、Gmail 一共 13 個登入網址設進去實測：AI 一碰被封的網站就直接吃到 Cannot attach to this target，連頁面都讀不到；沒被封的網站則完全不受影響，日常那些自動化照常跑。兩個方向都要測，這道鎖才算數。 兩個實作上的細節： 只封精確的網址，不用 *.整個網域 這種萬用字元。 封 *.esunbank.com.tw 會連信用卡活動頁一起封掉，而信用卡活動頁、線上表單這類，往往正是你想留給 AI 幫忙的地方。要封的是「登入後能動錢的那個網址」，不是整家銀行。 macOS 有一個陷阱：defaults write 寫進去的政策沒有用，而且是無聲失敗。 實測它在 chrome://policy 會顯示「有效」，但等級只是「建議採用」，AI 照樣進得去；政策要放在 /Library/Managed Preferences 底下、等級顯示「強制」，才真的擋得住。驗證標準要看等級，不是看政策有沒有出現。 做成開源工具：kimi-webbridge-lockdown 這個設定要手動改登錄檔（Windows）或系統政策檔（macOS），有點門檻。所以我把它做成了一鍵設定的工具，開源出來： ...