10 月 22 日，1Password 发布 1Password for Agents：AI 智能体可以代用户登录网站，但全程看不到、也存不下密码、密钥和一次性验证码。流程是智能体遇到登录页先用唯一数字密钥向 1Password 证明身份，用户在自己的设备上看到它要哪个账号、用来干什么，批准之后由 1Password 直接把凭据填进登录表单，密码始终留在保险库里。
这条新闻容易被归到「密码管理器的新功能」，其实它回答的是 Agent 落地里一个很具体的工程问题：凭据到底要不要进入模型的上下文。它和个人智能体协议 PAP、平台开始拦 AI Agent 是三个不同层次的事——PAP 解决「Agent 代表谁」，拦截解决「对方认不认这个身份」，这一篇解决的是「认了之后，它怎么登进去而不用把密码握在手里」。授权边界怎么划、权限怎么不漂移，本站此前的授权边界和权限漂移巡检已经讲过，这里补的是执行层。
一、事实梳理：它到底怎么工作
把官方描述拆成五步，其实很清楚：
- 身份自证：Agent 走到登录页时，用一把唯一的数字密钥向 1Password 证明「我是哪个 Agent」，而不是拿用户的密码。
- 带外批准：用户在自己手机上收到通知，看得到「要哪个凭据、为什么需要」，然后批准或拒绝。批准发生在用户自己的设备上，这一步被官方类比成给 AI 加了一道双重验证。
- 凭据注入：批准后由 1Password 直接把用户名、密码或一次性验证码填进目标网站的表单，不经过 Agent，也不进模型上下文。
- 会话级授权：权限按会话授予，只覆盖这次批准的具体条目，不会延续到后续任务。智能体也拿不到整个密码库的访问权，其他密码仍然端到端加密。
- 连续授权：跨多个站点的多步流程（比如订票 + 订酒店 + 付押金）可以连续跑，不必每一站都弹一次确认。
首批集成方包括 Meta 的 Muse、Anthropic 的 Claude Duet、OpenAI 的 ChatGPT Work 与 Dots、Grok Bot、Town 的 Townie。其中 Muse 和 Grok Bot 的集成这几天在全平台陆续推送，Claude Duet、ChatGPT Work/Dots、Townie 标注为即将上线。官方还提到 Browserbase、Browser Use、Dana、Instinct、KERNEL、Perplexity、Ramp、Tomo、Wajo 等在排队。功能面向个人版和家庭版，具体可用性按地区、设备和登录方式有差异，价格与正式可用时间都没公布，目前走候补申请。
值得注意的一个细节：1Password 在今年 7 月就做过一次 Claude 专用集成。从「给某一个 Agent 做适配」到「做一层所有 Agent 都能接的信任层」，这个变化本身就是信号——它判断 Agent 登录会变成一类通用需求，而不是某个产品的附属功能。
二、它真正解决的是「副本失控」，不是「权限过大」
在它之前，让 Agent 代登录基本只有三条路，每条都有明确缺陷。
把密码贴进对话。最省事，也最糟。密码一旦进了上下文，就可能被写进对话历史、被日志采集、被后续的工具调用带出去，还会被模型「记住」到下一次会话。用户根本不知道副本存在哪。
存进 Agent 的记忆或配置文件。表面上是自动化，实际是把凭据从保险库搬到了权限更松的地方。改密码时十个地方要同步，漏一个就是长期后门。
每次人工登录。最安全，但没人受得了。一次两次还行，天天订票查单，用户最后一定会回到第一种。
1Password 的做法是把问题从「给不给」改成「怎么给」：Agent 拿到的是这一次会话已登录的状态，而不是那把能反复使用的钥匙。这两者的差别很大——前者用完即失效，后者泄露就是长期风险。从这个角度看，它修补的不是授权范围，而是凭据的传播路径。
三、四个设计细节，做 Agent 的都该抄
第一，注入而不是交付。凭据由密码管理器直接填进目标表单，Agent 全程经手不到。这个「不过手」的原则可以推广到所有敏感数据：API Key、支付凭证、身份证号，只要能由受控组件直接注入，就不要经过模型。
第二，批准放在用户自己的设备上。不是弹在 Agent 的界面里，也不是发一条可被脚本伪造的消息。带外确认的意义在于：即使 Agent 被提示注入劫持，它也伪造不了一次真实的用户点击。
第三，会话级、不继承。这条最关键。大多数「Agent 权限」出问题，都是因为一次授权变成了永久授权。会话级授权把这个默认值反过来了——默认没有，用完就没了。
第四，审批粒度按流程而不是按动作。跨站点的多步任务不逐站弹窗，这是个很务实的设计。如果每一步都要点，用户三天就会开始盲批，审批就从控制点退化成橡皮章。这个取舍值得所有做审批流的团队参考。
四、它没解决什么：别把密码安全当成 Agent 安全
发布方自己也承认了边界，这几点必须说清楚。
- Agent 拿到了会话，就等于能做事。密码看不到，但登录成功后它照样能下单、改地址、取消订单、提交表单。订错一件不可退的机票，跟密码泄露是两种损失，后者可以改密码止损，前者只能认。
- 审批疲劳是真实风险。控制点全压在「人要看每一条请求」上，量一大就必然出现无脑批准。真正的解法是分级：低风险站点可预授权，涉及资金和身份的高风险动作强制逐次确认，中间地带按额度。
- 企业侧还没打通。目前是个人版和家庭版，企业环境的单点登录、SCIM、审计合规、离职回收这一整套，跟个人保险库是两套逻辑。Agent 进企业，最后还是要落到 IAM 上。
- 没有动作层的撤销。登进去之后做了什么，1Password 管不到；这笔操作怎么撤回、谁承担责任，也没有答案。
- 审计归属模糊。一次由 Agent 执行、用户批准的操作，日志里该记谁？记用户，等于替 Agent 背锅；记 Agent，又找不到责任主体。这个问题不解决，出了事仍然扯不清。
五、老达点评：战场从模型挪到了凭据和审批
这一年 Agent 安全的话题换过三次焦点。年初大家在讨论模型会不会越权、会不会被提示注入，那是模型层；年中开始讨论 Agent 代表谁、平台认不认，那是协议和身份层，本站写 PAP 时就是这个阶段；现在 1Password 这类基础设施公司进场，焦点变成凭据怎么托付、审批怎么设计——这是执行层。
焦点往下走，说明一件事：光靠让模型更听话解决不了安全问题。真正有效的做法是让模型根本不需要接触最危险的东西。密码是这样，支付凭证是这样，客户的身份证号也是这样。这个思路不新，但直到有基础设施厂商把它做成标准件，普通开发者才用得上。
国内的情况不太一样。企业侧走的是 OAuth 应用授权、扫码授权那一套，权限粒度到接口，但没有「代用户填表登录」这一层；个人账号侧基本是空白，各家 App 的风控对自动化操作又是一刀切地拦。结果是国内 Agent 要么压根拿不到登录能力，要么把活推回给用户手动登。这不是技术水平的差距，是账号体系与风控策略的路径差异——但代价是，Agent 在「需要登录才能办的事」上，国内落地会明显慢一拍。
对正在做 Agent 的团队，这篇新闻的现实价值是三条可以立刻用的原则：窄权限（只给这一次需要的）、短时效（用完即失效，别做长期授权）、可追溯（每一次调用留一条能说清「谁批准了什么」的记录，字段设计可以参考审计查询字段）。这三条不依赖任何厂商，自己就能做。
顺带说一句判断：这件事对做主动式个人智能体的公司是利好。Claude Duet、Muse、Dots 这类产品最卡的地方就是「要帮你办事就得先进你的账号」，没有这一层，它们只能停在起草和建议；有了这一层，才敢真的去执行。1Password 把自己插进这个位置，赌的是 Agent 越能干、凭据托管就越刚需。
六、给两类人的具体建议
普通用户：现在能用就先只用低风险场景——查订单、订餐、看账单，别一上来就让它管银行和证券。看到审批弹窗时花三秒确认「是哪个网站、用来干什么」，这三秒是整个链条里唯一的真人把关。碰上要求你把密码直接贴进对话框的 Agent，直接放弃，没有例外。
开发者：如果你的 Agent 现在要求用户填密码，把它当成一个必须修的技术债。退一步的做法是自己实现一层凭据代理：Agent 请求 → 校验请求来源与用途 → 由代理完成登录 → 只回传会话句柄，不回传凭据。做不到完整方案，至少做到「凭据不进上下文、日志不落明文」这两条。
七、总结
1Password for Agents 不是一个密码管理器的小功能，它把「Agent 怎么合法地用你的账号」这件事，从用户的个人习惯问题，变成了一个有接口、有审批、有边界的工程问题。它解决的是凭据传播，不解决动作后果；它把审批做成了控制点，也就把「别盲批」的责任交回给人。
对行业来说，这是一个明确的信号：Agent 的竞争已经从模型能力转向信任基础设施。谁能让用户敢把账号交出来，谁才拿得到下一批真实场景。
