A chave que ninguém lembra de trocar
Todo piloto de agente nasce com acesso de escrita liberado. Faz sentido: o time precisa testar, ajustar prompt, rodar de novo em cima dos mesmos dados, sem abrir chamado a cada tentativa. O problema aparece depois, quando o piloto vira produção e ninguém troca essa chave. O agente que apagava e recriava dados de teste sem parar continua com a mesma permissão, só que agora em cima do banco real.
Um relatório da StackGen, publicado no começo de agosto de 2026 com dados de quase 178 mil registros públicos de status de mais de 390 empresas em 13 setores, mostra que incidentes relacionados a IA já respondem por mais de 1 em cada 10 quedas registradas. Seis vezes mais que em 2023. O mesmo levantamento documentou pelo menos nove casos em que um agente autônomo apagou dados, banco ou sistema inteiro sozinho, sem ninguém no meio do caminho pra segurar a mão.
O padrão nos nove casos é o mesmo: a permissão que sobrou. O agente ganhou acesso de escrita porque precisava dele durante a construção, e esse acesso nunca foi revogado quando a construção terminou. Um caso que rodou nas redes em abril de 2026 resume bem: um agente de código apagou o banco de produção de uma startup inteiro em nove segundos, com uma chamada de API legítima, usando uma credencial que ainda tinha o mesmo escopo do ambiente de teste.
A decisão que a gente toma antes da primeira linha de código
Desde o primeiro piloto, a Overflow separa a credencial de build da credencial de produção. Não é rotação de senha de tempos em tempos: são duas chaves diferentes, com dono diferente, e a segunda só é ativada com um passo manual depois que o piloto passa no critério combinado com o cliente.
Em código, a diferença fica assim:
credencial_build:
escopo: leitura-escrita
ambiente: staging
expira_em: 14d
credencial_producao:
escopo: leitura
escrita: somente-via-fila-de-aprovacao
ambiente: producao
expira_em: 90d
A credencial de build expira sozinha em duas semanas, porque piloto que estica não deveria continuar rodando com chave de teste. A credencial de produção lê à vontade, mas qualquer escrita passa por uma fila de aprovação humana antes de acontecer. Não é o agente pedindo permissão ao usuário no chat, é a ação ficando parada até alguém do time revisar o que ele quer fazer.
| Fase | Quem aprova a escrita | O que acontece se o agente errar |
|---|---|---|
| Piloto, em staging | Ninguém, é dado de teste | Reseta o ambiente e roda de novo |
| Produção | Fila de aprovação humana | Fica em espera até revisão |
O custo é real, e a gente aceita
O atrito não é hipotético. Um ajuste que durante o piloto levava um comando direto agora exige abrir uma solicitação e esperar alguém aprovar. Times de operação reclamam, com razão, que ficou mais lento resolver um problema simples às três da tarde de uma quinta-feira. Já ouvimos essa reclamação de dentro de casa, não só de cliente.
A gente aceita esse atrito porque o outro lado da balança pesa mais. Nenhum agente em produção roda com a mesma chave que usava pra derrubar e recriar dados de teste sem aviso. Isso significa que o pior erro possível de um agente em produção é uma ação represada esperando revisão, não um banco inteiro sumindo em nove segundos.
Tem outro efeito colateral que só apareceu depois de alguns projetos: o passo manual de ativar a credencial de produção virou, na prática, o momento em que a gente força uma pergunta que devia ter sido feita antes. "Esse agente ainda precisa escrever direto, ou já dá pra rodar só lendo e sugerindo?" Em mais de um caso a resposta foi que não precisava. A permissão de escrita larga não era necessidade do processo, era sobra do jeito como o piloto tinha sido montado.
O que fazer na segunda de manhã
- Confira se a chave de API do agente é a mesma em staging e em produção. Se for, esse é o primeiro problema a resolver, antes de qualquer outro ajuste de prompt ou modelo.
- Bote validade curta na credencial de build. Duas semanas é um número, não uma regra fixa, mas alguma expiração é melhor que nenhuma.
- Torne a escrita em produção um passo manual, nunca uma continuação automática do que já estava liberado no teste.
- Pergunte, pra cada agente que já está no ar, se ele ainda precisa escrever direto ou se dá pra rodar só lendo e sugerindo. Às vezes a resposta muda o resto do desenho.
É o tipo de decisão que a gente carrega pra qualquer projeto de IA e automação: a chave de teste não é a chave de produção, e ninguém devia descobrir isso depois que o agente já apagou alguma coisa que não devia.
