Rodrigo Jorge · Preparado em 4 de novembro de 2026, às 05:57 (horário de Brasília, UTC-3). Horário de publicação a confirmar.
Um alerta dispara uma busca. A busca encontra outros indicadores, que geram novas consultas. O agente divide a análise em tarefas paralelas. Cada chamada respeita seu limite de tamanho e duração. Ainda assim, a investigação continua abrindo trabalho.
Esse cenário é hipotético. Ele não exige que o agente tenha recebido uma instrução maliciosa. Uma regra de expansão ampla demais pode produzir consumo excessivo com entradas legítimas. Um atacante também pode tentar explorar esse caminho, mas seria necessário verificar a integração para demonstrar que ele consegue fazê-lo.
A OWASP trata o consumo sem controle em LLM10:2025, Unbounded Consumption. Entre as medidas recomendadas estão quotas por usuário, timeouts e restrições sobre ações totais e em fila. O ponto operacional é que disponibilidade e consumo financeiro também entram na avaliação de segurança de uma aplicação de IA.
Para uma investigação, eu distinguiria três perguntas:
- Quanto pode consumir uma chamada?
- Quanto trabalho pode acumular a investigação inteira?
- Quanto podem consumir, juntas, as investigações daquele usuário ou integração?
Um limite não responde automaticamente aos outros. Uma quota por minuto pode permitir que uma investigação continue por muito tempo. Um teto por investigação pode permitir muitas investigações simultâneas. O escopo faz parte do controle.
A tarefa filha não começa com uma conta vazia
Minha proposta é associar buscas, retries e tarefas delegadas ao identificador da investigação que os originou. O executor deve verificar o saldo compartilhado antes de admitir mais trabalho. Se cada tarefa filha ganhar um orçamento independente, a delegação pode multiplicar a capacidade total em vez de dividi-la.
Esse orçamento pode incluir quantidade de ações, concorrência, tempo total e consumo de serviços pagos. São dimensões diferentes. Limitar tokens de saída não delimita o custo de ferramentas externas. Nenhum valor numérico é recomendado aqui: os tetos precisam ser escolhidos e avaliados para aquela operação.
A AWS documenta, no Step Functions, timeouts para tarefas e para a state machine. É um exemplo concreto de controles em escopos distintos. Não significa que adotar esse serviço implemente o orçamento proposto, nem que um timeout desfaça trabalho já enviado a outro sistema.
Ver o diagrama: um orçamento compartilhado entre as tarefas. Arquitetura proposta, sem valores ou desempenho medidos.
Também é preciso definir o que acontece quando o saldo acaba. Eu preservaria as evidências já reunidas, marcaria a análise como incompleta e impediria novas tarefas naquele fluxo até uma decisão de continuação autorizada. Ampliar o limite precisa ter responsável e registro; o agente não deve poder aumentá-lo porque ainda tem perguntas.
O teste útil é provocar expansão com dados sintéticos, incluindo tarefas paralelas e retries, e conferir o total admitido. Para o último saldo disponível, duas tarefas concorrentes conseguem autorização ao mesmo tempo? Conferir o contador depois da execução pode revelar o excesso quando o recurso já foi consumido.
A evidência esperada é a recusa de novo trabalho no escopo certo, junto ao destino das tarefas em andamento. Uma investigação interrompida pelo limite deve aparecer como tal. Encerrar o fluxo sem resolver a pergunta não é o mesmo que concluir que não houve ataque.
Referências
- OWASP: LLM10:2025 Unbounded Consumption, consultado em 4 de novembro de 2026.
- AWS: Best practices for Step Functions, seção Using timeouts to avoid stuck executions, consultada em 4 de novembro de 2026.