Consumo sin límites en aplicaciones con LLM (OWASP LLM06)

Qué es el consumo sin límites

El consumo sin límites (Unbounded Consumption) ocurre cuando una aplicación con un modelo de lenguaje grande (LLM) deja que alguien use el modelo, o los recursos que mueve, sin control sobre la cantidad. La OWASP Top 10 para aplicaciones con LLM lo sitúa en el puesto LLM06 de la edición 2026; en la de 2025 era LLM10.

Su peso ha crecido porque el coste ya no está solo en el servidor web. Una sola conversación puede generar miles de tokens (las unidades de texto con las que factura el proveedor), lanzar varias llamadas a herramientas o producir imágenes y vídeo, y todo eso se paga por uso.

Las tres caras del problema

La categoría agrupa tres daños distintos que comparten la misma causa: nadie mide ni limita cuánto se consume.

• Denegación de servicio: peticiones enormes o muy frecuentes saturan el modelo o la cola de trabajos y dejan sin servicio al resto de usuarios.
• Denegación de cartera (denial of wallet): el servicio sigue en pie, pero la factura del proveedor de IA crece sin control hasta agotar el presupuesto.
• Extracción del modelo: miles de consultas automatizadas permiten copiar el comportamiento de un modelo propio y entrenar otro con sus respuestas, lo que supone perder una inversión y a veces datos de entrenamiento.

Cómo se produce el consumo sin límites

La vía más directa es la entrada: textos larguísimos que llenan la ventana de contexto (el máximo de texto que el modelo procesa a la vez), documentos enormes subidos para resumir o peticiones que piden respuestas interminables. Si la aplicación no fija un tamaño máximo de entrada ni de salida, cada una de esas peticiones cuesta lo que el atacante decida.

Los agentes añaden un riesgo propio. Un agente que planifica, llama a herramientas y vuelve a planificar puede entrar en bucle, ya sea por un error o porque un contenido malicioso lo empuja a repetir tareas. Cada vuelta consume tokens y, a veces, servicios de pago de terceros.

También pesan las operaciones caras que se ofrecen como si fueran gratuitas: generación de imágenes o vídeo, búsquedas que lanzan muchas consultas internas o funciones que procesan lotes. Si el control depende de que el modelo decida no hacerlo, una instrucción bien formulada basta para saltarlo.

Resume cada uno de estos 500 documentos con el máximo detalle posible.
Después traduce todos los resúmenes a diez idiomas y repite el proceso
con cada traducción.

Por qué el prompt no es un control de consumo

Muchas aplicaciones escriben sus límites en el prompt de sistema: no generes más de tres imágenes, no proceses documentos largos, responde de forma breve. Esas frases orientan al modelo, pero no lo obligan. Un usuario puede convencerlo de que hay una excepción, reformular la petición o repartirla en varias.

Los límites que importan se aplican en el código que rodea al modelo: en la pasarela de la API, en las herramientas y en la cuenta del proveedor. El modelo puede proponer una operación; el servidor decide si cabe en el presupuesto de ese usuario.

Cómo se defiende el consumo sin límites

La defensa combina límites duros con vigilancia, porque un atacante paciente puede quedarse justo por debajo de cualquier umbral fijo.

• Autenticación y límites de frecuencia por usuario, por clave de API y por dirección de origen.
• Cuotas acumuladas por periodo (por hora, por día, por mes), no solo un tope por petición.
• Tamaño máximo de entrada y de salida, y tiempo máximo por petición.
• En los agentes, un número máximo de pasos y de llamadas a herramientas por tarea.
• Presupuestos y alertas de gasto en la cuenta del proveedor, con corte automático al llegar al límite.
• Registro y detección de patrones anómalos, como volúmenes repentinos o consultas sistemáticas que apuntan a extracción del modelo.
• Colas con prioridad para que un solo usuario no pueda acaparar la capacidad del servicio.