1Password让AI登录但看不见密码

AI 智能体终于能过登录这一关

1Password 于 10 月 22 日推出 1Password for Agents，允许 AI 智能体在获得用户批准后登录网站和在线服务，同时不让模型直接读取、复制或处理密码。对浏览器智能体而言，这是一个比“又能多点几个按钮”重要得多的更新：它第一次试图把登录凭证从模型上下文中剥离出来，让智能体能办事，但不必先把保险柜钥匙交给它。

**1Password for Agents 是一套面向 AI 智能体的受控登录能力。**当智能体执行需要登录的任务时，1Password 接收登录请求，由用户决定是否授权，再将对应凭证注入登录流程；智能体负责推进任务，却不会在对话记录或模型可见的页面信息中拿到密码明文。

这项功能不会向智能体开放整个 1Password 密码库。按照目前披露的信息，登录仍需要用户批准，智能体不能因为被授权登录一次购物网站，就顺手读取邮箱、银行和公司后台的全部凭证。1Password CEO Aashish Tripathi 对此的表述很直接：当智能体开始替人完成真实工作，“把凭证交出去，然后期待一切顺利”的旧模式已经行不通。

它解决的是智能体最现实的断点

**登录是当前浏览器智能体从演示走向实际工作的最大断点之一。**智能体已经能搜索网页、比较商品、填写表单、整理报销材料，但流程一旦进入账户页面，通常只能在三种不理想的方案里选择：让用户接管浏览器、把密码暴露给模型，或者提前在浏览器中保留一个长期有效的登录状态。

第一种方案最安全，却会频繁打断自动化。用户让智能体处理一项需要访问 Salesforce、GitHub、Slack 和 Box 的任务，可能需要中途接管四次；任务名义上由 AI 执行，实际仍然是人在各个登录页之间来回切换。

第二种方案最省事，却把秘密数据放进了错误的位置。密码一旦进入提示词、截图、浏览器可访问文本或智能体日志，就可能被模型供应商的遥测系统、第三方插件、调试工具和任务历史记录留存。即使模型本身没有恶意，提示词注入也可能诱导智能体把页面中的敏感内容发送到不该去的地方。

第三种方案把风险藏在了 Cookie 里。长期登录会话虽然避免了反复输入密码，但智能体获得的往往是一个已经完成认证的浏览器环境；只要会话仍然有效，它能做什么主要取决于网站权限，而不是本次任务的边界。密码没有泄露，并不意味着账户访问得到了控制。

**1Password 的判断是把“知道密码”和“使用密码”拆成两种权限。**人类用户可以授权智能体使用某一项凭证完成一次登录，但智能体不需要知道凭证内容。这类似公司前台代访客刷开指定会议室：访客通过了门，却没有拿到能复制、带走并反复使用的门禁卡。

“看不见密码”究竟意味着什么

**凭证注入是指秘密数据由可信组件直接交给目标登录界面，而不是先进入 AI 模型的上下文。**在这一流程中，模型可以识别用户名输入框、点击登录按钮并继续执行任务，但密码的读取与填写由 1Password 控制的组件完成。对模型而言，它知道“登录已经完成”，却不应获得密码字符串本身。

这一区别能显著缩小密码泄露面。传统浏览器自动化脚本经常把用户名和密码写入环境变量、配置文件甚至脚本源码；一些智能体则会把凭证当成普通文本拼进提示词。1Password for Agents 的价值，是让密码继续停留在密码管理器的信任边界内，只在执行登录动作时短暂参与流程。

不过，“AI 看不到密码”不等于“密码从未出现在任何计算环境中”。目标网站最终仍需要接收密码，浏览器也必须完成表单提交；真正被隔离的是模型、对话上下文以及智能体可自由操作的工具层。1Password 尚未公开足够多的底层实现细节，因此外界还不能据此断言密码从不进入浏览器进程内存，或对所有恶意扩展和受感染终端都具备绝对防护。

**更准确的安全表述应当是：智能体没有直接读取和带走密码的正常权限。**这比宣传一句“密码永不暴露”更严谨，也更符合真实威胁模型。假如设备本身已经被恶意软件控制，或者登录页面是精心伪造的钓鱼网站，单靠凭证注入并不能自动解决所有问题。

与现有登录方案相比，它补上了一层授权

**1Password for Agents 的核心优势不是取代 OAuth 或通行密钥，而是为暂时无法使用这些机制的智能体任务提供受控入口。**OAuth 仍然更适合服务之间的长期授权，通行密钥仍然是抗钓鱼登录的重要方向；但现实中的大量网站只有用户名和密码，许多后台系统也没有为智能体设计细粒度权限。

| 方案 | 智能体是否看到密码 | 是否需要用户介入 | 权限粒度 | 主要风险 | 适用场景 | |---|---:|---:|---|---|---| | 用户手动接管登录 | 否 | 每次需要 | 由用户现场决定 | 自动化被中断 | 低频、高敏感任务 | | 把密码直接交给智能体 | 是 | 通常仅首次 | 较粗 | 提示词注入、日志泄露、误传 | 不建议用于真实账户 | | 复用浏览器登录会话 | 否 | 较少 | 取决于现有会话 | Cookie 被滥用、权限长期有效 | 单设备上的连续任务 | | OAuth 授权 | 否 | 首次或权限变化时 | 通常较细 | 授权范围过宽、令牌泄露 | 已提供标准授权的平台 | | 1Password for Agents | 否 | 登录请求需要批准 | 以账户和任务授权为核心 | 批准疲劳、登录后的越权操作 | 仍依赖密码的网站任务 | | 企业 Credential Broker | 否 | 可按策略自动化 | 可按身份与策略配置 | 策略错误、工作负载身份失陷 | 服务器、CI/CD 与机器身份 |

这张表也说明，1Password for Agents 并不是 OAuth 的上位替代品。OAuth 可以限制应用只读取日历、不发送邮件，或者只访问特定仓库；而智能体通过网页登录后，通常会继承这个账户在网站中的完整操作能力。前者控制的是服务权限，后者目前主要控制的是登录入口，两者解决的问题并不相同。

真正的风险转移到了登录之后

**凭证不再暴露后，智能体的主要风险会从“偷走密码”转向“滥用已经登录的会话”。**一个智能体不需要知道电商账户密码，也能在登录后下单；不需要读取 GitHub 凭证，也可能修改仓库设置；不需要导出 CRM 密码，也可能删除客户记录。授权登录只是第一道门，不能代替操作审批。

提示词注入仍然是最值得警惕的攻击路径。攻击者可以在网页、邮件或共享文档里放入对人类不显眼、却会被智能体读取的指令，例如要求它忽略原任务、打开另一个站点并提交数据。即使密码始终不可见，一个已经通过认证的智能体仍可能利用当前会话完成危险操作。

用户批准机制也可能产生“授权疲劳”。如果智能体执行一个任务要连续申请十几个账户登录，用户很快会像处理浏览器弹窗一样机械点击允许。1Password 后续需要证明，它能清晰展示请求来源、目标域名、使用哪一项凭证、授权持续多久，以及智能体登录后准备执行什么动作。

**审计能力将决定这项功能能否进入企业环境。**企业安全团队不仅需要知道某个账户在什么时候登录，还需要区分操作来自员工本人、自动化脚本还是某个 AI 智能体，并在智能体被禁用后立即撤销访问。1Password 在其企业安全方案中已经强调来源追踪、最小权限和凭证撤销，但这些能力如何完整覆盖浏览器智能体，仍要等待更具体的管理功能和部署细节。

1Password 正在争夺智能体的身份层

**1Password 的长期目标显然不只是替 AI 填一次密码，而是成为人类、机器和智能体之间的凭证控制层。**它此前推出的 Credential Broker 面向机器身份和运行时凭证交付：任何能够签发 OIDC 令牌的系统，都可以向 1Password 证明自己的身份，并只获取被策略允许的凭证，避免把长期服务账户密钥保存在运行环境中。

1Password for Agents 更接近个人和浏览器一侧，Credential Broker 则面向企业工作负载。前者处理“这个智能体能否替我登录某个网站”，后者处理“这个工作负载能否在运行时取得某项秘密”。两条产品线共同指向一个判断：未来需要管理的身份不只有员工和服务器，还包括数量可能远超员工的 AI 智能体。

现有报道把 Claude 作为这项能力的代表性使用场景，也说明 1Password 选择了务实路线。Claude 的计算机操作能力可以观察屏幕、移动鼠标和填写表单，但认证一直是高风险环节；把密码填写交给密码管理器，正好补上了模型操作界面与账户安全之间的缺口。不过，产品最终价值取决于能否扩展到更多智能体框架，而不是只服务某一个模型。

**1Password 目前披露的信息还不足以回答定价、全面开放时间和兼容范围。**截至 2026 年 10 月 22 日，公开材料没有给出独立订阅价格，也没有完整列出支持的网站、浏览器、账户类型、双因素认证方式和通行密钥流程。对准备采用它的团队来说，这些细节比演示视频是否流畅更重要。

这是一块必要的安全拼图，但不是免责按钮

**1Password for Agents 是目前智能体产品中少见的基础设施级改进。**它没有让模型推理更强，也不会直接提高网页操作成功率，却解决了一个决定智能体能否接触真实账户的问题：如何让 AI 获得完成任务所需的访问权，又不让秘密数据进入模型可以读取和传播的范围。

这套思路值得肯定，因为它遵循了安全工程中最朴素的最小暴露原则。智能体只需要完成登录，就不该拥有查看、复制和长期保存密码的能力；需要访问一个账户，也不该默认获得整个密码库。相比让用户把密码粘贴进聊天窗口，这不是小幅优化，而是从权限模型上纠正了方向。

**它仍然不能把“批准登录”偷换成“批准所有后续操作”。**真正成熟的智能体安全体系至少还需要任务级权限、敏感操作二次确认、会话有效期、完整审计日志、异常行为检测和快速撤销机制。只有当用户能回答“谁在何时因为什么任务访问了什么，并做了哪些操作”，智能体才算真正进入可治理状态。

对普通用户而言，现阶段最稳妥的做法是只向智能体开放低风险、可恢复的账户，并保留支付、删除、发布和权限变更等关键操作的人工确认。对企业而言，则应把智能体当成新的工作负载身份管理，而不是一个会自己点网页的员工替身。

参考来源

• 1Password Shell Plugins：1Password 官方开源项目，展示其通过受控方式向命令行工具提供凭证的既有技术路线。
• 1Password Go SDK：1Password 官方 SDK，可用于了解应用在运行时读取受控秘密的产品生态与权限边界。
• Anthropic Computer Use Quickstart：Anthropic 官方示例，展示 Claude 操作桌面和浏览器界面的典型智能体运行方式。

本文关于新品功能与逐次授权机制的信息，综合自 1Password 产品公告、官方企业访问管理说明以及 The Verge 对 1Password for Agents 的报道；参考链接按站点发布规范仅保留国内可访问域名。