DEV Community

Cover image for Como impedir que um agente de programação faça mudanças destrutivas sem aprovação humana
Kusaki Werison
Kusaki Werison

Posted on

Como impedir que um agente de programação faça mudanças destrutivas sem aprovação humana

#security #ai #programming #devops

Agentes de programação reduzem drasticamente o tempo entre uma intenção e uma alteração real no projeto.

Esse ganho também muda o tipo de risco.

Quando um agente consegue editar dezenas de arquivos, executar comandos, instalar dependências ou alterar configuração em poucos segundos, a pergunta deixa de ser apenas:

“Ele consegue fazer?”

e passa a ser:

“Ele tinha autoridade para fazer isso?”

Uma estrutura mínima de governança pode reduzir essa ambiguidade sem transformar cada alteração em burocracia.

1. Autoridade deve ser explícita

Uma regra útil é:

Ausência de proibição não significa autorização.
Enter fullscreen mode Exit fullscreen mode

Separe as ações em três grupos:

Autônomas

Ações reversíveis e de baixo impacto, como:

  • ler código;
  • analisar erros;
  • elaborar planos;
  • executar testes existentes;
  • propor patches.

Com aprovação humana

Ações como:

  • excluir arquivos;
  • alterar dependências;
  • modificar produção;
  • fazer deploy;
  • publicar conteúdo;
  • alterar permissões;
  • executar operações destrutivas.

Fora de escopo

Quando a autoridade não está definida:

STATUS: BLOCKED
REASON: AUTHORITY_UNDEFINED
NEXT: REQUEST_HUMAN_APPROVAL
Enter fullscreen mode Exit fullscreen mode

2. Ações destrutivas precisam de um gate

Antes de uma ação difícil de reverter, o agente deve demonstrar quatro coisas:

  1. qual é o impacto;
  2. qual é o caminho de rollback;
  3. por que a ação é necessária;
  4. que recebeu aprovação humana explícita.

Sem esses quatro elementos, a execução para.

Isso é diferente de simplesmente pedir “tenha cuidado”.

O gate transforma cuidado em uma condição verificável.

3. Rollback vem antes da mudança

Uma mudança segura não começa pelo patch.

Ela começa respondendo:

“Como voltamos ao estado anterior se isso der errado?”

Dependendo do projeto, rollback pode significar:

  • branch;
  • commit;
  • snapshot;
  • backup;
  • arquivo de configuração anterior;
  • migration reversível;
  • feature flag.

Se não existe rollback e o impacto é relevante, o risco precisa subir de nível antes da execução.

4. “Concluído” exige evidência

Um dos erros mais comuns em fluxos com agentes é transformar ausência de erro visível em sucesso.

Uma regra simples:

UNKNOWN != PASS
Enter fullscreen mode Exit fullscreen mode

O agente só deve declarar uma alteração como concluída quando houver evidência observável.

Por exemplo:

CLAIM: bug corrigido
EVIDENCE: teste X passou + reprodução original não ocorre
RESULT: PASS
LIMITATIONS: não validado em produção
Enter fullscreen mode Exit fullscreen mode

Isso força a separação entre:

  • implementação;
  • validação;
  • declaração de sucesso.

5. Use um ciclo previsível

Um fluxo pequeno já ajuda bastante:

PLAN → IMPLEMENT → VALIDATE → RELEASE
Enter fullscreen mode Exit fullscreen mode

PLAN define escopo, autoridade e risco.

IMPLEMENT executa apenas o que foi autorizado.

VALIDATE procura evidência e regressões.

RELEASE só ocorre quando os gates relevantes foram satisfeitos.

Starter gratuito

Preparei um starter PT-BR com quatro arquivos pequenos:

  • AGENT_AUTHORITY_POLICY.md
  • HUMAN_APPROVAL_GATES.md
  • PRE_CHANGE_CHECKLIST.md
  • EVIDENCE_BEFORE_CLAIMS_MINI.md

Repositório gratuito:

https://github.com/werisonkusanagi-collab/safe-ai-coding-governance-starter-ptbr

Kit completo

Para quem precisa de uma estrutura reutilizável mais ampla, o Kit de Codificação Segura com IA — Governança de Agentes inclui:

  • manual completo;
  • guia rápido;
  • policies;
  • templates;
  • workflows;
  • checklists;
  • exemplos;
  • AGENTS.md;
  • CLAUDE.md;
  • rollback;
  • regression validation;
  • multi-agent review.

Página do produto:

https://kit-codificacao-segura-ia-governanca.lovable.app

Preço atual: R$ 39,90 — pagamento único.

Este material é uma camada de governança operacional. Ele não substitui permissões, sandboxing, backups, branch protection, gestão de credenciais, testes ou revisão técnica adequados ao risco do ambiente.

Top comments (0)