Las API solían tener un modelo de tráfico simple. Un desarrollador se registraba, obtenía una clave, escribía una integración y esa integración llamaba a tus endpoints según un horario o cuando un usuario hacía clic en algo. La gestión de bots para API creció alrededor de ese modelo: autenticar la clave, limitar el volumen, filtrar el tráfico obviamente abusivo y mantener el servicio disponible para todos los demás.
Ese modelo sigue vigente, y las herramientas creadas para él siguen siendo importantes. Lo que cambió es quién está detrás de las llamadas. La misma API key ahora puede transportar solicitudes de una persona que usa la app de tu cliente, de una persona que pidió a un asistente de IA que haga el trabajo, y de un agente autónomo que ejecuta una tarea de varios pasos durante la noche. Tus controles existentes ven una clave y una tasa de solicitudes. Tu producto, soporte y las decisiones de política a menudo necesitan más información.
Proof of Actor cubre ese vacío. Indica a tu API quién o qué actúa en cada solicitud y declara la evidencia, y luego deja la decisión en tu código. Esta página lo compara con las principales capas de protección de bots para API para que veas dónde encaja cada una.
La versión breve
| protección de bots para API | Proof of Actor | |
|---|---|---|
| Pregunta principal | ¿Esta solicitud está permitida, autenticada y dentro de los límites? | ¿Quién o qué actúa, y cuál es la evidencia? |
| Capas típicas | Gateway de API, reglas de bots del WAF, API keys, límites de tasa | Clasificación del actor dentro de tu API o MCP server |
| Identifica | La cuenta o integración que posee la clave | El actor detrás de cada solicitud: Human, Human + AI, Agent o Unknown |
| Resultado | Permitir, rechazar, limitar; a veces una puntuación de bot | Una clase más una base: verified, declared, inferred o unknown |
| Tráfico incierto | Normalmente se permite si la clave es válida, o se rechaza por una regla | Unknown, con un respaldo que eliges por ruta |
| Quién decide la respuesta | Configuración del gateway y del WAF | El código de tu aplicación |
| Valor por defecto al instalar | Aplicación de políticas | Observación; nada cambia hasta que añades una política |
| Lo mejor para | Disponibilidad, filtrado de abuso, cuotas, trazabilidad | Atender correctamente a cada actor y entender el uso de la API |
Las secciones siguientes explican cada parte.
Lo que la protección de bots para API hace bien
Conviene ser específico sobre la tarea de cada capa, porque Proof of Actor está diseñado para convivir con todas ellas, no para reemplazarlas.
Gateways de API
Un gateway es la puerta de entrada de tu API. Termina conexiones, autentica API keys o tokens, enruta solicitudes al servicio correcto, aplica cuotas y, a menudo, registra el uso para facturación y analítica. Responde "¿se permite la entrada a este llamador, y por qué puerta?" de forma rápida y consistente en cada endpoint.
Reglas de bots del WAF
Un web application firewall con reglas de bots inspecciona el tráfico en busca de patrones de ataque conocidos y automatización abusiva. Puede filtrar intentos de inyección, bloquear tráfico procedente de fuentes con historial de abuso y desafiar o descartar solicitudes que parezcan scraping o ataques de credenciales. Es tu mejor defensa contra el tráfico que no debería llegar nunca a tu código.
API keys y tokens
Las claves y los tokens te dan trazabilidad. Cada solicitud se asigna a una cuenta, así sabes qué integración hizo una llamada, puedes revocar el acceso y puedes atribuir el uso. Los tokens acotados van más lejos y restringen lo que un llamador puede hacer.
Límites de tasa
Los límites de tasa protegen la disponibilidad. Evitan que una integración consuma la capacidad destinada a todos y ralentizan los intentos de fuerza bruta y de enumeración. Los límites por clave y por ruta son un control estándar y eficaz.
Juntas, estas capas responden muy bien a las preguntas de protección y trazabilidad. Consérvalas.
La pregunta para la que no fueron creadas
Ninguna de esas capas está diseñada para decirte qué tipo de actor hay detrás de una solicitud autenticada. Una clave válida indica qué cuenta posee la integración. No dice:
- si esta llamada concreta provino de una persona pulsando un botón en la app de tu cliente,
- si una persona pidió a un asistente de IA que realizara la acción,
- si un agente autónomo hizo la llamada como un paso de una tarea más larga,
- o si nadie puede saberlo.
Esa distinción importa más cada mes. Una API que presta servicio a una integración de CRM, a una herramienta de programación o a una plataforma para desarrolladores recibe cada vez más tráfico de agentes a través de las mismas claves que sirven a apps impulsadas por humanos. Si quieres ofrecer a los agentes una respuesta estructurada, exigir confirmación para escrituras de alto impacto impulsadas por agentes, etiquetar envíos asistidos por IA, o simplemente medir cuánto de tu uso de la API está impulsado por agentes, necesitas contexto del actor.
Qué añade Proof of Actor a una API
Proof of Actor devuelve una de cuatro clases para cada interacción:
- Human: las señales observables indican una interacción dirigida por una persona.
- Human + AI: una persona dirigió la interacción con asistencia de IA que fue declarada o observada mediante una integración compatible.
- Agent: interacción automatizada o de origen agente.
- Unknown: la evidencia no respalda una determinación fiable.
Cada resultado también declara su base de evidencia:
- Verified: por ejemplo, una HTTP Message Signature (RFC 9421) verificada contra una clave publicada.
- Declared: el cliente o tu propia aplicación lo declaró.
- Inferred: señales de comportamiento o contexto, claramente etiquetadas como inferencia.
- Unknown: no hay una base fiable.
Para las API, la base verified es especialmente útil. Los agentes que firman sus solicitudes pueden verificarse frente a sus claves publicadas, que es el enfoque detrás del trabajo de IETF Web Bot Auth. Lee el explicador sobre Web Bot Auth para equipos de producto para contexto, y la guía sobre verificar solicitudes de agentes firmadas para la parte de implementación.
Aquí importa una limitación. Una firma válida demuestra qué clave firmó la solicitud. No demuestra que el agente esté autorizado a realizar la acción. La autorización sigue donde corresponde, en el control de acceso propio de tu API. La entrada sobre autorización de agentes explica la diferencia.
Puntuaciones y claves frente a evidencia del actor
Algunos productos de protección de bots asignan una puntuación a cada solicitud. Una puntuación es eficiente para decidir un bloqueo. Es menos útil para decisiones de producto sobre API, porque no te dice si una solicitud legítima fue impulsada por una persona o por un agente, y no separa los hechos verificados de la inferencia.
Las API keys tienen la limitación opuesta. Son precisas sobre la propiedad y silenciosas sobre el actor. La clave de un cliente puede transportar las cuatro clases en una sola hora.
Proof of Actor mantiene visibles ambas distinciones. Tu API ve la cuenta a partir de la clave, la clase del actor a partir de Proof of Actor y la base que la respalda. Cada capa responde la pregunta para la que es adecuada.
Dónde se ejecuta cada uno
Los gateways y los WAF se ejecutan en el borde de tu red o delante de tus servicios. Esa posición es adecuada para la protección y las cuotas.
Proof of Actor se ejecuta donde vive la lógica de tu API. Los equipos fundadores pueden integrarlo mediante middleware de Node.js, Next.js, una capa de edge que controles, la API HTTP genérica o una integración con MCP server. Consulta integraciones para la lista completa. Como se ejecuta dentro de tu aplicación, puede usar lo que tu API sabe: la ruta, el flujo de trabajo, si un cliente se declaró a sí mismo y si una firma se verificó.
Las decisiones de enrutamiento siguen en tu código
Proof of Actor no bloquea nada por defecto. Empieza en modo de observación, de modo que instalarlo no cambia nada en cómo responde tu API. Ves la mezcla de actores por endpoint, revisas la evidencia de resultados individuales y observas tu tasa de Unknown.
Cuando estés listo, escribes políticas definidas por la aplicación por ruta, por clase de actor y por base. Los resultados típicos son:
- Allow: atender la solicitud con normalidad.
- Adapt: devolver una respuesta estructurada o reducida para un agente verificado.
- Challenge: exigir un paso adicional de confirmación, por ejemplo una aprobación humana en una escritura de alto impacto.
- Review: poner la acción en cola para que la revise una persona.
- Rate-limit: aplicar un límite más estricto a una clase y base concretas en una ruta concreta.
Puedes previsualizar una política frente a tráfico real antes de aplicarla, y luego aplicarla ruta por ruta. La guía sobre desplegar políticas sensibles al actor de forma segura cubre el proceso, y proteger acciones sensibles sin bloquear agentes muestra patrones comunes.
Cómo manejar llamadores Unknown de la API
Toda API recibe tráfico que no puede clasificarse con confianza. Con los controles tradicionales, una clave válida normalmente significa que la solicitud pasa, y una inválida significa que no pasa. No hay nada intermedio.
Proof of Actor te da un resultado explícito Unknown y te permite elegir el respaldo por ruta. Los endpoints de catálogo de solo lectura pueden permanecer abiertos. Los cambios de cuenta pueden conservar tus comprobaciones más estrictas. Las exportaciones masivas pueden ir a revisión. Consulta manejo del tráfico Unknown y tráfico automatizado Unknown para más detalles.
Cómo se combinan
La configuración de API más sólida usa cada capa para su propia tarea:
- En el borde, el WAF filtra tráfico abusivo y mal formado.
- En el gateway, se autentican las claves, se aplican cuotas y se registra el uso.
- Dentro de la API, Proof of Actor clasifica cada solicitud que pasa y declara su base.
- En tus handlers, las políticas usan la clase y la base para elegir la respuesta: manejo normal para una llamada impulsada por una persona, una respuesta estructurada para un agente verificado, un paso de confirmación para una escritura de alto impacto impulsada por un agente, un respaldo para Unknown.
- En analítica, tu equipo ve qué endpoints y flujos de trabajo usa cada clase de actor, junto con los datos de cuenta del gateway.
Nada en esta pila se duplica. El gateway conoce la cuenta, el WAF conoce los patrones de amenaza y Proof of Actor conoce al actor.
Cuándo conviene centrarse en cada uno
Céntrate primero en la protección de bots para API cuando tus principales problemas sean el abuso, la disponibilidad o el uso no medido: ataques de credenciales contra endpoints de autenticación, scraping agresivo o una integración que deja sin capacidad a otras.
Céntrate en Proof of Actor cuando tus preguntas principales sean sobre tus llamadores: cuánto tráfico de tu API está impulsado por agentes, qué agentes llaman a qué endpoints, dónde difieren el uso impulsado por humanos y el impulsado por agentes, y qué rutas necesitan una política consciente del actor. Los apartados caso de uso de APIs y identificación de agentes de IA para API profundizan más.
La mayoría de los equipos que operan una API en producción necesita respuestas a ambas cosas.
Empezar
Proof of Actor está en beta privada. Los equipos fundadores seleccionados pueden recibir hasta 12 meses de acceso gratuito dentro de los límites de uso acordados, sin facturación automática. Solicita acceso anticipado y cuéntanos sobre la API y los llamadores que quieres entender.