密码不再经手 AI：1Password for Agents 让智能体代你登录，批准权始终在你手里

新闻核心：1Password 宣布成为 personal agent 的“信任层”

2026 年 10 月 22 日，密码管理公司 1Password 正式发布了新平台 1Password for Agents。它要解决的问题，一句话就能说明白：当 AI agent 替你去订餐厅、交账单、规划旅行时，它必须登录你的个人账户——而今天最常见的办法，是把密码直接粘贴到 agent 的对话框里。

1Password 官方通稿的措辞很直白：“把密码、密钥或凭证交给 agent 是一种常见捷径，但会把敏感信息留在你无法控制的地方——因为副本会被保存下来，供下一次使用。”1Password for Agents 的设计目标就是把这条捷径堵上：agent 可以完成需要登录的任务，但它永远看不到、也存不下你的密码。

发布时的集成阵容覆盖了当前个人 agent 生态的大多数重量级玩家：Meta 的 Muse、OpenAI 的 ChatGPT Work 与常驻型 Dots agent、Anthropic 的 Claude Duet、SpaceX 旗下 Super Intelligence 的 Grok Bot，以及创业公司 Town 的 Townie。其中 Muse 和 Grok Bot 是首批上线方，Claude Duet、ChatGPT Work、Dots 和 Townie 标注为 coming soon，Browserbase、Browser Use、Perplexity、Ramp 等也在后续集成名单上。此外，它包含在个人版和家庭版订阅中，无需单独付费。

这不是 1Password 第一次往 agentic 方向走。今年 7 月，它先为桌面端的 Claude 推出了专门集成；这次的 for Agents 则是把同一思路从桌面扩展到了各家 personal agent。换句话说，1Password 把自己定位成了 agent 生态的一层基础设施——“信任层”。

时机也值得注意。TechCrunch 在报道同一天指出，Axios 当天报道美国的银行已经开始在用户账户里检测到 agentic 活动的痕迹；Chase 更是直接提醒客户“不要把用户名和密码交给任何人”。银行在防，1Password 在疏——两边其实讲的是同一件事：agent 进账户已经是既成事实，问题只在于用什么方式进。

机制拆解：agent 的请求要过三道门

1Password for Agents 的核心是一套 agent、用户、密码管理三方之间的通信协议。整个流程可以拆成三步：

第一步：agent 自证身份，而不是出示密码

当 agent 在执行任务的过程中抵达某个网站的登录页，它不会去找你的密码。它做的是另一件事：用一把唯一数字密钥向 1Password 自证自己的身份。这把密钥是 agent 的“身份证”，1Password 借此确认“来请求的是哪一个 agent”，而不是简单地信任任何自称 agent 的东西。这一步解决了委派链里的第一个信任问题：请求方是谁。

第二步：批准权始终在人的手里

身份确认后，1Password 会向你的设备推送一条批准请求。这条请求不是一个模糊的“是否允许登录”，而是明确告诉你：哪个 agent、在请求哪个账户、为了做什么。你可以在自己手机上看清楚这三件事，然后手动批准或拒绝。没有你的批准，什么都不会发生——agent 无权自己批准自己的访问。这一步把“最终决定权”钉死在了人这边。

第三步：1Password 亲自填表，凭证不进模型上下文

一旦你批准，1Password 会把用户名、密码和一次性验证码直接注入到目标网站的表单里，完成登录。关键点在于：密码从头到尾都只在 1Password 管理的安全通道里流转——agent 这边只收到“访问被授予了”这个结果，模型的上下文里永远不会出现你的密码明文。

这三步之外还有两条约束值得单独拎出来。第一，授权是按会话、按批准项生效的，不延续。也就是说 agent 这次被批准登录了某账户做某件事，不等于它下次还能进，更不等于它拿到了账户的永久通行证。第二，1Password 商业负责人 John Torrey 对 PCWorld 表示，用户自己决定 agent 能用哪些凭证、用于什么任务、有效期多长——控制维度是“凭证 × 任务 × 时长”，而不是一个粗放的开/关。

对比：和“把密码粘给 agent”的旧模式差在哪

要理解这套机制的价值，得先看清它替代掉的旧模式有多糟。过去 agent 需要登录时，用户通常有三条路：把密码粘进对话框、让 agent 读密码管理器的导出文件、或者干脆把密码写进某个 agent 能读到的配置文件。三条路的共同点是：密码一旦进入模型的上下文，你就失去了对它的控制。

模型上下文里出现过的字符串，会以各种形式留存：对话记录、日志、缓存、微调数据、甚至 agent 自己的“记忆”功能。下一次 agent 被提示注入攻击诱导，或者某个第三方插件把上下文外传，密码就跟着出去了。更麻烦的是，这个过程是不可逆的——你没法“撤回”一段已经进过模型上下文的密码，只能改密码。而 1Password for Agents 的设计恰恰是把密码从这条链路上彻底摘掉：密码只在 1Password 的安全通道和你批准的那一刻存在，agent 侧从头到尾只有“被批准了 / 被拒绝了”两个状态。

另一个常被忽略的对比维度是一次性验证码。旧模式里 MFA 形同虚设——用户要么把 TOTP 密钥也一起交给 agent，要么每次手动去抄六位数字。而在 for Agents 的流程里，一次性验证码由 1Password 在批准后直接注入表单，MFA 的保护作用被完整保留了下来。这是“委派”和“交出钥匙”之间最实在的区别：前者保留了每一层已有的安全机制，后者把它们一层层拆掉。

维度	旧模式：密码进 agent 上下文	1Password for Agents
密码去向	进入模型上下文，可能被记录、缓存、记忆	只在 1Password 安全通道内，agent 侧不可见
批准机制	无；一次性交出即永久可用	每次登录需用户在自己设备上手动批准
授权范围	拿到密码 = 拿到账户全部权限	按会话、按批准项生效，不延续
MFA / 一次性验证码	形同虚设，需另行手工配合	批准后由 1Password 直接注入表单
事后可审计性	难以追溯哪次登录是 agent 做的	每次批准都是明确的授权记录

对 vibe 开发者的意义：登录环节该怎么设计

如果你正在做一个带 agent 能力的产品，1Password for Agents 的发布其实给了一份现成的设计参考——不是让你照抄它的实现，而是它把“agent 登录”这件事的正确姿势示范了一遍。

第一，把“凭证保管”和“任务执行”拆成两个角色。很多 vibe 项目在做到“让 agent 替用户登录”这一步时，第一反应是做一个“安全地存密码”的功能。但 1Password 的示范是：执行任务的 agent 根本就不该碰密码。保管凭证的是专门的可信组件（密码管理器、系统的钥匙串、企业的 secret vault），agent 只负责发起请求和接收结果。你的产品架构里如果出现了“把用户密码传给 LLM”这一步，设计就已经走偏了。

第二，批准界面是产品的一部分，不是安全团队的补丁。for Agents 最值得借鉴的不是密钥机制，而是那条推送：“哪个 agent、哪个账户、为什么”。用户愿意把登录权委托出去的前提，是他每次都能看懂自己在批准什么。做 agent 产品时，登录环节的 UX 应该回答三个问题：谁在请求、要进哪个账户、为了完成什么任务。答不上来这三个问题，所谓的“无缝登录体验”就是在透支用户信任。

第三，授权默认最小、默认过期。“按会话、按批准项生效，不延续”这句话值得做成你产品的默认策略。agent 完成一次订票任务，不应该顺手获得这个账户的长期访问权。最小权限不只是后端安全原则，它也是可以直接写进产品文案、讲给用户听的卖点——在 agent 信任普遍欠费的今天，“用完即走”本身就是竞争力。

第四，给用户留一条“我能看见”的审计线。for Agents 的每次批准都是一条明确的授权记录。对你的产品来说同理：agent 替用户登录了几次、进了哪些账户、分别做了什么，这些记录应该让用户随时可查。agent 时代的用户协议里，“可审计”会和“可用”一样重要。

诚实的局限：它没有解决所有问题

把话说满之前，得先泼三盆冷水。

第一，信任只是被转移了，没有消失。“密码不进模型上下文”不等于“密码绝对安全”——它现在住在 1Password 的保险库里。你仍然需要信任 1Password 本身：它的客户端实现、它的密钥管理、它的推送通道不被劫持。这套方案把“要不要信任 AI 公司”这个问题，替换成了“要不要信任 1Password”。对大多数人来说这是个更好的交易，但它依然是一笔信任交易，不是数学证明。

第二，批准疲劳是真实的风险。手动批准是整套机制的安全基石，但人是会累的。当 agent 一天发起二十次登录请求，用户大概率会从“仔细看”滑向“随手点批准”——而每一次随手批准，都在把精心设计的三方协议降级成一个昂贵的“确定”按钮。1Password 目前的解法是让请求信息足够清晰（哪个账户、为什么），但信息清晰只能延缓疲劳，不能消除疲劳。未来的关键变量是：系统能不能学会区分“高风险请求值得打断你”和“低风险请求可以按策略自动放行”，同时不把后者变成新的攻击面。

第三，生态覆盖才刚刚起步。发布时的名单看着很全，但仔细看会发现：真正“未来几天上线”的是 Muse 和 Grok Bot，Claude Duet、ChatGPT Work、Dots、Townie 都还是 coming soon，Browserbase、Browser Use、Perplexity、Ramp 等更在后面排队。加上目前仅支持 1Password.com 的个人与家庭账户（.eu 和 .ca 账户暂不支持），这意味着在未来几个月里，大部分用户的实际体验仍然是“名单上有、我的 agent 还没接”。一个信任基础设施的价值取决于覆盖率，而覆盖率是需要时间爬坡的。

还有一个更长期的追问：当 Anthropic、OpenAI、Meta 这些 agent 的母公司自己也在做身份与支付基础设施时，1Password 的“中立信任层”位置能维持多久？这次发布里各家都愿意合作，是因为大家都需要先解决“用户不敢把密码交出来”这个共同瓶颈。但瓶颈解决之后，信任层本身会不会成为新的必争之地——那是下一幕的故事了。

走一遍：一次真实的代登录是什么体验

把机制落到一次具体任务上，会更清楚这套设计在日常里是什么感觉。假设你让 Muse 帮你订下周五晚上的餐厅——一家需要登录会员账户才能预订的餐厅。

过去的做法是：你在对话框里粘贴账号密码，agent 打开浏览器、填表、登录、完成预订。你的密码从此躺在对话记录里，agent 的“记忆”里，甚至可能躺在某次崩溃上报的日志里。你改密码之前，它一直有效。

而在 1Password for Agents 的流程里，体验是这样的：你在聊天里只说“帮我订下周五晚上 7 点那家餐厅，4 个人”。Muse 打开餐厅网站，抵达登录页，随即用它的数字密钥向 1Password 自证身份并发起请求。你的手机亮起一条通知：“Muse 请求登录你的餐厅会员账户，用于完成餐厅预订，批准吗？”你看一眼，点批准。1Password 把用户名、密码和一次性验证码直接填进网站表单，登录完成，Muse 继续把座位订好，回来告诉你“订好了”。

注意这个过程里发生了什么、没发生什么。发生了的是：你做了一次明确的、知情的授权，你知道是谁、在进哪个账户、为了什么。没发生的是：密码没有出现在聊天框里，没有进入模型的上下文，Muse 的“记忆”里不会多一条你的密码；这次授权也不会延续到下一次——下周你再让它订，它得重新请求、你得重新批准。

这种“每次都要你点头”的设计，乍看有点烦。但换个角度想，它恰恰是 agent 从“玩具”变成“管家”的分水岭。管家可以帮你跑腿，但家里的保险柜钥匙始终在你手上，每次开柜你都得在场。这套机制做的，就是把数字世界里的“保险柜钥匙”从 agent 手里拿回来。

当然，真实世界的摩擦也不会少。比如你在开会，手机不在手边，agent 的任务就卡住了；比如网站用了奇怪的验证码或反机器人机制，1Password 的表单直填能不能每次都成功，还要看实测。这些体验细节，官方通稿都不会写，只能等首批集成的 Muse 和 Grok Bot 上线后看用户反馈。

背景：从“1Password for Claude”到 agent 生态的信任层

理解这次发布，还得把 7 月的那一步放进来一起看。今年 7 月，1Password 先为桌面端的 Claude 做了一个专门集成，解决的是“浏览器 agent 需要凭证”的问题。当时的方案已经确立了核心原则：给浏览器 agent 凭证，意味着把明文塞进它的上下文，模型看得见——所以必须换一条路。

for Agents 是把这条路从“桌面上的一个 agent”扩展到了“各家 personal agent”。措辞上也有升级：7 月谈的是“集成”，这次谈的是“平台”和“信任层”。1Password 的首席产品官 Aashish Tripathi 在通稿里说：“agent 应该能完成被交办的工作，而不必获得账户背后一切东西的永久访问权。”这句话其实定义了 1Password 想扮演的角色：不做 agent，而是做所有 agent 共用的、与 agent 公司彼此独立的信任基础设施。

这个“独立”值得玩味。agent 的母公司们——Meta、OpenAI、Anthropic——自己也有动机做登录与身份方案。但用户把密码交给 agent 母公司，和把密码粘进对话框，在信任结构上并没有本质区别：密码依然进了同一家公司的系统。而 1Password 赌的是另一条路：用户本来就把密码托付给了密码管理器，那么让密码管理器来当“守门人”，在心理账户上是顺理成章的。这也是为什么个人版和家庭版直接免费包含——它要的是覆盖率，而不是这项功能本身的收入。

从行业时间线看，2026 年下半年 agent 的“身份问题”正在集中爆发：银行开始检测账户里的 agentic 活动，Chase 公开提醒客户不要交出密码，1Password 则选择把“疏”的方案产品化。防和疏同时出现，说明一件事已经成为共识——agent 进账户挡不住了，接下来比的是谁的进场方式更体面。

结语：agent 落地缺的不是能力，是“敢把钥匙交出去”的理由

回头看，agent 落地过程中最大的信任瓶颈从来不是模型能力，而是那句用户心里的话：“我敢把密码交给它吗？”过去一年的答案普遍是“不敢”，于是 agent 们被挡在登录页之外，只能做些不需要身份的杂事。

1Password for Agents 给出的答案是：你不需要把密码交给 AI，你只需要批准每一次具体的登录。批准权在人手里，凭证不进模型上下文，授权用完即止。这套“委派而不交出”的模式，未必是最终形态——批准疲劳和生态覆盖都是待解的题——但它第一次把 agent 登录这件事做成了一个可讨论、可审计、可追责的正式协议，而不是一句“粘密码进来吧”的口头约定。

对所有在做 agent 产品的人来说，这篇新闻真正的 takeaway 只有一句话：别再让用户的密码出现在你的 prompt 里。登录环节的设计，决定了用户敢不敢把真正重要的任务交给你。