Agent 身份标准还在变，企业该等规范还是先落最小控制？

采购团队已经把供应商协同 Agent 接入试运行：它能查询合同、库存和供应商信息，也准备在审批后创建订单。与此同时，安全团队还在讨论 Agent 应该怎样注册、怎样代表员工访问跨应用资源，以及未来采用哪套身份标准。

业务不会等标准会议结束。企业真正要回答的，不是“哪项协议会最终胜出”，而是：在标准仍在演进的今天，怎样让已经开始工作的 Agent 不匿名、不越权、可追责、能随时停下来。

两种看似省事的做法，都会留下长期风险

第一种做法是等。等注册、委托和跨应用授权标准全部成熟，再统一建设。问题是，试点不会因此消失。项目组往往会先用共享账号、静态密钥或人工补审批把流程跑起来，治理空窗反而越来越大。

第二种做法是先直连。把业务系统的长期凭据交给 Agent，让它尽快完成任务。这样上线最快，却很难说清：这个 Agent 属于谁、代表谁、能访问什么、凭据何时失效、离职或项目下线后怎样撤销。

更稳妥的第三条路，是先落下与具体协议版本无关的最小控制，再用适配层承接标准变化。标准更新时，可以替换注册或换证方式；身份、权限、审计和撤销这些治理基础不必推倒重来。

第一项控制：每个生产 Agent 都必须有身份和负责人

企业首先要把 Agent 当成一类正式资产，而不是一段临时脚本。每个进入生产的 Agent，都应有唯一标识，并记录用途、所属团队、负责人、运行环境和生命周期状态。

这里还要区分几个容易混在一起的对象：员工是委托者，Agent 是完成业务目标的企业资产，Agent Client 是具体接入实例，运行身份则可能随环境和工作负载变化。把它们压成一个账号，短期简单，长期就无法回答“是谁以什么身份做了这件事”。

数犀 Agent Identity 的价值，是把 Agent、Owner、Client、运行身份和生命周期组织成可管理关系。项目换人、实例扩容或环境迁移时，企业仍能定位责任主体，也能停用孤儿 Agent，而不是四处寻找散落的密钥。

第二项控制：每次访问都要有明确委托和到期时间

员工可以查询合同，并不等于 Agent 自动继承员工的全部权限；Agent 被允许查询，也不等于它可以创建订单。

因此，访问授权至少要说清四件事：谁委托了哪个 Agent，访问哪个 Resource，允许哪些 Scope，以及授权在什么时候失效。凭据应尽量短期化，运行时按需获取，而不是把长期密钥写进提示词、配置文件或自动化脚本。

在数犀的能力链中，用户委托、Resource/Scope、短期凭据和 Token Exchange 可以共同承接这件事：先确认身份与委托关系，再为具体访问换取范围受限、时效明确的凭据。即使某个 Client 泄露，影响范围也更容易被控制。

第三项控制：在业务动作发生前执行最小权限策略

只在登录时鉴权还不够。真正的风险发生在工具调用前：Agent 准备调用什么工具、携带什么参数、操作哪类数据、是否触发高风险动作。

采购场景里，“查询库存”和“创建订单”显然不应共用一条粗粒度授权。金额超过阈值、修改收款信息或访问敏感供应商资料时，还可能需要拒绝或转人工确认。

这要求策略执行点尽可能靠近最终动作。数犀可以结合用户、Agent、资源、Scope 和调用上下文做访问判断，让授权从“这个 Agent 能不能进系统”细化为“这一次动作能不能执行”。

第四项控制：审计必须能够还原决策，并支持撤销

企业不能只记录“接口调用成功”。一条可用的审计链至少要回答：谁代表谁、使用哪个 Agent 和 Client、请求了什么工具与范围、策略为何允许或拒绝、凭据何时签发，以及后续业务执行结果是什么。

同时，授权必须可撤销。员工离职、Agent 下线、Owner 变更、凭据疑似泄露或风险策略调整时，都应能及时收回访问。需要特别注意：身份与网关审计证明的是访问决策，不天然等于下游订单已经创建成功；业务结果仍要结合连接流日志和目标系统回读。

要让这套控制真正执行，还需要把委托者、企业资产、接入实例和运行身份分层管理。

标准变化时，替换适配层，而不是重建治理底座

今天，Agent 身份和跨应用授权相关规范仍在演进。企业可以持续跟进 OAuth 2.1、Discovery、DCR、CIMD 等方向，但不必把生产治理押在某一个仍变化的实现上。

更可执行的路线是分三步：先盘点已经上线和准备上线的 Agent，补齐身份、Owner、委托、短期凭据、策略与审计；再把协议差异收敛到注册、发现和换证适配层；最后随着标准与产品验收成熟，逐步替换适配实现。

数犀当前的 Agent 身份、MCP 鉴权、安全策略、短期凭据、审计与撤销能力，可以作为这条渐进路线的治理底座。与此同时，对仍待完成正式初始化或 UAT 的协议能力，应继续保留明确边界，不把产品规划写成已经普遍可用的事实。

先检查一条真实链路

如果企业已经有 Agent 进入试点，可以先选一条最接近生产的链路，逐项检查：它有没有唯一身份和负责人？是否明确代表谁？使用的是长期密钥还是短期凭据？调用前能否按资源、Scope 和风险判断？出现异常时能否还原并撤销？

标准会继续变化，但这五个问题不该等待。越早建立最小控制，企业越能把 Agent 的速度，转化成可持续的生产能力。