跳转到主要内容

Agent 身份是基础设施原语,而非登录凭证

自主 agent 需要可委托、可撤销的机器身份,拥有自己的密钥、作用域和审计轨迹——而不是借用用户会话。

电路板的微距照片,在浅景深下显示走线、焊点和元件标记。

会话假设的崩塌

大多数 agent 系统都建立在一个从 Web 自动化继承而来的隐含假设之上:agent 只是一个更快的浏览器。它携带用户会话,呈现相同的 cookie,访问相同的端点。只要 agent 只做读取,这个假设就成立。一旦 agent 尝试进行交易,它就会失效。

OAuth 回答不了这个问题。访问令牌描述的是资源所有者对客户端应用的授权。它记录的是人类同意了什么,而不是当前正在行使该授权的自主进程是哪一个。当一个用户有三个 agent 针对同一账户运行时,令牌在所有 agent 之间是完全相同的。无法在不撤销其他 agent 的情况下撤销某一个 agent,也无法在事后将某笔具体交易归因到某个具体行为者。

缺口不在认证。缺口在身份。

委托身份需要什么

委托机器身份是由主体的控制平面签发给特定 agent 的凭证,携带自己的生命周期。它具备用户会话所没有的三个属性。

独立于主体的稳定标识符

agent 需要自己的密钥材料和自己的轮换计划。主体——agent 所代表的人类或组织——仍然是权限根,但 agent 是一个具有独立公钥的独立主体。正是这种分离使归因成为可能:签名请求指明 agent,agent 的密钥证明该声明,而无需暴露主体的凭证。

轮换应当独立进行。如果 agent 的密钥被泄露,轮换它不应迫使人类在所有地方重新认证。反过来,如果主体的凭证轮换,agent 的委托授权应当通过重新签发路径存续,而不是通过修改密码。

显式的作用域收窄

Circuit board macro

委托授权应当同时在三个轴上保持狭窄:

  • 按交易对手。 被授权从某个商户购买的 agent,并不被授权从另一个商户购买。作用域应当指明依赖方,而不是泛化的 API 表面。
  • 按交易类别。 读取、预留、提交和退款是不同的权限。大多数 agent 对前两者的需求远多于第三项。
  • 按时间窗口。 为结账流程签发的授权应当在流程结束时过期,而不是在会话 cookie 过期时。具有显式续期的短时授权比具有宽泛作用域的长时令牌更容易推理。

一个具体机制是签名能力令牌——agent 向交易对手出示的结构化凭证,包含 agent 标识符、允许的交易对手、允许的操作类别、有效期窗口,以及回溯到主体的签名链。交易对手验证签名链并在本地强制执行作用域。主体的控制平面无需在线即可让交易继续进行,但它仍然是唯一能够铸造新授权的一方。

不触及人类的撤销路径

撤销是最常缺失的属性。如果阻止某个 agent 的唯一方式是修改账户密码,那么这个 agent 就不是真正的委托——它在冒充。撤销必须是一等操作:在控制平面中将 agent 标识符标记为已撤销,发布该状态,并让交易对手拒绝已撤销凭证的出示。人类的凭证从不参与其中。

设计规则:身份作为控制平面资源

实际后果是,agent 身份与数据库凭证或服务账户属于同一类别。它由基础设施签发、限定作用域、限流、撤销和记录日志,而不是由登录表单完成。

这意味着控制平面需要一个注册表,为每个 agent 定义生命周期:

agent_id        稳定的、不透明的、永不复用
principal_id    权限根
key_material    公钥、轮换计划
scopes          [{counterparty, action_class, window}]
state           active | suspended | revoked
rate_limits     按交易对手、按 action_class
audit_log       仅追加,记录每一次出示

身份的每一次使用都会写入审计日志:哪个 agent、哪个交易对手、哪个操作类别、哪个授权,以及结果。正是这条记录使有争议的交易可被解决。没有它,代表主体行动的 agent 与主体直接行动就无法区分,问责会坍缩回人类身上。

Server rack closeup

为拒绝而设计

交易对手会对自主流量进行指纹识别并限流。有些会直接拒绝。这是正常的运行状况,而不是错误路径。将拒绝视为可重试异常的 agent 架构,会针对一个已经做出决定的交易对手产生不断升级的流量。正确的行为是记录拒绝、将其上报给主体,然后停止。

限流也应当位于边界中 agent 的这一侧。具有按交易对手上限的委托身份,可以防止 agent 耗尽主体同样需要的配额。它还会产生一个信号:对某个交易对手持续施加限流压力,是作用域错误的证据,而不是 agent 需要更多容量。

权衡

这种设计比复用会话更昂贵。它需要注册表、签名机制、轮换计划、撤销通道和审计流水线。它会给每笔交易增加延迟,因为交易对手必须验证凭证链,而不是接受 cookie。它需要与那些可能尚不接受委托凭证的交易对手协调——在这种情况下,agent 没有合规路径,必须回退到人在回路中的确认。

这个成本正是重点。替代方案是一个以人类全部权限行动的 agent,无法归因、无法收窄,也无法在不破坏人类访问的情况下被阻止。一旦 agent 与第三方进行交易,问责的单位就已经转移。基础设施必须跟上。

这意味着什么

Agent 身份不是螺栓固定在现有产品上的认证功能。它是一个原语,决定了 agent 被允许成为什么。将其视为登录的团队会不断发现,交易对手把他们的 agent 当作未知的客户端类别,并且在被问及谁在行动、在什么授权下行动时,始终没有答案。

将其视为基础设施的团队——签发、限定作用域、限流、撤销、记录日志——会有答案。他们也会有审计轨迹来证明这一点。

封面照片:Ivan Chumak / Pexels。

分享XLinkedIn永久链接5 分钟阅读

相关阅读

这能回答的问题

Why can't an agent just reuse the user's OAuth session?

An OAuth token records what a human consented to, not which autonomous process is acting. If several agents run under one token, they cannot be attributed, scoped or revoked independently. Delegated identity separates the agent from the principal.

What does a delegated agent identity need to include?

A stable agent identifier distinct from the principal, its own key material and rotation schedule, scopes narrowed per counterparty, per action class and per time window, and a revocation path that does not require the human to change a password.

How should an agent handle a counterparty refusing its traffic?

Treat refusal as a normal response. Record it, surface it to the principal and stop. Retrying against a counterparty that has already made a policy decision escalates traffic without changing the outcome.

What is the main trade-off of delegated agent identity?

It adds a registry, signing, rotation, revocation and audit infrastructure, plus validation latency at every counterparty. Some counterparties may not accept delegated credentials at all, forcing a human-in-the-loop fallback.