Agent Name Service de la Linux Foundation: identidad de agentes de IA anclada en DNS y cuándo adoptarla

El Agent Name Service (ANS) de la Linux Foundation es un estándar abierto que otorga a los agentes de IA nombres versionados y anclados en DNS, certificados de identidad emitidos tras la validación del dominio y registros públicos en un log de transparencia. ¿Por qué debería importarle a un responsable de TI? Los agentes de IA ya llaman a otros agentes, solicitan datos y desencadenan transacciones que cruzan los límites entre organizaciones. Nadie puede decir todavía si ANS se convertirá en el esquema dominante.

¿Qué es el Agent Name Service y por qué está en la Linux Foundation?

El 10 de noviembre de 2026, la Linux Foundation acogió el Agent Name Service como estándar abierto para la identidad, la verificación y el descubrimiento confiables de agentes de IA mediante la infraestructura DNS existente. La especificación completa abarca siete documentos que cubren la nomenclatura anclada en dominios, el registro y el versionado, la publicación en DNS, la auditoría de logs públicos, la supervisión de la integridad y la autenticación entre agentes. Ahora la desarrolla de forma abierta el comité directivo técnico del proyecto.

Desde que se anunció la intención de lanzarlo en junio de 2026, 11 organizaciones han contribuido al estándar o lo han adoptado, entre ellas Cisco, Cloudflare, DigiCert, GoDaddy, Infoblox, Salesforce y OWASP.

ANS nació en GoDaddy. El equipo decidió construir el descubrimiento de agentes sobre DNS, que según GoDaddy gestiona más de cien millones de solicitudes por segundo, y establecer la confianza mediante la misma PKI que protege cada conexión HTTPS. La implementación reutiliza la infraestructura DNS de GoDaddy y un servicio de certificados que gestiona más de 100 millones de certificados SSL y TLS activos.

Para los compradores empresariales, lo que cuenta es el cambio de gobernanza. Una especificación pública bajo una fundación neutral ofrece una base más sólida para redactar políticas. El CEO de la Linux Foundation, Jim Zemlin, lo dijo sin rodeos: los agentes de IA autónomos realizan transacciones en sistemas de todo el mundo, pero no pueden tener éxito sin una identidad verificable.

Por qué la identidad de los agentes de IA se ha convertido en un problema de gobernanza de TI

La presión ya se nota dentro de las organizaciones. Una encuesta de la Cloud Security Alliance a 418 profesionales de TI y seguridad, encargada por Token Security y publicada en abril de 2026, reveló que el 82% de las organizaciones había descubierto agentes de IA ejecutándose en su infraestructura sin que nadie lo supiera. La misma encuesta halló que el 65% había sufrido un incidente de seguridad relacionado con agentes en los 12 meses anteriores. Entre las organizaciones que tuvieron un incidente así, el 61% informó de exposición de datos y el 35% de pérdidas económicas. Esas dos cifras son porcentajes del 65% que sufrió un incidente, no del total de encuestados.

Conviene leer la encuesta con dos salvedades. La encargó un proveedor, y mide más la visibilidad interna que la identidad externa. Aun así, demuestra que la proliferación de agentes es un problema operativo actual, no hipotético.

La vertiente externa se entiende mejor con el escenario del borrador ANS v2 del IETF. El agente de pagos de una empresa recibe la instrucción de transferir $50,000 al agente de facturación de un proveedor, y el agente de facturación presenta una URL de sitio web protegida por un certificado TLS. Ese certificado le dice al agente de pagos que alguien controla el dominio. Para un sistema que está a punto de enviar dinero por su cuenta, el control del dominio es una prueba muy débil.

Cómo funciona ANS: nombres versionados, certificados validados y logs de transparencia

ANS toma mecanismos que cualquiera que gestione infraestructura web ya conoce y les añade niveles de verificación.

Nombres ans:// versionados

Cada agente recibe un nombre versionado al estilo DNS, como ans://v1.0.0.my-agent.example.com. Se lee de derecha a izquierda. El dominio (example.com) vincula el agente a una organización, la etiqueta (my-agent) identifica al agente y el prefijo (v1.0.0) fija una versión semántica. Una URL normal no tiene nada parecido a esta última parte. Con ANS, un cambio en el agente puede reflejarse como un cambio en su nombre.

El borrador ANS v2 limita el ANSName completo a 400 octetos, lo que deja margen para transportarlo con seguridad en cabeceras HTTP, campos TLS y columnas de bases de datos. Sus sistemas actuales pueden almacenar y transmitir estos nombres sin un tratamiento especial.

Certificados de identidad tras la validación DNS/ACME

Un certificado de identidad ANS solo se emite tras la validación del dominio mediante DNS/ACME. Desde el punto de vista operativo, nada de esto es nuevo. El inconveniente, al que volveremos en las salvedades, es que la identidad de un agente nunca puede ser más sólida que el control del dominio en el que se apoya.

Log de transparencia público

Cada registro genera además una entrada pública en un log de transparencia, de modo que cualquier parte puede verificar de forma independiente la identidad, las capacidades y el historial de un agente sin confiar en un intermediario.

Niveles de verificación Bronze, Silver y Gold

El borrador ANS v2 define tres niveles de verificación, Bronze (PKI), Silver (PKI más DANE) y Gold (PKI más DANE más log de transparencia), para que los clientes puedan elegir el nivel de garantía adecuado al riesgo de cada transacción. DANE vincula la información del certificado a los registros DNS y depende de DNSSEC. Tenga presente esa dependencia; volverá a aparecer más adelante.

La columna de la derecha es nuestra recomendación y no forma parte de la especificación. Defina sus propios umbrales.

Cómo se relaciona ANS con DNS-AID y AGNTCY Directory

ANS no es el único proyecto de agentes basado en DNS de la Linux Foundation. DNS-AID, un proyecto independiente para el descubrimiento descentralizado de agentes, se lanzó con Cloudflare, CSC, Equinix, GoDaddy, IDC, Indeed, Infoblox, Internet Systems Consortium y WWT como miembros iniciales.

Los dos proyectos responden a preguntas distintas. El borrador de DNS-AID establece que los consumidores deben tratar los registros DNS-AID como un transporte verificable de metadatos, no como una señal de confianza en sí mismos, y que los juicios de confianza deben hacerse fuera de banda combinando esos registros con sistemas de reputación, atestación o políticas organizativas. ANS es un candidato para esa capa de identidad. Funciona junto a DNS-AID; no lo sustituye.

El proyecto AGNTCY Directory muestra por qué ANS está despertando interés. Una épica abierta en ese proyecto se ocupa de verificar las afirmaciones de identidad ans://, y señala que todos los demás esquemas exigen que el publicador aloje material criptográfico como un archivo JWKS, un registro TXT o un documento DID, y casi nadie lo hace, así que no se verifica nada. Un registro ANS ya genera un certificado de identidad, un puntero DNS y una entrada en el log de transparencia. Dicho de otro modo, la evidencia existe por defecto en lugar de depender de que los publicadores hagan un trabajo adicional.

El panorama sigue saturado. En junio de 2026, The New Stack contabilizó al menos cuatro iniciativas basadas en DNS, entre ellas DNS-AID de Infoblox, y ahora Infoblox también respalda ANS. Una propuesta competidora, DNSid, es un Internet-Draft individual de un solo autor sin adopción por ningún grupo de trabajo, y su versión actual caduca el 31 de diciembre de 2026.

Cuándo registrar sus propios agentes: la escalera Anchor-Version-Tier de Optijara

El nombre describe la secuencia. Ancle (Anchor) cada agente a un dominio que vaya a conservar, versiónelo (Version) al ritmo de sus lanzamientos y asigne a cada caso de uso un nivel de verificación (Tier). Cada peldaño depende del anterior, así que el orden importa. Se trata de un marco de planificación, no de un informe de resultados de clientes.

1. Inventariar y clasificar. Enumere todos los agentes que ejecuta y etiquételos como solo internos, orientados a socios, públicos o transaccionales. Dado cuántas organizaciones encuentran agentes que desconocían, espere sorpresas en este paso.
2. Empezar por los agentes externos y de alto riesgo. Registre primero los agentes a los que llaman los agentes de otras organizaciones, junto con todo lo que afecte a pagos, intercambio de datos o acciones contractuales. Los agentes solo internos pueden esperar, ya que sus controles actuales de identidad y acceso ya los cubren.
3. Anchor: elegir el dominio a conciencia. Use un dominio de marca que vaya a mantener durante años, no un dominio de campaña. Trate la caducidad de un dominio de marca como un evento de seguridad, porque la autoridad de registro revoca los registros cuando falla la validación del dominio.
4. Version: vincular los nombres a los lanzamientos. Asocie la versión semántica de cada nombre ans:// a su proceso de lanzamientos. Cualquier cambio sustancial en prompts, herramientas, modelos o permisos debería generar una nueva versión y una nueva entrada en el log.
5. Probar fuera de producción. Ejecute primero el registro y la verificación en un entorno de pruebas, y lea la salvedad sobre madurez que aparece más abajo antes de que cualquier decisión de confianza en producción dependa de ANS.
6. Tier: fijar niveles de garantía y responsables. Decida el nivel objetivo para cada caso de uso y designe responsables de la renovación de certificados, los registros DNS y la supervisión del log de transparencia. Haga a esas mismas personas responsables de los secretos que guarda cada agente. Saber quién es un agente no limita en absoluto aquello a lo que puede acceder, y patrones como un proxy de credenciales que mantiene las claves de API fuera de los agentes de IA se encargan de esa capa independiente.

Uso de identidades ANS en compras y en listas de permitidos en tiempo de ejecución

En compras

ANS ofrece a los equipos de compras un vocabulario concreto para la identidad de los agentes. Preguntas que vale la pena plantear a los proveedores:

• ¿Tienen sus agentes nombres ans:// y qué dominio los ancla?
• ¿Qué nivel de verificación pueden ofrecer hoy: Bronze, Silver o Gold?
• ¿Está la zona de anclaje firmada con DNSSEC, de modo que las comprobaciones DANE tengan sentido?
• ¿Cómo se corresponden las versiones de los agentes con sus lanzamientos de producto y registros de cambios?
• ¿Quién en su organización es responsable de la renovación del dominio y del acceso al registrador?

Los contratos deberían exigir aviso previo antes de cambios de versión de agentes que alteren sus capacidades, y antes de cualquier cambio de dominio de anclaje o de registrador. Esos son los eventos que cambian lo que usted realmente aprobó.

Una matriz de decisión para proveedores

Para clasificar las respuestas de los proveedores, usamos una matriz sencilla basada en tres señales. Al igual que la correspondencia de niveles, es nuestra visión y no forma parte de la especificación.

Un proveedor situado en la primera columna en las tres señales es candidato para flujos de pagos o de datos regulados. Cualquier respuesta en la columna de la derecha debería mantener a los agentes de ese proveedor en interacciones de bajo riesgo y nivel Bronze hasta que cambie. Las respuestas mixtas suelen apuntar a un piloto con criterios de salida claros.

En tiempo de ejecución

En tiempo de ejecución, el peldaño Tier se convierte en una regla de aplicación. Incluya los agentes en listas de permitidos por su ANSName versionado completo más comprobaciones de certificado, nunca solo por URL o dominio. Si ignora la versión, un agente modificado sustancialmente hereda la aprobación que usted dio a una versión anterior. Exija Gold, incluida la comprobación del log de transparencia, para acciones de alto riesgo como los pagos, y acepte Bronze solo para búsquedas de bajo riesgo. Eso sigue la propia intención del borrador de que los clientes ajusten la garantía al riesgo de la transacción.

La verificación Gold no detendrá a un agente correctamente identificado que empiece a comportarse mal. Combine sus requisitos Gold con una forma probada de detener rápidamente un agente, y revise qué detiene un interruptor de apagado de IA y qué sigue necesitando su runbook de agentes.

Combine las comprobaciones ANS con sus propios controles de políticas y reputación. El principio fuera de banda del borrador de DNS-AID también se aplica aquí: la evidencia de identidad alimenta una decisión, no es la decisión. Supervise los logs de transparencia en busca de registros inesperados bajo sus propios dominios, y vigile los registros en dominios que se parezcan a los suyos, ya que quien posea un dominio similar puede registrar en él un agente totalmente verificado.

Si lo que le preocupa son los asistentes de IA que acceden a sus propias propiedades web, y no las llamadas entre agentes, necesita otro conjunto de controles; consulte nuestra guía para permitir, limitar o bloquear asistentes de IA en su sitio.

Salvedades y críticas que conviene sopesar antes de comprometerse

Confianza heredada del DNS

El análisis de la Cloud Security Alliance identifica DNSSEC como la dependencia en la que ANS más se apoya para que los vínculos entre nombres y claves sean a prueba de manipulaciones. Dos décadas después de su introducción, DNSSEC se valida en aproximadamente un tercio de las rutas de resolución, pero solo alrededor del siete por ciento de las zonas está firmado criptográficamente. Por tanto, la garantía Silver y Gold depende de si la contraparte ha hecho un trabajo de DNSSEC que muchas organizaciones nunca priorizaron. Revise sus propias zonas antes de prometer a sus socios un nivel que no puede ofrecer.

Madurez

Según la revisión de la Cloud Security Alliance de junio de 2026, el proyecto estaba en fase anterior a la 1.0 y su implementación de referencia usaba criptografía simulada con fines de demostración en lugar de una PKI apta para producción. La criptografía simulada sirve para aprender. No sirve para mover dinero. La gobernanza de la fundación puede acelerar su consolidación, pero compruebe el estado actual directamente en la organización de GitHub del proyecto en lugar de darlo por supuesto.

Incentivos de los registradores

Un comentario en CircleID plantea el debate sin rodeos: cada agente necesita un nombre, y a la industria de los dominios le gustaría venderlo. Es una perspectiva justa. Los registradores y las autoridades de certificación se benefician cuando cada agente necesita un dominio y un certificado. Nada de eso hace que el diseño sea erróneo. Sí significa que debe evaluar los costes de registro, las condiciones de renovación y la portabilidad por sus propios méritos, sin suponer que un único registrador es la única vía.

Dominios similares e impostores verificados

La verificación vincula un agente a un dominio. No puede decirle que el dominio pertenece a quien usted cree. ANS no resuelve el typosquatting, y un agente totalmente verificado en un dominio similar sigue siendo un impostor. La supervisión de la marca y las comprobaciones al incorporar contrapartes siguen siendo responsabilidad suya.

La visión equilibrada

Los aspectos positivos son reales. La especificación es pública y abarca siete documentos. Once organizaciones de los sectores de redes, seguridad, certificados y SaaS han contribuido a ella o la han adoptado. En nuestra opinión, ese respaldo, sumado a una gobernanza neutral, da a ANS un punto de partida más sólido que el de las propuestas de un solo proveedor o un solo autor. Como varios esquemas basados en DNS siguen compitiendo, coloque las comprobaciones de identidad de agentes detrás de una capa de abstracción interna cuando resulte barato, para que un cambio en el esquema ganador no le obligue a reescribir cada integración. Lo recomendable es una adopción por etapas, no evitarlo.