Saltar al contenido principal
AUTOMATIZACIÓN VERIFICADA

Reconoce solicitudes automatizadas verificadas

Cuando un cliente automatizado firma sus solicitudes, tu aplicación puede comprobar esa firma y tratar al remitente en consecuencia. Proof of Actor convierte esa comprobación en un resultado claro y enrutable.

Obtener acceso anticipadoExplorar cómo funciona
Toshendra Sharma

Por Toshendra SharmaFundador y CEO, AgentCredia · Updated November 13, 2026

No todo el tráfico automatizado es igual

Los clientes automatizados llegan a tu aplicación cada minuto: rastreadores de búsqueda, herramientas de monitoreo, integraciones de socios, asistentes de IA que recuperan páginas para un usuario y agentes autónomos que completan tareas. Durante años, la única forma en que la mayoría de las aplicaciones podía distinguirlos era el encabezado user-agent, una cadena que cualquier cliente puede poner con cualquier valor.

Eso deja a los equipos de aplicación en una situación complicada. Trata toda automatización con sospecha y degradarás la experiencia de los agentes legítimos de los que dependen tus clientes. Confía en el encabezado y le das a cualquiera la oportunidad de decir que es un rastreador conocido.

Las solicitudes automatizadas verificadas cambian la ecuación. Cuando un cliente automatizado firma sus solicitudes con una clave que ha publicado, tu aplicación puede comprobar la firma y saber, criptográficamente, qué cliente firmó la solicitud. Proof of Actor convierte esa comprobación en un resultado único y coherente sobre el actor sobre el que tu código puede enrutar. Para ver más de cerca qué establece y qué no establece esa comprobación, lee qué demuestran las solicitudes de agentes de IA firmadas.

Cómo funciona la firma de solicitudes

El enfoque emergente para el tráfico automatizado usa HTTP message signatures, estandarizadas en RFC 9421, que define cómo crear, codificar y verificar firmas sobre componentes de un mensaje HTTP. El cliente firma partes seleccionadas de cada solicitud con una clave privada e incluye la firma y sus parámetros en los encabezados. Publica la clave pública correspondiente en una ubicación vinculada a un identificador que controla, normalmente su dominio.

Cuando llega la solicitud, el receptor obtiene o consulta la clave publicada, reconstruye el contenido firmado y comprueba la firma. Si se valida, la solicitud fue firmada por el titular de esa clave. El trabajo sobre la firma del tráfico automatizado continúa en el grupo de trabajo IETF Web Bot Auth working group, cuyo mandato abarca la autenticación criptográfica de clientes automatizados como rastreadores y agentes de IA que actúan para usuarios finales; la entrada del glosario Web Bot Auth lo resume. La entrada del blog sobre qué demuestran las solicitudes de agentes de IA firmadas recorre una solicitud verificada de extremo a extremo, y el caso de uso de APIs use case muestra dónde compensa primero la verificación.

La guía sobre verificación de solicitudes de agentes firmadas cubre la mecánica en detalle, incluidas las marcas de tiempo, las ventanas de repetición y la caché de claves.

Qué demuestra una firma verificada, y qué no

Esta distinción es la parte más importante para manejar bien las solicitudes automatizadas verificadas.

Una firma válida demuestra que la solicitud fue firmada con una clave asociada al identificador publicado. Si la clave pertenece al dominio de un operador, la solicitud vino de un cliente que tiene la clave de ese operador.

Una firma válida no demuestra:

  • quién instruyó al agente, o si alguna persona pidió esta acción;
  • que una persona haya delegado autoridad al agente;
  • la identidad legal del mundo real detrás del operador;
  • que la acción solicitada sea segura o esté permitida en tu aplicación.

Esas son preguntas distintas. Tu aplicación las responde con sus propias credenciales, su modelo de autorización y su política. Proof of Actor las mantiene separadas de forma deliberada, y la página sobre Detection & Limitations explica con precisión qué puede establecer cada tipo de evidencia.

Cómo Proof of Actor maneja las solicitudes automatizadas verificadas

Detect

Tu integración pasa el contexto de la solicitud, incluidos los encabezados de firma, a Proof of Actor. Las firmas se comprueban frente a las claves publicadas. Las solicitudes que se validan se registran con una base verified. Los clientes que solo se declaran a sí mismos se registran como declared. Los patrones de comportamiento se registran como inferred. Cuando no hay suficiente información, el resultado es Unknown. Nada se promueve a verified salvo que haya pasado una comprobación criptográfica.

Understand

Ve qué operadores verificados llaman a tu aplicación, qué rutas usan, con qué frecuencia y cómo se compara eso con la automatización declarada y Unknown. El resumen de evidencia en cada resultado te dice qué clave e identificador estuvieron involucrados, para que tu equipo pueda investigar cualquier solicitud con rapidez.

Route

Usa la base en tus políticas. Los patrones comunes incluyen:

  • Dar a los agentes verificados una respuesta estructurada en rutas de solo lectura, como una API o una versión Markdown de una página.
  • Aumentar los límites de tasa para operadores verificados que reconoces mientras mantienes límites estándar para clientes declarados.
  • Mantener tu autorización existente en cada ruta de escritura, diga lo que diga la firma.
  • Definir un recurso alternativo explícito para llamantes sin firma y Unknown en cada ruta.

Tus políticas deciden; Proof of Actor aporta la evidencia.

Por qué el encabezado user-agent no basta

Las cadenas user-agent son declaraciones. Cualquier cliente puede enviar cualquier valor, y el user-agent spoofing no requiere habilidad. Por eso los operadores de rastreadores publican sus propias comprobaciones: Google documenta búsquedas DNS inversas y directas y rangos de IP publicados para verifying Googlebot, Bing documenta una comprobación DNS para verifying Bingbot, y OpenAI publica archivos de rangos de IP para cada uno de sus crawlers and user agents. Proof of Actor trata una afirmación de user-agent como evidencia declarada, nunca como verificación. Eso significa que un cliente que dice ser un rastreador conocido sin una firma válida se reporta con base declared o inferred, y tu política puede tratarlo de forma distinta a un cliente que demostró su identidad.

Esto es lo que hace valiosas las solicitudes automatizadas verificadas: te dan una forma fiable de extender confianza a los clientes que la ganan, sin extenderla a todos los que copian su encabezado.

Evidencia de identidad, credenciales y autorización

Tres capas trabajan juntas en cualquier aplicación que atiende a clientes automatizados:

  1. Evidencia de identidad: ¿qué cliente firmó esta solicitud? Una firma verificada responde a esto.
  2. Credenciales: ¿qué cuenta es responsable? Tu API key, token o sesión responde a esto.
  3. Autorización: ¿puede este remitente hacer esto? Tu modelo de permisos responde a esto.

Proof of Actor refuerza la primera capa y la hace visible. No emite credenciales de identidad ni de delegación, y no reemplaza tu autorización. Mantener las capas separadas es lo que te permite ser generoso con los agentes verificados en rutas de bajo riesgo y cuidadoso en las de alto impacto.

Dónde encaja

Proof of Actor se sitúa junto a tu gateway, autenticación y limitación de tasa. Las integraciones se ejecutan como middleware del lado del servidor, en el edge, en tu MCP server o mediante una integración HTTP genérica, entregada de forma práctica con cada equipo fundador. Si tu tráfico son sobre todo APIs y herramientas, los casos de uso de APIs y MCP Servers muestran los patrones que más importan.

Empieza en modo de observación

Toda integración empieza en modo de observación. Los resultados se registran sin cambiar cómo responde tu aplicación, para que puedas ver qué parte de tu tráfico automatizado está verificada, qué operadores están firmando y dónde la tasa de Unknown es más alta. Las políticas llegan después, ruta por ruta, cuando la evidencia las respalda. How It Works recorre el flujo completo.

Detalles prácticos que hacen que la verificación sea fiable

La comprobación de firmas es tan buena como lo sean los detalles que la rodean. Algunas prácticas hacen que las solicitudes automatizadas verificadas sean fiables en producción.

Comprueba la frescura

RFC 9421 define los parámetros de firma created y expires, y las solicitudes firmadas suelen llevarlos. Rechaza las firmas fuera de una ventana corta, para que una solicitud capturada no pueda repetirse más tarde.

Cachea las claves con criterio

Obtener las claves publicadas de un operador en cada solicitud añade latencia. Guárdalas en caché durante un período razonable y actualízalas cuando una firma falle con un identificador de clave desconocido, para que la rotación de claves no provoque fallos falsos.

Firma las partes correctas de la solicitud

Una firma que cubre solo una marca de tiempo demuestra muy poco. Comprueba que los componentes firmados incluyan el método, la ruta y el host, para que la firma quede vinculada a la solicitud que tu aplicación recibió realmente.

Registra la evidencia

Conserva el identificador de clave, el identificador publicado y el resultado con cada solicitud verificada. Cuando ocurra algo inusual, tu equipo puede ver exactamente qué cliente firmó qué y cuándo.

Proof of Actor maneja estas comprobaciones como parte del paso Detect y reporta el resultado como una base que tus políticas pueden leer, para que el código de tu aplicación siga siendo sencillo.

Únete al programa para desarrolladores fundadores

Proof of Actor está en beta privada. Los equipos de desarrollo fundadores seleccionados pueden recibir hasta 12 meses de acceso gratuito, dentro de los límites de uso acordados, con soporte directo de integración por parte de nuestros ingenieros.

Si los clientes automatizados llegan a tu aplicación y quieres tratar de forma distinta a los verificados, solicita acceso anticipado. Cuéntanos sobre tu aplicación y sobre los llamantes automatizados que ves, y te mostraremos cómo encaja Proof of Actor.

Fuentes

PARA DESARROLLADORES

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent o Unknown.
basis
Qué tan sólida es la evidencia: Verified, Declared, Inferred o Unknown.
evidence
Las señales detrás del resultado, para que tu equipo vea por qué.

Empieza en modo de observación: registra los resultados junto a tus logs y no cambies nada hasta que elijas una política. Lee la guía de integración de Node.js

Preguntas frecuentes

¿Qué es una solicitud automatizada verificada?

Es una solicitud de un cliente automatizado cuya firma criptográfica se valida frente a una clave publicada para un identificador conocido, como el dominio del operador. Muestra qué cliente firmó la solicitud.

¿Una firma verificada significa que el agente está autorizado?

No. Una firma asocia una solicitud con una clave y su identificador publicado. Si ese cliente puede realizar una acción es una decisión de autorización separada que toma tu aplicación.

¿Qué pasa con los clientes automatizados que no firman sus solicitudes?

Proof of Actor aun así los clasifica, usando evidencia declared e inferred cuando está disponible, y reporta Unknown cuando la evidencia no es lo bastante sólida. Cada resultado indica su base.

¿Puede una cadena user-agent verificar un cliente?

No. Las cadenas user-agent son fáciles de imitar, así que cuentan como una declaración, no como una verificación. Las firmas criptográficas son lo que hace verificable una solicitud.

¿Cómo empiezo?

Solicita acceso anticipado. Los equipos fundadores empiezan en modo de observación y los equipos seleccionados pueden recibir hasta 12 meses gratis dentro de los límites de uso acordados.

Sabe quién usa tu app.

Beta privada para un pequeño grupo de desarrolladores fundadores.

Obtener acceso anticipadoVer precios

¿Prefieres hablar primero? Habla con los fundadores