Existe um jeito rápido de fazer um agente de defesa errar: pedir a ele que "bloqueie ataques". A frase parece uma instrução. Na prática é uma pergunta aberta demais, e o modelo responde como responde a qualquer pergunta aberta: com uma opinião plausível, confiante e difícil de auditar.
O problema não é o modelo ser fraco. É a pergunta ser larga. "Isto é um ataque?" exige que ele saiba, ao mesmo tempo, o que é SQL injection, XSS, traversal, credential stuffing, scraping, um bot de monitoramento legítimo e um cliente com um plugin velho. Cada uma dessas coisas tem sinais diferentes, falsos positivos diferentes e consequências diferentes se a decisão der errado. Jogadas no mesmo saco, viram uma média, e uma média não bloqueia bem nada.
Pergunta estreita, resposta melhor
O que funciona é o oposto: dividir por categoria e fazer uma pergunta por vez. Em vez de "isto é um ataque?", o agente recebe "isto é SQL injection?", com um prompt escrito para SQL injection, exemplos de SQL injection, o que não é SQL injection e o limiar de confiança que a operação aceita para SQL injection. Depois a mesma coisa para XSS, para traversal, para cada categoria que a organização decidiu tratar.
A diferença aparece em três lugares:
- Precisão. O modelo acerta mais quando o espaço de resposta é pequeno e os exemplos são da mesma família.
- Calibração. Cada categoria tem o seu próprio limiar. O que é confiança suficiente para bloquear um traversal óbvio não é o mesmo que para um padrão de credential stuffing, onde o custo de bloquear um cliente legítimo é alto.
- Correção. Quando a IA erra, dá para saber em qual categoria errou e ajustar aquele prompt, aqueles exemplos ou aquele limiar, sem mexer no resto. Falso positivo vira bug localizado, não motivo para desligar o motor.
Como isso aparece no Cyberbot
O caso Cyberbot, que roda em produção, faz exatamente isso, e foi assim que chegou a menos de um minuto do log ao bloqueio sem derrubar cliente. A categoria vem de uma lista fechada; o modelo não inventa categoria nova. Severidade e confiança são validadas por código. Regras simples pré-detectam os suspeitos óbvios (traversal, SQLi, .env exposto, web shell) e entregam para a IA só o que precisa de julgamento contextual. E a ação automática é habilitada por categoria e severidade, com lista e TTL definidos, nunca em bloco.
Se o modelo foge do contrato e devolve algo fora da lista, o pedido cai em fallback. Nada acontece. Essa é a parte que mais importa: a pergunta estreita não é só um truque de prompt, é o que permite colocar um contrato verificável entre o modelo e a ação.
O que mudar no seu playbook
Se você está desenhando um agente que pode agir, a regra cabe em uma linha: nenhuma ação é autorizada para "ataque". Ações são autorizadas por categoria, e cada categoria tem prompt, exemplos e limiar próprios, revisados separadamente.
O gerador de playbook deste guia passou a incluir isso na lista de guardrails. Não é um detalhe de implementação. É a diferença entre um agente em que a operação confia e um que a operação desliga na primeira semana.