)
Imagina dos agentes de IA a punto de iniciar diálogo entre fronteras organizacionales. Un agente de compras en la Empresa A contacta a un agente proveedor en la Empresa B para negociar un pedido. Nunca han interactuado antes. No comparten backend, no hay secreto precompartido ni humano en el loop que avale a ninguna parte. Llega el primer mensaje y el agente de la Empresa B debe decidir qué hacer con él.
¿Qué puede verificar realmente en ese instante?
Con el stack web actual, sorprendentemente poco sobre el propio agente. TLS confirma que el certificado del dominio emisor es válido, lo que indica que algún servicio en company-a.example posee una clave privada asociada a un nombre DNS. No dice qué agente dentro de esa infraestructura hizo la llamada, quién lo controla ni qué está autorizado a hacer. OAuth y OpenID Connect se diseñaron alrededor de un usuario humano que inicia sesión, consiente y entrega un token a un cliente. Si eliminas al humano, la mayoría de supuestos de confianza del protocolo se desmoronan. Una API key es aún más débil: prueba solo que quien llama conoce una cadena concreta. Eso está más cerca de una contraseña que de una identidad.
El resultado es una brecha entre lo que garantiza la capa de red y lo que necesita saber la capa de agentes. Hay tres preguntas que deben responderse juntas al inicio de un diálogo cross-domain, automáticamente y sin aprobación humana:
- Quién es este agente como entidad estable que persiste entre sesiones y despliegues
- Quién lo controla, es decir, qué persona u organización responde por sus acciones
- Qué está autorizado a hacer en este diálogo concreto, incluyendo delegaciones de autoridad desde su principal
Los protocolos actuales responden como mucho una de estas preguntas, y solo parcialmente. Estándares recientes agente-a-agente como A2A y sus extensiones de pagos resolvieron interoperabilidad y coordinación económica, lo cual era el primer paso correcto. Pero se apoyan en las mismas primitivas de seguridad web, por lo que heredan supuestos centrados en humanos sobre establecimiento de sesión y gestión de credenciales.
¿Por qué esto importa ahora y no hace cinco años? Porque cambió la topología. Mientras los agentes vivían dentro del jardín cerrado de una sola empresa, la identidad era implícita. La plataforma sabía quién era quién y el control de acceso era un problema de configuración. Cuando los agentes empiezan a actuar como actores económicos que gestionan presupuestos, firman contratos, acceden a datos regulados y negocian con desconocidos, esa confianza implícita desaparece. El agente proveedor no puede suponer que la Empresa A registró su agente de compras en un directorio que él controle. Ese directorio no existe.
Así que el agente proveedor queda en una disyuntiva binaria: rechazar a todo llamante desconocido (matando el comercio abierto agente-a-agente), o aceptar todo y confiar en checks posteriores (cómo se drenan APIs expuestas). Ninguna opción es seria para sistemas que pronto moverán dinero y datos de forma autónoma.
La pregunta interesante es cómo se ve una respuesta real. Debe dar al agente receptor del primer mensaje un modo de verificar criptográficamente la identidad del emisor, resolver quién está detrás e inspeccionar qué autoridad concreta porta, sin configuración bilateral previa entre Empresa A y Empresa B. Debe funcionar la primera vez que se encuentran dos agentes y seguir funcionando cuando roten claves, cambien propietarios o caduquen autorizaciones.
Qué son realmente DIDs y Verifiable Credentials
La respuesta que sustenta la investigación se basa en dos estándares W3C diseñados justo para verificación cross-domain: Decentralized Identifiers y Verifiable Credentials. A menudo se describen bajo la etiqueta self-sovereign identity, que es correcta pero poco útil si quieres entender qué bytes viajan por el canal. Veámoslos como los usa el agente.
Un Decentralized Identifier es un identificador que el sujeto crea y controla por sí mismo, sin pedir permiso a un registrador central. Tiene forma URI, por ejemplo did:web:agents.company-a.example:procurement-7 o did:key:z6Mk.... Lo importante no es la cadena, sino a qué resuelve. Resolver un DID devuelve un DID Document: estructura JSON pequeña con claves públicas asociadas al identificador, métodos de verificación válidos y endpoints de servicio donde contactar al sujeto. El DID Document se ancla en un ledger o en otra fuente verificable de datos, de modo que cualquiera puede consultarlo y confiar en que no fue manipulado.
Tres propiedades de este diseño importan para agentes. Primera: el DID Document no contiene atributos personales; lleva claves y punteros, nada más, por lo que publicarlo no filtra datos sensibles. Segunda: el sujeto puede rotar claves publicando un DID Document actualizado, sin certificate authority y sin cambiar el DID. El identificador del agente permanece estable durante su ciclo de vida, aunque cambie material criptográfico subyacente. Tercera: el DID Document puede declarar deputies, es decir, otros DIDs autorizados para actuar en su nombre. Así se codifican propiedad humano-a-agente y delegación agente-a-agente directamente en la capa de identidad, no como parche posterior.
Una Verifiable Credential es una afirmación firmada que una parte emite sobre otra. Su estructura es simple: issuer, subject, conjunto de claims y prueba criptográfica. El issuer firma con clave privada ligada a su DID. El subject se identifica por su DID. Las claims son aserciones key-value, y ahí reside su flexibilidad.
Concretamente, el agente de compras podría guardar tres VCs:
- Una emitida por el sistema HR de la Empresa A: "este DID pertenece a la Empresa A, rol compras"
- Una emitida por finanzas de la Empresa A: "este DID puede comprometer fondos hasta 10.000 EUR por transacción, válido hasta fin de trimestre"
- Una emitida por un auditor externo de compliance: "este DID opera bajo marco ISO 42001, certificado X"
Cada issuer tiene su propio DID, anclado en el mismo ledger o en uno accesible al verificador. Así, cuando el agente proveedor recibe una VC, puede resolver el DID del issuer, obtener su clave pública y verificar la firma sin contactar al issuer. La VC es autocontenida y verificable offline. Esa propiedad permite operar desde el primer mensaje entre agentes que nunca se conocieron.
Lo útil surge al combinar ambas primitivas. El DID aporta identidad criptográfica estable bajo control del agente. Las VCs permiten que terceros adjunten claims a esa identidad para presentarlas a cualquiera. Ninguna pieza sola basta. Un DID sin credenciales solo prueba control de una clave. Credenciales sin DID no tienen sujeto estable al que anclarse. Juntas, dan al agente proveedor lo necesario para contestar las tres preguntas anteriores en un único handshake, sin relación previa con Empresa A.
El handshake de confianza en el primer mensaje
Ahora la mecánica. Dos agentes acaban de abrir canal. Cada uno tiene su DID y un pequeño portafolio de Verifiable Credentials. ¿Qué ocurre entre "hola" y el momento de confiar lo suficiente para operar?
El handshake corre en cuatro fases. Ninguna exige que Empresa A y Empresa B se conocieran antes.
Fase 1: intercambio de DIDs. Cada agente envía su DID. El agente proveedor recibe el DID del agente de compras, toma la parte específica del método y la resuelve. Si es did:web, resuelve vía HTTPS. Si es un método anclado en ledger como did:ion o did:ethr, resuelve vía ledger. El resultado es el DID Document del agente de compras, con clave pública actual y métodos de verificación declarados por el propio sujeto. Paso simétrico en sentido inverso. Al final, ambos saben qué clave deberían estar usando. Aún no saben si la contraparte realmente la controla.
Fase 2: prueba de control. Es un challenge-response. El agente proveedor envía un nonce fresco y pide al agente de compras firmarlo con la clave privada vinculada al DID presentado. El agente de compras firma, devuelve firma y el proveedor verifica con la clave pública obtenida en fase 1. Paso simétrico al otro lado. Aquí identidad se convierte en autenticación. Cualquiera puede afirmar un DID; solo el controlador legítimo produce firma válida con la clave del DID Document.
Fase 3: presentación de credenciales. Ahora cada agente decide qué VCs son relevantes para este diálogo y las presenta. La selectividad importa. El agente de compras no vuelca todo su almacén; envía el subconjunto necesario, por ejemplo VC de ownership y VC de spending authority. Si política del proveedor exige attestation de compliance, añade la VC del auditor. Esta presentación viaja en una Verifiable Presentation firmada por el DID del holder, probando que quien presenta es el mismo sujeto de las credenciales.
Fase 4: verificación de issuers. Aquí ocurre la decisión real de confianza. El agente proveedor toma cada VC, lee issuer, resuelve ese DID en ledger, obtiene clave pública del issuer, valida firma, y comprueba expiración/revocación. La revocación puede implementarse de varias formas según despliegue: listas de estado publicadas en endpoint conocido o entradas de registro en ledger. Después viene el policy check: para cada claim, el proveedor evalúa si ese issuer está reconocido como autoridad para ese tipo de claim. Una firma del HR de Empresa A puede valer para ownership; una firma self-issued aleatoria no debería valer para spending authority. Esta evaluación es local al verificador y gobierna su propia política.
Algunas observaciones clave:
La confianza no es transitiva por defecto. El proveedor no confía en el HR de Empresa A "porque Empresa A lo diga"; confía porque su propia política lo lista como autoridad para claims de identidad legal. Si no está en política, la credencial puede ser criptográficamente válida y operativamente ignorada.
El handshake es stateless en el sentido de que no hubo setup bilateral previo entre organizaciones. El onboarding se reduce a "configura qué issuers confías para qué tipos de claim". Nuevos agentes de nuevas organizaciones pueden integrarse sin registro bilateral.
El flujo encaja naturalmente encima de protocolos de transporte agente-a-agente como A2A. La AgentCard de A2A puede portar el DID. La primera solicitud firmada tras handshake vincula sesión de aplicación a identidad verificada. La capa de identidad agrega verificación al abrir canal, sin reemplazar lo que A2A ya resuelve en routing y discovery.
Confianza diferenciada, y por qué es el cambio real
El handshake anterior produce una lista de claims criptográficamente válidos sobre la contraparte. Esa lista no es una decisión; es materia prima. La decisión ocurre cuando el verificador mapea claims contra su política local, y ahí este modelo se separa de cómo funciona autorización web clásica.
Llamémoslo confianza diferenciada. Cada agente decide por sí mismo, en tiempo real, qué credenciales pesan cuánto, para qué acciones y desde qué issuers. No hay autoridad global que diga "este token da este scope". Hay un verificador, un conjunto de claims presentados y una política local que los compone.
Llévalo al caso de compras. El agente proveedor recibe tres VCs:
- Una VC firmada por cámara de comercio nacional, afirmando que la entidad controladora es la persona jurídica Empresa A
- Una VC firmada por finanzas de la Empresa A, afirmando que este agente puede comprometer fondos hasta 10.000 EUR por transacción
- Una VC autoemitida por el propio agente, afirmando preferencia de respuestas JSON frente a XML
Las tres pueden ser criptográficamente válidas. Ninguna es automáticamente más confiable. La política del proveedor asigna peso. Una configuración razonable: la VC de cámara de comercio se acepta para identidad legal porque ese issuer está marcado como autoridad para ese claim; la VC de finanzas se acepta para spending authority porque ese DID está marcado como autoridad de delegaciones de Empresa A sobre sus agentes; la VC autoemitida se trata como informativa sin peso de autorización.
Lo importante: esto no es un scope OAuth predefinido por un provider. Es composición de claims heterogéneos con distintos issuers evaluados contra reglas propias del verificador.
Esto resuelve un problema que sistemas bilaterales manejan mal. La autorización cross-domain en el mundo real involucra claims de fuentes distintas con autoridad distinta sobre cosas distintas. Cámara de comercio es autoridad sobre existencia legal, no sobre límites de gasto. Finanzas es autoridad sobre sus delegaciones, no sobre compliance regulatorio. Auditor de compliance es autoridad sobre su auditoría, no sobre empleo. Un único authorization server no puede hablar por todos. La confianza diferenciada permite que cada issuer hable solo de lo que conoce, y el verificador componga el resultado.
La otra consecuencia es operativa. Dos organizaciones sin interacción previa pueden hacer negocio a nivel agente sin registrarse mutuamente. El agente proveedor no necesita cuenta precreada de Empresa A. Necesita una política que diga qué issuers acepta y para qué claim types. Nuevas contrapartes aparecen, presentan credenciales emitidas por partes ya confiadas, y el handshake completa. El onboarding cambia de "registrar cada contraparte" a "curar tu lista de issuers confiables".
Hay un coste claro: la trust policy se vuelve artefacto crítico. Decide qué se acepta y qué no, por lo que decide en qué gastará dinero el agente, qué datos liberará y con quién operará. Un bug en política es un incidente de seguridad. Una entrada obsoleta en trusted issuers es vulnerabilidad silenciosa. Esa política requiere versionado, revisión y proceso explícito de alta/baja de issuers. No es un archivo de config para escribir una vez y olvidar.
)
Dónde se rompe cuando el LLM controla el procedimiento
Las primitivas criptográficas funcionan. Es importante afirmarlo con claridad: resolución de DIDs, challenge-response, validación de firmas de VCs, lookup de issuer en ledger… todo funciona end-to-end. Dos agentes de organizaciones distintas pueden completar el handshake sin pre-registro bilateral y llegar a identidad verificada de la contraparte. La "plomería" técnica es sólida.
El problema empieza una capa arriba. Cuando el LLM del agente asume control total del procedimiento de seguridad, aparecen degradaciones que no son fallo de criptografía, sino consecuencia de usar un componente probabilístico para una tarea que exige determinismo. La evaluación del prototipo lo deja claro, y los modos de fallo indican exactamente qué piezas no deben dejarse al modelo.
El diálogo se vuelve superficie de ataque. Si la lógica de verificación está expresada en instrucciones de lenguaje natural dentro del system prompt, un atacante puede moldear la conversación para empujar al modelo a aceptar una credencial que debería rechazar. El modelo fue instruido para verificar cuidadosamente, pero también para ser cooperativo. Una contraparte que encuadra credenciales de forma persuasiva o inyecta instrucciones disfrazadas de conversación puede inclinar la balanza. La verificación criptográfica puede pasar mientras el policy check, si vive en prompt, se "negocia".
La selective disclosure filtra bajo presión. El agente de compras debe presentar solo credenciales relevantes. Si esa selección la hace el LLM en respuesta a solicitudes de la contraparte, una contraparte insistente puede extraer credenciales no pertinentes. El agente sobreexpone claims que debieron quedarse en su store. La criptografía no falló; el modelo compartió demasiado.
Deriva de trusted issuers. La política "acepto issuer X para claim type Y" es la base de la confianza diferenciada. Si esa política se codifica como texto en prompt y el modelo la aplica a lo largo de múltiples turnos y diálogos, deriva. Issuers válidos para un tipo de claim se tratan como válidos para otro. Casos límite se resuelven distinto entre ejecuciones. La política deja de ser política y pasa a sugerencia.
Se omite revocación. Los checks de revocación son poco vistosos y fáciles de saltar. Una credencial puede ser criptográficamente válida y operativamente muerta al mismo tiempo. Cuando el flujo lo orquesta el modelo, la revocación suele ser de los primeros pasos que desaparecen silenciosamente, especialmente en diálogos largos con objetivos en conflicto. Resultado: credenciales vencidas o revocadas terminan aceptadas.
El patrón común: el fallo no está en DIDs, VCs, ledger o firmas. Está en poner a un razonador probabilístico a cargo de operaciones que deben ser deterministas, auditables y resistentes a input adversarial proveniente del propio canal que se intenta proteger.
La lectura correcta no es genérica de "este enfoque tiene problemas". Es específica: funciona cuando primitivas de identidad viven en una capa de seguridad determinista que el LLM invoca como herramientas; se degrada cuando el LLM ejecuta directamente la verificación. Resolver DID, validar firma, chequear revocación, evaluar autoridad de issuer por claim type… son operaciones con respuestas correctas/incorrectas. Deben vivir en código detrás de interfaces limpias, con el modelo consumiendo resultados booleanos. No deben residir en ventana de contexto como "guía" interpretativa.
Las decisiones de diseño que este modelo te obliga a tomar
Si tomas en serio lo anterior, la arquitectura de un agente que usa DIDs y Verifiable Credentials debe diferir de un agente LLM estándar con auth añadida al final. Hay decisiones concretas que tomar, casi todas orientadas a trazar una frontera dura entre lo que orquesta el modelo y lo que ejecuta de forma determinista la capa subyacente.
La clave privada no es problema del LLM. La clave asociada al DID del agente es lo que vuelve real la identidad. Debe vivir en un componente que el LLM no pueda leer: HSM, enclave o al menos servicio local de firma expuesto como tool. El modelo invoca sign(payload) y recibe firma. Nunca ve material de clave, nunca lo recibe como string, nunca lo mantiene en contexto. Lo mismo aplica a claves de descifrado asociadas al DID. No es paranoia: es el único modo de evitar exfiltración de identidad criptográfica por prompt injection.
El credential store es un activo gestionado, no memoria. El portafolio de VCs tiene ciclo de vida. Credenciales se emiten con vigencia; algunas se revocan; otras se reemiten por cambios de delegación. Tratarlo como blob estático que el modelo "lee" es receta para presentar credenciales expiradas en producción. El store debe ser un servicio con operaciones explícitas: listar credenciales, obtener credencial concreta, marcar expiración. Una VC de delegación vencida es la nueva API key olvidada.
La trust policy es código, no prompt. La lista de issuers aceptados por tipo de claim debe residir en motor de política determinista. Open Policy Agent sirve. Un rules layer propio también. Un módulo con tests explícitos también. Lo que no sirve es escribir política en system prompt y pedir al modelo que la aplique. La política debe versionarse, revisarse y auditarse. Añadir un issuer confiado debe ser cambio de código, no turno conversacional.
La elección de método DID no es cosmética. Métodos DID tienen propiedades distintas y consecuencias operativas. did:web es barato y simple, pero ata resolución a DNS/HTTPS y hereda supuestos de confianza de web PKI. did:key es autocontenido, pero sin historia robusta de rotación. Métodos anclados en ledger como did:ion o did:ethr dan mejor resistencia a censura y rotación clara, pero agregan latencia y complejidad operativa. Para un agente de compras que interactúa con múltiples proveedores al día, suele funcionar un enfoque híbrido: did:web para el agente por velocidad, DID anclado en ledger para issuers cuyas firmas deban verificarse independientemente de cualquier dominio.
El caching debe respetar rotación. Resolver DID Documents en cada primer mensaje añade latencia acumulativa en agentes de alta interacción. Cachear es la respuesta obvia. Lo no obvio es el TTL. Si cacheas demasiado, puedes ignorar rotación de clave de la contraparte y validar contra claves obsoletas. Si cacheas muy poco, vuelve la latencia. El TTL debe alinearse con cadencia real de rotación de issuers y permitir invalidación explícita ante eventos de revocación.
Integración A2A es cuestión de secuencia. Cuando el transporte es A2A, AgentCard es lugar natural para publicar DID. El handshake debe ejecutarse antes de abrir diálogo de aplicación, y la primera petición firmada posterior vincula sesión a identidad verificada. Colocar verificación después de iniciar mensajes de aplicación es secuencia incorrecta, porque para entonces el agente ya pudo exponer intención o datos a una contraparte no autenticada. Disciplina: identidad primero, aplicación después.
La conclusión de la investigación —y la clave práctica— es concreta: la identidad verificable de agentes funciona cuando se fuerza criptográficamente fuera del LLM y se expone al LLM solo mediante herramientas bien definidas. El modelo orquesta diálogo, decide qué pedir y razona sobre resultados. No ejecuta verificación, no guarda claves y no arbitra trust policy. Esa separación es lo que permite que un agente verifique a otro desde el primer mensaje, entre dominios organizacionales, sin registro bilateral previo.
)