KYA-OS 1.0 propone una identidad verificable para saber qué agente de IA actúa, quién lo autoriza y con qué permisos
Fecha efectiva / observada:
Qué ha cambiado
KYA-OS 1.0 ha superado la aprobación del Steering Committee de la Decentralized Identity Foundation (DIF). Su objetivo es añadir a los agentes de IA una capa verificable de identidad, autoridad delegada y pruebas criptográficas para poder responder mejor a tres preguntas: quién actúa, quién le ha autorizado y qué puede demostrar sobre esa actuación. QUÉ HA CAMBIADO DIF comunicó en su Newsletter #63, publicada en julio de 2026, que KYA-OS 1.0 había pasado la aprobación de su Steering Committee. El registro de esquemas del proyecto describe actualmente KYA-OS v1 como una especificación ratificada del grupo Trusted Agents & Authority de DIF. El cambio importante no es que los agentes “obtengan un DNI” en sentido humano. Lo que KYA-OS intenta aportar es una forma técnica de enlazar: - una identidad criptográfica; - una parte responsable; - una delegación de autoridad; - restricciones de alcance; - pruebas firmadas de cada petición o respuesta; - revocación; - y una base para auditoría posterior. POR QUÉ HACE FALTA ALGO ASÍ Un agente puede utilizar herramientas, consultar datos, llamar APIs, delegar trabajo a otro agente o realizar acciones en nombre de una persona u organización. Pero conocer el nombre del agente no responde automáticamente a preguntas como: - ¿quién controla realmente este agente?; - ¿qué clave demuestra su identidad?; - ¿quién le dio permiso para actuar?; - ¿qué acciones concretas puede realizar?; - ¿puede delegar esos permisos a otro agente?; - ¿cuándo caduca esa autoridad?; - ¿se puede revocar?; - ¿cómo sabemos que esta petición concreta fue realmente enviada por ese agente?; - ¿cómo se conserva una evidencia verificable después? KYA-OS intenta convertir esas preguntas en información y pruebas que una máquina pueda comprobar. IDENTIDAD: NO SOLO UN NOMBRE La implementación de referencia utiliza identificadores descentralizados o DIDs. Entre los métodos contemplados están: - `did:key`, útil para identidades ligadas directamente a una clave; - `did:web`, que permite vincular la identidad a un dominio web controlado por una organización. El objetivo no es confiar en un texto que diga “soy el agente de Empresa X”. La identidad debe poder vincularse a material criptográfico verificable. La implementación actual también contempla otros resolvers opcionales, pero RA debe separar siempre lo que forma parte del núcleo estable de lo que se añade después como extensión. DELEGACIÓN: IDENTIDAD NO ES LO MISMO QUE PERMISO Saber quién es un agente no significa que tenga derecho a hacer cualquier cosa. KYA-OS separa identidad de autoridad. La delegación puede expresarse mediante credenciales verificables y restricciones que describen: - recursos permitidos; - scopes; - límites; - audiencia; - condiciones temporales; - capacidad de volver a delegar. Una cadena puede tener esta forma: PERSONA U ORGANIZACIÓN RESPONSABLE → delega una autoridad limitada AGENTE A → puede ejecutar determinadas acciones AGENTE A → si está permitido, delega una parte todavía más limitada AGENTE B Cada salto debe respetar las restricciones de la autoridad anterior. La idea importante es la atenuación: un agente delegado no debería poder ampliar por sí mismo los permisos que recibió. PRUEBA POR PETICIÓN Una de las piezas más interesantes es que la identidad no se demuestra solo al comenzar una sesión. La arquitectura actual de KYA-OS incluye pruebas firmadas ligadas a peticiones concretas. Eso permite verificar cosas como: - qué clave firmó; - para qué destinatario era la petición; - qué contenido estaba vinculado a la prueba; - si la prueba está dentro de su ventana temporal; - si existe una delegación suficiente; - si la petición puede ser una repetición de otra anterior. El objetivo es evitar que una credencial capturada sea suficiente por sí sola para hacerse pasar por el agente legítimo. La documentación actual de Entity Card lleva esta idea más lejos mediante pruebas holder-of-key por petición: el agente debe demostrar que posee la clave asociada a la autoridad que presenta. REPLAY: EVITAR QUE UNA PETICIÓN VÁLIDA SE REUTILICE Una petición firmada puede ser válida y aun así ser peligrosa si un atacante puede capturarla y repetirla. KYA-OS incluye mecanismos de nonce y validación temporal para detectar replays. En términos sencillos: “esta petición fue legítima una vez” no debe implicar: “esta misma petición puede ejecutarse infinitas veces”. Para despliegues distribuidos, la propia implementación advierte de que el estado necesario para impedir replays debe compartirse entre instancias y sobrevivir a reinicios mediante almacenamiento adecuado. REVOCACIÓN Los permisos tampoco deberían durar para siempre. KYA-OS contempla mecanismos de revocación para que una autoridad emitida pueda dejar de ser válida. Esto resulta importante cuando: - un agente es retirado; - una clave se compromete; - termina una relación contractual; - cambia un puesto o responsabilidad; - una delegación ya no debe continuar; - un subagente deja de estar autorizado. La revocación debe comprobarse dentro del proceso de verificación, no tratarse como una nota informativa. MCP Y KYA-OS NO SON LO MISMO Model Context Protocol (MCP) permite que modelos y agentes se conecten con herramientas, datos y servicios mediante una interfaz común. KYA-OS intenta añadir una capa distinta: MCP → cómo se comunican agentes o clientes con herramientas y servidores KYA-OS → quién está actuando, qué autoridad presenta y qué evidencia criptográfica acompaña a esa acción Por tanto, KYA-OS no sustituye MCP. Puede utilizar MCP como uno de sus entornos de integración. La implementación de referencia del proyecto está precisamente centrada en su binding para MCP. EL BINDING MCP MÁS RECIENTE SIGUE SIENDO DRAFT Este punto es importante para no mezclar niveles de madurez. KYA-OS v1 aparece actualmente descrito por el proyecto como especificación ratificada. Sin embargo, el documento que adapta KYA-OS al nuevo sistema de extensiones de MCP está marcado: Version: 1.0.0-draft Status: Draft Ese binding propone la extensión: `org.kya-os/decentralized-authority` y define cómo transportar en MCP moderno: - declaración de capacidad; - pruebas por petición; - pruebas de respuesta; - delegación; - challenges de autorización; - propagación a través de gateways; - descubrimiento. Por tanto: KYA-OS v1 ratificado ≠ cada integración futura de KYA-OS está ya ratificada o finalizada. RA debe mantener esta diferencia visible. ENTITY CARD: QUIÉN ES LA ENTIDAD QUE ESTAMOS VIENDO El proyecto también desarrolla un perfil denominado Entity Card. Su objetivo es publicar una identidad tipada y anclada en DID que pueda proyectarse sobre varios mecanismos de descubrimiento. La documentación actual contempla tipos como: - agent; - MCP server; - client; - verifier; - human. La tarjeta puede proyectarse hacia ecosistemas como: - MCP; - A2A; - NANDA. Pero el documento actual de Entity Card sigue identificado como un work item de DIF TAAWG. Además, algunas de sus primitivas están específicamente marcadas como candidatas a ratificación. Esto vuelve a mostrar por qué RA debe separar: - núcleo ratificado; - perfiles posteriores; - extensiones draft; - implementación de referencia. IDENTIDAD NO EQUIVALE A CONFIANZA Una de las distinciones más importantes es esta: verificar quién firma no demuestra que esa entidad sea buena. Una identidad criptográfica puede ayudar a demostrar: - continuidad; - control de una clave; - origen de una petición; - vínculo con una delegación. Pero no demuestra automáticamente: - que el agente sea competente; - que diga la verdad; - que no tenga vulnerabilidades; - que sus herramientas sean seguras; - que su propietario sea confiable; - que una decisión sea correcta; - que una acción esté permitida legalmente. KYA-OS puede aportar identidad y accountability. La confianza final necesita más evidencia. AUTORIDAD TAMPOCO EQUIVALE A SEGURIDAD Un agente puede tener permiso legítimo para una acción y aun así ejecutarla mal. Por ejemplo: “este agente está autorizado a modificar una reserva” no demuestra: “la modificación que propone es correcta”. La seguridad de un sistema multi-agente necesita combinar: - identidad; - autorización; - límites; - aislamiento; - validación; - políticas; - auditoría; - controles humanos cuando correspondan. KYA-OS cubre principalmente la parte de identidad, autoridad y prueba. PRUEBAS DE RESPUESTA Y TRAZABILIDAD La implementación actual permite generar pruebas criptográficas también sobre respuestas. Esto puede servir para registrar: - qué servidor produjo una respuesta; - qué contenido se vinculó a la prueba; - qué delegación se utilizó; - qué resultado se obtuvo. El proyecto ha desarrollado además una capa de auditoría que puede componer eventos de autorización, delegación y pruebas en un historial firmado. Esa capa ya va más allá del anuncio inicial de KYA-OS 1.0 y RA debe seguirla como evolución del sistema, no confundirla con todo lo ratificado originalmente. RELACIÓN CON A2A A2A y KYA-OS tampoco hacen el mismo trabajo. A2A: → permite que agentes se descubran, se comuniquen y se deleguen tareas. KYA-OS: → intenta aportar identidad, autoridad delegada y prueba verificable sobre quién actúa. Una arquitectura podría utilizar ambos: A2A → Agent A envía una tarea a Agent B KYA-OS → Agent B comprueba quién es Agent A, de qué autoridad procede la petición y si las pruebas son válidas Esto conecta directamente esta señal con el ID 82 de RadarAbierto sobre A2A. RELACIÓN CON TRACE TRACE, cubierto por RA en el ID 80, trabaja sobre otra capa complementaria: evidencia verificable del entorno y ejecución de cargas de IA. Una arquitectura futura podría necesitar responder simultáneamente: KYA-OS → ¿quién actúa y con qué autoridad? A2A → ¿cómo hablan y se delegan tareas los agentes? MCP → ¿cómo acceden a herramientas y contexto? TRACE → ¿qué evidencia podemos conservar sobre el runtime y la ejecución? No significa que estos proyectos vayan a integrarse necesariamente entre sí de una forma concreta. Significa que atacan problemas diferentes que pueden coexistir en una misma arquitectura. POR QUÉ ESTO IMPORTA PARA AGENTES QUE ACTÚAN POR PERSONAS Cuando un chatbot solo responde preguntas, una identidad técnica débil puede parecer un problema menor. La situación cambia si un agente puede: - comprar; - transferir dinero; - firmar; - reservar; - modificar infraestructura; - desplegar código; - consultar datos personales; - actuar en nombre de una empresa; - encargar tareas a otros agentes. En ese entorno, “es un agente autorizado” ya no debería ser una afirmación informal. Debería poder comprobarse: - quién es responsable; - qué permisos concretos tiene; - qué clave presenta; - qué cadena de delegación existe; - qué acción ejecutó; - y cuándo dejó de estar autorizado. KYA-OS intenta proporcionar piezas para construir esa trazabilidad. QUÉ PUEDE COMPROBAR UN VERIFICADOR En una implementación completa, un verificador puede llegar a comprobar elementos como: - firma; - clave; - DID; - audiencia; - ventana temporal; - nonce; - hash de la petición; - cadena de delegación; - scopes; - restricciones; - estado de revocación; - vínculo entre la clave que presenta la prueba y la autoridad delegada. Esto permite trasladar parte de la decisión desde: “confío en este nombre” hacia: “puedo verificar una cadena de evidencias y decidir según mi política”. QUÉ NO RESUELVE KYA-OS KYA-OS no resuelve por sí solo: - reputación; - calidad de las respuestas; - alucinaciones; - prompt injection; - seguridad del modelo; - seguridad de las herramientas; - malware; - cumplimiento legal completo; - responsabilidad jurídica automática; - confianza entre organizaciones; - atribución humana definitiva cuando las claves o sistemas han sido comprometidos. Tampoco evita que una persona conceda permisos excesivos. Puede ayudar a expresar y comprobar autoridad. No decide si esa autoridad era prudente. A QUIÉN PUEDE INTERESAR Si desarrollas agentes: permite separar identidad, permisos y pruebas de la lógica de negocio del agente. Si construyes servidores MCP: puede ofrecer un mecanismo adicional para verificar quién llama y qué autoridad presenta. Si diseñas plataformas multi-agente: ayuda a pensar en cadenas de delegación y restricciones entre agentes. Si trabajas en seguridad: interesa la prueba por petición, holder-of-key, replay prevention, revocación y fail-closed. Si trabajas en auditoría o cumplimiento: interesa poder reconstruir quién actuó, bajo qué delegación y con qué evidencia. Si eres una organización que desplegará agentes autónomos: obliga a plantear desde el principio quién es la parte responsable y hasta dónde puede delegar. Si eres usuario final: su impacto será indirecto, pero puede ser una de las capas que permita exigir más trazabilidad cuando un agente actúe en tu nombre. QUÉ PUEDES HACER AHORA Si quieres evaluar KYA-OS: 1. Lee primero la especificación v1 y distingue el núcleo ratificado de los perfiles posteriores. 2. Revisa la implementación de referencia alojada por DIF. 3. Prueba una identidad `did:key` en un entorno controlado. 4. Evalúa `did:web` si necesitas una identidad vinculada a un dominio organizativo. 5. Construye una delegación mínima con scopes muy reducidos. 6. Comprueba que una delegación hija no pueda ampliar los permisos del padre. 7. Prueba expiración y revocación. 8. Intenta repetir una petición para validar las defensas anti-replay. 9. No interpretes una identidad válida como reputación o confianza suficiente. 10. Si utilizas MCP, separa la especificación KYA-OS ratificada del binding de extensiones MCP que todavía aparece como draft. RECURSOS DIF Newsletter #63: https://blog.identity.foundation/ama-with-gz-and-newsletter-63/ Implementación y especificaciones KYA-OS: https://github.com/decentralized-identity/kya-os-mcp Registro de esquemas: https://github.com/decentralized-identity/kya-os-schema Notas del KYA-OS Task Force: https://github.com/decentralized-identity/trusted-ai-agents/blob/main/agenda/agenda-kyaos-tf-2026.md Entity Card: https://github.com/decentralized-identity/kya-os-mcp/blob/main/SPEC-ENTITY-CARD.md Binding como extensión MCP: https://github.com/decentralized-identity/kya-os-mcp/blob/main/SPEC-MCP-EXTENSION.md QUÉ VIGILARÁ RADARABIERTO RA debe seguir: - publicación y evolución de KYA-OS 1.x; - diferencias entre núcleo ratificado y nuevos perfiles; - cambios en Entity Card; - ratificación o cambios de las primitivas actualmente en work item; - evolución del binding MCP `org.kya-os/decentralized-authority`; - si el binding llega a una extensión MCP oficialmente adoptada; - interoperabilidad real entre implementaciones independientes; - soporte para A2A y otros mecanismos de descubrimiento; - revocación en despliegues reales; - gestión y rotación de claves; - ataques de replay; - cadenas de delegación excesivamente largas; - comportamiento fail-closed; - casos en los que un agente tenga identidad válida pero autoridad insuficiente; - adopción fuera de sus promotores iniciales; - evaluaciones de seguridad independientes; - relación con otros trabajos de identidad, autorización y procedencia; - capacidad de reconstruir incidentes mediante evidencia verificable. Esta señal debe mantenerse como historia viva. La aprobación de KYA-OS 1.0 no cierra el problema de identidad de agentes: abre una base técnica que deberá demostrar interoperabilidad, seguridad y utilidad real cuando agentes de diferentes organizaciones empiecen a actuar unos en nombre de otros.
Por qué puede importarte
A medida que los agentes pasan de responder preguntas a ejecutar acciones y delegarlas, identificar al agente no basta: también es necesario comprobar quién le otorgó autoridad, qué límites tiene y qué evidencia deja cada operación. KYA-OS intenta convertir esa cadena de responsabilidad en artefactos verificables por máquinas.
Cómo ha evolucionado
Estado actual: actual. Añadiremos los cambios posteriores sin borrar este registro.
Qué todavía no sabemos
DIF Newsletter #63 confirma que KYA-OS 1.0 pasó la aprobación del Steering Committee y el registro de esquemas describe v1 como ratificada. La newsletter solo fecha el anuncio como 'July 2026', sin día exacto; por eso effective_at usa 2026-07-01 como precisión mensual. Entity Card sigue como DIF TAAWG work item y el binding MCP figura como 1.0.0-draft; no deben presentarse como partes ratificadas del núcleo.
Seguir el contexto
La señal conserva procedencia y relaciones internas para que puedas comprobar el origen y explorar cambios relacionados.
Esta ficha verificable es igual para todos. Puedes indicar si te afecta, si no se entiende, si quieres seguirla o si no te interesa. Para que seguir u ocultar cambie solo tu selección, crea Mi Radar.