1Password让Agent登录时不接触密码

让 AI Agent 登录账号，麻烦的不只是输密码，还有密码交出去之后，权限到底能收回来多少。1Password 给出的方案是：Agent 发起登录请求，用户在自己的设备上批准，再由 1Password 填入凭据，Agent 全程不接触密码。

原文介绍的 1Password for Agents，试图把「允许代办任务」和「交出账号密码」分开。这个方向值得看，但需要分清：看不到密码，和登录后只能做指定的事，是两个问题。

Agent 怎么登录，又为什么看不到密码

按照原文描述，登录过程分成几步：

1. Agent 遇到登录表单时，用一个独有的数字密钥向 1Password 验证身份。
2. 1Password 向用户发送通知，说明需要哪个账号的凭据，以及申请原因。
3. 用户在自己的设备上批准请求。
4. 1Password 填入登录信息，Agent 登录成功后继续执行任务。

这里有两种不同的凭据：数字密钥用于向 1Password 证明 Agent 的身份；账号密码用于登录目标服务。前者不等于后者，也不能把它理解成 Agent 拿着一把钥匙就能读取整个密码库。

用户授权的是一次登录请求，密码由 1Password 负责填入。

原文将设备端批准比作双因素认证，原因是两者都需要用户参与确认。不过，报道没有说目标网站因此开启了双因素认证，也没有解释填入密码时，系统如何防止 Agent 通过页面或其他工具读取凭据。具体的隔离机制没有展开。

它想解决的是交出密码后的失控

1Password CEO Aashish Tripathi 的主张是：Agent 应该能完成委托的工作，却不该因此获得账号背后所有资源的永久访问权。

这套流程确实改变了凭据的交付方式。用户不必为了让 Agent 登录服务，就直接把密码放进对话或交给它处理；每次登录申请还有一个用户确认的关口。对于需要登录多个服务的代办任务，这有望减少手动接管操作的麻烦。

但原文没有给出实测。登录成功率、审批耗时、支持哪些登录页面，以及验证码等额外步骤如何处理，都没有说明。

接入范围也要分开看。原文称，这套系统面向的 Agent 包括 Meta Muse、ChatGPT Work and Dots、Claude Duet、Grok Bot 和 Town。

Browserbase、Browser Use、Dana、Instinct、Kernel、Perplexity、Ramp、Tomo、Wajo 则被列为正在推进支持的合作伙伴。报道还提到后续会有更多集成，但没有给出逐项上线时间，不能把这张名单理解成所有产品都已可用。

我的判断

我认可把密码留在凭据管理工具里，再让 Agent 申请使用的方向。相比直接把密码写进提示词，它能减少密码进入模型上下文的机会，也让用户保留登录前的批准权。

但作者引用的产品愿景，比报道展示的机制更宽。

不暴露密码，不等于限制登录后的操作权限。

Agent 登录成功后，可能仍然拿到了可操作账号的会话。它能访问哪些页面、能否修改设置、是否需要为敏感操作再次申请批准，原文都没说清。登录时展示申请原因，也不能单独证明后续操作一定符合这个原因。

对于支持正式 API、权限范围和短期令牌的开发流程，仍应比较这些方式能否更准确地限制任务权限。1Password for Agents 展示的是另一条路径：在需要通过登录表单进入服务时，减少向 Agent 交付密码的需求。

至于它是否更安全、更省事，报道没有提供对照数据，目前应当视为产品机制介绍和厂商主张。

能拿来做什么

• 使用浏览器 Agent 处理需要登录的任务时，可以把「是否必须直接交出密码」作为选型条件，并先确认所用 Agent 是否已经支持这套流程。
• 给团队制定 AI 编程工具的使用规则时，可以分别规定凭据如何提供、登录如何批准、登录后允许做什么，避免把一次登录批准当成整个任务的无限授权。
• 如果任务可以通过 API 完成，先比较权限范围和令牌有效期；如果必须操作网页，再评估这类代填方案，同时检查登录后的会话权限和敏感操作确认机制。