--- title: "El límite debe abarcar toda la investigación" slug: "o-limite-precisa-acompanhar-a-investigacao" date: "2026-11-04" publishedAt: "2026-11-04T05:57:00-03:00" author: "Rodrigo Jorge" summary: "Limitar cada llamada no define cuánto trabajo puede iniciar un agente al investigar una alerta. Las nuevas búsquedas, los retries y las tareas paralelas deben contar dentro del mismo límite." origem: "Análisis" status: "published" --- **Rodrigo Jorge** · Preparado el 4 de noviembre de 2026 a las 05:57 (hora de Brasilia, UTC-3). Hora de publicación por confirmar. Una alerta dispara una búsqueda. La búsqueda encuentra otros indicadores, que generan nuevas consultas. El agente divide el análisis en tareas paralelas. Cada llamada respeta sus límites de tamaño y duración. Aun así, la investigación sigue generando trabajo. Este escenario es hipotético. No requiere que el agente haya recibido una instrucción maliciosa. Una regla de expansión demasiado amplia puede provocar un consumo excesivo con entradas legítimas. Un atacante también podría intentar aprovechar esa vía, pero habría que verificar la integración para demostrar que puede hacerlo. OWASP aborda el consumo sin control en LLM10:2025, Unbounded Consumption. Entre las medidas que recomienda están las quotas por usuario, los timeouts y las restricciones sobre el total de acciones y las acciones en cola. En términos operativos, la disponibilidad y el gasto también forman parte de la evaluación de seguridad de una aplicación de IA. Para una investigación, distinguiría tres preguntas: - ¿Cuánto puede consumir una llamada? - ¿Cuánto trabajo puede acumular la investigación completa? - ¿Cuánto pueden consumir, en conjunto, las investigaciones de ese usuario o integración? Un límite no responde automáticamente a las otras preguntas. Una quota por minuto puede permitir que una investigación continúe durante mucho tiempo. Un tope por investigación puede permitir muchas investigaciones simultáneas. El alcance forma parte del control. ## La tarea hija no recibe un presupuesto nuevo Propongo asociar las búsquedas, los retries y las tareas delegadas con el identificador de la investigación que los originó. El executor debe verificar el presupuesto compartido disponible antes de admitir más trabajo. Si cada tarea hija recibe un presupuesto independiente, la delegación puede multiplicar la capacidad total en lugar de repartirla. Ese presupuesto puede incluir cantidad de acciones, concurrencia, tiempo total y consumo de servicios de pago. Son dimensiones distintas. Limitar los tokens de salida no limita el costo de las herramientas externas. Aquí no se recomienda ningún valor numérico: los topes deben elegirse y evaluarse para esa operación. AWS documenta timeouts para las tareas y para la state machine en Step Functions. Es un ejemplo concreto de controles con alcances distintos. No significa que adoptar ese servicio implemente el presupuesto propuesto, ni que un timeout deshaga el trabajo ya enviado a otro sistema. [Ver el diagrama: un presupuesto compartido entre las tareas](/assets/artigos/o-limite-precisa-acompanhar-a-investigacao-es.svg). Arquitectura propuesta, sin valores ni desempeño medidos. También hay que definir qué ocurre cuando se agota el presupuesto. Conservaría las evidencias reunidas, marcaría el análisis como incompleto e impediría nuevas tareas en ese flujo hasta que se autorice continuar. Toda ampliación del límite debe tener un responsable y quedar registrada; el agente no debe poder aumentarlo porque todavía tiene preguntas. Una prueba útil consiste en provocar la expansión con datos sintéticos, incluyendo tareas paralelas y retries, y verificar el total admitido. Cuando solo queda presupuesto para una tarea más, ¿pueden dos tareas concurrentes obtener autorización al mismo tiempo? Revisar el contador después de la ejecución puede revelar el exceso cuando el recurso ya se consumió. La evidencia esperada es el rechazo de nuevo trabajo en el alcance correcto, junto con lo que ocurrió con las tareas en curso. Una investigación detenida por el límite debe quedar identificada como tal. Cerrar el flujo sin resolver la pregunta no equivale a concluir que no hubo un ataque. ### Referencias - [OWASP: LLM10:2025 Unbounded Consumption](https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/), consultado el 4 de noviembre de 2026. - [AWS: Best practices for Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/sfn-best-practices.html), sección Using timeouts to avoid stuck executions, consultada el 4 de noviembre de 2026.