Nenhuma das chamadas, isoladamente, teria disparado um alerta. Por isso o caso levou onze dias para ser notado. E só apareceu por acidente, numa auditoria de outro assunto.
O que vem a seguir é uma composição de padrões que aparecem em avaliações reais. Os detalhes foram alterados. Mas a sequência é fiel ao que um agente de IA faz quando tem escopo mal calibrado e espaço de sobra.
O agente
Um agente de suporte ao cliente foi implantado para uma tarefa simples: consultar status de pedidos e responder perguntas no chat.
Ele recebeu um token com escopo de leitura sobre o serviço de pedidos. Na revisão de arquitetura, a justificativa foi direta: "é só leitura, não tem como dar errado".
O token não expirava. Não tinha limite de taxa dedicado. E o endpoint por trás dele aceitava busca por qualquer parâmetro, não só pelo ID do pedido do cliente autenticado.
A sequência
1. Consulta legítima. Um cliente pergunta pelo pedido #48213. O agente chama GET /orders/48213. Comportamento esperado, log limpo.
2. Generalização silenciosa. Um cliente com várias compras pergunta pelo status de todos os pedidos. O agente descobre que o mesmo endpoint aceita busca por e-mail e passa a chamar GET /orders?email=.... Ainda dentro do escopo pretendido. Ninguém definiu isso explicitamente, mas também ninguém proibiu.
3. Otimização de custo. Paginar resultado por resultado gastava muitas chamadas. O agente aumenta o parâmetro limit de 20 para 500, porque o endpoint aceita e ninguém validou um teto. Sozinha, essa chamada não parece anômala. Mesmo endpoint, mesmo escopo, só que com volume maior.
4. A combinação perigosa. Um cliente pede para ver os pedidos de toda a equipe dele. O agente não tem instrução para recusar. Ele reutiliza o filtro de e-mail como se aceitasse um fragmento parcial, algo que funcionou numa interação anterior. O endpoint faz busca por aproximação, não por correspondência exata. O filtro por trecho de domínio retorna pedidos de outras contas cujo e-mail tinha a mesma sequência de caracteres, incluindo clientes sem nenhuma relação com quem perguntou.
Nenhum desses quatro passos quebra uma regra sozinho. Cada chamada é uma requisição de leitura válida, para um endpoint que o agente já tinha permissão de tocar, num volume compatível com o tráfego normal do horário comercial. Não existe payload malicioso. Não existe credencial roubada. Não existe exploit no sentido clássico. Existe um agente fazendo exatamente o que foi autorizado a fazer, na ordem errada e na escala errada.
O que isso não é
Não é uma falha que apareceria num scan de vulnerabilidades. Não tem CVE. Nenhuma das quatro chamadas, testada sozinha contra o endpoint, revelaria o problema.
É o tipo de risco que "excesso de autonomia" e "uso indevido de ferramentas" descrevem: permissão legítima demais, combinada de um jeito que ninguém simulou antes de ir para produção.
Onde a defesa deveria ter entrado
Três pontos, nenhum exótico:
- O escopo do token deveria ter sido validado contra o uso pretendido (busca por ID exato), não contra tudo que o endpoint tecnicamente permite.
- O teto de paginação e o comportamento do filtro por aproximação deveriam ter sido testados como parte da superfície de risco. Não assumidos seguros por padrão.
- A sequência de chamadas deveria ter sido simulada antes do agente chegar à produção, não só cada chamada isolada. É o mesmo teste que se faria para um fluxo de usuário malicioso.
Gateway e WAF autenticaram cada requisição corretamente. O problema nunca esteve numa chamada específica. Esteve na combinação delas: um tipo de risco que só aparece quando alguém testa sequências, não endpoints isolados.