银行已经在拦截那些使用客户主动提供的凭据登录的 Agent。摩根大通表示，他们正在封禁那些共享凭据并转移资金的服务，同时也在研究如何以正确的方式实现这一点。
我们正走向一场分裂。一些企业在为 Agent 敞开大门，另一些则在封堵它们的入口。沃尔玛刚刚宣布推出基于 MCP 的 Agent Gateway（Agent 网关），先从开发者测试版开始；下个月还将上线带有消费限额的 Agent Profiles（Agent 档案）。
在 Meta 的财报电话会议上，扎克伯格表示购物是 Muse 最常见的用例，平均订单金额超过 200 美元。这绝对是一个金融问题，而解决它的回报极其丰厚。
David Sacks 认为，银行应该支持一种由客户授予、限制和撤销的访问方式。我认同这个方向。更难的问题是：怎么做？
在银行眼里，你的 Agent 就像一个巨大的欺诈与责任风险。
交出我的登录信息，并不能告诉银行是哪个 Agent 在使用它、我让它做什么，或者它的操作是否与我的指令一致。客户可以批准某项访问权限，而不必批准 Agent 可能尝试的所有操作。
我感觉是时候画张图了。
一共分四层：入口（Entry）、身份（Identity）、工具（Tools）和意图（Intent）。
1. 入口：给 Agent 一个受支持的进入方式。
Personal Agent Protocol（个人 Agent 协议，简称 PAP，现更名为 Poppy），让企业能够公开发布 Agent 与其交互的方式：在哪里登录、提供哪些接口、以及会授予什么权限。
我的 Agent 会发现这些信息，并使用受支持的登录流程。我来批准访问权限；企业决定允许哪些操作。这些权限可以被限制和撤销。美国银行（Bank of America）和富国银行（Wells Fargo）是设计合作伙伴，这意味着他们在参与塑造这套标准，而不是承诺我的 Agent 明天就能用他们的银行 App。
Visa 的 Trusted Agent Protocol（可信 Agent 协议，TAP）让购物 Agent 可以用签名信息进行自我介绍：“我是通过 Visa 项目认证的购物 Agent，我在为这位客户购物，这是付款方式。”商家可以在放行前核验这些信息。但它仍然需要确认我是否批准了这笔购买。
Web Bot Auth 让网站能够核查是谁在运营这个 Agent。光自称“Muse”是不够的；网站会将请求的签名与运营方公布的密钥进行比对。TAP 对购物 Agent 就采用了这种方式。
这些方案是互补的：“嘿，我是个机器人，是个好机器人，我想做件事。”
2. 身份：带上服务所需的证明。
Proof 的 x401 让服务可以索要关于 Agent 背后那个人的证据。银行说明需要什么，Agent 出示凭证，银行进行核验。“我的 Agent 说我是 Simon”只是一个声明；来自可信签发方的签名凭证才能提供证据。
OpenID for Verifiable Presentations (OpenID4VP) 是钱包出示该凭证的方式。x401 负责索要证据；OpenID4VP 负责协助交付。
FIDO 标准是通行密钥（passkey）的基础。 我用面部、指纹或设备 PIN 码解锁，设备随后发送一个可供服务核验的签名。我的生物特征始终留在设备上。这样无需把密码交给 Agent 就能完成身份验证；但它本身并不能确立我的法律身份。
现有银行客户可能只需要完成身份验证。新客户或受限服务可能还需要经过验证的身份或资格。
3. 工具：给 Agent 一个精确的操作方式。
MCP 让银行能够描述 Agent 可以做什么以及如何发起请求。“要冻结卡片，就调用这个工具并提供卡号 ID。”Agent 发送 ID；银行返回结果。
WebMCP 通过浏览器提供结构化工具，这样 Agent 可以直接使用“冻结卡片”工具，而不必去猜该点哪个按钮。API 则提供直接的软件接口。MCP 可以描述一项操作，而 API 在底层执行这项工作。
Agent2Agent (A2A) 让我的 Agent 可以把任务交给企业的 Agent，并跟踪进度。但它无法证明我授权了这项任务。
浏览器是可预见的未来里，Agent 访问众多服务的主要途径。它们只能逐页点击，因为目前只有这种方式可用，而一个意外的弹窗就可能让整个任务泡汤。
访问控制权依然在企业手中。发现了一个“转账”工具，并不意味着我的 Agent 就有权清空我的账户。
4. 意图：让操作与我批准的内容相匹配。
找不到手机时那种心慌的感觉已经够糟了，更别提还要挨个通知每一家银行。我希望我的 Agent 能冻结我的卡片并锁定设备。“冻结我的卡”并不等于授权转账或修改账户信息。
购物还会附加条件。如果我让 Agent 订酒店，“合适”意味着要有 25 磅以上的免费哑铃、小冰箱和免费取消政策——因为行程随时会变。我可能只批准某个特定房间、特定日期，以及每晚含费用在内 200 美元的预算。
批准只是第一步。接收服务随后还需要将实际预订内容与这些条件进行比对。一间 190 美元但附加 60 美元费用的房间就超出了我的限额。签署付款也无法证明这家酒店有我想要的健身房。
x401 还可以请求签名操作。 我在设备上查看条款并批准，服务在执行前会核验签名后的响应。只要提供方支持，这不仅能用于支付，还能覆盖账户变更和文件签署。
Mastercard 的 Verifiable Intent（可验证意图）为企业提供签名证据，将我的授权与 Agent 的购买行为关联起来。它会核验签名和交易是否符合限额，而不是听信 Agent 的一面之词。
Google 的 AP2 将结账与支付权限（称为 mandate，即授权指令）关联起来。商家核查 Agent 可以买什么；支付提供方核查它是否可以在这次结账中使用我的支付方式。
Visa Intelligent Commerce 提供支付指令与控制机制。我对一条指令进行身份验证；Agent 请求支付凭证，Visa 则根据该指令核验请求和商家的付款。TAP 帮助识别 Agent；而这些控制机制负责管理支付。
欧洲的强客户认证（Strong Customer Authentication）提供了一个有用的升级验证对比：对于相关的远程支付，批准是与金额和收款方绑定的。它不会给我们一个通用的权限去处理整个“丢手机”流程。
企业依然得点头同意。
归根结底，消费者需要掌控 Agent 的行为。
没错，每家银行仍必须为自己的服务授予访问权限。我的指令不能代替银行做出许可。实现这一切的协议都已经存在，只是需要把它们串联起来；而且 Agent 需要汇报结果，让我知道哪些已受保护、哪些仍需关注。
每个人的风险偏好可能不同。
我很乐意让 Agent 自行处理几百美元以下的消费。但超过这个数额，我希望它先来问我，并留下审计轨迹，记录是哪个已知 Agent 做了什么事。
如果我们拥有：
- 消费者权限（通过意图实现）
- 并与 Agent 开发者及真人的身份相关联
- 可以向企业和银行请求权限
- 并且整个过程都有审计轨迹
那么未经授权的 Agent 就会越来越少。
当然，问题在于“获得授权”往往意味着“要付钱”。摩根大通与 Plaid 的数据访问协议已经包含了定价条款，而这份协议花了将近十年才最终敲定。
你觉得银行不会向 Meta 索要更多吗？
我们花了好几年时间让客户更容易点对按钮。现在，他们的 Agent 带着指令来了。
我们需要让 Agent 能够证明自己的权限并把事情办成。
而这可能意味着银行在这个过程中也要分一杯羹。
如果你喜欢这篇文章，我还在 brainfood.xyz 写作——欢迎来看看 :)
