Auditoría del Agent Name Service: 351.912 entradas del log

El Agent Name Service promete una respuesta verificable a "¿quién es este agente?". Descargamos las 351.912 entradas de su transparency log en producción y contrastamos la respuesta con la spec. La criptografía se sostiene. Lo que se registra es otra historia.

ANS es la propuesta más completa hasta ahora para anclar la identidad de agentes a la infraestructura existente de internet. Usa nombres DNS, validación ACME y certificados X.509, más un log append-only que cualquiera puede auditar. También es la única de estas propuestas con un despliegue grande en producción: GoDaddy opera una Registration Authority y un Transparency Log público, y publica SDKs open source en Go, Rust y Java.

Este post hace tres cosas. Lee la spec: el draft de la IETF y las siete especificaciones por capas del repositorio de referencia. Verifica el log en vivo sin nada más que una root key y SHA-256. Y hace un censo de todos los eventos que el log ha sellado. La brecha entre lo que el protocolo puede probar y lo que el despliegue realmente registra es la parte útil.

Qué es ANS, en un párrafo

El texto vigente es draft-narajala-courtney-ansv2-01, fechado el 13 de abril de 2026. Es una Independent Submission con estatus Informational, que expira el 15 de octubre de 2026. Sus autores vienen de GoDaddy, OWASP, DistributedApps.ai y Cisco. Reemplaza al draft-narajala-ans-00 de mayo de 2025, que ya expiró. La idea central: la identidad de cada agente se ancla a un nombre de dominio. Una Registration Authority (RA) verifica vía ACME que controlas el dominio. Después emite dos certificados y sella el evento en un Transparency Log (TL). El draft resume la división así: "DNS-AID le dice a un cliente dónde conectarse, ANS le dice si confiar en el agente".

El identificador es el ANSName, ans://v{major.minor.patch}.{fqdn}. Por ejemplo, ans://v1.0.0.sentiment-analyzer.example.com. La versión es parte del nombre a propósito. Cada cambio de código o de capacidades exige una nueva versión y un nuevo registro. Esto apunta a un modo de falla que el draft nombra explícitamente: un proveedor pasa una auditoría y después "actualiza silenciosamente su modelo. El certificado sigue válido, el endpoint sigue arriba, pero el código detrás ya no es el que se auditó".

Dos certificados, tres niveles

El modelo de doble certificado es la decisión de diseño más interesante. El Server Certificate es un certificado ordinario de CA pública para el FQDN estable, y sobrevive a los cambios de versión. El Identity Certificate lo emite una CA privada y lleva el ANSName versionado en un URI SAN. Hace falta una CA privada porque los Baseline Requirements del CA/Browser Forum prohíben URI SANs en certificados de servidor de confianza pública. Así que ninguna CA pública puede emitir un certificado ans://.

La verificación viene en tres niveles, y describen lo que el cliente comprobó, no una calificación que asigna la RA:

• Bronze: validación PKI estándar del server certificate.
• Silver: Bronze más DANE, un registro TLSA 3 0 1 en _443._tcp.{fqdn} cuyo SHA-256 coincide con el server certificate. DANE requiere DNSSEC. Según RFC 6698, un RRset TLSA inseguro es inutilizable.
• Gold: Silver más una comprobación en el Transparency Log de que el registro fue sellado y de que el fingerprint del certificado coincide con el sellado.

El draft es franco sobre lo que la RA no hace. Responde "¿Quién eres?" y nada más. La madurez operativa (SOC 2, SBOMs) y la reputación de comportamiento se delegan a capas separadas. Una especificación complementaria, el Trust Index, puntúa a los agentes en cinco dimensiones: integrity, identity, solvency, behavior y safety. Solvency es donde entran los pagos. La spec del Trust Index define pruebas zero-knowledge de solvencia sobre saldos como USDC, ancladas a un chainId y un maxBlockAge. Cuando un agente tiene un registro ERC-8004 con su propia agent wallet (setAgentWallet), la prueba debe verificar esa wallet, no al dueño del token.

El repositorio ya dejó atrás al draft

El repositorio de referencia divide ahora el protocolo en siete specs, de ANS-0 a ANS-6. La mayoría se reescribió contra la implementación de referencia en julio de 2026, y ANS-6 se agregó en septiembre. Tres cambios importan a quien construye un runtime de agentes:

DNS-AID es el discovery profile por defecto desde el 23 de julio. Los registros emiten ahora un registro SVCB (RFC 9460) por endpoint, con los parámetros de DNS-AID en claves de uso privado (key65400 para la URL de capacidades, key65401 para su SHA-256). El registro TXT _ans del draft pasa a ser opcional.

Un identity profile para ENS llegó el 20 de agosto. Permite a una RA aceptar un nombre .eth, con el control probado por una firma EIP-712 o ERC-1271 de la cuenta dueña resuelta on-chain. El profile señala el riesgo obvio: los nombres ENS se transfieren y expiran, así que el monitoreo pesa más que para cualquier otro tipo de identidad.

ANS-6, autenticación agent-to-agent, se integró el 14 de septiembre. Es la capa por request, y está bien diseñada. Exige tres pruebas independientes: identity (el certificado está sellado en el log), liveness (el registro es válido ahora) y possession (el peer tiene la clave privada para este request). Como dice la spec, verificar un receipt sin comprobar liveness "autentica a un cadáver".

ANS-6 define dos maneras de que un caller pruebe posesión. El Method A es mTLS con el Identity Certificate. El Method B es una prueba DPoP (RFC 9449) en un header HTTP. El Method B existe porque mTLS no sobrevive a proxies L7 que terminan TLS, que es el caso de la mayoría de los gateways en producción. El profile es estricto: el header JOSE debe ser exactamente typ, alg (solo ES256), jwk y un x5c de una sola entrada. Un claim obligatorio ans_content_digest amarra el body del request. Cualquier parámetro extra en el header invalida la prueba.

El "SCITT tier" recomendado no necesita llamadas de red por request. Cada agente adjunta su propio receipt COSE y un status token de vida corta como headers HTTP (X-SCITT-Receipt, X-ANS-Status-Token). El verificador comprueba ambos localmente contra una root key que descargó una sola vez. La revocación es acotada, no instantánea. Con la configuración por defecto, el peor caso es una hora de TTL del token, más 10 minutos de desfase de reloj, más hasta un TTL de gracia: 2 horas y 10 minutos.

Verificar el log en vivo desde cero

El log de producción está en transparency.ans.godaddy.com. Todos los endpoints de lectura son sin autenticación, como exige ANS-4. Descargamos la root key, luego el checkpoint C2SP, y verificamos la firma nosotros mismos:

# GET /root-keys  ->  name+keyhash+base64(0x02 || SPKI)
name, kid, mat = rootkeys.split('+', 2)
spki = b64decode(mat)[1:]
assert sha256(spki).hexdigest()[:8] == kid     # c9e2f584

# GET /checkpoint  ->  origin \n size \n root \n\n signature lines
body = cp.split('\n\n')[0] + '\n'
sig  = b64decode(line.split()[-1])             # 4-byte key hash + DER sig
pub.verify(sig[4:], body.encode(), ECDSA(SHA256()))   # OK

El checkpoint que verificamos se firmó a las 09:02:17 UTC del 23 de septiembre de 2026, para un árbol de 351.912 entradas. Después tomamos el badge de un agente (leaf 234) y recorrimos su inclusion path RFC 9162 de 19 hashes. Recalculó exactamente la raíz firmada. También decodificamos el status token. Es un COSE_Sign1 (CBOR tag 18) con firma ES256, kid c9e2f584 y una vida de exactamente una hora. Verificó con la misma clave. El receipt también es COSE_Sign1 y declara el algoritmo de árbol RFC 9162 SHA-256.

En resumen: con una root key de 91 bytes y una función hash, puedes comprobar que un registro dado está en el log y que el log es el que firmó el operador. Es una propiedad real, y más rara de lo que debería en el espacio de identidad de agentes.

El censo: 351.912 eventos

Descargamos los 1.375 tiles de entradas y parseamos cada evento. Todos usan el schema V1. El primero está fechado el 18 de enero de 2026.

Mezcla de eventos. 220.057 AGENT_REGISTERED, 131.780 AGENT_RENEWED, 75 AGENT_REVOKED. Casi todas las renovaciones (131.768) ocurrieron en septiembre, sobre todo en tres días: 15, 17 y 18 de septiembre. Los registros cubren 219.987 hostnames distintos.

Concentración. 210.834 registros (95,8%) son subdominios de un solo dominio, helpagent.club. Otros 8.687 (3,9%) están bajo agenthost.club. Juntos son el 99,8% del log. Los 536 registros restantes se reparten entre otros 56 dominios padre. El patrón de helpagent.club es uniforme: un host support-{uuid}.helpagent.club con un display name que termina en "Customer Support Agent". El primero aparece el 16 de marzo de 2026. RDAP muestra ambos dominios registrados a través de GoDaddy, en nameservers de GoDaddy, con delegationSigned: false. El registrante está redactado.

El versionado no se usa. 351.711 de 351.912 eventos (99,94%) son de v1.0.0. El ciclo de vida atado a versiones, la función que debería detectar el "modelo actualizado silenciosamente", casi no tiene datos con qué trabajar. No significa que nadie actualice sus agentes. Significa que las actualizaciones no se registran.

La identidad es DV de punta a punta. Cada uno de los 351.912 eventos registra un server certificate X509-DV-SERVER. Ningún evento lleva un campo lei, providerId ni dnssecStatus, aunque los tres aparecen en el payload de ejemplo del draft. La identidad a nivel de organización, que el draft describe como la forma de "cerrar la brecha entre la propiedad del dominio y la identidad organizacional", no existe en los datos de producción.

Un tercio no tiene Identity Certificate. 74.563 registros (33,9%), todos bajo helpagent.club entre junio y agosto, solo llevan server certificate. Sin Identity Certificate un agente no puede autenticarse como caller con ninguno de los dos métodos de ANS-6. Los 74.563 tienen server certificates que expiran en septiembre de 2026, y ninguno se ha renovado. Los que consultamos muestran badge status WARNING, que ANS-6 define como "el certificado expira pronto". No es una marca de abuso.

DANE casi no existe. Solo 395 registros (0,18%) aprovisionaron un registro TLSA _443._tcp. Silver requiere DNSSEC, y las dos zonas padre que contienen el 99,8% de los registros no están firmadas. Así que casi todos los agentes del log quedan limitados a Bronze más la comprobación del log, sin importar cuánto esté dispuesto a verificar el cliente.

La revocación nunca ha tocado a la plataforma grande. De las 75 revocaciones, 49 son de webmesh.ai y ninguna de helpagent.club. La primera que inspeccionamos lleva el reason code SUPERSEDED.

Como verificación cruzada, en julio ZeroFox reportó unos 174.000 agentes ANS, 163.500 de ellos en helpagent.club. Contando desde el log, obtenemos 175.531 registros sellados hasta el 20 de julio, 166.447 en ese dominio. Las cifras coinciden.

Lo que vale un display name sellado

ZeroFox también señaló un agente cuyo display name suplanta a Zelle. Está en el log en la entrada 90.043, sellado el 27 de mayo de 2026, con el display name Zelle: [email protected] Customer Support Agent. Se renovó el 18 de septiembre, y su badge devolvió ACTIVE cuando lo consultamos el 23 de septiembre.

No es el único que nombra una marca de pagos. Entre los registros hay display names como support-mail-coinbase.com Customer Support Agent, do-not-replysessbinance.com Customer Support Agent, amazonrefundsupport.com Customer Support Agent y Venmo Customer Service Customer Support Agent. No podemos juzgar la intención detrás de ninguno en particular. Lo que sí podemos decir es estructural: en ANS, el display name es texto que aporta el registrante. El protocolo lo sella, lo que prueba que fue declarado. No lo valida contra nada.

Es el propio escenario motivador del draft, al revés. Un agente de pagos que pregunta "¿este agente de facturación pertenece al proveedor?" recibe una respuesta criptográficamente sólida: el agente controla support-{uuid}.helpagent.club. Es verdad, es verificable y no sirve para la pregunta que se hizo. La identidad anclada a dominio es tan fuerte como el vínculo entre el dominio y la organización. Con certificados DV y sin LEI, ese vínculo no existe en los datos.

Lo que el protocolo hace bien

Nada de esto es un argumento contra el diseño. Varias partes van por delante de todo lo demás en el espacio:

El modelo de tres pruebas de ANS-6 es la forma correcta de autenticar peers máquina. La mayoría de los esquemas de identidad de agentes que hemos revisado comprueban identidad y olvidan liveness, o comprueban un token y olvidan posesión.

El método DPoP acepta que los despliegues reales terminan TLS en un CDN o gateway, y aun así amarra cada request a método, URL y body.

El transparency log es real, público y verificable offline. Cualquier tercero puede repetir este censo, y así es exactamente como se hicieron visibles las brechas anteriores. Un registry sin log no nos habría dejado ver nada de esto.

Y la separación entre identidad y reputación es honesta. La RA no afirma que un agente registrado sea seguro. El problema es que un badge que dice "verificado" se leerá como "confiable" por los usuarios y, cada vez más, por los agentes.

Faltan dos protecciones en producción. El draft nombra el anclaje de checkpoints HCS-27 como "la mitigación principal" contra un operador de RA y TL comprometido o en colusión. ANS-4 dice que la implementación de referencia "todavía no incluye el adaptador de publicación HCS". Y los registros IANA del esquema URI ans y de las etiquetas _ans siguen siendo trabajo futuro.

Qué significa para LLM4Agents

Estamos a ambos lados de una llamada agent-to-agent. Los agentes llaman a nuestro gateway compatible con OpenAI y pagan por request en stablecoins vía x402. Y nuestros endpoints son, a su vez, algo que los agentes compradores necesitan identificar antes de firmar una autorización EIP-3009. ANS toca ambos lados.

Del lado entrante, un registro ANS no nos dice nada sobre si extender crédito o relajar límites. Nuestro modelo de confianza ya es payment-first: un agente que presenta una autorización EIP-3009 válida por el monto exacto es bueno para ese request, sea quien sea. Ese diseño es el correcto a la luz de este censo. Un tercio de los registros no puede probar posesión como caller. El resto prueba control de un subdominio DV, casi todo en una sola plataforma. Lo que ANS-6 sí aporta es una forma limpia y barata de asociar una identidad estable y revocable a un caller a través de distintas wallets. Eso sirve para rate limiting, atribución de abuso y analítica por agente, no para autorización. Es la misma conclusión a la que llegamos con Web Bot Auth y con los registries de ERC-8004: las señales de identidad son inputs de la política, no la política.

Del lado saliente, ANS cubre un hueco que x402 deja abierto. Una respuesta 402 le dice a un agente comprador que pague a una dirección payTo. Lo único que autentica esa dirección es la sesión TLS con el host que respondió. Como señalamos en la auditoría de discovery DNS de x402, nada vincula una dirección de pago con una organización. ANS tampoco vincula wallets. Pero el status token lleva metadataHashes, un hash del agent card firmado por el TL. Si el card lista nuestras direcciones de cobro, un comprador puede comprobar que el payTo de una respuesta 402 coincide con un card que el log ha sellado. Eso convierte "confía en la sesión TLS" en "confía en una declaración sellada y auditable".

El lado de las amenazas son los display names. Los registries de agentes alimentan el discovery. Los resultados de discovery terminan en context windows de LLMs, donde un modelo elige a qué agente llamar o pagar. Un display name sellado como Zelle: ... Customer Support Agent es texto controlado por el registrante que llega a un modelo con un badge de confianza adjunto. Eso es superficie de prompt injection, y pertenece a nuestro threat model junto a las descripciones de tools.

Cómo mantenerse en la frontera

Seis pasos, en orden de valor por unidad de trabajo.

1. Nunca mapear "registrado en ANS" a un nivel de confianza. El registro no debe cambiar spend caps, crédito ni rate limits. Lo escribiremos explícitamente en la política del gateway, porque el instinto de producto por defecto es premiar los badges.

2. Aceptar el Method B de ANS-6 en el edge, solo en modo registro. Nuestro tráfico cruza un edge que termina TLS, así que mTLS (Method A) no es opción y DPoP sí. La verificación necesita la root key del TL descargada una vez, un replay cache para jti y comprobaciones COSE locales del receipt y del status token. No necesita llamadas al TL por request. Registraremos el ANSName verificado junto a la wallet que paga y lo usaremos para atribución antes que para cualquier otra cosa.

3. Registrar nuestros propios endpoints bien y apuntar a Gold. Firmaremos nuestra zona con DNSSEC, publicaremos el registro TLSA y los registros SVCB de DNS-AID, y nos registraremos con un ANSName versionado. Registraremos una nueva versión en cada cambio de model routing o de precios, que es para lo que existe el versionado. Estar entre el 0,18% con DANE cuesta poco y hace nuestro endpoint verificable de punta a punta.

4. Publicar el payTo dentro del agent card sellado. Listaremos nuestras direcciones de cobro por cadena en el card cuyo hash va al log. Después propondremos una comprobación a los SDKs cliente de x402: antes de firmar, comparar el payTo del 402 con el card sellado cuando el beneficiario tenga registro ANS. Es el cambio más pequeño que vincula una dirección de pago con una declaración auditada.

5. Tratar el texto de los registries como input no confiable. Display names, descripciones y nombres de funciones de cualquier registry (ANS, el MCP registry, AGNTCY) deben citarse y sanitizarse antes de llegar a un modelo. Nunca deben concatenarse a instrucciones. La misma regla que aplicamos a las descripciones de tools.

6. Correr nuestro propio monitor sobre el log. El log completo son unas 1.375 descargas de tiles, y cualquiera puede leerlo. Un job semanal que marque registros nuevos con nombres parecidos a "llm4agents" o a las marcas de nuestros clientes cuesta casi nada. Es la versión para agentes del monitoreo de certificate transparency, y el log se construyó para hacerlo posible. Cuando el operador publique un topic HCS-27, agregaremos al mismo job la verificación de checkpoints anclados.

ANS resuelve bien la parte difícil: un registro público y verificable de quién declaró qué, y cuándo. Lo que no puede hacer es que un certificado DV sobre un subdominio compartido signifique más de lo que significa. Para agentes que mueven dinero, la identidad vendrá del historial de pagos y del vínculo organizacional, no del badge. El log hace visible esa brecha, y ahí está su valor hoy.