了解您的智能体：如何将人类与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 被 2,000 多家生产公司使用。MCP 服务器本身是免费的，因此团队可以评估委托和权限模型，而无需额外支付连接器费用。

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

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

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

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