Agent 要替你下单、替你审批、替你签合同?先解决「我到底是谁」的问题 ## 一份 2.4 版本更新引发的企业身份基础设施问题 2026 年 9 月 2 日,开源身份认证平台 Authorizer 的作者 Lakhan 在 Hacker News 上发布 2.4 版本更新,这个版本的关键词不是某个新功能,而是一个新约束——当 agent 要代替用户调用下游服务时,身份如何在一连串的调用里正确传递
Agent 要替你下单、替你审批、替你签合同?先解决「我到底是谁」的问题
## 一份 2.4 版本更新引发的企业身份基础设施问题
2026 年 9 月 2 日,开源身份认证平台 Authorizer 的作者 Lakhan 在 Hacker News 上发布 2.4 版本更新,这个版本的关键词不是某个新功能,而是一个新约束——当 agent 要代替用户调用下游服务时,身份如何在一连串的调用里正确传递、谁能代表谁、权限如何在每一跳被削减。Lakhan 直接点名这是他做 Authorizer 几年里遇到的最棘手的问题域:「服务、工作负载、agent 都在发起请求,它们的边界已经越过了传统用户/应用的二分法。」
这个 2.4 版本的核心交付是 RFC 8693 OAuth Token Exchange(令牌交换)的实现。所谓令牌交换,简单说就是:当一个 agent 要代表某个用户去调用下游服务,它不能再简单地把用户的访问令牌透传下去——因为下游看到同一个令牌,无法区分「这是用户本人在调」还是「这是一个 agent 在替用户调」,权限边界就糊了。RFC 8693 的解法是引入 actor claim(执行者声明)链:被交换出来的令牌里同时记录「subject 是谁(原始用户)」「actor 是谁(中间 agent)」「可能还有 act2、act3 等多层嵌套」,下游服务按这个链做权限削减(scope attenuation),最终有效权限是「用户允许的 ∩ agent 允许的 ∩ 本次请求请求的」三个集合的交集。Lakhan 在 2.4 里把这条链路做成了默认开启,delegated token 内置 actor chain。
第二个新增是 service accounts(服务账号)作为机器对机器身份的一等公民。Service account 可以通过三种方式身份验证:JWT bearer assertion、SPIFFE JWT-SVID(工作负载身份证明)、Kubernetes TokenReview(当 workload identity 已配置)。它们在授权模型里不再是「特殊用户」,而是 first-class subject——授权决策可以明确区分「这是一个用户」和「这是一个自主工作负载」。
第三个新增是 MCP 资源服务器保护。Authorizer 把自己的 MCP 接口通过 Streamable HTTP 暴露出来,并按 OAuth 2.1 资源服务器的方式保护它——具体实现了 Protected Resource Metadata、Dynamic Client Registration、Client ID Metadata Documents,以及 RFC 8707 audience binding。简而言之,任何一个 MCP 客户端要调 Authorizer 的 MCP 接口,都得先经过完整的 OAuth 2.1 流程,不再有「裸奔」的可能。
## 为什么 agent 时代的身份比过去更复杂
Authorizer 2.4 解决的不是一个抽象的合规问题,而是一个正在真实生产环境里爆发的运营事故源。如果把过去 20 年的企业 IT 身份基础设施压缩成一句话,就是「OAuth 是给人用的」——用户登录,服务器发 access token,客户端凭 token 调资源服务器,资源服务器校验 token 的 scope 决定放不放行。这个模型在 SaaS 时代够用,因为调用链路通常是「人 → 应用 → 后端 API」三段,actor 单一、scope 静态、生命周期跟用户 session 绑定。
但 2025 年开始流行的 agent 工作流把这个模型彻底压扁了。现在一个典型企业流程可能是这样:用户让一个 agent(Planner)在 Confluence 里起草会议纪要,Planner 又调用 Calendar agent 查与会者日程,Calendar agent 又调用 Notion agent 抓上次会议的行动项,Notion agent 又调用 Slack agent 把行动项推给相关人……整个调用链可能有 5-7 个 agent 互相串接,每个 agent 都有自己的运行时上下文和凭据。如果所有 agent 都拿着用户的原始 access token 在调用,任何一个 agent 被攻陷,攻击者就拿到了用户的全量权限,scope attenuation 完全失效——这正是 Lakhan 在 2.4 changelog 里反复强调的「keep the user's permissions separate from the permissions of the agents acting on their behalf」。
RFC 8693 的设计就是为了切断这条攻击路径。每跨一个边界,token 都被重新签发,scope 自动收敛,actor 链追加一行,审计日志多一条记录。这意味着即便 Calendar agent 被劫持,攻击者拿到的也只是「原始用户 ∩ Calendar agent 自身被允许的 scope」,既不能反向冒充用户去调 Planner agent 改文档,也不能横向扩展到 Notion agent 去看未授权的页面。对 CISO 来说,这是把传统的 IAM 边界从「人 vs 应用」细化为「人 vs agent-A ∩ agent-B ∩ agent-C ∩ ...」的多层网格,审计粒度从月度降到每次调用。
## 工作负载身份:W3C 标准之外的另一条腿
Authorizer 2.4 把 SPIFFE(工作负载身份)作为 service account 的可选认证源之一,这背后是 2024-2026 年企业基础设施领域最重要的一条技术线——NHI(Non-Human Identity,非人身份)。在传统 IAM 体系里,机器身份是「用户的一个属性」,在 AD 里叫 service account,在云厂商叫 service principal;但这些「伪装的用户」没有独立生命周期,权限继承自某个真人,撤销延迟以天计。
SPIFFE 的设计哲学是反过来的:机器身份应该是工作负载本身的属性,而不是某个用户的衍生。一个 Kubernetes Pod 启动时,SPIRE(SPIFFE Runtime Environment)会给它签发一个 SVID(SPIFFE Verifiable Identity Document),格式是 `spiffe://trust-domain/workload-identifier`,里面写了「我是哪个信任域下的哪个工作负载」。这个身份不依赖任何真人,Pod 重启就重新签发,Pod 删除就自动失效,生命周期严格绑定到工作负载本身。
Authorizer 把 SPIFFE JWT-SVID 作为 service account 的一种登录凭据,意味着企业里跑在 Kubernetes 上的 agent 可以直接用自己的工作负载身份去 Authorizer 拿 OAuth token,中间不需要任何「管理员手动创建 service account + 配 client secret」的运维步骤。这听起来像是一个技术细节,但对在生产环境跑过 agent 的工程师来说,这是省下 80% 运维工单的关键能力。
Kubernetes TokenReview 走的也是同一条路——Authorizer 直接信任 kubelet 给出的 Pod 身份证明,把 Kubernetes 集群的边界作为身份信任根。两条路合起来,Authorizer 在企业 Kubernetes 环境里实现了「agent 一启动就有身份,不需要提前注册,不需要长期 secret」的全自动 NHI 体系。
## agent-to-agent 商业基础设施的雏形:Bitroad
如果说 Authorizer 解决的是「agent 调用服务时身份怎么传」,那么 2026 年 9 月 11 日(也就是大约 10 天前)YC R26 团队 Bitroad 发布的 Agent-to-Agent 服务市场则解决了另一个侧面——agent 要互相付钱、互相交付、互相仲裁时,谁来当中介。
Bitroad 的创始人在帖子里引用了 YC RFS 的 Aaron Epstien 那句「下一万亿互联网用户不会是人类,会是 AI agent,现在是 Make Something Agents Want 的时候了」,然后他坦白说,自己也经历了从「这到底什么意思」到「我得把基础设施搭出来」的转变。Bitroad 的产品形态是:一个 seller agent 在平台上挂出一个服务(盲代码审查、双人密室评审、跨 seller RFQ 竞拍……任意合法服务);一个 buyer agent 找到它,要么直接购买,要么请求报价;seller 交付,买家确认后付款释放,或者无人申诉 7 天后自动释放。两个 agent 从不直接对话——都通过 Bitroad 的 MCP 端点(`https://app.bitroad.ai/api/v1/mcp`,OAuth 2.1 auto-discovery)对接,Bitroad 是中介、托管方、仲裁方。
Bitroad 在每一次扣费前都会跑同一组校验:人类设置的支出上限(单笔/单日/累计,跨两个主体求和)在每次扣费前重新评估、报价对照挂牌价区间重新验证、只有这些都通过了才通过 Stripe 实际扣款。超出上限直接拒绝,不发起任何动作。每笔交易都捕获「人类是谁、agent 实例是谁、它在哪个 delegation 下运行」三要素,「agent 背后必须有一个具名的人」是平台刻意的设计约束——没有人类挂靠的 agent 不能买也不能卖。
这是非常具体的产品设计选择,也对应了 RFC 8693 + SPIFFE 的合规要求:Bitroad 的 MCP 端点是 OAuth 2.1 protected resource,任何接入的 buyer agent 必须先经过 OAuth discovery,拿到合法的 access token 才能发起调用;而它在每次扣费前捕获的「agent 实例 + delegation」信息,恰好就是 actor chain 里 act1、act2 那一层。这两条技术线——Authorizer 2.4 的 RFC 8693 实现 + Bitroad 的 OAuth 2.1 MCP 端点——合起来看,其实就是 agent 商业基础设施的雏形:身份层和结算层各自独立,但都建立在 OAuth 2.1 + RFC 8693 + MCP 的同一组协议之上。
## 对企业的具体含义
如果你的公司正在评估或已经在用 agent(无论是 OpenAI 的 Operator、Anthropic 的 Claude Code、Cursor 的 Background Agent,还是自建的内部 multi-agent 系统),Authorizer 2.4 + Bitroad 这一对组合给出了三个非常具体的工程信号。
第一,身份基础设施升级不能再拖。 过去 5 年企业 IT 的身份投资集中在「员工能不能登录」「客户能不能下单」这些单跳场景;但 2026 年的 agent 工作流是 5-7 跳的多层调用,任何一个中间节点被攻陷都可能导致用户身份被冒充。RFC 8693 的 actor chain、scope attenuation、audience binding 这三件套不是可选项,是 baseline。一个还在用「长期 access token 透传 + 静态 scope」的企业,任何 agent 化改造都是在裸奔。
第二,MCP 端点要按 OAuth 2.1 resource server 标准保护。 Authorizer 2.4 实现的那套 Protected Resource Metadata + Dynamic Client Registration + RFC 8707 audience binding,本质上是把 MCP 端点当成 first-class 公民来对待——它不是某个内部 API,它是面向外部 agent 的资源接口,任何不鉴权的 MCP 暴露都等于把公司系统开放给全网。Bitroad 的 MCP 端点已经按 OAuth 2.1 标配来做了,这会成为行业模板,任何 2026 年下半年新发布的 MCP 服务,不按这个标准来就是合规欠账。
第三,NHI(非人身份)治理要进入 CISO 议程。 过去 NHI 是 IAM 团队的小众议题,但 2026 年开始 NHI 的数量会快速超过人类身份——一个企业跑 100 个 agent,就有 100 个 SPIFFE workload identities、100 个 Kubernetes service accounts、可能还有 200 个 API keys 用于 MCP 客户端。传统「人离职就删账号」的 IAM 流程已经无法覆盖这种密度,需要的是 SPIFFE 式的「身份跟着工作负载生命周期自动创建和销毁」机制。Authorizer 2.4 把 SPIFFE 列为 service account 的可选认证源,就是给企业开了一条低成本的迁移路径。
## 一个悬而未决的协议问题
这两份发布合在一起,揭示了 2026 年下半年 agent 基础设施领域最大的悬而未决问题:agent delegation 的标准应该谁来定。OAuth 2.0 的 RFC 6749、RFC 6750 解决了「人登录」的 token 流程;RFC 8693 解决了「token 怎么交换」的委托语义;RFC 8707 解决了「token 给谁用」的 audience 绑定;OAuth 2.1 把这些打包成现代最佳实践。但 agent 时代还缺一块——跨厂商、跨框架、跨 agent runtime 的 delegation 互操作协议。
Bitroad 在帖子里说「两个 agent 从不直接对话」,依赖 Bitroad 当中介;Authorizer 把 SPIFFE 作为信任根,假设企业已经在跑 SPIRE 集群。但这两个模型之间没有标准桥梁——Bitroad 怎么消费 Authorizer 的 token、Authorizer 怎么理解 Bitroad 捕获的 actor chain,目前都是私有实现。在一个 agent 商业生态即将从「单点实验」走向「多 agent 协作」的转折点,这种协议层的真空会很快成为瓶颈。
对企业来说,这意味着今天选 agent 基础设施时,要特别留意厂商在 delegation 协议上的开放程度——是按 RFC 8693 + RFC 8707 + OAuth 2.1 标准实现,还是闭门造车。选前者,未来切换成本低;选后者,会被单家供应商锁死 3-5 年。