AI 替你登录，却始终看不到密码：1Password 把「授权」做成了独立的一层

智能体要替你办事，第一步往往是登录。订机票、查账单、填报销、开发票，每一个动作背后都是一个账号。而大多数人的做法，是把用户名和密码直接粘进对话框。

粘进去的那一刻，密码就离开了你的密码库，变成对话历史的一部分。它可能被存下来、被下一次任务复用、被日志记录，也可能被模型「记住」——你无法确认它到底留在了哪里。

10 月 22 日，1Password 发布了 1Password for Agents，想解决的正是这一步：让智能体完成登录，但始终看不到密码。

这件事听起来像一个功能，实际是一条产品线。它把「授权」从密码里剥出来，单独做成一层：密码归密码库，批准归用户，执行归智能体，三者分开。

分开的意义在于责任可追溯。过去出了问题只能查聊天记录，现在可以查「哪一次授权、批给了哪个智能体、用来做什么」。对个人是安心，对企业是合规。

第一步，智能体遇到登录页，用一个唯一的数字密钥向 1Password 证明「我是谁」，而不是「我知道密码」。身份先立住，后面的请求才有意义。

第二步，请求发到用户自己的设备上：要用哪个账号、为了完成什么任务，写清楚。批准的动作发生在用户手里，不在智能体手里，也不在浏览器插件里。

第三步，用户批准后，1Password 把用户名、密码或一次性验证码直接填进目标网站的登录表单。凭据从密码库到网页，中间不经过模型。

第四步，登录完成，智能体继续干活。它能用这次登录做事，但拿不到密码本身，也看不到密码库里的其他条目——这一点比「记住密码」重要得多。

这套流程有个隐含前提：智能体必须能被识别。没有身份，1Password 无法判断请求来自哪个产品、该不该把这条凭据给它。所以「数字密钥」不是装饰，而是整套机制的地基。

也正因为要识别身份，接入方必须逐个适配。这也解释了为什么首批只有五家、还有九家在排队——不是不愿意，而是每一家的登录时机、页面结构、交互方式都不一样。

让 AI 记住密码，工程上很简单：存一个加密字段，用的时候解出来。难的是责任——一旦泄露，你无法证明是谁用的、用来做了什么、扩散到了哪里。

不给密码，工程上复杂得多：要证明身份、要传递请求、要在正确的页面上填正确的字段、要处理验证码与二次验证，还要保证整个过程可撤销、可审计。

这套机制的核心不是加密，而是「代填」。密码始终在密码管理器里，由它代替人完成输入动作。智能体拿到的是「这次登录成功」的结果，不是「以后都能登录」的凭证。

这也是它和「给 AI 一个子账号」的根本区别。子账号是长期身份，代填是临时授权；子账号要定期回收，代填可以随时断开。前者管的是人，后者管的是动作。

从这个角度看，1Password 做的不是密码管理，而是「授权的粒度」。粒度越细，能放开的场景越多：过去不敢让 AI 碰的系统，如果它只能填一次表单、只能看一个页面，风险就从「不可接受」降到「可以试试」。

首批接入的名单很说明问题：Meta 的 Muse、Anthropic 的 Claude Duet、OpenAI 的 ChatGPT Work 与 dots、Grok Bot、Town，几乎覆盖了目前所有「会主动替你操作网页」的产品。

这五家的共同点是：它们都要代替用户进入第三方系统。而第三方系统的登录页，是它们永远绕不过去的一关。谁掌握这一关，谁就掌握了智能体的通行证。

1Password 选择做这一层，而不是自己做智能体，等于站到了所有智能体的必经之路上。这个位置的好处是稳定：不管哪家智能体胜出，都要来这里拿钥匙。

还有九家在排队，包括浏览器自动化与云端浏览器的服务商。这个名单本身就是趋势：智能体越能干，越需要有人替它管钥匙、记账、留痕。

值得注意的是，这份名单里既有模型公司，也有做浏览器、做自动化、做办公套件的公司。它们愿意把「登录」这一环交给第三方，说明大家默认了一件事：凭据不该由智能体自己保管。

个人场景的边界很清楚：这是我自己的账号，我批准，我负责。企业场景完全不是这样——账号是公司的，数据是客户的，操作要留痕，人员会流动。

一个员工让智能体登录公司的系统查数据，用的是谁的权限？如果智能体把数据导到了个人网盘，责任算谁的？如果这个人下个月离职，智能体还能不能继续用这个账号？

所以企业不能照搬「个人批准」这一套。至少要加三层：账号归属（属于岗位还是个人）、权限范围（能查哪些字段、能做哪些动作）、操作留痕（谁在什么时候让哪个智能体做了什么）。

这三层不在密码管理器里，在业务系统里。工具能解决「密码不被看到」，解决不了「权限给得太多」——后者只能靠系统设计。

还有一个容易被忽略的问题：智能体的行为会被「教」。用户在授权时如果长期不看用途、直接点通过，这套机制就退化成了自动放行。工具给了闸门，但闸门有没有人守，取决于流程有没有要求人守。

第一张是账号台账。哪些系统有账号、归属哪个岗位、谁在用、有没有共享账号。共享账号是智能体落地时最大的坑——它意味着无法追溯，也无法单独收回。

第二张是权限矩阵。按角色列清楚「能看什么、能改什么、能导出什么」。智能体应该拿一个比人更窄的角色，而不是直接借用某个管理员的账号，图省事的结果通常是事故。

第三张是操作日志。智能体的每一次登录、每一次读写，都要落到可查询的日志里。日志不必给所有人看，但必须存在，且保留足够长的时间——多数事故是在一个月后才被发现的。

这三张表做完，再谈接哪个工具。顺序反了，工具越方便，风险扩散得越快：过去要人工点五次的操作，现在一句话就能跑完。

还有一个常被忽略的字段：用途。同一张报销单，是「查进度」还是「代提交」，需要的权限完全不同。台账里如果只记账号不记用途，等于把所有请求都当成同一种。

把这三张表放到一张纸上，其实就是一句话：这个智能体，能用哪个账号，做哪几件事，留下什么记录。写不出来，就说明还没准备好让它碰生产系统。

如果嫌复杂，可以先从最小可用版本开始：列十个最想让 AI 接的系统，每个写清三个字段——归属岗位、允许动作、日志位置。十分钟能写完，但能挡掉后面八成的争论。

大多数系统的权限只到「菜单级」：能进这个模块，就能看这个模块的所有数据。这个粒度对人勉强够用，对智能体太粗——它不会「顺手看一眼」，它会全量扫一遍。

智能体需要的是更细的粒度：能查订单，但不能改价格；能看客户手机号的后四位，但不能导出全表；能提交审批，但不能自己批准。

这类粒度靠密码管理器给不了，得靠业务系统本身的权限模型。所以 AI 接入的真正门槛，往往不在模型，而在老系统的权限设计——这一点在选型阶段最容易被忽略。

一个现实的判断方法：如果今天你没法给一个「只干一件事」的实习生配出合适的权限，那你也配不出合适的智能体权限。问题在系统，不在 AI。

落到执行上，可以先做一次「权限盘点」：把智能体要接的系统列出来，逐个标注「只读、可写、可导出、可审批」四类动作，再对照现有角色看有没有现成的窄权限。多数企业会在这一步发现，问题不是权限不够细，而是角色本来就是按部门粗分的。

很多企业把 AI 权限问题交给安全团队，结果做成了一堆禁止清单：不许连外网、不许碰客户数据、不许自动执行。这类规定能防住事故，也一并防住了价值。

更有效的做法是把它当成流程设计：这个环节需要什么信息、做完要留下什么、出错由谁兜底。把这三件事写清楚，权限自然就窄了，而且窄得有依据。

流程图比安全清单更好用的原因很简单：清单只写「不许」，流程写「怎么才行」。前者让人绕路，后者让人照着走。AI 接入最后能不能落地，差别往往就在这一点上。

1Password 这类工具的价值，是把「授权」这个动作变得可见：用户能看到请求、能拒绝、能断开。可见本身就是一种治理——很多风险不是因为授权太宽，而是因为根本没人知道授权发生过。

但可见只解决一半。另一半在系统里：账号有没有台账、权限有没有分级、操作有没有留痕。这三样补齐，AI 才真的能替人干活，而不是替人闯祸。

最后是一个很朴素的建议：先让智能体做「只读」的事。查库存、查物流、查审批进度、查历史报价——这些动作错了只是信息不准，不会造成实际损失。等团队对它的判断有了体感，再逐步放开写入与提交。