Agent 身份安全要验证授权绑定关系

请求里带上 user_id、agent_id 和 run_id，并不代表 Agent 已经有了可信的身份体系。真正要回答的是：这些值由谁确定、谁能修改，以及调用者拿着有效凭证时，能不能把其中一个值换成别人的。

作者用一个虚构的发票审核流程，提出了身份与授权的绑定方案。它没有性能数据，也不是可部署的认证服务，但给出了一个实用的验收标准：别只检查 ID 是否存在，要证明错误的组合会在哪里被拒绝。

同样叫身份，这几个字段证明的事情不同

一次 Agent 任务至少涉及四种角色：发起任务的人、承接业务权限的逻辑 Agent、实际执行代码的运行时，以及允许它代别人办事的委托授权。

例如，Mariam 属于 Cedar 租户，请 invoice-reviewer 为发票 INV-204 起草说明。这个 Agent 可以读取发票，却不能修改供应商银行账户。Mariam 是发起人，invoice-reviewer 是应用层主体，执行任务的 worker 是运行时，委托授权则限定这次任务能做什么。

run_id 只负责关联执行过程，不能充当权限凭证。模型名也只是依赖项，不能代表使用模型的业务主体。

这里还有一个容易混淆的边界：工作负载身份未必对应单个 Agent 实例。SPIFFE 允许一个工作负载包含多个实例，团队必须自己决定身份代表独立部署、worker 池，还是其他隔离边界，不能假定它与应用里的 Agent 主体一一对应。

身份说明谁在执行，授权说明这次执行允许做什么。

两者需要关联，但不能互相替代。

为什么可信上下文不能放进工具参数

作者建议在请求入口验证用户身份，从可信账户数据解析租户归属，再通过经过授权的路由选择已注册的 Agent 主体。客户端提交的显示名称，不能直接成为主体映射依据。

随后，由受保护的任务分配记录绑定租户、Agent、权限模式、允许访问的发票和执行策略。队列只携带记录引用，worker 通过经过认证的路径读取记录。

下面这段 JSON 用来展示绑定关系，解决的是「这次任务究竟允许谁读哪张发票」的问题：

{
  "assignment_id": "assignment-204",
  "tenant_id": "cedar",
  "agent_principal": "invoice-reviewer",
  "initiator": "user:mariam",
  "authority_mode": "user-delegated",
  "grant_ref": "grant-204",
  "permitted_resource": "invoice:INV-204",
  "operation": "read",
  "environment": "production"
}

重点看 permitted_resource：模型即使提出 invoice_id=INV-990，也不能顺手把可信记录中的 invoice:INV-204 改掉。

这份 JSON 本身没有安全能力。存储访问控制、完整性、签发、过期和读取校验，都要由实现负责。把它复制进 prompt，会丢掉原本想建立的信任边界。

接下来，凭证代理先认证 worker，再检查它是否有权在指定环境执行该 Agent，以及使用这份任务记录和授权。SPIRE 可以依据配置的证明条件签发工作负载身份，但不会自动替应用建立 Agent 与租户映射。

因此，即使每个 ID 都真实存在，也可能必须拒绝：staging 的身份不能执行 production 任务，某个 worker 不能冒用未获授权的 Agent，其他任务或租户的 grant 也不能拿来拼装。

检查还不能止于凭证代理。下游 invoice API 仍要核对请求的资源和操作，避免一次代理放行变成读取任意发票的通行证。具体由受限令牌承载约束，还是由目标服务查询 grant，原文没有规定唯一方案。

换一张新凭证，未必能隔离共享 worker

如果发票审核和供应商管理运行在同一进程，而且进程能访问两套凭证，给它们起不同的 agent_id 并不能形成隔离。进程被攻破后，攻击者可能同时获得两类权限。

作者给出三种选择：拆分部署、加强运行时内部隔离，或让代理只向经过独立认证的任务释放严格受限的凭证。每种选择都有运维成本，也都要考虑凭证窃取和上下文替换。

逐次运行签发凭证并非必需，也不天然充分。新凭证如果权限宽泛，照样可以越权；有效期短，只缩短可利用时间，不能证明租户和用途正确。作者引用 Google Cloud 的身份委托架构作为具体实例，也明确提醒，通用 Agent 框架未必提供同等保证。

定时任务还要单独处理。计划对账的发起者可以是获批的调度器，使用明确的服务授权。OAuth client credentials grant 对应机密客户端访问自身资源或预先安排的访问，不能包装成某个用户仍在持续委托。

用户授权缺失时，不应静默降级成权限更大的服务令牌。

验收时，应沿真实入口替换字段：跨租户发票必须在数据披露前拒绝；同一 worker 凭证换一个 Agent 主体，除非有独立可信的任务和映射授权，否则拒绝；staging 身份访问 production 任务也应拒绝。反过来，换成获授权的 production 副本，保留有效任务，则应允许读取指定发票，并继续受当前资源策略约束。

只对手工构造的可信上下文做单元测试不够。如果入口直接接收模型参数里的 tenant_id，最终比较逻辑再严密，也可能建立在攻击者提供的上下文上。

我的判断

我认同作者把审查重点放在「错误关系能否被拒绝」上。它比检查接口是否携带 agent_id 更接近实际风险，也能解释为什么凭证有效仍可能越权。

不过，这是一套设计提案和拟议集成测试，没有提供已部署系统的验证结果，也没有对照数据证明某种隔离方式更划算。凭证代理如何实现、授权如何撤销、各层检查如何分工，仍需团队补齐。NIST 的设计原则在这里提供参考，不能作为方案通过合规测试的证明。

对普通团队，可以先把这些绑定检查落实到现有认证和资源授权链路，再根据共享凭证的风险决定是否增加代理或拆分部署。组件数量不是验收目标，真实入口能否挡住替换才是。

能拿来做什么

• 在 Node 工具服务中，把模型提出的资源参数与服务端解析出的租户、任务记录分开处理，并在读取前核对资源和操作。
• 给现有 Agent 调用链补充替换测试，覆盖跨租户发票、Agent 主体替换和 staging 访问 production，并验证获授权副本可以继续执行有效任务。
• 为定时任务明确设置服务权限模式，禁止用户 grant 缺失后自动换用服务令牌。
• 审计日志记录经过认证的主体引用、解析后的任务记录、策略结果和受保护资源引用，同时避免记录密钥，让拒绝与放行都有可追查的依据。