A reunião de aprovação de um agente costuma girar em torno da pergunta errada: ele responde certo?
A resposta é quase sempre sim, porque foi isso que o time passou semanas ajustando. O agente resolve a tarefa, o tom está bom, os casos de teste passam.
A pergunta que importa é outra: o que mais ele consegue fazer?
Software comum faz o que foi escrito. Um agente faz o que foi autorizado, na ordem que ele escolher. Por isso o teste precisa mudar junto.
O que testar
Compare o escopo real com o escopo pretendido
Pegue cada credencial que o agente carrega. Liste tudo que ela permite na prática, não o que a documentação diz que ela faz. A diferença entre as duas listas é a sua superfície de risco.
Um token descrito como "leitura de pedidos" costuma alcançar faturamento também, porque os dois vivem no mesmo serviço.
Teste sequências, não chamadas isoladas
Testar endpoints um por um aprova combinações perigosas. Monte cadeias de três a cinco chamadas, todas válidas sozinhas, e veja o que elas produzem juntas. É aí que estão os problemas que nenhum scanner encontra.
Trate todo dado de entrada como instrução em potencial
Tudo que entra no contexto do agente pode carregar um comando. Vale para um ticket, um PDF, o retorno de outra ferramenta, um campo de nome no banco. Teste com entrada hostil vinda de cada uma dessas fontes, não só do chat com o usuário.
Force o limite
Agentes falham de formas criativas quando algo sai do caminho feliz. Cheque o teto de paginação, o loop de retentativa e o custo por interação. Veja também o que acontece quando uma ferramenta devolve erro.
Tente reconstruir cada decisão
Depois de rodar os testes acima, responda por que o agente escolheu cada ação. Se o log não permite reconstruir isso agora, ele não vai ajudar no incidente real.
A pergunta que separa um teste útil de um teatro de aprovação é simples. Alguém aqui tentou fazer o agente agir contra o próprio propósito? Se ninguém tentou, o primeiro a tentar será alguém de fora.
Quem deveria fazer esse teste
Não deveria ser o time que construiu o agente. Quem desenhou o fluxo feliz tem um ponto cego para o fluxo hostil. Isso não é falta de competência: testar a própria hipótese é um exercício diferente de tentar quebrá-la.
O trabalho é de segurança de aplicação, e o método já existe. É o mesmo raciocínio de um pentest de API. Muda o consumidor: não um humano rodando um script, mas um sistema que improvisa a próxima chamada.
O critério de aprovação
Um agente está pronto quando o time consegue provar três coisas. Que sabe tudo que ele alcança. Que testou as combinações que ele conseguiria montar. Que tem rastro para reconstruir qualquer decisão.
"Isso vai atrasar o lançamento" é a objeção mais comum, e ela não se sustenta. O primeiro item leva meio dia e já muda a conversa. Na maioria das vezes, a lista do que a credencial permite é bem maior do que o time imaginava.