了解您的智能体：如何将人类与AI智能体绑定 (ZH)

主要收获

• 了解您的智能体 (KYA) 并非通过命名智能体来解决。持久的控制是一个委托链，它连接了经过身份验证的人员、注册的客户端、授予的范围、组织上下文以及每个产生的操作。
• Didit 的托管模型上下文协议 (MCP) 端点通过 19 个领域公开了 115 种工具，并使用带有代码交换证明密钥 (PKCE) 和动态客户端注册的 Open Authorization (OAuth) 2.1。
• MCP 作为登录的 Didit 用户。它继承了该用户的组织角色，因此连接的智能体无法获得该人员尚未拥有的权限。
• 存储在配置文件中的应用程序密钥证明了凭据的拥有，而不是哪个用户委托了特定的操作。共享密钥将多个操作员和智能体合并为一个应用程序身份。
• 问责制需要强制执行和证据：操作前的范围令牌和角色检查，然后是显示谁更改了什么的审计记录。

Didit 已经发布了该机制。其托管 MCP 服务器通过登录用户将 AI 客户端连接到身份和欺诈操作，而不是将智能体视为应用程序秘密的匿名持有者。该端点免费，使用无状态可流式 HTTP，并公开了 115 种工具。该实现也可在公共 MIT 许可的 GitHub 存储库中获得。

该工件改变了有用的问题。与其询问 KYA 的另一个定义，不如问：当智能体创建验证会话、读取决策或更改工作区数据时，什么能证明是哪个人授权了它，那个人允许了什么，以及哪个组织接受了该操作？

人类绑定是一个委托链

智能体名称、模型标识符、公钥或软件证明有助于识别机器执行者。它们本身都不能确定谁应对智能体的行为负责。人类绑定需要一个具有不同链接的链条：

• 主体：智能体代表其行事的已认证用户或服务所有者。
• 客户端：请求访问的 AI 应用程序。
• 委托：授予该客户端的范围和同意。
• 授权上下文：应用于请求的组织角色和应用程序边界。
• 证据：操作及其结果的可审查记录。

每个链接都回答一个不同的问题。身份验证说明谁登录。OAuth 说明哪个客户端获得了委托访问权限。范围说明哪些操作类别获得了批准。角色说明用户可以在组织内做什么。审计记录说明实际发生了什么。将这些控制合并到单个“已验证智能体”徽章中会隐藏最重要的部分：权限是上下文相关的且可撤销的。

一个值得信赖的智能体不仅仅是可识别的。它必须能够显示从负责任的主体到特定允许操作的完整路径。

为什么配置文件中的密钥无法通过问责测试

应用程序 API 密钥可能适用于受控的服务器到服务器集成。它本身不是人类到智能体的绑定机制。复制的密钥通常回答一个问题：“此调用者是否拥有此应用程序接受的凭据？”它不回答谁启动了智能体，谁批准了当前任务，或者使用相同密钥的两次调用是否来自不同的人。

故障模式是可预测的。团队在本地环境之间共享密钥。智能体进程从配置文件继承它。第二个智能体收到一份副本。然后日志将每个调用都归因于相同的应用程序凭据。撤销该凭据会中断使用它的每个工作负载，同时使单个委托事件不明确。

Didit 特意不为其托管 MCP 端点提供应用程序密钥路径。后端集成仍然可以使用 Didit 的 REST API 和应用程序凭据，但远程 MCP 访问需要用户 OAuth 流程。这种分离很重要：REST 凭据代表应用程序集成；MCP 令牌代表来自登录用户的委托访问。

OAuth 2.1、PKCE 和动态客户端注册

OAuth 是此设计中的委托原语。该流程不会将用户的密码交给智能体，也不会将可重用的平台秘密放置在 MCP 配置中。相反，AI 客户端在用户通过 Didit 进行身份验证并批准访问后获得一个有限的访问令牌。

1. 注册客户端

动态客户端注册允许兼容的 MCP 客户端向 Didit 授权服务器注册，而无需手动预配置客户端标识符。这为授权服务器提供了一个独特的客户端注册，它可以向其颁发访问权限。注册识别 OAuth 客户端；它本身不证明客户端的软件是值得信赖的。

2. 将授权响应绑定到客户端

PKCE 为授权尝试创建一次性验证器和质询。启动流程的客户端必须在交换授权码时提供验证器。这限制了被截获代码的价值，因为另一个进程无法在没有验证器的情况下赎回它。

3. 认证并同意

用户在 Didit 商业控制台（作为授权服务器）登录，并批准请求的范围。Didit 为验证操作宣传 didit:verification，为工作区管理宣传 didit:management。客户端应仅请求任务所需的范围。

4. 验证每次调用

托管 MCP 资源服务器在分派工具调用之前验证持有者令牌。经过验证的用户令牌和组织上下文随请求一起传输到 Didit。下游服务然后评估该用户的现有角色和权限。结果是“作为用户”的语义，而不是为智能体创建的新超级用户身份。

MCP 认证指南记录了流程，而MCP 概述解释了托管端点和客户端模型。

作为用户行事使权限清晰可辨

假设合规操作员将 AI 客户端连接到 Didit。客户端首先调用 didit_context_get，它返回登录用户可以访问的组织和应用程序。如果用户有一个明确的组织和应用程序，上下文可以自动解析。如果存在多个可用，操作可以缩小到明确的组织和应用程序。

然后智能体可以调用 didit_session_create 来创建验证会话，并调用 didit_session_get_decision 来检索其结果。这些是当前 MCP 目录中真实的领域优先工具名称。缺乏所需权限的用户不会通过连接智能体来获得权限；相同的组织授权边界仍然适用。

这是与共享应用程序凭据的核心区别。在 OAuth 模型中，请求作为已知用户通过已注册客户端和声明范围到达。在共享密钥模型中，下游系统看到应用程序凭据，而特定调用背后的人类和智能体仍然无法区分，除非单独的控制平面提供该上下文。

可审计性：从“谁可以行动？”到“谁做了什么？”

授权阻止了超出范围的操作。可审计性解释了操作发生后的情况。Didit 公开了 didit_audit_log_list，以便授权用户可以检查描述谁更改了什么的应用程序审计条目。由于每个托管 MCP 请求都带有登录用户的持有者令牌和已解析的组织上下文，因此该操作可归因于该调用者，而不是匿名智能体进程。

完整的取证记录还应保留智能体侧的证据。对于高影响工作流，请记录智能体运行标识符、客户端注册、请求范围、目标组织和应用程序、工具名称、时间戳、批准状态以及输入和输出的安全表示。不要记录访问令牌或敏感身份负载。平台审计跟踪和智能体执行日志应该可以关联，而无需复制秘密或受监管的个人数据。

归因与不可否认性不同，审计日志不能替代最小权限。这些控制相互加强：

• 使用短期访问和受控刷新，而不是永久共享凭据。
• 授予最窄的 OAuth 范围和最低权限的组织角色。
• 对于破坏性或异常高影响的操作，需要人工确认。
• 当有多个目标可用时，保持组织和应用程序上下文明确。
• 当委托应结束时，撤销用户会话或客户端授权。
• 监控审计记录中是否存在意外的执行者、工具、目标或时间。

绑定证明了什么——以及没有证明什么

此模式证明了经过身份验证的 Didit 帐户将范围访问权限委托给 OAuth 客户端，并且每个请求都使用该用户的组织权限进行评估。它为帐户创建了实际的问责制，并为平台操作创建了可审查的链。

它不会自动证明帐户持有人拥有经过验证的公民身份，批准的客户端二进制文件未被修改，或者人类正在积极监控每个步骤。这些需要额外的保证。如果需要法律身份保证，请在入职期间使用了解您的客户 (KYC) 控制措施验证主体，并将结果绑定到帐户。如果软件来源很重要，请添加客户端证明和签名发布。如果存在很重要，请在敏感操作发生时要求逐步批准。

这种分层视图使 KYA 保持诚实。智能体身份、人类身份、委托授权、运行时策略和审计证据是相关的控制，而不是可互换的标签。

一个您可以检查的实际实现

Didit 的实现为设计相同问责边界的团队提供了具体的参考。托管服务器作为登录的 Didit 用户进行身份验证，继承该用户的组织角色，并将该身份应用于每个工具调用。其 115 种托管工具涵盖 19 个领域，从上下文和验证会话到工作流、组织、分析和审计日志。当前工具目录列出了确切的界面。

就产品背景而言，完整的 KYC 套餐费用为 0.33 美元，结合了身份验证、被动活体检测、人脸匹配和 IP 分析。Didit 每月提供 500 次免费验证，并被 2,000 多家生产公司使用。MCP 服务器本身是免费的，因此团队可以评估委托和权限模型，而无需额外支付连接器费用。

要了解此机制如何融入更广泛的智能体工作流，请阅读身份和欺诈 MCP 如何为 AI 智能体工作以及Didit MCP 工具参考。

在信任操作之前绑定智能体

智能体身份的难题不是为软件发明一个持久的名称。它是在软件跨越接口并以机器速度运行时保持人类问责制。OAuth 2.1 提供委托访问。PKCE 保护授权交换。动态客户端注册识别连接客户端。范围和组织角色限制权限。审计记录使结果可审查。

您可以在Didit MCP 存储库中检查架构，查看认证文档，或将 Didit 连接到 Claude。有用的测试很简单：对于任何提议的智能体操作，您能否识别负责任的用户、客户端、授予的范围、组织边界以及由此产生的审计证据？如果任何链接缺失，则智能体未完全绑定。