La lista de permitidos por user agent es uno de los patrones más antiguos de la web. Mantienes una lista de nombres de rastreadores y clientes en los que confías. Cuando llega una solicitud con un encabezado User-Agent coincidente, la dejas pasar, omites un desafío o le sirves una página más ligera. Se configura en minutos y todo el equipo la entiende.
El patrón tenía más sentido cuando los principales visitantes automatizados eran unos pocos rastreadores de búsqueda y algunas herramientas de monitoreo. Hoy, los agentes de IA, los asistentes y los clientes automatizados llegan a las aplicaciones en números crecientes, y muchos de ellos anuncian un nombre. Algunos de esos nombres son reales. Algunos están copiados. El encabezado no puede decirte cuál.
Proof of Actor adopta un enfoque distinto. Trata una cadena de User-Agent como lo que es, una declaración, y la informa junto con evidencia más sólida cuando esa evidencia existe. Esta página explica los límites de autorizar por nombre, en qué ayudan las comprobaciones a nivel de red y cómo las firmas verificadas y una clase Unknown explícita cambian el panorama.
La versión corta
| Lista de permitidos por user agent | Proof of Actor | |
|---|---|---|
| Evidencia principal | Un nombre en el encabezado User-Agent | Firmas, declaraciones y señales, cada una etiquetada con su base |
| ¿Puede un cliente falsearlo? | Sí, enviando la misma cadena | Se puede afirmar una base declarada; una base verificada requiere la clave de firma |
| Resultado | En la lista o no | Human, Human + AI, Agent o Unknown, además de una base |
| Tráfico poco claro | Se trata como no autorizado o se permite por defecto | Unknown, con una alternativa que eliges por ruta |
| Personas asistidas por IA | Invisible; usan navegadores normales | Una clase distinta, Human + AI, cuando se declara u observa |
| Mantenimiento | Actualizaciones manuales de la lista cuando cambian los nombres | Claves publicadas por operadores de agentes; políticas en tu código |
| Valor predeterminado al instalar | Lo que permita la lista | Observación; nada cambia hasta que añades una política |
| Mejor para | Enrutamiento barato de clientes conocidos y que se comportan bien | Contexto del actor basado en evidencia para decisiones de producto y política |
El resto de la página explica cada fila.
Por qué autorizar por User-Agent se puede falsear
El encabezado User-Agent lo establece el cliente. Lo establece un navegador, lo establece un script y lo establece un framework de agentes. Nada en HTTP comprueba que el valor sea verdadero. Si tu lista de permitidos confía en una cadena, cualquiera que copie esa cadena recibe el mismo tratamiento.
Esto se llama user agent spoofing y es común por una razón sencilla: no cuesta nada. Un scraper que quiere evitar un desafío solo necesita pedir prestado el nombre de un rastreador en el que confías. Un cliente que se comporta mal puede afirmar ser un asistente popular. Incluso una herramienta legítima puede enviar una cadena genérica de navegador porque un valor predeterminado de la biblioteca lo hizo.
El resultado es que una lista de permitidos por user agent tiene dos modos de fallo:
- Falsa confianza: un cliente no confiable afirma un nombre confiable y pasa.
- Falsa duda: un cliente legítimo envía una cadena inesperada o genérica y falla.
Ninguno de los dos fallos es visible solo desde el encabezado. Esa es la limitación central, y ninguna cantidad de mantenimiento de la lista la elimina.
Para qué sigue siendo útil el encabezado
Nada de esto significa que debas ignorar las cadenas User-Agent. Los rastreadores y agentes que se comportan bien se identifican con honestidad, y el nombre es una pista útil para enrutar, analizar y depurar. Te dice lo que un cliente dice ser.
El lugar adecuado para esa información es como una declaración, ponderada junto con otras evidencias, no como una clave que desbloquea el acceso por sí sola. Proof of Actor la registra exactamente así.
Reverse DNS y listas de IP: medidas parciales
Muchos equipos refuerzan una lista de permitidos con comprobaciones de red. Ayudan, y vale la pena entenderlas con precisión.
Verificación de reverse DNS
Algunos operadores de rastreadores documentan un proceso de verificación: buscar el hostname de la dirección IP de la solicitud, comprobar que pertenece al dominio del operador y luego buscar ese hostname y confirmar que resuelve de nuevo a la misma IP. Cuando este ciclo completo se cumple, tienes evidencia real de que la solicitud vino de la infraestructura del operador.
Los límites son prácticos. Solo funciona para operadores que lo documentan y lo admiten. Añade búsquedas DNS que debes almacenar en caché. Y te dice algo sobre la red, no sobre qué producto o agente hizo la solicitud en esa red.
Rangos de IP publicados
Otros operadores publican los rangos de IP que usan sus clientes automatizados. Comparar una solicitud con esos rangos es rápido y proporciona una evidencia similar a la del reverse DNS. Hay una discusión activa en el IETF sobre un formato estándar para publicar estos rangos, pero a noviembre de 2026 no existe un estándar cerrado, y la cobertura depende de que cada operador decida publicar.
La evidencia de IP también se debilita a medida que más agentes se ejecutan en infraestructura compartida en la nube, detrás de proxies o desde el propio dispositivo de un usuario. Una dirección en la nube puede alojar muchos clientes no relacionados, y un agente que actúa desde el navegador de una persona parece ser la red de esa persona.
Qué aportan en conjunto las comprobaciones de red
El reverse DNS y las listas de IP convierten algunas declaraciones en algo más sólido para un subconjunto de operadores conocidos. No cubren la cola larga de agentes y herramientas, y no ayudan en absoluto con personas que trabajan junto con IA. Son medidas parciales: útiles, pero no suficientes por sí solas.
Firmas frente a declaraciones
La forma más sólida de evidencia es una firma criptográfica. Con HTTP Message Signatures, definido en RFC 9421, un cliente firma partes seleccionadas de cada solicitud con una clave privada. El verificador recupera la clave pública publicada del operador y comprueba la firma. Si se verifica, la solicitud fue firmada por quien posee esa clave, y las partes firmadas no se alteraron en el camino.
El grupo de trabajo del IETF Web Bot Auth está estandarizando cómo los clientes automatizados usan estas firmas y cómo publican sus claves. Nuestra explicación sobre Web Bot Auth para equipos de producto cubre el estado actual.
Proof of Actor usa una firma válida como evidencia Verified. Una cadena User-Agent, un client hint o una autodescripción en el cuerpo de una solicitud cuentan como Declared. Las señales conductuales y contextuales cuentan como Inferred y se etiquetan así. Cada resultado indica en qué base se apoya, para que tu equipo nunca confunda una afirmación con una comprobación. Consulta la entrada de base de evidencia para ver las definiciones completas.
Incluso para la evidencia verificada se aplica un límite. Una firma válida demuestra qué clave firmó la solicitud. No demuestra que el agente esté autorizado para hacer lo que solicita. Esa es una cuestión de autorización de agente, y sigue estando en tu aplicación.
Gestionar Unknown en lugar de adivinar
Una lista de permitidos obliga a cada solicitud a entrar en una de dos categorías: en la lista o fuera de ella. En la práctica eso significa que el tráfico poco claro recibe lo que sea tu valor predeterminado, y ese valor normalmente se elige una sola vez para todo el sitio.
Proof of Actor trata Unknown como un resultado de primera clase. Cuando la evidencia no respalda una determinación fiable, lo dice en lugar de adivinar. Tus políticas deciden entonces qué significa Unknown en cada ruta:
- En documentación pública o páginas de marketing, permitirlo.
- En endpoints de búsqueda o listado, permitirlo con tus límites de tasa normales.
- En cambios de cuenta, mantener tus comprobaciones existentes.
- En acciones de alto impacto, enviarlo a revisión o pedir una señal más sólida.
La guía sobre gestionar tráfico Unknown y la entrada de clasificación Unknown recorren estos patrones. Hacer seguimiento de tu tasa de Unknown a lo largo del tiempo también te dice qué parte de tu tráfico sigue apoyándose en evidencia débil.
¿Y las personas asistidas por IA?
Una lista de permitidos por user agent no tiene nada que decir sobre una persona que usa un asistente de IA dentro de un navegador normal. Su User-Agent es una cadena normal de navegador. Sin embargo, muchos productos quieren reconocer esa interacción, por ejemplo para etiquetar envíos redactados con IA o entender cómo los usuarios asistidos por IA avanzan en la incorporación.
Proof of Actor informa estas interacciones como Human + AI cuando la asistencia se declara o se observa mediante una integración admitida. No adivina solo por el estilo de escritura. Lee más en interacción asistida por IA.
Pasar de una lista de permitidos a políticas basadas en evidencia
No necesitas eliminar tu lista de permitidos el primer día. Un camino seguro se ve así:
- Instálalo en modo observación. Proof of Actor no cambia nada. Tu lista de permitidos sigue funcionando.
- Compara. Para cada ruta, mira qué solicitudes permitidas llevan evidencia verificada, cuáles solo llevan una declaración y cuáles terminan como Unknown.
- Previsualiza políticas. Redacta una política que trate de forma distinta a los agentes verificados, a los agentes declarados y a Unknown, y previsualiza su efecto sobre el tráfico real.
- Aplica ruta por ruta. Empieza por las rutas en las que un nombre falseado tendría más impacto.
- Mantén la lista de permitidos como una pista. Los nombres siguen siendo útiles para enrutar y analizar, ahora con su base visible.
La guía sobre desplegar políticas conscientes del actor de forma segura cubre cada paso, y solicitudes automatizadas verificadas explica cómo encajan los clientes firmados.
Cuándo una lista de permitidos es suficiente
Para el enrutamiento de bajo riesgo, como servir una página más ligera a un rastreador conocido en contenido público, una lista de permitidos por user agent suele ser suficiente. El coste de un nombre falseado es pequeño.
Cuando la decisión tiene consecuencias, como omitir un desafío, exponer datos más ricos o permitir una escritura, quieres una evidencia que puedas comprobar. Ahí es donde encaja Proof of Actor, trabajando junto con las comprobaciones de red y los controles en el edge que ya utilizas.
Empezar
Proof of Actor está en beta privada. Los equipos seleccionados del Founding Developer Program pueden recibir hasta 12 months de acceso gratuito dentro de límites de uso acordados, sin facturación automática. Solicita acceso anticipado y cuéntanos qué clientes autorizas hoy y qué rutas quieres proteger con mejor evidencia.