1Password 在 2026 年 10 月 22 日推出「1Password for Agents」：AI 代理要登入網站時，先向 1Password 出示一組數位金鑰證明身分，你在自己的裝置上看到「哪個帳號、什麼理由」後按下核准，1Password 再把帳密直接填進登入表單——整個過程代理與背後模型從頭到尾看不到、也存不到那組密碼。
換句話說，這件事賣的不是「AI 會用你的帳號」，而是「AI 用了你的帳號，但你還握得住鑰匙」。在 2026 年這個人人都在把 ChatGPT、Claude、Muse、Grok 當助理用的時間點，這條產品線補的是一個很現實的洞：你要嘛把帳密貼給代理，要嘛每次登入都自己手動來。
事件：10 月 22 日，1Password 把「信任層」做成產品
官方新聞稿在美東時間 10 月 22 日上午 9 點發布，Toronto 發出，產品定位寫得很直白：「personal AI agents 的信任層（trust layer）」。1Password 產品長 Aashish Tripathi 的說法是：
「代理已經開始替我們做真正的工作。過去那種『把憑證交出去，然後祈禱沒事』的模式行不通了。一個代理應該能完成它被交付的任務，而不需要取得帳號背後所有東西的永久存取權。」
官方的問題陳述也講得很具體：把密碼、secret 或憑證交給代理是最常見的捷徑，但代價是「敏感資訊被複製一份、留在你再也控制不了的地方」。
值得注意的是發表節奏。1Password 這次不是單打獨鬥推一個功能，而是拉了一整排代理公司一起站台：Meta 的 Muse、Anthropic 的 Claude Duet、OpenAI 的 ChatGPT Work 與 dots、SpaceXSI 的 Grok Bot、Town 的 Townie，再加 9 家在建置中的夥伴。這種「同一層信任機制、多家代理接入」的打法，基本上就是把 1Password 放在代理生態的中介位置。
痛點：把帳密貼進聊天框，代價比想像中高
在多數人的日常裡，「讓 AI 幫我訂東西」目前長這樣：把帳號密碼打在對話框裡，請代理去登入。這個做法同時踩到三個雷：
| 風險 | 實際發生什麼 |
|---|---|
| 憑證進入模型 context | 密碼變成一則訊息，可能被寫進對話歷史、記憶摘要，或被送到其他工具／外掛 |
| 提示注入（prompt injection） | 代理若讀到藏有惡意指令的網頁，它手上「有密碼」這件事本身就是攻擊面 |
| 永久站立權限（standing access） | 一次給出長效 session 或 cookie，等於給代理無期限的帳號控制權，之後不會自動收回 |
1Password 的說法很精準：「舊模式是交出一組憑證然後希望沒事。」 新模式的目標是把「一次性任務的操作權」和「憑證本身」拆開——代理可以做事，但不能持有鑰匙。
運作機制：五個步驟，密碼不經過模型
官方文件與技術分析對流程的描述相當一致，拆成五步：
| 步驟 | 誰在做 | 發生什麼 |
|---|---|---|
| 1. 遇到登入頁 | AI 代理 | 代理在任務中途撞到登入表單，停下來發出憑證請求 |
| 2. 出示數位金鑰 | AI 代理 → 1Password | 代理用一組唯一數位金鑰（digital key）向 1Password 證明「我是哪一個代理」，不是不明程序 |
| 3. 使用者核准 | 你，在自己的裝置上 | 通知會顯示「要哪一個帳號、代理聲稱的理由」，你按核准（可在手機、筆電上完成，帶生物辨識） |
| 4. 憑證直填 | 1Password | 1Password 透過自己控制的安全通道（瀏覽器擴充、agentic autofill）直接把帳密與一次性驗證碼填進目標網站表單 |
| 5. 完成任務 | AI 代理 | 代理取得登入後的 session 繼續做事，密碼則留在 1Password 的加密金庫裡 |
三個技術要點值得特別記住：
- 憑證不進 prompt、不進 context、不進記憶。 這是整個設計的核心賣點，也是它跟「把密碼貼給 AI」最大的差別。
- 核准發生在使用者自己的裝置上，代理無法自我核准。 這等於把同意權從模型端拉回人身上。
- 零知識架構不變。 1Password 維持既有的 master password + secret key 模型，它在這裡扮演的是「憑證仲介（credential broker）」而不是「保管你明文密碼的雲端服務」。
與其他「不給密碼」路線的差異
很多人會問：那為什麼不用 OAuth、不用 passkey？答案很現實——大部分網站根本沒有 API、也沒有 OAuth。這張表把四條路線放在一起看：
| 路線 | 適用場景 | 限制 |
|---|---|---|
| 直接把帳密貼給代理 | 任何網站 | 憑證外洩風險最高，密碼會留在對話紀錄與記憶中 |
| OAuth／授權 token | 有開放 API、支援授權流程的服務 | 消費級網站與老舊系統常常沒有；代理仍需持有 token |
| Passkey（FIDO2／WebAuthn） | 已支援無密碼登入的服務 | 綁定使用者裝置與生物辨識，代理無法自行完成 |
| 1Password for Agents | 需要填傳統帳密表單的網站 | 仍須逐次核准；登入後的 session 權限無法回收 |
換句話說，1Password 這條路線不是要取代 OAuth 或 passkey，而是去補那塊「只能填表單」的長尾。至於 MCP，兩者是不同層：MCP 解決「模型怎麼呼叫工具」，1Password for Agents 解決「呼叫工具時憑證怎麼安全送進去」，可以疊在一起用（1Password 自己也有 MCP server 產品線）。
首波夥伴與整合狀態：這幾天能用的只有兩個
官方把「已經在滾動開放」和「即將推出」講得很清楚，這也是很多首日報導寫錯的地方（一口氣寫成「全部上線」）：
| 代理 | 官方狀態（2026-10-22） |
|---|---|
| Meta Muse | 這幾天陸續在所有平台開放（rolling out over the coming days） |
| SpaceXSI Grok Bot | 這幾天陸續在所有平台開放 |
| Anthropic Claude Duet | 即將推出（coming soon） |
| OpenAI ChatGPT Work、dots | 即將推出 |
| Town Townie | Web 與 iOS 版本即將推出 |
| Instinct、Browserbase、Browser Use、Dana、KERNEL、Perplexity、Ramp、Tomo、Wajo | 建置中／即將推出 |
一個很容易被忽略的細節：官方部落格明白寫著 「The safeguards and controls vary by integration.」（防護與控制方式依整合而異）。也就是說，「1Password for Agents」不是一個統一的技術規格，而是一組與各家代理談出來的整合。你在 Muse 得到的防護細節，未必等於在 Claude Duet 得到的。
至於費用，官方對個人與家庭訂閱者的說法是「不額外收費、包含在既有訂閱中」，但目前整體仍在候補名單（waitlist）階段，而且 1Password.eu 與 1Password.ca 區域帳號暫不支援。實際可用範圍與定價請以官網當下顯示為準。
為什麼是現在：同一天，Axios 揭露美國銀行開始「抓」代理
這次發布最有意思的背景，是它與 Axios 同一天（10 月 22 日）的獨家報導撞在一起。Axios 的標題是「未經審查的 AI 代理正在進入美國銀行帳戶」，重點有三個：
- 代理進入銀行系統的速度，比金融機構能反應的速度還快；
- 銀行很難分辨「這是本人授權的操作」還是「未經授權的機器人」；
- 因此銀行開始封鎖這類行為，並快速改寫服務條款。
TechCrunch 的報導補了一句關鍵：這些代理活動未必是惡意盜用，更多是消費者自己讓自動化服務代為操作（包含理財）。真正的問題在於「銀行分不出來」。有受訪銀行員用「horrifying」形容這個狀況，Chase 發言人則重申「客戶不該把帳號密碼交給任何人」。
把兩件事放在一起看，1Password 這場發布的時機就很清楚了：代理已經跑在制度前面，而「可被稽核、可被核准的授權」正是金融與企業場景最缺的那一塊。
四個還沒解的問題（官方沒藏，但也沒解）
這篇不是業配，該講的缺口要講。以下四點，官方文件與資安社群的討論都有觸及：
| 問題 | 具體內容 |
|---|---|
| 登入後的權限 | 代理看不到密碼，但登入成功後的 session 仍然在它手上：它能讀登入後的頁面資料、能下單、能改設定。這個機制管的是「進門」，不是「進門後做什麼」 |
| 核准疲勞（approval fatigue） | 代理若頻繁請求登入，使用者很可能不看內容就一路按核准，安全門檻自然失效 |
| 理由可被偽造 | 通知上顯示的「存取原因」字串由請求方代理提供。被挾持或有惡意的代理，可以編一個很合理的故事騙你按下核准 |
| 金庫成為高價值單點 | 把眾多代理的授權集中在一處，等於替攻擊者標好了一個高價值目標 |
再加上兩件事實：目前沒有任何公開的獨立第三方安全審計報告驗證這套機制，機制細節仍以官方說法與初期報導為主；而各家整合的防護強度「依整合而異」，等於把一部分風險管理責任丟回使用者身上。
對企業還多一層：這套東西目前主要面向「個人代理」。公司如果真要讓代理碰內部系統，重點還是特權存取管理（just-in-time、零站立權限）與稽核紀錄，而不是把個人金庫當企業方案用。
對台灣讀者與自架族的實務建議
如果你是開發者、或正在自架服務，這件事有幾個可以馬上用的判斷：
- 先分清楚「代理需要什麼權限」與「代理需要什麼憑證」。 前者是授權設計（scope、時效、可撤銷），後者是保管問題。1Password 解的是後者，前者仍得自己設計。
- 能給 token 就別給密碼。 有 API 的服務優先走 OAuth／短效 token；真的只有表單的長尾，才輪到憑證仲介這種機制。
- 自架族可以參考同樣的分層思路。 例如用 Vaultwarden 集中保管，再讓自動化流程透過一次性授權取得憑證，而不是把密碼寫進
.env或 CI secret 裡複製貼上。 - 不要讓代理的 session 無限長。 這是目前所有代理登入方案共同的缺口：進門管得住，進門後的 session 壽命與可做的事，得靠你自己的規則。
- 等 waitlist 的時候先想清楚要授權哪幾個帳號。 目前仍在候補、且有區域限制（1Password.eu／.ca 不支援），別把 production 帳號當第一批白老鼠。
站內延伸閱讀
- Vaultwarden 完整教學 2026：自架密碼管理器，把 1Password 換成自己的伺服器
- Apple 收緊 macOS「完全磁碟存取權限」：AI Agent 被點名風險過大
- Walmart 開門、Amazon 關門：Agent Gateway 用 MCP 讓 AI 代理代客下單
- MCP 完整教學 2026：Model Context Protocol 入門到實戰
資料來源與查證方式
- 1Password 官方新聞稿（2026-10-22）：1Password for Agents Launches as the Trust Layer for Personal AI Agents
- 1Password 官方部落格（2026-10-22，John Torrey）：Introducing 1Password for Agents
- TechCrunch（2026-10-22，Lucas Ropek）：1Password launches a way for AI agents to log in on your behalf without seeing your password
- Axios（2026-10-22）：Scoop: Unvetted AI agents are accessing U.S. bank accounts
- 機制細節另以 NotebookLM 彙整 10 個來源（官方文件、技術分析部落格、第三方報導）交叉核對；「防護依整合而異」「尚無獨立第三方審計」兩點為本文自行標註的保留，非官方說法。
- 價格與方案資訊以官方頁面為準，本文未逐一驗證各地區實際收費；整合上線狀態以 2026-10-22 官方部落格標示為準，之後可能變動。