Know Your Agent (KYA): verificar la identidad de los agentes
El KYC verifica humanos. Pero quien abre cuentas o mueve dinero en 2026 no es humano — es un agente de IA actuando por él. Esa brecha es el KYA.

La próxima cuenta que se abra en tu plataforma no la abrirá un humano.
Suena a eslogan. No lo es. En 2026, la entidad que rellena un formulario, llama a tu API o intenta un pago es cada vez más un agente de IA autónomo actuando bajo las instrucciones de una persona. Visa lanzó Agentic Ready como infraestructura de pagos para el comercio impulsado por IA. Mastercard respondió con Agent Pay. OpenAI, Anthropic y Google envían runtimes de agentes con uso de herramientas, control de navegador y autoridad de pago integrados. El Model Context Protocol convirtió la invocación de herramientas por agentes en estándar.
Tu stack KYC se construyó para responder a una pregunta: ¿el humano al otro lado es quien dice ser? En un mundo donde el actor es software, esa pregunta ni siquiera tiene sentido. Necesitas otra: ¿qué agente es este, quién lo autorizó y qué tiene permitido hacer? Eso es el KYA — Know Your Agent — y tratarlo como una nota al pie del KYC es la brecha por la que pasarán tanto los defraudadores como los auditores.
Qué es realmente el KYA
El KYA es la capa de verificación para actores no humanos. Valida tres cosas, ninguna opcional:
Identidad. El agente tiene una identidad criptográfica que se resuelve a su propietario, su operador y su contexto de ejecución — no un nombre de usuario, no una clave de API en el bolsillo de alguien. Es exactamente para lo que se estandarizaron los W3C Decentralized Identifiers (DIDs) y las Verifiable Credentials, aplicados a actores de software en vez de a humanos.
Autoridad. El agente puede demostrar que actúa dentro de un mandato que el titular le otorgó: este usuario autorizó a este agente a gastar hasta esta cantidad en esta categoría de comercio durante esta ventana. Autorización de tipo capability, no "confía en el token portador". La presencia de una clave no es lo mismo que la presencia de consentimiento.
Procedencia. El agente corre sobre un modelo y un stack de herramientas que puedes atestar — pesos conocidos, salvaguardas conocidas, cadena de suministro conocida. El ecosistema creciente de constructores de agentes, y el auge de los agentes de IA autónomos en compliance, solo funciona si el verificador aguas abajo puede distinguir un modelo sancionado de uno con jailbreak.
Una verificación KYC te dice "un humano se verificó una vez". Una verificación KYA te dice "este agente, con este mandato, en este modelo, está actuando ahora mismo". No son intercambiables, y una no subsume a la otra.
Por qué es urgente en 2026, no en 2030
Tres fuerzas comprimieron el calendario.
Los pagos agénticos salieron del laboratorio. Visa Agentic Ready, Mastercard Agent Pay y los toolkits de agentes de Stripe son ya raíles de producción que cursan autorizaciones reales sin presencia de tarjeta originadas por agentes autónomos. La infraestructura existe; la capa de verificación de los agentes está mayormente improvisada. La brecha que mapeamos en Know Your Human: la brecha KYC en los pagos agénticos es la misma brecha vista desde el lado de la institución financiera.
El uso de herramientas es la nueva superficie de ataque. Un agente con navegador, herramienta de pago y memoria tiene la capacidad de acción de un empleado con tarjeta corporativa — pero la vulnerabilidad a prompt injection de un chatbot. El Top 10 de OWASP para LLMs (LLM01 prompt injection, LLM06 manejo inseguro de salidas, LLM07 fuga del prompt del sistema) describe ataques que, aplicados a un agente con herramientas, se convierten en transacciones no autorizadas en vez de texto filtrado. Verificar la identidad y el mandato del agente es lo único que impide que un agente con prompt-injection exitoso gaste el dinero de su titular.
Los reguladores empiezan a preguntar. La Ley de IA de la UE incluye obligaciones de transparencia en el Artículo 50 para sistemas de IA que interactúan con personas, y el cuadro más amplio bajo las obligaciones de alto riesgo de agosto de 2026 crea responsabilidad para los desplegadores cuando un agente actúa en nombre del usuario. La lógica de CDD continua de AMLR no se detiene en el humano; si un agente mueve dinero, la acción del agente es el evento CDD relevante.
Si tu plataforma tiene al menos un cliente usando un asistente basado en agentes para interactuar con ella — y a mediados de 2026 lo tienes, lo sepas o no — tienes tráfico no humano sin verificar en tu embudo de autenticación.
Los tres pilares, anclados en estándares reales
Identidad criptográfica del agente. Cada agente lleva un DID y una Verifiable Credential emitida por su operador, que a su vez vincula al agente con un titular. El handshake es una presentación verificable, no un token portador. Es la misma maquinaria que la implantación de la cartera EUDI bajo eIDAS 2.0, aplicada un nivel más arriba: la cartera verifica al humano, la credencial verifica al agente al que el humano delegó.
Verificación de mandato e intención. La Verifiable Credential que el agente presenta incluye el ámbito: cantidad, categoría de comercio, jurisdicción, ventana temporal, tipo de acción. Tu plataforma no tiene que confiar en la afirmación del agente sobre lo que hace; valida que la acción solicitada está dentro del mandato firmado criptográficamente. Si el agente intenta hacer algo fuera del mandato — porque sufrió prompt injection, fue secuestrado o simplemente se confundió — la acción falla en la capa de verificación, no en la cola de chargebacks.
Procedencia y reputación del modelo. Una atestación firmada del runtime del agente — modelo base, fine-tunes, conjunto de herramientas, configuración de seguridad — ligada a la credencial. Es la idea del ML-BOM (un SBOM para el stack de IA) hecha operativa. El patrón que derrota la dinámica IA contra IA del Fraude 4.0 en la capa del agente es exactamente este: un agente cuyo modelo está sancionado y cuyo runtime está atestado pertenece a una clase de riesgo distinta a la de un agente cuyo runtime es desconocido.
Estos tres juntos producen algo que una API key estática no puede: un actor verificado en runtime, vinculado a un mandato, con procedencia atestada. Ese es el suelo para permitir que un no humano ejecute acciones consecuentes en tu plataforma.
Qué se rompe si lo saltas
Saltarse el KYA no solo crea exposición al fraude. Colapsa varios controles a la vez.
Un usuario legítimo delega en un agente, el agente sufre prompt injection vía una página web maliciosa que navega y ejecuta un pago que el usuario no autorizó. Sin KYA, tu sistema antifraude ve una transacción desde el dispositivo de un usuario verificado y aprueba. Con KYA, el pago falla porque el mandato no incluía "enviar fondos a una dirección controlada por el atacante".
Un atacante construye un agente que imita a uno legítimo — mismo nombre, misma UX, mismos patrones de API. Sin KYA, distinguirlos requiere heurísticas. Con KYA, las credenciales simplemente no validan.
Un auditor pregunta quién realizó una acción y bajo qué autoridad. Sin KYA, puedes mostrar una sesión autenticada y un ID de usuario. Con KYA, puedes mostrar la cadena criptográfica de humano → mandato → agente → acción. La segunda sobrevive a un regulador.
La respuesta de 20 puntos del sector al fraude de identidad por IA lo reconoce explícitamente. Varias de sus medidas solo funcionan si existe una capa de identidad de agente debajo; no puedes defenderte del fraude impulsado por agentes a escala sin antes poder identificar a los agentes.
El KYA es la mitad superior de la infraestructura de identidad
El KYC verifica al humano. El KYC 3.0 convierte esa verificación en una señal continua y predictiva. El KYA verifica al agente al que el humano delegó. KYA continuo — verificando al agente en cada acción consecuente, no solo una vez — cierra el bucle.
Esta es la forma de la infraestructura de identidad para el resto de la década: un humano verificado de forma continua, agentes verificados por acción, mandatos firmados y revocables, y procedencia atestada hasta los pesos del modelo. Los proveedores construidos en torno al KYC tipo selfie-documento de 2010 tendrán que retroadaptarse. Las plataformas que envíen KYA de fábrica recibirán el tráfico agéntico por defecto, porque serán aquellas por las que las Visas y Mastercards puedan enrutar comercio agéntico consecuente sin heredar la responsabilidad.
Esa es la apuesta de Joinble. Nuestra arquitectura de KYC agéntico ya opera sobre la asunción de que el actor puede ser un agente; el KYA es la capa que vuelve esa asunción operativa. No estamos retroadaptando proveedores basados en selfie para la era de los agentes — la construimos así.
Preguntas frecuentes
¿El KYA sustituye al KYC? No. El KYA se monta sobre el KYC. El humano se sigue verificando en la base del stack — el KYC 3.0 hace que esa verificación sea continua. El KYA verifica al agente al que el humano delegó. Uno no elimina la necesidad del otro.
¿En qué se diferencia el KYA de la autenticación por API? Una API key autentica a un cliente. El KYA verifica la identidad criptográfica del agente, el titular por el que actúa, el mandato bajo el que opera y la procedencia de su modelo y herramientas. Una API key filtrada es plenamente utilizable por un atacante; una credencial KYA robada sin el mandato con el que se firmó no concede nada accionable.
¿Por qué W3C DIDs y Verifiable Credentials? Porque ya existen como estándares, se están desplegando bajo eIDAS 2.0 para carteras humanas y son las únicas primitivas criptográficas de identidad maduras e interoperables. Construir el KYA sobre el mismo sustrato mantiene al humano y al agente en el mismo grafo de identidad en vez de en silos paralelos.
¿El KYA obliga a cambiar cada flujo de login de mi plataforma? No. El KYA se invoca cuando un agente se presenta a tu plataforma — típicamente vía un intercambio estandarizado de credenciales en el API gateway o en la capa de autorización de pagos. Los flujos solo-humano existentes siguen sin cambios. El trabajo está en el perímetro, no en cada superficie de producto.
¿Y la prompt injection sobre un agente verificado? El KYA no impide que el agente se confunda. Impide que un agente confundido cause daño. Si un agente con prompt injection intenta actuar fuera de su mandato, la verificación falla en la plataforma y la acción no se ejecuta. La credencial dice "el agente puede gastar en la categoría X hasta la cantidad Y", no "el agente puede hacer cualquier cosa".
Si tráfico no humano está llegando a tu plataforma — y está llegando — tu stack KYC ya no es la respuesta entera. Habla con nuestro equipo sobre cómo cablear el KYA en tus capas de autenticación y pago antes de que los reguladores te pregunten por qué no lo hiciste.
Artículos relacionados

KYC de conocimiento cero: verificar sin revelar
El ZK-KYC permite verificar el cumplimiento sin almacenar datos personales. Cómo las pruebas de conocimiento cero resuelven la paradoja RGPD-compliance en 2026.

KYC Agéntico: Cómo los Agentes de IA Autónomos Están Sustituyendo las Revisiones Manuales de Compliance
El KYC tradicional depende de revisores humanos. El KYC agéntico usa agentes de IA autónomos que detectan deepfakes, evalúan riesgo y toman decisiones de compliance. Descubre cómo la arquitectura multi-agente reduce el 80% de revisiones manuales cumpliendo MiCA y AMLD6.

Tokenización de activos: por qué el KYC es clave
La tokenización de activos está transformando las finanzas, el inmobiliario y el mercado del arte. Pero sin una verificación de identidad robusta, la economía token no puede escalar. Descubre cómo el KYC potenciado por IA permite una tokenización segura y conforme.