让智能体看不见密码

浏览器智能体要替人办事，就绕不开登录这一步；可一旦把密码明文交给它，密码就会进入模型上下文、记忆和日志，随时可能被提示注入、跨域读取或被人套走。

2026 年 7 月 16 日，1Password 与 Anthropic 推出 1Password for Claude，给出一个“零暴露”答案：智能体只负责说要登录哪个网站，密码由密码管理器直接填进网页，全程不进入模型上下文、记忆和厂商系统。

它的关键不是“让模型更守规矩”，而是让机密根本不经过模型：本地信任锚、端到端加密、逐会话授权、生物识别批准，填充那一刻智能体甚至会“闭眼”。

但这项技术并非银弹，独立研究发现浏览器智能体仍可能从 DOM 读到掩码密码、注入脚本，且登录成功后的会话本身仍在智能体手里。

对银行而言，这是一个值得直接照搬的设计范式：把“给智能体密码”换成“给它一次受限、短命、可审计、当面批准的授权”。

一、问题：智能体登录为什么是死结

1. 登录是刚需：浏览器智能体要查邮件、对账单、开发票、改设置，第一步几乎都是登录，而登录依赖密码、一次性验证码这类可重用机密。
2. 密码一旦进入上下文就失控：大模型会把页面内容、输入框、DOM 文本读进上下文，密码因此可能出现在对话记忆、日志、用于训练或排障的数据里，也可能被一段藏在网页里的提示注入套出。
3. 模型无法自己过滤敏感信息：Anthropic 在《Use Claude in Chrome safely》中明确，Claude 无法从它看到的内容中过滤敏感信息，因此官方建议不要在敏感站点使用、或用一个不登录敏感账户的独立浏览器配置。
4. 同源策略对智能体失效：浏览器用三十年的同源策略阻止不同网站互相读取，但智能体在浏览器之上能看到所有标签页，是否隔离取决于模型能否抵御提示注入，这正是安全研究最担心的地方。
5. 传统密码管理器是给人用的：它默认“看屏幕、点按钮的是人”，一旦控制权交给智能体，自动填充弹窗、内联建议反而可能被智能体点击利用。

二、核心思路：把“给密码”改成“借授权”

1. 委托而非交付：1Password 在其《Delegated authority, running locally》中把这一模式称为“本地委托授权”，智能体代具体人行事，但人始终是授权主体，智能体不持有自己的常驻机密。
2. 本地信任锚：由用户早已信任、保管密钥的独立代码签名应用（1Password 桌面端）充当“信任锚”，类似工作负载身份代理；长寿命密钥留在锚的安全区，智能体手里没有任何长寿命密钥。
3. 最小、短命、可审计：每次授权只针对一个会话、一个登录项，任务结束即销毁，每次释放都记入使用历史，可追溯到具体的人和具体的智能体会话。
4. 人在回路：密码是否释放，不取决于智能体的请求，而取决于用户在一次弹窗里的显式生物识别批准。
5. 机密不进模型：携带真实权限的秘密只在密码管理器与网页之间流动，模型侧只表达“意图”，永远拿不到原始密码。

三、零暴露架构的四条规则

1Password 官方安全说明把这套集成概括为四条硬规则。

1. 智能体永不接触机密：Claude 只能描述需求、触发填充，凭据的解密与填充完全由 1Password 自己的软件完成；智能体只收到凭据项的元数据和成功/失败状态，从不收到密码值。
2. 每次释放都要人批准：没有常驻批准（no standing approvals），一个新的智能体会话意味着一次新的批准弹窗。
3. 访问范围限定且短命：凭据只释放给单个 Claude 会话，用该会话专用密钥加密保存，会话结束或达到硬性时限后丢弃。
4. 敏感数据全程端到端加密：保险库数据静态加密，传输中从桌面应用到浏览器扩展走双向认证、端到端加密通道，中间的智能体和本地传输都无法读取。

四、技术拆解：密码如何不被看见地填进网页

1. 一次性应用配对：Claude 桌面端首次使用须与 1Password 桌面端配对。1Password 借助操作系统的代码签名能力校验对方：必须有效签名、签名身份在可信伙伴白名单内、且由 Anthropic 已验证的 Apple 开发者团队发布，任何其他进程的请求都被拒绝。
2. 逐会话的智能体身份：每个智能体会话单独注册，Claude 为会话声明一个标识符，1Password 据此铸造绑定该标识符的加密会话凭据；官方称这是类似 OIDC 的本地联邦模型，之后每个请求都要密码学地证明持有该会话密钥，一个会话拿到的凭据对其他会话不可见。
3. 请求被当成不可信输入：智能体说明要登录哪个站点、可附简短理由，但 1Password 把请求每个字段都视为不可信声明，只用于匹配凭据项并以纯文本渲染，请求内容无法触发释放、也无法冒充 1Password 的界面。
4. 生物识别显式批准：桌面端弹窗显示智能体请求的是哪个保险库项、为什么，用户可以批准、换一个登录项或拒绝，并用 Touch ID 等生物识别确认；批准后只把所选项释放给当前会话，下一次请求重新弹提示。
5. 本地盲中继加 Noise 加密：1Password 浏览器扩展与桌面应用之间走本地回环中继，中继是“盲传输”，每条消息在两端用基于 Noise 的协议端到端加密，带双向认证和每会话密钥，中继既读不到也改不了载荷；机密全程不经过 1Password 或 Anthropic 的服务器。
6. 内存暂存、绝不落盘：批准后的凭据经加密通道到扩展，扩展用 AES-256-GCM、以会话密钥派生的密钥仅在内存中加密保存，不写磁盘；任务完成、浏览器关闭或达到硬性上限九小时后销毁，每次授权都记入账户的使用历史。
7. 智能体只看得到“标签”：智能体只能看到已批准项的概要——标题、用户名/邮箱、保存的网站，类似自动填充建议，足以选对凭据但永远不含秘密值；其余回应只有成功或失败。
8. 填充那一刻智能体“闭眼”：这是整套设计最精巧的一环。填充是凭据唯一进入网页的瞬间，此时智能体进入睡眠、停止读取和跟踪页面，直到 1Password 报告结果；1Password 在此窗口完成填充、提交并确认提交发生，成功时代理再看页面，密码已离开，失败则先清空所有已填值再交还控制。
9. 只填进匹配的网站：凭据项只会被填进与该项保存网址匹配的页面，防止智能体把密码送进仿冒站点。
10. Agentic Mode 自动锁定：当智能体接管某个标签页时，1Password 扩展会从页面上移除自身全部界面（内联建议、自动保存提示、通知），让智能体无法通过点击便利界面触及未批准内容，范围限定在该标签页，会话或标签关闭即结束；该模式在扩展层默认开启，即使没配置 1Password for Claude 也生效。

五、更完整的蓝图：信任锚与控制平面分离

1Password 同时发布了一份“本地委托授权”参考架构，明确其中哪些已经落地、哪些仍是方向。

1. 设备级密钥托管：信任锚在苹果 Secure Enclave 或 Windows TPM 等安全区持有设备绑定密钥对，私钥不出安全区，智能体不持有长寿命密钥。
2. OS 充当证明权威：每次请求，信任锚先校验调用进程的代码签名身份（macOS 代码签名、Windows Authenticode），操作系统在没有可信执行环境的消费设备上替代 TEE 完成身份证明。
3. 短寿命工作负载身份：架构建议用 SPIFFE 工作负载标识和十分钟以内的短期身份令牌，智能体的“身份”由代码签名证明后获得，不能自报家门。
4. 一个令牌、两个身份：委托访问令牌同时携带 sub（被代理的人）与 act（执行动作的智能体），让每条审计记录都能还原“这个智能体代表这个人”，并要求令牌权限严格是人的权限子集。
5. 控制平面与模型分离：这是最关键的原则——携带真实权限的访问令牌和逐次交易令牌绝不进入语言模型，由一个独立的“网关”持有并附加到出站请求、再返回净化结果，模型只表达意图和工具描述；这样即使提示注入也偷不走令牌、无法越权重放。
6. 意图绑定与可撤销：更完整的方案还包括约六十秒、绑定具体意图与工具的交易令牌，策略执行点与策略决策点分离，以及标准的风险事件撤销机制；官方坦承这些尚未在产品中全部落地，属于行业共建方向。

六、它不解决什么：残留的四个风险

官方安全说明也列出了“已接受风险”，独立研究则给出了更尖锐的提醒。

1. DOM 里的掩码密码仍可能被读：华盛顿大学 Roesner 与 Kohlbrenner 在 2026 年 ICLR 研讨会上报告，他们测试七款浏览器时，Claude for Chrome 与登录态的 ChatGPT Atlas 曾读取到掩码密码字段，Claude 解释是用了读取页面 DOM 的工具，而 DOM 里存的是明文；1Password 方案保证填充瞬间闭眼，但对已登录页面、其他来源的掩码字段，Anthropic 并未正面回应这一发现。
2. 扩展权限带来脚本注入面：同一研究中，仅 Claude for Chrome 可被注入 JavaScript，因为它以浏览器扩展形式运行、拥有访问所有域的权限；这是便利与攻击面的权衡。
3. 会话令牌与 Cookie 仍是目标：即使看不到密码，智能体继承了用户已登录的会话，Cookie 与站点令牌同样能让它以你的身份操作；1Password 明确其保证覆盖凭据的存储、批准、交付与填充，不覆盖登录成功后智能体在会话内的行为。
4. 提示注入与同源弱化未根除：研究的核心结论是“同源策略的强度，被降低到智能体抵御提示注入的强度”；Anthropic 自称针对其配置的攻击成功率低于 0.08%，但同时强调风险不为零。需要说明，该研究测试于 2026 年 1 至 2 月、无版本号、尚无独立复测，结论应作为风险提示而非最终判决。

七、行业横向对比

1. Google（Gemini in Chrome）：由 Google 密码管理器在用户授权后替智能体登录，密码不共享给 Gemini，但官方同样声明防护不覆盖全部风险，且功能有地区、年龄与套餐限制。
2. Microsoft（Copilot in Edge）：浏览时 Copilot 无法访问自动填充、已保存密码与钱包，但可以访问 Cookie，意味着你已登录的站点它也处于登录态。
3. Brave（Leo AI）：走架构级隔离，用独立浏览配置运行智能体浏览，Cookie、登录态、缓存不跨配置，但该开关默认关闭。
4. 1Password 路线：属于“机密带外注入”，用独立信任锚把密码挡在模型之外；Brave 属于“会话隔离”，二者互补而非互斥。
5. 共同短板：没有一家厂商声称完全解决提示注入，密码问题解决了，已登录会话中的越权动作仍是开放问题。

八、对银行的技术与风控启示

1. 网银密码绝不进智能体：无论客服机器人还是对客助手，都不应让用户把登录密码、短信验证码、U盾口令输入或暴露给模型；应让银行 App 或独立安全组件充当信任锚完成认证，智能体只拿到授权结果。
2. 用令牌化代替可重用密码：以 OAuth 式短时令牌、通行密钥（passkey）、一次性交易凭据替代可重用密码，令牌绑定主体、智能体、范围、金额、商户与有效期，且权限严格小于客户本人。
3. 动作级强身份核验：把登录与高危动作分开，转账、改预留信息、加收款人等关键步骤做 step-up 生物识别或硬件密钥核验，即使智能体在已登录会话里被诱导，也无法完成高危动作。
4. 机密与模型上下文隔离：银行内部为 RPA、开发与运维智能体建设特权访问管理与凭据保险库，数据库口令、API 密钥由网关注入、只在内存短时存在，禁止把机密写进提示词、工具描述或训练语料。
5. 独立身份与保险库：为智能体配置独立浏览器环境或服务身份，不与员工、客户的登录态混用；默认关闭跨域与自动填充，按最小授权逐项开放。
6. 把会话当成新的攻击面：密码看不到不等于安全，Cookie、令牌、已登录会话同样要监控异常操作，建立智能体行为基线、越权检测与速率限制。
7. 供应商尽调硬指标：采购或集成第三方智能体时，把“凭据是否进入模型上下文、是否经独立保险库、是否逐任务生物授权、是否有公开安全白皮书与威胁模型、是否支持企业级开关与审计”列为准入清单。
8. 审计要能归属到人：借鉴 sub/act 双身份设计，确保智能体每一步操作都可还原到具体客户或员工、具体智能体版本与具体授权记录，满足可追溯与责任认定。
9. 隔离与纵深防御：对高风险操作使用独立配置、独立终端或隔离区，结合网络分段、数据脱敏与“只读优先、写入复核”，不把安全押在单一提示词护栏上。

九、落地清单

1. 盘点所有会让智能体接触密码、验证码、令牌、密钥的系统，标出“机密进入模型上下文”的路径。
2. 引入或自建凭据保险库与本地信任锚，统一接管认证，智能体只表达意图、不持有秘密。
3. 对每次凭据释放做显式、可追溯的人或策略批准，禁止常驻授权与批量放行。
4. 对高危金融动作实施意图绑定的短时令牌与二次核验，并设置金额、收款方与时效约束。
5. 为智能体建独立身份与隔离环境，关闭不必要的跨域、脚本与自动填充能力。
6. 建立覆盖会话期行为的审计与风控模型，监测提示注入、越权与异常交易。
7. 将上述要求写入供应商合同与验收标准，要求对方提供威胁模型、已知限制和事件响应承诺。

结语

1Password for Claude 是一个切口很小、原则很大的技术。它把过去“相信模型会替你守好密码”的脆弱假设，换成了“密码从一开始就不经过模型”的结构性保证：本地信任锚、Noise 端到端加密、AES-256-GCM 内存暂存、填充时让智能体闭眼、逐会话生物授权——这些机制组合起来，回答了“智能体如何在不持有秘密的情况下使用秘密”。但它也诚实地划出了边界：它管得住密码的存储、批准、交付与填充，管不住登录之后的会话，更没有终结提示注入。对银行来说，真正可借鉴的不是某一款插件，而是背后的设计哲学：身份可以委托，机密必须隔离，授权应当短命、最小、可追溯，而最终的放行权永远握在人手里。 沿着这条路，把“看不见密码”推进到“越不了权、赖不掉账”，才是智能体时代金融身份体系真正要补齐的功课。

（口径说明：本文事实依据 1Password 官方新闻稿、安全说明与本地委托授权参考架构博客（2026 年 7 至 8 月）、Anthropic 官方帮助与安全说明，以及 Notebookcheck 综述的华盛顿大学等学术研究。1Password for Claude 截至发文为 macOS 付费套餐 beta，仅支持登录项与一次性验证码，不支持信用卡、身份信息等；参考架构中 SPIFFE 工作负载身份、sub/act 令牌交换、逐次交易令牌与标准撤销机制，官方明确为尚未完全落地的方向。安全研究测试于 2026 年 1 至 2 月、无版本号、尚无独立复测，部分研究受企业资助，引用时已注明。具体产品能力与安全边界以官方当时有效文档为准。）