La Linux Foundation lanza Agent Name Service para la identidad de los agentes de IA

The Linux Foundation anunció el 10 de noviembre de 2026 que Agent Name Service (ANS) se ha lanzado formalmente como proyecto de la fundación, y ofrece identidad vinculada a dominios, descubrimiento y autenticación para agentes de IA mediante una especificación abierta y herramientas de código abierto.

ANS está diseñado para que un sistema pueda determinar con qué agente registrado está interactuando antes de aplicar su propia política de seguridad. Vincula un nombre versionado a un dominio controlado por el operador del agente, utiliza el Domain Name System (DNS) para publicar información de descubrimiento y registra eventos firmados del ciclo de vida en un registro de transparencia. El enfoque reutiliza la infraestructura de Internet existente, en lugar de exigir un único registro de agentes propietario.

El lanzamiento convierte el anuncio de intención del 23 de junio de 2026 de la fundación en un proyecto sujeto a gobernanza. La fundación afirma que, desde entonces, 11 organizaciones han contribuido a ANS o lo han adoptado: Cisco, Cloudflare, DigiCert, DistributedApps.ai, GoDaddy, HOL, Infoblox, Radix, Salesforce, OWASP y Trustmodel.ai.

Cómo funcionan el registro y la autenticación de ANS

La especificación de siete capas abarca la identidad, el registro, la asignación de nombres versionados, la publicación en DNS, la transparencia, la supervisión de la integridad y la autenticación de agentes. Un nombre ANS vincula una versión a un dominio, como en ans://v1.0.0.payments.example.com; una versión nueva requiere un registro nuevo.

Durante el registro, el operador envía el host del agente, la versión, los puntos de conexión y el material de los certificados a una autoridad de registro, que verifica el control del dominio y las pruebas requeridas. El operador publica los registros DNS recibidos y la autoridad los comprueba antes de la activación. Luego, firma el evento del ciclo de vida y hace que el Registro de Transparencia lo selle, lo que genera artefactos públicos que vinculan el registro con certificados autorizados.

Los pares utilizan un perfil de descubrimiento compatible para localizar los puntos de conexión y el registro compartido _ans-badge para encontrar pruebas de transparencia. El descubrimiento, por sí solo, no autentica a quien realiza la llamada. La autenticación requiere tres comprobaciones: que el certificado esté vinculado a la identidad registrada, que el registro siga siendo válido y que quien realiza la llamada posea la clave privada correspondiente.

El borrador de autenticación ANS-6 otorga el mismo nivel de importancia a TLS mutuo (mTLS) y a la prueba de posesión demostrable (DPoP) en la capa de aplicación. mTLS es adecuado para una conexión TLS de extremo a extremo, mientras que DPoP vincula una prueba de un solo uso a una solicitud HTTP y puede funcionar a través de puertas de enlace que terminan la conexión TLS. Un verificador de nivel de insignia consulta el Registro de Transparencia para obtener pruebas actuales; el nivel SCITT verifica un recibo y un token de estado localmente, sin llamadas de red por solicitud. DPoP requiere la vinculación SCITT.

Software e interoperabilidad inicial

El software disponible incluye una implementación de referencia en Go de la autoridad de registro, el Registro de Transparencia y un verificador sin conexión, además de SDK para Go, Rust y Java con distintas API y cobertura de funcionalidades. La ans-cli herramienta admite el registro, el descubrimiento, la gestión de certificados y las consultas al Registro de Transparencia en macOS, Linux y Windows. La guía de inicio rápido local utiliza claves de desarrollo y un noop verificador de DNS, por lo que una comprobación satisfactoria del recibo no evalúa el DNS público, la emisión de certificados de producción ni una implementación activa.

En cuanto a la interoperabilidad, la Linux Foundation informa que Agent Directory Service de AGNTCY admite la verificación de identidades ANS y que ANS Finder implementa Agentic Resource Discovery (ARD) y supera sus pruebas de conformidad del registro. La propia especificación de ARD aborda el descubrimiento previo a la invocación, no la ejecución, y permite múltiples servicios de descubrimiento con distintas políticas de confianza, clasificación y acceso, en lugar de imponer un catálogo central. Este trabajo conecta las pruebas de identidad verificables con el descubrimiento sin crear un directorio universal de agentes.

Especificaciones preliminares y límites de seguridad

El comité técnico directivo inicial tiene cinco miembros con derecho a voto: Scott Courtney, Keith Perry y Connor Snitker, de GoDaddy; Ken Huang, de DistributedApps.AI; y Michael Kantor, de Hashgraph Online. El comité define la orientación técnica, mientras que los responsables del mantenimiento de los repositorios revisan los cambios, gestionan las versiones y atienden los informes de seguridad. Aunque el comunicado del lanzamiento describe la especificación como formalizada, la documentación del proyecto señala que las especificaciones publicadas son borradores en desarrollo activo; ANS-6 está marcado como DRAFT v1.0, versión 0.2.0, con fecha del 3 de noviembre de 2026.

El modelo de seguridad establece la identidad, no los permisos. La autorización, la delegación a lo largo de una cadena de llamadas y la puntuación de confianza quedan fuera del alcance de ANS-6, por lo que cada aplicación debe decidir qué puede hacer un agente autenticado. Los resúmenes criptográficos sellados de los metadatos no dan fe del código que se ejecuta en una máquina remota ni garantizan el comportamiento del agente; además, los clientes siguen necesitando claves de registro de confianza, una verificación correcta de firmas y pruebas, comprobaciones de vigencia y una política ante fallos. Las insignias públicas, los recibos y los tokens de estado también pueden reproducirse si el verificador omite la comprobación de posesión.

Un recibo demuestra el historial del registro, no la validez actual, y puede seguir verificándose después de que se revoque un agente; por eso, debe acompañarse de una comprobación del estado actual. El grado de madurez de las integraciones también varía. El trabajo de NVIDIA OpenShell está catalogado como una vista previa de investigación, y sus comprobaciones del registro de destinos no implementan la vinculación de ANS-6 con el certificado TLS real del par.

ANS ya cuenta con gobernanza de la fundación, borradores publicados e implementaciones de referencia. Su valor práctico en materia de seguridad depende de que las implementaciones hagan cumplir conjuntamente la identidad, el estado actual y la posesión de la clave, y mantengan la autorización y las evaluaciones del comportamiento de los agentes fuera de la afirmación de identidad.