El problema del registro de agentes que nadie menciona

Seguro conoces robots.txt. Desde 1994, guía a los rastreadores web sobre qué zonas evitar. Has oído de llms.txt para dar contexto a los modelos de IA, o .well-known/security.txt para reportar fallos de seguridad. Pero falta algo clave: un estándar para que un sitio web le diga a un agente de IA: "Sí, puedes registrar una cuenta para mi usuario, pero con estas reglas".

Este vacío es más grave de lo que parece. Para 2026, los agentes de IA no solo leen páginas. Actúan como usuarios delegados. Rellenan formularios, abren cuentas, prueban APIs y se inscriben en pruebas... todo por un humano real. Desde el servidor, parece spam puro. Por eso hay confusión en sitios web y creadores de agentes.

Por qué los estándares actuales fallan

La web tiene archivos de políticas dispersos. Ninguno cubre el registro de cuentas.

• robots.txt controla el rastreo para buscadores.
• llms.txt da pautas para modelos de IA.
• Los sitemaps listan URLs para indexar.
• OpenAPI y MCP definen interfaces llamables.
• security.txt indica contactos para vulnerabilidades.

Crear una cuenta no es navegar. Implica:

• Cambios permanentes en tu plataforma.
• Riesgo de límites de tasa o detección de abuso.
• Impacto en métricas de registro.
• Vínculo a tus términos de servicio.
• Posibles comportamientos inesperados.

Un simple sí/no no basta. Hay demasiado en juego, y casos muy distintos.

Presentamos: El manifiesto de políticas para agentes

Una propuesta experimental, /.well-known/agent-policy.json desde wkdomains.com, lo resuelve con un archivo legible por máquinas. Es un sistema de permisos detallado y escalonado para agentes de IA.

Lo innovador no es un permiso binario. Son niveles de permiso.

El manifiesto responde:

• ¿Qué pueden hacer agentes en zonas públicas? (Leer páginas, seguir enlaces, ver precios).
• ¿Qué pide acceso API explícito? (Entornos de prueba, flujos para agentes).
• ¿Cuáles son las condiciones para registros delegados? (Intención humana verificada, identidad clara, logs auditables).
• ¿Cuándo parar en seco? (Pagos, identidades falsas, términos con riesgos).

Cómo funcionan los niveles de permiso

Supón que gestionas un SaaS. Tu agent-policy.json podría indicar:

Modo exploración pública: Activado por defecto. Agentes leen docs, precios y funciones.

Modo automatizado declarado: Solo vía API oficial o sandbox.

Modo registro delegado: Condicional. Permite cuentas de prueba si:

• Se verifica la intención del humano (no automatizada).
• El agente muestra su identidad real (sin fingir ser humano).
• El email es traceable, como usuario+agente-{dominio}@ejemplo.com.
• Hay un log visible para el usuario.
• El agente frena antes de pagos o términos graves.

Aquí va lo esencial. Diferencia:

• Casillas rutinarias (aceptar política de privacidad): OK con transparencia.
• Términos con riesgos (indemnizaciones legales, pagos): Exigen confirmación humana.

La estructura de la propuesta

Un agent-policy.json real arranca con metadatos (versión, dominio, fecha de caducidad). Luego, secciones clave. La de account_creation es el núcleo.

Allí defines:

• Modo por defecto (si no hay política).
• Modos disponibles y condiciones.
• Cómo registrar aceptación de términos.
• Qué activa paradas obligatorias.

Esos "hard stops" incluyen:

• Captchas o pruebas antibots.
• Términos que vetan cuentas automáticas.
• Necesidad de identidades falsas.
• Pagos o verificaciones telefónicas.
• Publicaciones públicas.
• Aceptación de riesgos legales.
• Impactos desconocidos.

El agente debe pausar y pedir al humano que intervenga.

Reglas de procesamiento para agentes

La propuesta da instrucciones claras:

Sin archivo? Solo exploración pública. Lee y resume, nada de registros.

Permiso explícito? Avanza solo en el modo indicado. Registra la URL del manifiesto y el humano detrás.

Casilla rutinaria? Procede si la política lo permite, con log.

Términos graves? Para ya. Nada de que un agente acepte pagos o riesgos por un usuario.

Por qué importa a los desarrolladores

Si creas agentes de IA, esto te da una guía fija. Olvídate de lógica personalizada por sitio:

• Busca el manifiesto primero.
• Interpreta niveles de forma estándar.
• Usa fallbacks seguros.
• Genera logs transparentes.

Si manejas una plataforma, ganas control preciso:

• Fomenta registros asistidos sin riesgos.
• Políticas por tipo de usuario.
• Cumplimiento regulatorio con logs.
• Límites claros para agentes.

Para usuarios, hay transparencia total. Ves qué permite el agente en tu nombre y controlas los logs.

Fase experimental: ¿Qué sigue?

Es un borrador de wkdomains.com, abierto a debate entre dueños de dominios, constructores de bots, expertos en estándares y creadores de agentes. Puede evolucionar o cambiar.

Caduca el 1 de noviembre de 2026, para iterar rápido sin estancar.

El panorama general

Estamos en un punto de quiebre. Los agentes de IA son usuarios delegados, no solo rastreadores. La web no tiene permisos al día. robots.txt funciona porque los incentivos son claros: buscadores quieren indexar, editores visibilidad.

Pero ¿agentes registrándose? Es más complejo. Plataformas buscan seguridad. Usuarios, claridad. Agentes, límites nítidos. Un estándar como agent-policy.json no lo resuelve todo, pero crea un idioma común.

Si tu plataforma permite registros con agentes, publica una política. Si builds agentes, búscala. Si te apasionan los estándares, opina ya.

La opción contraria: adivinar. Con agentes más listos y automatización avanzada, adivinar no alcanza.