Cómo Manejar el Tráfico de AI Agents en APIs: 5 Correcciones para Rate Limits, Auth y Observabilidad

AI agents de OpenAI, Anthropic y cientos de startups ya están llamando APIs en producción. No es un escenario futuro. Está en los logs de tráfico ahora.

Toda API construida en los últimos cinco años fue diseñada para un humano del otro lado: un usuario, una sesión, solicitudes llegando a la velocidad en que alguien escribe o toca la pantalla. Los AI agents no funcionan así. Un solo agent puede abrir 50 conexiones paralelas, llamar el mismo endpoint 200 veces en 10 segundos y rotar IPs entre llamadas. La mayoría de las veces lo hace de forma completamente legítima, recuperando datos para un usuario real en nombre de una integración real.

El problema es que la mayoría de las APIs no tienen forma de distinguir una integración de AI bien portada de un ataque de scraper. El tráfico se ve igual. El rate limit ve el mismo patrón. Las reglas del WAF fueron escritas para SQL injection y XSS, no para un agent llamando un endpoint de búsqueda 300 veces por minuto.

Los logs de tráfico de tres APIs en producción, una plataforma SaaS pública, una API de datos fintech y un producto de herramientas para desarrolladores, muestran que el tráfico de agents tiene un patrón distinto tanto del tráfico humano como de los ataques de bots. Lo mismo aplica para las fallas que causa y para las correcciones.

El resumen: Los rate limits por IP son invisibles para agents que usan rotación de IP. Los flujos OAuth con redirect humano excluyen a los agents por completo. Las APIs que retornan 200 con errores en el body generan retry loops. Los dashboards estándar no muestran nada de esto. Los cinco problemas tienen solución en uno a dos sprints, sin reconstruir la API.

Cómo se ve el tráfico de AI agent en términos de HTTP

La diferencia entre tráfico humano y tráfico de agent no es sutil. Aparece en el patrón de solicitudes antes que cualquier otra cosa.

Un humano usando un producto SaaS inicia sesión una vez, hace algunas llamadas de API durante una sesión y para. El patrón de solicitudes parece una curva de campana: rampa lenta mientras navega, un pico durante el uso activo, luego nada. Un usuario humano activo genera entre 10 y 30 solicitudes por minuto.

Un AI agent recibe una tarea, “resume los últimos 30 días de actividad del cliente”, y se dispersa de inmediato. Llama al endpoint de auth, obtiene un token y lanza solicitudes paralelas a cada endpoint que necesita. Todo al mismo tiempo. 50 solicitudes en el primer segundo. Luego termina. Luego lo vuelve a hacer cuando llega la siguiente tarea.

Un bot tradicional se ve diferente de ambos. Más lento, más distribuido, apuntando a endpoints específicos repetidamente, buscando vulnerabilidades o haciendo scraping de contenido. Un flood lento, no un pico. Las reglas del WAF fueron diseñadas para este patrón y funcionan contra él.

Tres fuentes de tráfico distintas. Tres patrones distintos. Un modelo de defensa construido para exactamente uno de ellos.

Cuatro cosas que fallan cuando los agents llegan a una API diseñada para humanos

Rate limits. Casi todo rate limit es por IP por minuto, calibrado para lo que parece un usuario humano. Un AI agent distribuido en 20 IPs envía 3 solicitudes por IP por minuto, bien por debajo de cualquier límite razonable, mientras hace 60 solicitudes por minuto en total. El rate limiter no ve nada mal. El agent pasa. El rate limit solo agregó latencia y nada más.

Hacer rate limiting por cuenta o API key, en lugar de por IP, resuelve esto. Una cuenta tiene un presupuesto de solicitudes por ventana de tiempo sin importar cuántas IPs usa.

Auth flows. La mayoría de los flujos OAuth asumen un humano en el proceso: redirect a una página de login, ingresar credenciales, aprobar un scope. Los agents no pueden hacer clic en un browser. Necesitan machine-to-machine auth: client credentials, API keys, service accounts. Si la única opción de auth requiere un redirect humano, el agent no puede autenticarse, o almacena credenciales en caché de formas que el dueño de la API no diseñó y no puede revocar. El flujo de client credentials de OAuth 2.0 resuelve esto: el agent intercambia un client ID y un secret por un bearer token de corta duración, sin ningún redirect humano.

Error handling. Los agents no leen mensajes de error. Parsean status codes. Si una API retorna 200 con un error dentro del body, algo que las APIs más antiguas comúnmente hacen, el agent lo trata como éxito y sigue llamando. La API retorna errores, el agent entra en loop, y cada solicitud en ese loop consume cuota y genera costo sin ningún valor. Retornar los códigos 4xx o 5xx correctos y agregar un header Retry-After a las respuestas de rate limit le da a los agents bien portados una señal clara para detenerse.

Observabilidad. Las métricas estándar de API rastrean solicitudes por endpoint, tasas de error y latencia. Eso es suficiente para tráfico humano. Para tráfico de agent, las preguntas relevantes son: ¿qué agent es este, qué tarea está completando y el patrón de solicitudes es normal para esta integración? Nada de eso aparece en las métricas estándar. Sin eso, el tráfico inusual de agent se ve idéntico a un ataque de scraper, lo que significa que los equipos bloquean ambos o ninguno.

El problema de identidad: saber qué está llamando tu API

La parte más difícil de manejar el tráfico de agent es la identidad. ¿Cómo sabe una API que algo es un AI agent? La respuesta honesta: de forma imperfecta, con múltiples señales.

Algunos agents envían un header User-Agent que los identifica. El crawler de OpenAI usa GPTBot. El agent de Anthropic usa ClaudeBot. Pero cualquier desarrollador puede configurar el User-Agent como quiera. Un scraper puede llamarse GPTBot. Un agent real puede eliminar su User-Agent por completo. User-Agent no es una frontera de seguridad.

Una señal más confiable es el behavioral fingerprinting. Los AI agents tienen un patrón de llamada consistente: solicitudes paralelas, recorrido estructurado de endpoints, comportamiento de retry predecible y ausencia de datos de fingerprint del browser, sin movimientos de mouse, sin render timing, sin eventos de scroll. El Bot Manager de Azion clasifica el tráfico usando estas señales de comportamiento junto con machine learning, puntuación de solicitudes, reputación de red y device fingerprinting. No es perfecto, pero es mucho más confiable que hacer match de User-Agent.

La tercera señal es la integración en sí. Una API key registrada por una empresa conocida haciendo solicitudes con patrón de agent es identificable. Construir políticas explícitas para agents conocidos, con rate limits más altos, flujos de auth dedicados y observabilidad por scope, resuelve el caso legítimo. Los agents desconocidos reciben fricción hasta que se identifiquen. Los bots maliciosos se bloquean.

Cinco correcciones que cubren el tráfico de agent sin reconstruir la API {#agent-api-fixes}

Las cinco son implementables en uno a dos sprints. Ninguna requiere reconstruir la API desde cero.

Behavioral rate limiting. Cambia los rate limits de por-IP a por-cuenta o por-API-key, con un presupuesto de solicitudes por ventana de tiempo. Una cuenta tiene 1,000 solicitudes por minuto sin importar cuántas IPs usa. Esto cierra el bypass de rotación de IP y le da a los agents legítimos un contrato predecible y documentado.

Machine-to-machine auth. Agrega un flujo de client credentials de OAuth 2.0. Los agents reciben un client ID y un secret, los intercambian por un bearer token con corta expiración y hacen llamadas de API con ese token. Sin redirect humano. El token es revocable. Puede tener scope por integración. La mayoría de los frameworks de agents ya soportan este flujo de forma nativa.

Status codes HTTP correctos. Audita la API en busca de respuestas 200 con errores en el body. Cámbialas por los códigos 4xx o 5xx correspondientes. Agrega un header Retry-After a las respuestas de rate limit. Esto solo puede reducir significativamente la carga de origen relacionada con agents al detener los retry loops antes de que se acumulen.

Observabilidad orientada a agents. Agrega dos campos a cada log de API: tipo de cliente (humano, agent conocido, agent desconocido) y un request context ID que agrupe todas las solicitudes de una sola tarea de agent. Con estos campos, es posible ver qué está intentando hacer un agent, cuánto tiempo tarda y si su comportamiento es el esperado para esa integración. Real-Time Events de Azion expone esto en la borda de la red antes de que las solicitudes lleguen al origen.

Una capa de clasificación. Entre internet y la API, una capa que clasifica la intención del tráfico en tiempo real cambia lo que es posible. El Bot Manager de Azion usa señales de comportamiento, Reputation Intelligence y machine learning para clasificar cada solicitud como humano, bot legítimo, bot malicioso o en evaluación. Los agents legítimos conocidos reciben una regla de allow con límites mayores. Los agents desconocidos reciben una respuesta con fricción que las integraciones legítimas pueden manejar y los bots abusivos no.

El tráfico de agent como canal de distribución

La mayoría de los equipos enmarca el tráfico de AI agent como un problema de seguridad. El otro enfoque, el que importa para la estrategia de producto, es la distribución.

Si una API tiene machine-to-machine auth limpio y retorna respuestas bien estructuradas, los AI agents pueden usarla para construir cosas que el dueño de la API no construyó. La API se convierte en un componente en una aplicación de IA de otra empresa. Stripe se volvió infraestructura así. Twilio se volvió infraestructura así. Las empresas que van a definir los próximos cinco años de software son aquellas cuyas APIs los agents pueden de verdad llamar.

Sin plan para el tráfico de agent, se llega a uno de dos resultados: la API cae por uso legítimo a escala, o el equipo bloquea todo el tráfico de agents y pierde las integraciones que debían impulsar el crecimiento. Ninguno es bueno.

Los equipos que van adelante en esto hicieron tres cambios: behavioral rate limiting, client credentials auth y una capa de clasificación frente a la API. Un sprint. La ventana para hacerlo antes de que se vuelva urgente se está cerrando.

Los AI agents ya están en producción, ya están llamando APIs, ya están golpeando suposiciones que nunca se probaron a velocidad de máquina. Las cinco correcciones de arriba no son un item de roadmap futuro. Son una respuesta al tráfico que ya está ahí.

Habla con un especialista de Azion para ver cómo Bot Manager y Real-Time Events manejan la clasificación y observabilidad de AI agents en la borda de la red.

Preguntas frecuentes

¿En qué se diferencia el tráfico de AI agent del tráfico de bot? Los ataques de bot generalmente usan un flood lento y sostenido apuntando a endpoints específicos de forma repetida, buscando vulnerabilidades o haciendo scraping de contenido. Los AI agents generan un patrón de pico: 50 a 200 solicitudes paralelas en pocos segundos, luego silencio, luego otro pico cuando llega la siguiente tarea. Las reglas de WAF y la mayoría de las configuraciones de rate limiting fueron construidas para patrones de ataque de bot y no son efectivas contra el tráfico con estilo de agent. Los dos tipos de tráfico son distintos en comportamiento, intención y en las defensas que funcionan contra ellos.

¿Por qué el rate limiting por IP falla contra los AI agents? La infraestructura de AI agents generalmente distribuye el tráfico en múltiples IPs. Un agent con un presupuesto de 60 solicitudes por minuto puede enviar 3 solicitudes desde cada una de 20 IPs, manteniéndose por debajo de cualquier límite por IP mientras consume el presupuesto completo en paralelo. El rate limiting por cuenta o API key, donde una cuenta tiene un solo presupuesto de solicitudes sin importar el número de IPs, cierra este bypass.

¿Qué es OAuth machine-to-machine y por qué lo necesitan los AI agents? El flujo de client credentials de OAuth 2.0 permite que un servicio se autentique directamente con una API usando un client ID y un secret, sin ningún redirect humano ni interacción de browser. Los AI agents no pueden completar flujos OAuth con redirect humano porque no tienen un browser para hacer clic. El auth de client credentials le da a los agents un token revocable y con scope que pueden obtener de forma programática, lo que también es más fácil de auditar y revocar que las credenciales almacenadas en caché.

¿Qué detecta el behavioral fingerprinting que el match de User-Agent no detecta? Los strings de User-Agent son autodeclarados y trivialmente falsificables. El behavioral fingerprinting analiza patrones reales de solicitudes: paralelismo, secuencia de recorrido de endpoints, comportamiento de retry y ausencia de señales de browser como movimientos de mouse, render timing y eventos de scroll. Un agent que se declara como un crawler legítimo via User-Agent sigue mostrando patrones de comportamiento específicos de agent que el fingerprinting detecta. Es más confiable, aunque no es infalible.

¿Qué es un header Retry-After y por qué importa para los AI agents? El header HTTP Retry-After le dice al llamador cuánto tiempo esperar antes de hacer otra solicitud. Cuando una API retorna una respuesta 429 Too Many Requests sin Retry-After, un agent mal configurado puede reintentar de inmediato, creando una carga creciente en el origen. Un agent bien portado que recibe Retry-After esperará la duración especificada. Agregar este header a las respuestas de rate limit es una de las correcciones de menor esfuerzo con mayor impacto en la reducción de retry loops de agents.

¿Cuál es el argumento de negocio para hacer las APIs compatibles con agents? Las APIs diseñadas para tráfico de agent se convierten en canales de distribución. Los AI agents que construyen aplicaciones sobre una API bien estructurada y autenticada via M2M extienden su alcance hacia casos de uso que el equipo original nunca construyó. Stripe y Twilio se volvieron infraestructura fundamental en parte porque sus APIs eran fáciles de llamar de forma programática. Los equipos que diseñan para tráfico de agent ahora están posicionando sus APIs como componentes en la capa de aplicaciones de IA que se está construyendo en toda la industria. Los equipos que bloquean o ignoran el tráfico de agent se están excluyendo de esa capa.