El rate limit es la primera defensa que se subestima

Cuando arrancás a desplegar agentes, el rate limit te lo mete el proveedor o el equipo de infra: "para que no te facturen de más". Eso es cierto. también es la mitad de la historia.

Una vez que tu asistente pega contra tools que leen datos o disparan acciones, el rate limit es defensa contra ataques de volumen:

• Enumeration: intentar muchas combinaciones de input hasta encontrar las que devuelven info útil.
• Brute force: probar muchas variantes de payload de inyección hasta encontrar la que el modelo no rechaza.
• Cost-bombing: quemar tu presupuesto de tokens / API a propósito.
• Tool-flooding: llamar tools que disparan side effects (emails, webhooks, notificaciones) en loop.

Tres rate limits que vale la pena tener

1. Por IP / por usuario. El más obvio. Limita el daño de un atacante con una sola identidad.

2. Por argumento sensible. Si tu tool toma un order_id, user_id, email, limitá las llamadas que comparten ese valor incluso si vienen de IPs distintas. Esto es lo que detiene un atacante distribuido que ya tiene una lista de targets.

3. Por costo, no por llamada. Algunos modelos tienen llamadas baratas (200 tokens) y caras (10k tokens). un atacante puede explotar la métrica. limitá tokens-por-minuto, no solo llamadas-por-minuto.

Combiná con observación

El rate limit que solo bloquea no aporta inteligencia. El rate limit que bloquea y logea te dice quién está empujando los bordes. Esa señal entra a tu monitoreo, dispara alertas cuando el patrón es sospechoso, y te deja ajustar antes de que pase a incidente.

El rate limit no atrapa al atacante hábil. eleva el costo. lo hace lento. le quita la ventaja del volumen. eso es lo que vos podés hacer desde el lado defensivo. el resto es responder a alertas a tiempo.

A la derecha: dos configuraciones para el mismo endpoint público. Elegí la que sobrevive un atacante motivado.