O novo problema e coordenar agentes, nao so prompts
Quando um agente ajuda, a pergunta e permissao. Quando varios agentes trabalham em paralelo, a pergunta vira governanca: quem pode ler, quem pode escrever, quem pode chamar ferramenta, quem pode abrir PR, quem pode mexer em ambiente e quem responde pelo resultado?
Antigravity, Managed Agents e subagents no Gemini CLI tornam esse desenho mais comum. O ganho de velocidade e obvio. O risco tambem: tarefas independentes podem tocar a mesma fronteira de seguranca sem ninguem perceber.
Regra pratica por agente
- Um objetivo pequeno por agente.
- Ferramentas permitidas por tarefa, nao por conveniencia.
- Sem segredo de producao no contexto.
- Sem write access em banco real.
- Branch separada e PR com diff revisavel.
- Logs de tool call sem payload privado.
- Aprovacao humana antes de deploy, migracao, pagamento e mudanca de auth.
O que procurar em SaaS
Agentes costumam mexer bem em UI, copy, testes e documentacao. O cuidado cresce quando entram rotas server-side, webhooks, plano pago, tenant, storage, login social, mobile e integracoes externas. Uma alteracao pequena em middleware pode valer mais risco que uma tela inteira.
Se o app tem cliente real, o primeiro passo e pedir ao Promptbook para separar sinais por fluxo. Quando o sinal tocar receita ou dados, Risk Review entra para decidir prioridade sem virar pentest completo desnecessario.
Sinais de alerta
- Agente pedindo permissao ampla porque "precisa testar".
- Subagent lendo arquivo de env, dump, log ou artifact.
- Duas branches alterando auth, billing ou schema ao mesmo tempo.
- Deploy automatico sem smoke de checkout/login.
- Teste visual verde com API quebrada.
Fontes usadas
Quanto mais agentes, mais importante fica saber quem podia fazer o que, onde e com qual prova.
