Conoce a tu Agente: Cómo Vincular un Humano a un Agente de IA

Conclusiones clave

• Conoce a tu Agente (KYA) no se resuelve nombrando a un agente. El control duradero es una cadena de delegación que vincula a una persona autenticada, un cliente registrado, ámbitos concedidos, un contexto de organización y cada acción resultante.
• El endpoint del Protocolo de Contexto de Modelo (MCP) alojado de Didit expone 115 herramientas en 19 dominios y utiliza Open Authorization (OAuth) 2.1 con Proof Key for Code Exchange (PKCE) y Registro Dinámico de Clientes.
• El MCP actúa como el usuario de Didit con sesión iniciada. Hereda el rol de organización de ese usuario, por lo que un agente conectado no puede obtener permisos que la persona ya no tuviera.
• Una clave de aplicación almacenada en un archivo de configuración prueba la posesión de una credencial, no qué humano delegó una acción particular. Las claves compartidas colapsan múltiples operadores y agentes en una sola identidad de aplicación.
• La rendición de cuentas requiere tanto cumplimiento como evidencia: tokens con ámbito y verificaciones de roles antes de una acción, y luego registros de auditoría que muestren quién cambió qué.

Didit ya ha implementado el mecanismo. Su servidor MCP alojado conecta un cliente de IA a operaciones de identidad y fraude a través de un usuario con sesión iniciada, en lugar de tratar al agente como un titular anónimo de un secreto de aplicación. El endpoint es gratuito, utiliza HTTP "Streamable" sin estado y expone 115 herramientas. La implementación también está disponible en el repositorio público de GitHub con licencia MIT.

Ese artefacto cambia la pregunta útil. En lugar de pedir otra definición de KYA, pregunte: cuando un agente crea una sesión de verificación, lee una decisión o cambia datos del espacio de trabajo, ¿qué prueba qué persona lo autorizó, qué permitió esa persona y qué organización aceptó la acción?

La vinculación humana es una cadena de delegación

Un nombre de agente, identificador de modelo, clave pública o atestación de software puede ayudar a identificar al actor de la máquina. Ninguno de ellos, por sí solo, establece quién es responsable de lo que hace el agente. La vinculación humana necesita una cadena con eslabones distintos:

• Principal: el usuario autenticado o propietario del servicio en cuyo nombre actúa el agente.
• Cliente: la aplicación de IA que solicitó acceso.
• Delegación: los ámbitos y el consentimiento otorgados a ese cliente.
• Contexto de autorización: el rol de organización y el límite de aplicación aplicados a la solicitud.
• Evidencia: un registro revisable de la acción y su resultado.

Cada eslabón responde a una pregunta diferente. La autenticación dice quién inició sesión. OAuth dice qué cliente recibió acceso delegado. Los ámbitos dicen qué clases de operación fueron aprobadas. Los roles dicen lo que el usuario puede hacer dentro de la organización. Los registros de auditoría dicen lo que realmente sucedió. Colapsar estos controles en una única insignia de "agente verificado" oculta la parte más importante: la autoridad es contextual y revocable.

Un agente confiable no es simplemente identificable. Debe ser capaz de mostrar un camino ininterrumpido desde un principal responsable hasta una acción específica y permitida.

Por qué una clave en un archivo de configuración falla la prueba de rendición de cuentas

Una clave API de aplicación puede ser apropiada para una integración controlada de servidor a servidor. No es, por sí misma, un mecanismo de vinculación de humano a agente. Una clave copiada normalmente responde a una pregunta: "¿Este interlocutor posee una credencial aceptada para esta aplicación?" No responde quién lanzó al agente, quién aprobó la tarea actual, o si dos llamadas que usan la misma clave provienen de personas diferentes.

Los modos de fallo son predecibles. Los equipos comparten una clave entre entornos locales. Un proceso de agente la hereda de un archivo de configuración. Un segundo agente recibe una copia. Los registros atribuyen entonces cada llamada a la misma credencial de aplicación. Revocar esa credencial interrumpe todas las cargas de trabajo que la utilizan, mientras que deja el evento de delegación individual poco claro.

Didit deliberadamente no ofrece una ruta de clave de aplicación para su endpoint MCP alojado. Las integraciones de backend aún pueden usar las API REST de Didit con credenciales de aplicación, pero el acceso remoto al MCP requiere un flujo de usuario de OAuth. Esa separación importa: la credencial REST representa una integración de aplicación; el token MCP representa acceso delegado de un usuario con sesión iniciada.

OAuth 2.1, PKCE y Registro Dinámico de Clientes

OAuth es la primitiva de delegación en este diseño. El flujo no entrega la contraseña del usuario al agente, y no coloca un secreto de plataforma reutilizable en la configuración del MCP. En cambio, el cliente de IA obtiene un token de acceso limitado después de que el usuario se autentica con Didit y aprueba el acceso.

1. Registrar el cliente

El Registro Dinámico de Clientes permite que un cliente MCP compatible se registre con el servidor de autorización de Didit sin un identificador de cliente preaprovisionado manualmente. Esto le da al servidor de autorización un registro de cliente distinto al que puede emitir acceso. El registro identifica al cliente OAuth; no, por sí mismo, certifica que el software del cliente es confiable.

2. Vincular la respuesta de autorización al cliente

PKCE crea un verificador y un desafío únicos para el intento de autorización. El cliente que inicia el flujo debe presentar el verificador al intercambiar el código de autorización. Esto limita el valor de un código interceptado porque otro proceso no puede canjearlo sin el verificador.

3. Autenticar y dar consentimiento

El usuario inicia sesión en la Consola de Negocios de Didit, que actúa como servidor de autorización, y aprueba los ámbitos solicitados. Didit anuncia didit:verification para operaciones de verificación y didit:management para la gestión del espacio de trabajo. Un cliente solo debe solicitar el ámbito requerido para la tarea.

4. Validar cada llamada

El servidor de recursos MCP alojado valida el token de portador antes de enviar una llamada de herramienta. El token de usuario validado y el contexto de la organización viajan con la solicitud a Didit. El servicio descendente evalúa entonces el rol y los permisos existentes para ese usuario. El resultado es una semántica de "actuar como usuario", no una nueva identidad de superusuario creada para el agente.

La guía de autenticación de MCP documenta el flujo, mientras que la descripción general de MCP explica el endpoint alojado y el modelo de cliente.

Actuar como el usuario hace que la autoridad sea legible

Supongamos que un operador de cumplimiento conecta un cliente de IA a Didit. El cliente primero llama a didit_context_get, que devuelve las organizaciones y aplicaciones a las que el usuario con sesión iniciada puede acceder. Si el usuario tiene una organización y aplicación inequívocas, el contexto puede resolverse automáticamente. Si hay varias disponibles, la operación puede reducirse a una organización y aplicación explícitas.

El agente puede entonces llamar a didit_session_create para crear una sesión de verificación y a didit_session_get_decision para recuperar su resultado. Esos son nombres de herramientas reales, primero de dominio, en el catálogo actual de MCP. Un usuario que carece del permiso requerido no lo obtiene al conectar un agente; el mismo límite de autorización de la organización sigue aplicándose.

Esta es la diferencia central con una credencial de aplicación compartida. En el modelo OAuth, la solicitud llega como un usuario conocido que opera a través de un cliente registrado con ámbitos declarados. En el modelo de clave compartida, el sistema descendente ve la credencial de la aplicación, mientras que el humano y el agente detrás de una llamada particular permanecen indistinguibles a menos que un plano de control separado proporcione ese contexto.

Auditabilidad: de "¿quién puede actuar?" a "¿quién hizo qué?"

La autorización previene una acción fuera de ámbito. La auditabilidad explica una acción después de que ocurre. Didit expone didit_audit_log_list para que un usuario autorizado pueda inspeccionar las entradas de auditoría de la aplicación que describen quién cambió qué. Debido a que cada solicitud de MCP alojado lleva el token de portador del usuario con sesión iniciada y el contexto de organización resuelto, la acción es atribuible a ese interlocutor en lugar de a un proceso de agente anónimo.

Un registro forense completo también debe preservar la evidencia del lado del agente. Para flujos de trabajo de alto impacto, registre el identificador de ejecución del agente, el registro del cliente, el ámbito solicitado, la organización y aplicación de destino, el nombre de la herramienta, la marca de tiempo, el estado de aprobación y una representación segura de las entradas y salidas. No registre tokens de acceso ni cargas útiles de identidad sensibles. La pista de auditoría de la plataforma y el registro de ejecución del agente deben ser correlacionables sin duplicar secretos o datos personales regulados.

La atribución no es lo mismo que el no repudio, y un registro de auditoría no sustituye al privilegio mínimo. Los controles se refuerzan mutuamente:

• Utilice acceso de corta duración y actualización controlada en lugar de credenciales compartidas permanentes.
• Conceda el ámbito OAuth más estrecho y el rol de organización con menos privilegios.
• Requiera confirmación humana para operaciones destructivas o de impacto inusualmente alto.
• Mantenga el contexto de la organización y la aplicación explícito cuando haya más de un objetivo disponible.
• Revoque la sesión de usuario o la concesión del cliente cuando la delegación deba finalizar.
• Supervise los registros de auditoría en busca de actores, herramientas, objetivos o tiempos inesperados.

Lo que la vinculación prueba, y lo que no

Este patrón prueba que una cuenta autenticada de Didit delegó acceso con ámbito a un cliente OAuth y que cada solicitud se evalúa con los permisos de organización de ese usuario. Crea una rendición de cuentas práctica a una cuenta y una cadena revisable para las acciones de la plataforma.

No prueba automáticamente que el titular de la cuenta tenga una identidad civil verificada, que el binario del cliente aprobado no haya sido modificado, o que el humano esté observando activamente cada paso. Esos requieren una garantía adicional. Si la garantía de identidad legal es necesaria, verifique al principal durante la incorporación con controles de Conozca a su Cliente (KYC) y vincule ese resultado a la cuenta. Si la procedencia del software importa, agregue atestación de cliente y lanzamientos firmados. Si la presencia importa, requiera una aprobación por pasos en el momento de la acción sensible.

Esta visión por capas mantiene la honestidad de KYA. La identidad del agente, la identidad humana, la autorización delegada, la política en tiempo de ejecución y la evidencia de auditoría son controles relacionados, no etiquetas intercambiables.

Una implementación funcional que puedes inspeccionar

La implementación de Didit proporciona una referencia concreta para los equipos que diseñan el mismo límite de rendición de cuentas. El servidor alojado se autentica como el usuario de Didit con sesión iniciada, hereda el rol de organización de ese usuario y aplica esa identidad a cada llamada de herramienta. Sus 115 herramientas alojadas abarcan 19 dominios, desde sesiones de contexto y verificación hasta flujos de trabajo, organizaciones, análisis y registros de auditoría. El catálogo de herramientas actual enumera la superficie exacta.

Para el contexto del producto, el paquete completo de KYC cuesta $0.33 y combina Verificación de ID, Detección de Vida Pasiva, Coincidencia Facial y Análisis de IP. Didit incluye 500 verificaciones gratuitas por mes y es utilizado por más de 2,000 empresas en producción. El propio servidor MCP es gratuito, por lo que los equipos pueden evaluar la delegación y el modelo de permisos sin agregar una tarifa de conector separada.

Para ver cómo este mecanismo encaja en flujos de trabajo de agentes más amplios, lea cómo funciona el MCP de identidad y fraude para agentes de IA y la referencia de herramientas MCP de Didit.

Vincule al agente antes de confiar en la acción

El problema difícil en la identidad de los agentes no es inventar un nombre duradero para el software. Es preservar la responsabilidad humana a medida que el software cruza interfaces y actúa a la velocidad de la máquina. OAuth 2.1 proporciona acceso delegado. PKCE protege el intercambio de autorización. El Registro Dinámico de Clientes identifica al cliente que se conecta. Los ámbitos y los roles de la organización restringen la autoridad. Los registros de auditoría hacen que el resultado sea revisable.

Puede inspeccionar la arquitectura en el repositorio MCP de Didit, revisar la documentación de autenticación o conectar Didit a Claude. La prueba útil es simple: para cualquier acción de agente propuesta, ¿puede identificar al usuario responsable, al cliente, el ámbito concedido, el límite de la organización y la evidencia de auditoría resultante? Si falta algún eslabón, el agente no está completamente vinculado.