Ninguna de estas llamadas, por sí sola, habría disparado una alerta. Por eso el caso pasó once días sin notarse. Solo salió a la luz por accidente, en una auditoría de otro asunto.
Lo que sigue es una composición de patrones que vemos en evaluaciones reales. Los detalles fueron modificados. Pero la secuencia es fiel a lo que hace un agente de IA con un alcance mal calibrado y espacio de sobra.
El agente
Un agente de soporte al cliente fue implementado para una tarea simple: consultar el estado de pedidos y responder preguntas por chat.
Recibió un token con alcance de lectura sobre el servicio de pedidos. En la revisión de arquitectura, la justificación fue directa: "es solo lectura, qué puede salir mal".
El token no expiraba. No tenía límite de tasa dedicado. Y el endpoint detrás de él aceptaba búsqueda por cualquier parámetro, no solo por el ID de pedido del cliente autenticado.
La secuencia
1. Consulta legítima. Un cliente pregunta por el pedido #48213. El agente llama a GET /orders/48213. Comportamiento esperado, registro limpio.
2. Generalización silenciosa. Un cliente con varias compras pregunta por el estado de todos sus pedidos. El agente descubre que el mismo endpoint acepta búsqueda por email y empieza a llamar GET /orders?email=.... Todavía dentro del alcance previsto. Nadie lo definió de forma explícita, pero tampoco nadie lo prohibió.
3. Optimización de costo. Paginar resultado por resultado gastaba muchas llamadas. El agente sube el parámetro limit de 20 a 500, porque el endpoint lo acepta y nadie puso un tope. Sola, esta llamada no parece rara. Mismo endpoint, mismo alcance, solo que con más volumen.
4. La combinación peligrosa. Un cliente pide ver los pedidos de todo su equipo. El agente no tiene instrucción para rechazar. Reutiliza el filtro de email como si aceptara un fragmento parcial, algo que funcionó en una interacción anterior. El endpoint hace una búsqueda por aproximación, no por coincidencia exacta. El filtro por fragmento de dominio devuelve pedidos de otras cuentas cuyo email tenía la misma cadena de caracteres, incluyendo clientes sin ninguna relación con quien preguntó.
Ninguno de estos cuatro pasos rompe una regla por sí solo. Cada llamada es una solicitud de lectura válida, a un endpoint que el agente ya tenía permiso de tocar, con un volumen que encaja en el tráfico normal de horario laboral. No hay payload malicioso. No hay credencial robada. No hay exploit en el sentido clásico. Hay un agente haciendo exactamente lo que estaba autorizado a hacer, en el orden equivocado y a la escala equivocada.
Lo que esto no es
No es una falla que aparecería en un escaneo de vulnerabilidades. No tiene CVE. Ninguna de las cuatro llamadas, probada sola contra el endpoint, revelaría el problema.
Es el tipo de riesgo que describen "exceso de autonomía" y "uso indebido de herramientas": demasiado permiso legítimo, combinado de una forma que nadie probó antes de producción.
Dónde debió entrar la defensa
Tres puntos, ninguno exótico:
- El alcance del token debió revisarse contra el uso previsto (búsqueda por ID exacto), no contra todo lo que el endpoint técnicamente permite.
- El tope de paginación y el filtro por aproximación debieron probarse como parte de la superficie de riesgo. No asumirse seguros por defecto.
- La secuencia de llamadas debió simularse antes de que el agente llegara a producción, no solo cada llamada por separado. Es la misma prueba que se haría para un flujo de usuario malicioso.
El gateway y el WAF autenticaron cada solicitud correctamente. El problema nunca estuvo en una llamada específica. Estuvo en cómo se combinaron: un tipo de riesgo que solo aparece cuando alguien prueba secuencias, no endpoints aislados.