Credenciales verificables W3C para agentes, explicadas
Contenido revisado el 17 de septiembre de 2026 · Equipo editorial NextAI
VC 2.0, DID, listas de estado, KMS y hash del manifiesto: cómo funciona por dentro la identidad de un agente de IA, con analogías y límites claros.
Una credencial verificable para un agente de IA es una declaración firmada sobre su identidad y alcance. Un verificador puede comprobar firma, vigencia y estado con las claves y recursos correspondientes. La credencial no observa automáticamente qué configuración ejecuta cada herramienta ni elimina todas las dependencias del emisor.
Este artículo desarma la parte técnica del DNI digital para agentes de IA sin exigir conocimientos de criptografía. Para la versión de negocio, empieza por qué es un DNI digital para agentes de IA.
Las cinco piezas y para qué sirve cada una
1. El identificador: DID
Un DID es un identificador digital que no depende de una autoridad central de registro. Usamos el método did:web, que ancla el identificador a un dominio: el emisor es did:web:digitalcortex.tech y cada agente tiene el suyo, con el formato did:web:digitalcortex.tech:agents:<slug>.
La analogía es el domicilio social. No te lo inventas al vuelo, cuelga de un sitio que alguien controla y un tercero puede ir a comprobarlo. En este caso, el documento DID del emisor está publicado en una ruta estándar y declara qué clave pública se usa para firmar.
2. La credencial: W3C Verifiable Credentials 2.0
El contenido —quién es el emisor, quién es el sujeto, qué se afirma, desde y hasta cuándo— se expresa en el modelo de datos W3C Verifiable Credentials 2.0. Nosotros lo serializamos en formato vc+jwt, es decir, empaquetado como token firmado.
Que el formato sea estándar importa por una razón práctica: un verificador que no sepa nada de nosotros puede leerlo igual. Si el formato fuese propietario, la verificación dependría de una herramienta nuestra, y entonces volveríamos al punto de partida: fiarse del emisor.
3. La firma: ES256 con la clave en un KMS
La credencial se firma con ES256, que es firma ECDSA sobre la curva P-256. El identificador de clave (kid) que viaja en la credencial es la huella JWK de la clave pública, de modo que el verificador sabe exactamente con cuál debe contrastar.
La parte relevante no es el algoritmo, sino dónde vive la clave privada: en Google Cloud KMS, nunca en el servidor web. La analogía es la caja fuerte. Que alguien entre en la web no le da la capacidad de firmar credenciales nuevas, porque la llave no está en el cajón del mostrador.
4. La huella de la configuración: hash del manifiesto
Cada agente tiene un manifiesto registrado con una versión y un hash SHA-256. El alcance y las prohibiciones se firman en la emisión. No debe suponerse que todos los prompts, herramientas y permisos efectivos forman parte de ese manifiesto.
La analogía útil es una referencia a una versión documentada. Comparar hashes permite detectar una diferencia en el manifiesto contrastado. No detecta por sí solo cambios en prompts cargados, modelos o permisos de servicios externos.
5. La revocación: Bitstring Status List v1.0
La credencial caduca a los 90 días y se renueva. Además puede anularse antes mediante una lista de estado firmada, según el estándar W3C Bitstring Status List v1.0.
La caducidad y la revocación limitan la aceptación de la credencial. El estado consultado depende de la frescura de los datos y las cachés. Retirar permisos y detener sesiones requiere medidas adicionales, como explica la guía de revocación.
Cómo encaja todo: las ocho comprobaciones
El verificador público ejecuta ocho comprobaciones en vivo, sin registro previo. Esta tabla asocia cada una con la pieza que la hace posible.
| Comprobación | Qué permite contrastar |
|---|---|
| Formato | Estructura admitida de la credencial |
| Clave del emisor | Referencia pública de la clave |
| Firma | Integridad y origen criptográfico |
| Coherencia del emisor | Correspondencia de identificadores |
| Vigencia | Fechas de aceptación |
| Revocación | Estado consultado según su actualización |
| Manifiesto | Coincidencia con el hash registrado |
| Documento DID | Publicación y vínculo del documento |
Estas comprobaciones no sustituyen a la autenticación de quien presenta la credencial ni al control de permisos en las herramientas.
La regla práctica para quien comprueba es simple: si alguna de las ocho falla, no te fíes. Y conviene recordar que la comprobación número 7 es la que distingue este enfoque de una acreditación clásica. Sin ella, la credencial describiría a un agente que pudo cambiar ayer por la tarde.
Una credencial útil permite comprobar una declaración y saber cuándo deja de ser aceptable. Su valor crece cuando se conecta con controles de ejecución que también se pueden probar.
El sello visual y por qué no es la prueba
Del hash del manifiesto y del DID se genera, de forma determinista, una imagen única por agente y por versión: el Sello CORTEX. El anillo exterior tiene 256 marcas que representan los bits del hash; los rombos claros son las acciones permitidas; los rombos rojos, las prohibidas; una barra indica el nivel de autonomía; y un código QR abre la verificación pública.
El sello enlaza con una comprobación. Imagen, credencial y firma pueden copiarse: la firma permite detectar alteraciones del contenido, no autenticar a quien comparte el QR. Su estado visual depende de la actualización del servicio y sus cachés.
Qué NO garantiza una credencial verificable
Es la sección más importante y la que casi siempre falta en el material del sector.
- Calidad: una firma no garantiza respuestas correctas.
- Independencia: se trata de una autodeclaración verificable, no de una auditoría de terceros.
- Seguridad: declarar una prohibición no bloquea una herramienta.
- Corte: revocar y detener son operaciones distintas que deben ensayarse.
- Configuración: el hash del manifiesto registrado no observa por sí solo cambios externos.
- Privacidad: la credencial de referencia identifica al agente y la sociedad; hay que revisar qué campos se publican en cada emisión.
Estándares abiertos, no dependencia
Todo lo anterior se apoya en especificaciones públicas del W3C: Verifiable Credentials 2.0, DID con el método did:web y Bitstring Status List v1.0. La especificación de nuestro perfil se publicará con licencia abierta, y la documentación de campos y endpoints ya está disponible en la documentación técnica de identidad agéntica junto con la política pública.
Cualquier empresa puede emitir credenciales de sus propios agentes con este enfoque sin pasar por nosotros. Hasta donde hemos podido comprobar, no conocemos otra consultora de IA para pymes en el mercado hispanohablante que publique credenciales verificables de sus agentes; si existe, la citaremos encantados. Una lectura menos técnica del mismo asunto está en por qué cada agente debería llevar carné, y el encaje con el inventario interno, en registro de agentes.
Preguntas frecuentes
¿Qué es una credencial verificable del W3C?
Es un modelo de datos estándar para afirmaciones firmadas digitalmente que un tercero puede validar por su cuenta. Define quién emite, sobre quién afirma, qué afirma y durante cuánto tiempo, en un formato que cualquier verificador compatible puede leer.
¿Por qué usar did:web y no otro método de DID?
Porque ancla la identidad a un dominio que ya es comprobable y no exige infraestructura adicional. El documento DID se publica en el dominio del emisor y declara la clave pública de firma, con lo que la cadena de confianza es corta y auditable.
¿Por qué se guarda la clave privada en un KMS?
Para separar la capacidad de firmar del servidor que sirve la web. Si el servidor se ve comprometido, el atacante no obtiene la clave, porque las operaciones de firma se realizan en el módulo de gestión de claves y la clave privada no sale de ahí.
¿Qué pasa si el emisor desaparece?
El documento DID dejaría de publicarse y la comprobación número 8 fallaría. Es una propiedad intencionada: una identidad cuyo emisor ya no responde no debería seguir validándose como si nada.
¿Se puede verificar sin conexión a internet?
La firma y el formato sí, si se dispone de la clave pública. La vigencia, la revocación y el documento DID requieren consultar fuentes en línea, porque describen un estado que cambia con el tiempo.
Qué hacer con esto
- Pide el formato, no la promesa. Si un proveedor dice que sus agentes son verificables, pregunta qué estándar usa y dónde está publicada la clave.
- Comprueba la comprobación de integridad. Que exista firma es lo mínimo; contrastar la configuración efectiva con la declaración firmada es lo que aporta valor.
- Revisa dónde vive la clave privada. En el servidor web es una mala señal.
- Exige revocación y caducidad explícitas, con un plazo concreto.
- Valida tú mismo una vez. Abre el verificador público, ejecuta las comprobaciones y comprueba qué información obtienes sin pedir permiso a nadie.
¿Quieres aplicar esto a los agentes que ya operan en tu empresa? Habla con nosotros.
Actualización editorial del 17 de septiembre de 2026 realizada con apoyo de IA y contraste de documentación pública. No se presenta como una auditoría externa.
Identidad y ejecución: alcance de esta explicación
Las comprobaciones públicas describen la credencial y su relación con el manifiesto registrado. No prueban la autenticación de quien la presenta, el estado de cada permiso externo ni el bloqueo real de acciones. Consulta las evidencias y límites publicados.