Durante años, la única forma en que un cliente automatizado podía decirle a un sitio web quién era consistía en un nombre dentro del encabezado User-Agent y, para unos pocos operadores grandes, una lista publicada de direcciones IP o una comprobación de DNS inverso. Los nombres son fáciles de copiar. Las listas de red solo cubren a los operadores que las mantienen. A medida que los agentes de IA empiezan a actuar en nombre de personas reales en la web, esa brecha se ha convertido en un problema de producto, no solo de seguridad.
Web Bot Auth es el esfuerzo líder para cerrarla. Ofrece a los clientes automatizados una forma de firmar sus solicitudes con una clave que controlan y publican, de modo que un sitio pueda comprobar la firma en lugar de confiar en un nombre. Esta explicación está pensada para responsables de producto y líderes de ingeniería que necesitan entender qué es, qué cambia y qué no, sin leer las especificaciones de principio a fin.
La versión corta
- Qué es: un grupo de trabajo de IETF, webbotauth, y el enfoque que está estandarizando para autenticar clientes HTTP automatizados.
- Cómo funciona: el cliente firma partes de cada solicitud usando HTTP Message Signatures (RFC 9421) y apunta a un directorio de sus claves públicas. El sitio obtiene la clave y verifica la firma.
- Qué demuestra: qué clave firmó la solicitud y que las partes firmadas no cambiaron en tránsito.
- Qué no demuestra: que el agente esté autorizado para hacer lo que pide, que actúe en nombre de un usuario concreto o que vaya a comportarse bien.
- Estado a noviembre de 2026: RFC 9421 es un Proposed Standard publicado. El documento del protocolo Web Bot Auth es un Internet-Draft del grupo de trabajo, todavía no un RFC.
- Qué hacer: planifica tratar las firmas válidas como evidencia sólida, sigue gestionando el tráfico sin firmar y mantén las decisiones de autorización en tu propio código.
Qué es el trabajo de IETF Web Bot Auth
IETF creó el grupo de trabajo Web Bot Auth para estandarizar métodos de autenticación criptográfica de clientes automatizados y para dar a los sitios web más información sobre los operadores que hay detrás de ellos. El alcance del charter se centra en sitios que sirven principalmente a personas, y enumera un conjunto amplio de clientes: rastreadores, archivadores web, comprobadores de enlaces, rastreadores de entrenamiento de IA y agentes de IA que actúan para usuarios finales.
Hay dos exclusiones del charter que conviene destacar para los equipos de producto. La autenticación del usuario final está fuera de alcance, así que esto no sirve para iniciar sesión de una persona. El seguimiento de la reputación de bots también está fuera de alcance, así que el estándar te dice quién firmó una solicitud, no si ese operador es confiable.
El charter enumera tres tipos de entregables:
- Documentos de Standards track sobre técnicas para autenticar clientes automatizados hacia sitios web creados para personas.
- Documentos de Standards track sobre cómo transmitir más información acerca de un bot solicitante usando un identificador existente como un nombre de dominio o URL.
- Documentos de Best Current Practice o informativos sobre temas operativos como gestión de claves, ciclo de vida y despliegue.
En qué punto están los documentos, a noviembre de 2026
A noviembre de 2026, el grupo de trabajo tiene un documento adoptado del grupo: draft-ietf-webbotauth-httpsig-protocol, titulado "HTTP Message Signatures for automated traffic", en revisión 01 y con fecha 29 de octubre de 2026. Es un Internet-Draft, lo que significa que es un trabajo en curso que todavía puede cambiar. No es un RFC.
También hay varios borradores individuales asociados al grupo y en discusión, incluidas propuestas sobre un registro y un formato de tarjeta de agente, autenticación anónima de bots, un formato JSON para publicar los rangos de IP de clientes automatizados y un encabezado para metadatos de agente firmados. Los borradores individuales son propuestas; ninguno ha sido adoptado por el grupo a esta fecha.
El charter fijó hitos durante 2026 para enviar especificaciones al IESG para su aprobación. A noviembre de 2026, el documento del protocolo sigue siendo un borrador del grupo de trabajo. Puedes seguir el estado actual en la página de IETF datatracker del grupo de trabajo y en el borrador del protocolo.
Cómo funcionan HTTP Message Signatures
Web Bot Auth se apoya en RFC 9421, HTTP Message Signatures, publicado en febrero de 2024 como Proposed Standard. RFC 9421 es un mecanismo general: define cómo firmar partes seleccionadas de un mensaje HTTP y cómo transportar la firma en los encabezados. Web Bot Auth lo adapta para clientes automatizados.
En términos simples, una solicitud de agente firmada funciona así:
- El operador crea un par de claves. Mantiene la clave privada en secreto y publica la clave pública.
- El cliente elige qué firmar. Selecciona componentes de la solicitud, como el host de destino o la URI y una hora de creación. El borrador actual exige cubrir la autoridad o la URI de destino, de modo que una firma para un sitio no pueda reutilizarse sin más en otro.
- El cliente firma y envía. La solicitud lleva un encabezado
Signature-Inputque describe qué se firmó y con qué clave, y un encabezadoSignaturecon el valor de la firma. El borrador usa una etiquetaweb-bot-authy espera tiempos de creación y expiración en cada firma. - El sitio verifica. Encuentra la clave pública, reconstruye los componentes firmados a partir de la solicitud recibida y comprueba la firma. Si la verificación pasa, la solicitud fue firmada por el titular de esa clave y las partes cubiertas no se alteraron.
El borrador también permite que un sitio pida una firma. Un origen puede enviar un encabezado Accept-Signature, normalmente con una negativa, para señalar que desea solicitudes firmadas.
La idea del directorio de claves
Una firma solo sirve si el sitio puede encontrar la clave pública correcta. Web Bot Auth responde a eso con un directorio de claves.
En el borrador actual del grupo de trabajo, el cliente añade un encabezado Signature-Agent que contiene una URL HTTPS. Esa URL sirve un directorio de las claves públicas del operador como un JSON Web Key Set. El sitio obtiene el directorio, selecciona la clave que coincide con el identificador de clave de la firma y verifica. El borrador también define una ruta bien conocida, /.well-known/http-message-signatures-directory, donde un operador puede servir su directorio.
La idea útil para los equipos de producto es que la URL se convierte en la identidad. Un operador de agente queda identificado por dónde publica sus claves, lo que vincula la firma con un dominio que el operador controla. La rotación de claves funciona publicando una clave nueva junto con la antigua y después retirando la antigua.
Los sitios que verifican necesitan gestionar los directorios con cuidado: almacenarlos en caché siguiendo las reglas normales de HTTP, establecer límites de tamaño y timeouts, y evitar obtenerlos desde direcciones de red privadas. Estas son preocupaciones de ingeniería estándar, y también una de las razones por las que muchos equipos prefieren un componente que haga la verificación por ellos.
Qué demuestra una firma válida y qué no demuestra
Esta es la sección más importante para cualquiera que escriba políticas de producto.
Una firma válida demuestra:
- Que la solicitud fue firmada por el titular de una clave privada específica.
- Que esa clave está publicada en una URL de directorio que controla el operador.
- Que las partes firmadas de la solicitud no cambiaron en tránsito y que la firma está dentro de su ventana de validez.
Una firma válida no demuestra:
- Que el agente esté autorizado para realizar la acción. Ser identificable no es lo mismo que tener permiso. Consulta autorización de agentes.
- Que el agente actúe para una persona concreta o dentro de la autoridad que esa persona le dio. Consulta autoridad delegada.
- Que el operador sea confiable o que el agente vaya a comportarse bien. La reputación está explícitamente fuera de alcance para el grupo de trabajo.
- Nada sobre las solicitudes que no están firmadas. El tráfico sin firmar sigue necesitando su propio tratamiento.
Trata una firma válida como evidencia sólida de quién envió una solicitud, y luego deja que tu propio control de acceso decida qué puede hacer ese remitente.
Qué deberían hacer los equipos de producto al respecto
No necesitas esperar a un RFC para planificar. El tráfico de agentes firmado es algo para lo que puedes prepararte ahora, con la expectativa de que algunos detalles del borrador pueden cambiar.
1. Mide antes de decidir
Descubre cuánto de tu tráfico es automatizado, qué rutas usan los agentes y cuánto de eso está firmado. Empieza en modo de observación para que la medición no cambie nada para tus usuarios.
2. Separa la evidencia de la política
Registra lo que dice la evidencia, verified, declared, inferred o unknown, por separado de lo que decidas hacer. Eso mantiene las políticas legibles y te permite endurecerlas o relajarlas sin volver a instrumentar. La entrada de base de evidencia explica los cuatro niveles.
3. Da a los agentes verified una mejor vía
Cuando tenga sentido, sirve a los agentes verified contenido estructurado o un flujo adaptado a agentes en lugar de páginas creadas para personas. La guía sobre servir a agentes de IA contenido estructurado cubre los patrones.
4. Mantén la autorización en tu código
Usa la firma para saber quién está pidiendo algo. Usa tus permisos, ámbitos y confirmaciones existentes para decidir qué puede hacer. Las acciones de alto impacto pueden seguir requiriendo confirmación humana, haya firmado quien haya firmado la solicitud. Consulta proteger acciones sensibles sin bloquear agentes.
5. Planifica para tráfico sin firmar y Unknown
El soporte para firmas varía entre agentes y herramientas, así que espera una mezcla de solicitudes firmadas y sin firmar durante un tiempo. Decide por ruta qué ocurre con el tráfico declared, inferred y Unknown, en lugar de elegir una única regla para todo el sitio. La guía sobre gestionar tráfico Unknown lo explica paso a paso.
Cómo usa Proof of Actor Web Bot Auth
Proof of Actor le dice a tu aplicación quién o qué actúa en cada interacción, Human, Human + AI, Agent o Unknown, y señala la base de evidencia. Las firmas de Web Bot Auth son una de sus fuentes de evidencia más sólidas.
Cuando un agente firma su solicitud con HTTP Message Signatures, Proof of Actor comprueba la firma frente a la clave publicada del operador. Si la comprobación pasa, el resultado lleva una base verified, junto con la evidencia que tu equipo puede revisar. Si un cliente solo se identifica en un encabezado, el resultado es declared. Si la conclusión se basa en señales de comportamiento o de contexto, se etiqueta como inferred. Si la evidencia no es suficiente, el resultado es Unknown.
Tu aplicación decide qué hacer con ese contexto. Las políticas se escriben por ruta, por clase de actor y por base, con resultados como allow, adapt, challenge, review y rate-limit. Nada se aplica por defecto: previsualizas una política frente al tráfico real y la aplicas ruta por ruta, en tu propio código.
Los equipos fundadores pueden recopilar evidencia a través de middleware de Node.js, Next.js, una integración de edge, un colector de navegador en páginas aprobadas, la API HTTP genérica o una integración de servidor MCP. Consulta integraciones y la guía sobre verificar solicitudes de agente firmadas para los pasos prácticos.
Proof of Actor sigue el mismo límite que el estándar: una firma verificada te dice qué clave firmó la solicitud, no si el agente está autorizado. La autorización sigue siendo tu responsabilidad. La página evidencia y límites detalla exactamente qué puede y qué no puede respaldar cada resultado.
Empezar
Proof of Actor está en beta privada. Los equipos fundadores seleccionados pueden recibir hasta 12 meses de acceso gratuito dentro de límites de uso acordados, sin facturación automática. Solicita acceso anticipado y cuéntanos qué rutas esperas que usen los agentes firmados y qué quieres hacer con ellos.