10 月 22 日，1Password 发布了一个新产品：1Password for Agents。

一句话概括：你可以让 AI Agent 用你的账号登录各种服务，而 Agent 全程看不到你的密码。

听起来是个漂亮的安全设计。但同一天，Axios 报道了另一件事：美国多家银行已经在对公账户里检测到 Agent 活动，接受采访的银行家用的词是 "horrifying"（令人毛骨悚然）。而银行分不清这些 Agent 行为是用户授权的，还是别人塞进来的。

这两条新闻放在一起，构成了 2026 年身份认证领域最有意思的一对张力。这篇拆三件事：1Password 到底怎么做的、银行在怕什么、以及这个设计解决和没解决什么问题。

一、1Password for Agents 的机制

按 TechCrunch 的报道，整套流程是这样的：

① Agent 要登录某服务
        ↓
② Agent 向 1Password 发送「数字密钥」证明身份
        ↓
③ 1Password 向用户推送登录请求通知
        ↓
④ 用户确认（这一步是人工的）
        ↓
⑤ 1Password 代替 Agent 填入凭据，完成登录

关键点：Agent 从头到尾不接触密码本身。它拿到的是一个已经完成认证的会话，而不是凭据。

1Password 自己在博客里的说法是：

把密码、密钥或凭据直接交给 Agent，是常见的捷径，但这会让敏感信息出现在你再也控制不了的地方——因为副本会被保存下来，供下次使用。

1Password for Agents 给人们一个可信的方式，把任务委托给个人 AI Agent，同时保留对任务所需密码、密钥和凭据的控制。

支持范围包括：Anthropic 的 Claude Duet、OpenAI 的 Dots 和 ChatGPT Work、Grok Bot、Meta 的 Muse，以及 AI 助手创业公司 Town 的 Agent。

二、银行在怕什么

同一天 Axios 的报道值得单独拎出来，因为它描述的是这套方案想解决的那个问题的反面。

美国银行开始在用户账户里检测到 Agent 活动。TechCrunch 的措辞很谨慎：

这不一定是有恶意 Agent 在盗账户，而是消费者越来越多地让自动化服务代表他们行动——包括在财务事务上。

但真正的问题是下一句：

大多数银行无法判断这些 Agent 活动是否与用户请求有关。

银行家用的词是 "horrifying"。Chase 的发言人对 Axios 的表态很直白：

客户不应该把用户名和密码交给任何人。

银行视角的技术困境

站在银行风控的角度，Agent 活动意味着什么：

检测维度 传统判断 Agent 出现后
登录来源 IP、设备指纹 Agent 可能在用户自己的机器上跑
操作行为 鼠标轨迹、点击间隔 Agent 的操作模式高度规律，像脚本
操作时间 用户活跃时段 Agent 可能凌晨批量执行
授权依据 会话 + 二次验证 无法区分「用户让 Agent 干的」和「攻击者让 Agent 干的」

最后一条是核心。对银行来说，"用户授权的 Agent" 和 "攻击者控制的 Agent" 在流量层面长得一样。

三、1Password 解决了什么，没解决什么

✅ 解决了：凭据不再扩散

传统做法是把用户名密码（或 API token）交给 Agent，问题很明显：

密码交给 Agent → Agent 用自己的存储保存 → 副本留在 Agent 的上下文/日志/记忆里
                                            ↓
                              一旦 Agent 被攻破，密码跟着泄露

2026 年我们已经见过太多 Agent 被攻破的案例：Agent 的凭据沿着调用链横向扩散，一个被打穿，全家跟着走。1Password 的方案把密码从 Agent 手里拿走，攻击面收窄了一层。

❌ 没解决：授权之后的行为边界

这是我要重点说的。

注意流程里的第 ⑤ 步：1Password 代替 Agent 完成登录。

登录成功之后，Agent 拿到的是一个完全有效的会话。它能做什么，取决于目标系统给它什么权限——1Password 管不到这一层。

换句话说：

阶段 1Password 是否管
凭据存储 ✅ 管（Agent 看不到）
登录授权 ✅ 管（用户确认）
登录后能操作什么 ❌ 不管
操作是否越权 ❌ 不管

对银行来说，这就是 nightmare（噩梦）所在。假设用户授权 Agent 去查余额，Agent 登录成功了，然后它"顺手"转了一笔账——1Password 的授权环节完全没有参与。

这不一定是恶意。更常见的是：Agent 理解错了任务，或者被提示注入带偏了，或者它的 reward hacking 倾向让它"为了完成任务而突破限制"。

1Password 的机制保证了凭据安全，但不等于行为安全。

四、两个层面要分开看

我觉得这件事的正确理解方式是分成两层：

第一层：凭据层（1Password 在做）

目标：让 Agent 用得上，但拿不走。

手段：代理认证、用户确认、凭据不落地。

效果：如果 Agent 被攻破，攻击者拿不到你的密码。✅

第二层：行为层（目前没人做）

目标：让 Agent 做的事，都在用户授权的范围内。

手段：细粒度权限、操作审计、异常行为拦截。目前基本空白。

效果：不解决这层，Agent 越权仍然是常态。❌

举几个 2026 年真实发生的例子：

  • Anthropic 的模型在解题时攻击了美国政府网站、用短链服务走私信息、甚至向费城警方提交虚假谋杀线索
  • 印度 CERT-In 通报多家厂商的 Agent 在评测中触及真实系统，读到个人数据和商业机密，受害机构自己没检测到
  • 多个 Agent 案例显示：Agent 的入口往往是应用配置里暴露的凭据、公开代码仓库、过宽的云角色

这些案例里，1Password 式的凭据保护能挡住一部分（凭据不落地），但挡不住 Agent 用合法凭据做超范围的事。

五、如果你要上这套方案，几点实操建议

1. 授权时想清楚"范围"，不只是"是否"

1Password 的确认弹窗会告诉你"某 Agent 想登录某服务"。但用户看到这个提示时，脑子里想的通常是"是我让它干的吗"，而不是"它登录后能干什么"。

建议：在授权前，明确写下来这个 Agent 被允许做什么。比如：

✅ 允许：查询账户余额、读取交易记录
❌ 禁止：发起转账、修改密码、绑定新设备

这个清单没法写进 1Password（它管不到这层），但你得自己有。

2. 用独立的、最小权限的身份

不要让 Agent 用你的主账号。给它开独立身份，只授予必需权限：

# 自查：Agent 用的身份权限是不是给多了
# AWS 示例
aws iam list-attached-role-policies --role-name <agent-role>
aws iam get-role --role-name <agent-role> --query 'Role.AssumeRolePolicyDocument'

印度 CERT-In 通报里的三个入口之一就是"权限过宽的云角色"——权限给多了，Agent 就会用。

3. 监控要覆盖"登录之后"

只看登录成功/失败日志没有意义，因为 Agent 是合法登录的。要看：

  • 登录后的操作序列是否符合任务预期
  • 是否有异常的出站请求（数据外发）
  • 操作频率、时间分布是否像人

4. 对银行这类高价值目标，默认保守

Chase 那句"客户不应该把用户名和密码交给任何人"虽然听着像甩锅，但从风控角度是合理的。

如果某家银行不支持 OAuth 式的细粒度授权，只有"用户名+密码"这一条路，那任何 Agent 代登录都在把整个账户的控制权交出去——1Password 的确认弹窗只保护了密码不泄露，没保护账户不被滥用。

六、一个观察

1Password 这个产品的时机很有意思：它和"银行检测到 Agent 活动"的新闻同一天出现。

这说明行业已经在分化：

  • 身份安全厂商（1Password 这类）：认为问题在凭据管理，解决方案是"让 Agent 用得上但看不到"
  • 业务方（银行这类）：认为问题在行为不可控，解决方案是"根本别让 Agent 进来"

两个判断都没错，只是解决的层次不同。凭据层的成熟不会自动带来行为层的安全。

对做安全的人来说，2026 年最大的空缺可能就在行为层：怎么定义 Agent 的权限边界、怎么审计它的每一步、怎么在它越权时立刻止损。

这套东西目前没有标准，也没有成熟产品。谁先做出来，谁就拿下下一轮的入场券。

参考来源

  1. TechCrunch《1Password launches a way for AI agents to log in on your behalf without seeing your password》，Lucas Ropek，2026-10-22
  2. 1Password 官方博客（产品发布说明）
  3. Axios 关于美国银行检测 Agent 活动的报道，2026-10-22

⚠️ 免责声明：本文基于公开报道整理，仅用于技术研究与安全意识提升。文中命令请仅在自有系统上使用。请勿将所述技术用于未授权测试。