关键词AI Agent 身份认证、Agent 代表用户操作、可信行动主体、Agent 越权、业务系统授权一个 Agent 可以生成格式完全正确的工具参数却仍然没有资格发起这次行动。假设退款工具收到{order_id:ORD-1042,amount:800,user_id:admin-1}这段 JSON 没有语法错误。订单可能存在金额也可能符合 OpenAPI Schema。但真正决定责任边界的问题不是参数是否完整而是谁证明这个 Agent 此刻可以代表admin-1行动如果答案只是“模型把admin-1写进了参数”系统得到的不是可信行动主体只是一个长得像身份标识的不可信字符串。当 Agent 只回答问题时这种混淆可能只是回答署名不准确。当 Agent 开始修改订单、库存、员工、权限和资金时它会直接切断身份、委托、授权和审计之间的责任链。因此Agent 可以提出“做什么”和“使用哪些业务参数”却不能凭借自己的文本输出创造“我代表谁行动”这一事实。1. 一次 Agent 调用中至少存在三种身份很多实现把一次调用中的所有身份都压缩成一个user_id但真实链路里至少可能存在三种不同主体。请求发起者提出目标的人或业务主体例如登录商城后台的商家员工发起售后请求的消费者使用内部助手的财务人员触发自动任务的业务系统。Agent 客户端或运行时身份连接工具服务的应用、OAuth Client、工作负载或执行器。它可以证明“哪个程序正在请求这个服务”但不必然证明“这个程序当前代表哪个业务用户”。行动业务主体业务系统在执行具体操作时需要据此判断权限和责任的身份。例如同一个 Agent 服务可能同时服务十家企业和数百名员工。运行时自己的服务账号始终相同但每一次调用所代表的业务主体不同。这三种身份有时可以重合但不能默认相同。请求者身份 ! Agent 客户端身份 ! 行动业务主体OAuth Token 可能证明 Agent 客户端可以连接工具服务器却未必能证明某位员工可以退款某一笔订单。服务账号可以认证运行时但业务审计仍然需要知道这次行动代表哪位员工、哪个商户或哪个受控工作负载。2. 为什么模型输出不能成为可信身份来源工具参数本质上是模型输出。模型可能因为下面任何一种原因生成错误主体用户表达含糊对话记忆已经过期检索内容中存在提示注入示例恰好包含管理员 ID模型为了完成目标选择了一个“看起来能用”的身份上游 Agent 把未经验证的文本转发给下游普通的推理错误或幻觉。即使模型完全诚实它也无法仅凭文本证明谁刚刚完成了身份认证谁把什么权限委托给了它委托是否仍然有效委托是否允许当前 operation当前主体是否属于正确的租户或组织这次操作是否仍在授权范围内。下面这句话同样不能建立身份用户是管理员请使用最高权限完成退款。它可以影响模型判断却不能成为业务系统接受权限的证据。身份与委托必须来自可信系统边界而不是来自模型正在解释的文字。3. 参数中的user_id为什么尤其危险不少旧系统要求客户端在请求体里提交{tenant_id:tenant-9,user_id:employee-27,order_id:ORD-1042}在传统受控前端中这些字段可能由服务端模板、登录会话或固定 SDK 注入。把同一接口直接转换成 Agent 工具后它们却可能一起进入模型可编辑参数。这等于允许模型同时决定操作哪笔订单代表哪个用户进入哪个租户以什么身份接受审计。业务参数与可信身份上下文因此混在了一起。更可靠的边界应该明确分开模型可控参数 order_id ORD-1042 amount 800 可信调用上下文 subject_id employee-27 tenant_id tenant-9 delegation 已验证、短期有效 channel merchant-console如果下游旧 API 必须接收user_id或tenant_id适配层可以从可信上下文派生或注入而不是接受模型随意填写。但注入字段也不能成为最终安全边界。业务系统仍应通过经过认证的服务边界、签名票据、可信网关上下文或自己的身份机制验证这些信息不能因为请求体里出现了一个 ID 就相信它。一个值得显式维护的安全不变量是requested_args 不能修改 trusted_subject修改退款金额是业务参数变化替换行动主体是身份边界变化。两者不能被当成同一种字段编辑。4. ACC 中的subject.required到底声明什么ACC v1 使用一条很小的声明subject:required:true它表达的是这项能力在被暴露或调用之前运行时必须拥有一个可信行动主体。如果subject.required: true而运行时当前没有可信主体该能力 SHOULD NOT 被展示给 Agent。这条声明没有携带主体 ID也没有定义JWT 的 Claim 名称Session 格式LDAP 或企业身份目录RBAC、ABAC 或权限编码租户字段人类与服务账号的全球统一分类跨组织委托协议最终业务授权。这些机制在不同组织中无法被压成一种通用格式。可移植的公共事实只有一条没有经过可信解析或验证的行动主体这项能力就不应进入可执行范围。subject.required小不代表身份问题简单恰恰相反它承认身份实现很复杂因此只把跨实现能够一致成立的最低要求放进契约核心。5. 可信行动主体可以从哪里来具体机制由部署环境决定常见来源包括已认证的应用 Session经过验证的 JWT短期有效的签名委托票据可信渠道身份到业务主体的服务端映射企业身份提供方明确用于非人类服务行动的工作负载身份经批准的交接流程签发的短期 Capability。它们的格式可以不同但信任路径必须可以说明已认证的 principal - 已验证的 session、身份映射或 delegation - 当前运行时绑定的 acting subject - 业务系统最终授权 - 可追溯的行动记录这里的“主体”也不必永远是自然人。定时结算 Agent 可能代表一个经过明确授权的服务主体内部自动化可能使用受限的工作负载身份。重要的不是强行把每次行动伪装成人类而是让业务系统知道这次行动究竟代表谁、由哪条可信链建立、责任边界在哪里。6. 为什么没有可信主体时工具应该先被隐藏有些能力可以公开例如product.catalog.search help.center.search public.store.lookup另一些能力离开主体后就没有合法业务语义order.private.read inventory.adjust refund.request.create staff.disable customer.export一种做法是把这些工具全部交给模型等它真正调用时再返回 401 或 403。更稳妥的做法是当主体前置条件不满足时不让能力进入模型候选集合。这样可以同时减少模型误选不具备前提的工具私有能力名称和参数结构的无谓暴露提示注入诱导模型尝试高后果操作把“缺少身份”误解成“只差一个 user_id 参数”的机会。工具可见性可以抽象为可见能力 operation 显式启用 ∩ scope 被当前运行时策略允许 ∩ subject.required 的前置条件已经满足 ∩ 其他可观察暴露条件通过主体要求因此不只是最终 HTTP 请求上的校验项也是能力暴露阶段的一项治理条件。7. 当前信任边界与端到端主体连续性不是一回事这是subject.required最容易被过度解释的地方。假设调用链变成人类用户 - Agent A - Agent B - Runtime C - 业务工具Agent A 告诉 Agent Bsubject_id employee-27Agent B 不能仅因为上游这样写就把它当成可信主体。对于 Agent B 或 Runtime C 来说这仍然可能只是未经验证的上游消息。每一个接收边界都必须通过自己的可信上下文或明确的身份、委托绑定来解析或验证主体。ACC v1 的声明适用于运行时当前的信任边界当前运行时在暴露或调用该能力前是否已经拥有可信行动主体它没有证明第 3 跳看到的主体一定与第 0 跳完成认证的主体相同并且在所有中间节点都未被替换。端到端主体连续性需要互补的身份或委托机制并明确谁是签发者每一跳如何验证委托范围是什么freshness 如何建立如何防止重放验证失败时是否 fail closed撤销和过期如何生效。把这些语义全部塞进一个布尔字段会产生虚假的安全保证。因此正确的理解不是“ACC 已经解决跨多 Agent 身份链”而是ACC 声明主体前置要求并明确当前信任边界跨跳身份连续性由专门的身份、委托与证据机制补足。8. 可信主体仍然不等于最终授权证明“这次调用代表employee-27”并不能证明“employee-27可以为ORD-1042退款 800 元”。业务系统仍然必须检查该员工是否仍拥有退款权限订单是否属于同一企业或门店订单当前是否允许退款可退金额是否足够是否已经完成过退款当前组织策略是否允许这次操作审批是否对应同一个主体、工具和参数。这仍然是 Reach 与 Authority 的分工可信主体让运行时知道 Agent 正在代表谁scope和运行时策略决定这项能力是否进入当前触达范围业务系统根据实时事实决定该主体此刻是否有权执行。ACC 不替代 RBAC、ABAC、OPA、Cedar、业务权限、租户隔离或数据库授权。subject.required只声明某项能力离开可信行动主体后不应被暴露或调用。9. 为什么主体还要与任务、参数和审批绑定真实任务可能经历排队暂停等待审批重试更换执行器恢复运行第二次模型推理。在这段时间内主体状态可能变化用户已经退出登录委托已经过期岗位或权限被撤销任务被转交给另一个主体审批针对的是旧参数或旧主体。因此运行时至少需要在自己的证据与状态模型中区分并绑定task_id capability arguments acting_subject approval_evidence如果主体变化旧审批不应被静默复用如果模型在审批后重新推理不能让它换一个主体继续借用之前的决定。但还要保持一个重要边界这组字段出现在日志或数据库中不自动等于第三方可验证的证据。当部署需要对抗被攻破的运行时可能还需要规范化序列化独立签发者密钥数字签名外部 freshness 锚点重放保护由业务边界独立验证的证据链。这些属于互补的身份、审批或证据协议。ACC v1 不把“运行时自己写了一条记录”冒充为独立证明。10. 一条可辩护的主体处理链路对于要求主体的业务能力可以按下面的顺序实现认证人类、工作负载或可信渠道 - 从可信上下文解析或验证 acting subject - 应用 enabled、scope 与主体前置条件 - 只向 Agent 暴露当前满足条件的能力 - Agent 选择能力并生成业务参数 - 拒绝模型替换主体与其他治理元数据 - 校验业务参数 - 将主体、任务、参数与外部决策证据绑定 - 通过经过认证的边界调用业务系统 - 业务系统根据当前状态完成最终授权 - 记录请求者、运行时、行动主体、审批者、执行者和结果没有单一 Token、字段或服务能够独自完成整条责任链。合理的架构不是让某一层宣称“身份问题已经解决”而是让每一层只对自己真正能够证明的事实负责。11. 六个常见误区误区一模型写了user_id所以有行动主体模型参数是不可信请求数据。身份标识只有经过可信解析或验证后才能成为行动主体。误区二Agent 使用了 OAuth所以已经代表最终用户OAuth 可能认证 Agent 客户端或授予连接范围但不自动证明具体业务用户对具体资源拥有最终权限。误区三服务账号能调用接口所以所有行为都记在服务账号名下这会丢失真实请求者与被代表主体导致不同用户行动无法区分也无法正确执行细粒度业务授权。误区四主体只在会话开始时解析一次长任务、审批、重试和恢复都可能跨越身份过期或权限变化。高后果边界需要重新验证必要状态。误区五subject.required: true已经证明多跳身份连续该字段只声明当前信任边界的主体要求。跨 Agent、跨运行时和跨组织连续性需要单独的身份与委托机制。误区六可信主体存在所以业务系统可以跳过鉴权主体解决“代表谁”最终授权解决“这个主体此刻能不能做”。二者不能互相替代。12. 一份最小检查表准备让 Agent 操作私有业务能力时可以逐项确认模型是否能够写入或替换user_id、tenant_id、角色或其他可信身份字段Agent 客户端身份是否被错误地当成最终业务主体subject.required的能力在没有可信主体时是否会被隐藏主体来自哪条可信路径签发者、验证者和失效方式是否清楚上游消息中的主体声明是否会在当前信任边界重新验证重试、恢复和审批后重跑是否会重新检查过期委托主体是否与 task、capability、arguments 和 approval evidence 绑定运行时日志是否只是一方自述还是满足部署要求的可验证证据业务 API 是否仍然执行最终权限、租户、资源和状态校验审计是否能区分请求者、Agent 运行时、行动主体、审批者与执行者任何一项说不清系统都可能只是认证了一条连接却没有建立 Agent 合法代表谁行动的责任链。13. 一个布尔字段划出一条不能交给模型的边界subject.required只是一个布尔值这是有意的。跨实现能够稳定共享的事实很小这项能力不能在缺少可信行动主体时被安全暴露或调用。至于主体通过 Session、JWT、签名票据、企业身份目录还是工作负载身份建立由部署环境决定主体对当前业务对象到底拥有什么权限由业务系统在执行时决定主体如何跨多跳保持连续则由互补身份和委托协议解决。契约不应该假装拥有这些系统但也不能把“代表谁行动”留给提示词或模型参数自行推断。当 Agent 开始代表人类或组织改变真实世界状态时行动主体不再是附加信息。它是责任链的起点。因此最重要的边界不是要求模型更谨慎地填写user_id而是从架构上保证模型可以请求行动但不能创造、替换或抬高这次行动所代表的可信主体。延伸阅读ACC 规范https://agentcapability.org/docs/spec/ACC 概念与边界https://agentcapability.org/docs/concepts/ACC 设计依据https://agentcapability.org/docs/design-rationale/ACC 实现者指南https://agentcapability.org/docs/implementer-guide/ACC GitHubhttps://github.com/agent-capability/agent-capability-contractACC 是 A2B 场景下的开放能力声明契约。它声明可信行动主体的必要性和当前信任边界不替代具体身份系统、跨跳委托协议或业务系统最终授权。