Trulioo KYA：开放权限前，核实 Agent 背后的组织

采购平台收到一个陌生 Agent 的请求，对方声称代表某家供应商。请求带着看似有效的签名，平台仍想知道：软件背后是哪家组织，提出的操作是否符合其声明范围。Trulioo KYA 为这个判断补充组织和 Agent 两层信息。

证据边界： 2026 年 11 月 1 日核对官方公开材料，没有申请 Alpha、核验真实企业或调用在线验证 API。采购场景仅用于说明。

当前产品是 Alpha 阶段的 Digital Agent Profile

Trulioo KYA 页面描述了核实开发组织、评估 Agent 信号，再把两者连接为 Digital Agent Profile，简称 DAP。页面明确标为 Alpha。应使用当前名称，不把旧的 passport 用语当成另一个产品。

这为平台提供了请求方证据，但不能证明供应商发票真实，也不能证明买方已批准付款。后两件事需要各自的记录。已核实组织仍可能提交错误请求，合法部署也可能受到外部恶意内容影响。

KYA 评估概念图，非在线核验结果。身份依据用于接收方决策，并不是付款批准。

验证签名证据，不是验证一个徽章

A2A 扩展规范区分具有权威性的签名 attestation 与便于展示的 display 对象，要求验证签名并正确绑定 Agent 指纹。允许的操作范围由接收方执行，而不是由 Trulioo 自动执行。

这是具体接入边界。前端可以展示友好身份标签，但决定准入的后端不能把标签本身当凭证，否则修改展示内容就可能冒充通过核验。

我们建议向业务应用提供决定、原因和证据引用，而不是把完整凭证散发给每个下游组件。保留解释拒绝所需的内容，同时避免敏感身份材料进入普通对话日志。

有效期与接收方会改变凭证含义

过去有效的一次身份响应，不一定足以支持之后更高影响的操作。修改供应商收款账户前，应确认材料是否仍有效、是否对应同一 Agent，以及范围是否涵盖该动作。

接入应区分验证不通过与验证依赖暂时不可用。两者都可能阻止敏感操作，但用户提示和恢复路径不同。“现在无法确认”不能自动写成“该组织存在欺诈”。

若所选出示流程要求绑定接收方，就要按实际接收方和请求验证。把缓存 Agent Card 里的凭证复制出来，不能普遍替代所需证明。具体校验应遵循当前规范，而不是自行解释解码后的令牌。

平台问题	应保存的证据和控制
Agent 背后是谁	已核实组织引用及相关状态
是否同一个 Agent	出示证据与 Agent 身份的绑定
是否允许这项操作	当前范围与具体请求的对应关系
证据被撤销怎么办	执行边界上的刷新和拒绝逻辑
客服能否解释	策略版本、证据引用与决定原因

A2A 接入不代表普遍互信

该扩展以独立标识发布，目前是草案规范，可以在 A2A中携带 KYA 信息，但不意味着所有 A2A 参与方都支持或要求它。对手方缺少必要证据时，应明确处理方式，而不是悄悄降级到更弱路径。

也应把 Trulioo KYA 与独立的 KYAPay 协议分开。“了解你的 Agent”用语相近，不代表凭证、签发方和验证规则可以互换。

需要为 Agent 准入建立组织责任依据的平台，可以评估 Trulioo KYA。资料页保留当前产品和扩展入口。判断价值应看接收应用能核验并执行哪些证据，而不是界面有没有“已认证”徽章。