O artigo nada sexy. O que decide se Claude Code vira infraestrutura ou vira a história que você conta no postmortem.

Aqui está a regra em torno da qual você constrói tudo o mais:

Essa única regra esclarece 90% das decisões de permissão. Tudo o mais é operacionalizá-la.

Reversibilidade, não "medo"

A maioria dos times configura allowlists no feeling. "Testes parecem seguros; deletes assustam." Errado.

Reformule em torno do blast radius:

• Reversível: editar arquivo na working tree, rodar testes, rodar pnpm install, criar feature branch. Se algo quebra, git checkout/git stash te salva.
• Irreversível: git push, npm publish, migrações de DB em prod, terraform apply, enviar e-mails, cobrar cartão, deletar recursos cloud.

A primeira lista deve estar na allowlist do agente. A segunda deve exigir uma tecla humana toda vez, sem exceção.

O .claude/settings.json mínimo para repo de produção

{
  "tools": {
    "shell": {
      "allow": [
        "pnpm test",
        "pnpm test:watch",
        "pnpm lint",
        "pnpm build",
        "pnpm db:migrate:dev",
        "pnpm db:reset:dev",
        "pnpm install",
        "git status",
        "git diff *",
        "git log *",
        "git stash *",
        "git checkout *",
        "git branch",
        "git add *",
        "git commit *",
        "ls *",
        "rg *",
        "cat *"
      ],
      "deny": [
        "git push *",
        "git rebase *",
        "git reset --hard *",
        "rm -rf *",
        "npm publish *",
        "pnpm publish *",
        "docker push *",
        "kubectl apply *",
        "terraform apply *",
        "aws *",
        "gcloud *",
        "psql -h prod*"
      ]
    }
  }
}

Algumas coisas a notar:

• git commit é permitido; git push não. O agente pode preparar a mudança local; você publica.
• pnpm db:migrate:dev é permitido; a variante prod não — e migrações de prod não deveriam rodar de máquina de dev de qualquer jeito.
• aws * e gcloud * são negados por completo. Se você precisa de um sub-agente que chame APIs cloud, dê a ele um comando específico, não a CLI inteira.

A lista "arquivos que o agente nunca deve mexer"

Mesmo confiando no agente, alguns arquivos devem exigir edição humana. Trave eles em CLAUDE.md:

# Nunca modificar
- /infra/terraform/   (só humanos)
- /.github/workflows/release.yml
- O campo "version" de /package.json
- Qualquer arquivo em /db/migrations/ já aplicado
- /SECURITY.md

Claude Code respeita com força as instruções do CLAUDE.md. Combinado com a revisão do git diff, isso basta para 99% dos times.

Separação de papéis dos sub-agentes = defesa em profundidade real

Cobrimos os 11 sub-agentes no artigo 5. Por que separação de papéis importa para segurança:

• code-reviewer não pode editar. Mesmo que "decida" que está tudo bem, não consegue subir.
• test-writer não pode mexer em código de produção. Teste falhando é evidência real, não saída flaky.
• migration-runner só pode rodar pnpm db:migrate. Mesmo comprometido, o blast radius é um único comando.

Isso é defesa em profundidade real — construída com arquivos de restrição, não teatro de segurança.

Coisas que você não deveria automatizar

Lista curta de "não, mesmo que funcione":

• Postar em canais públicos (Slack, Discord, Twitter). Latência tudo bem; uma mensagem com tom errado no #engineering, não.
• E-mails para clientes. Conteúdo gerado, ok em rascunho. Envio é humano.
• Dinheiro. Cobranças, reembolsos, repasses. Não automatize. Nunca.
• Auth e identidade. Adicionar usuário, conceder admin, rotacionar chave.
• Force pushes. Mesmo em branches de feature. O custo de um force-push acidental é alto demais.

Regra de bolso: se o pior cenário é um postmortem, um e-mail de desculpas ou uma carta de regulador, mantenha uma tecla humana entre intenção e execução.

Trilha de auditoria — a feature subestimada

Toda sessão do Claude Code escreve um transcript em ~/.claude/sessions/. Num time, mande esses transcripts para algum lugar durável:

• Um bucket S3 privado.
• Um stream de logs no Datadog.
• Um simples git log de .claude/transcripts/ comitado no repo.

Você não vai ler com frequência. Mas no dia em que ler — quando algo estranho aconteceu no codebase e você precisa saber quem/o que mudou — vale ouro.

Checklist prático de segurança

Antes de deixar Claude Code rodar num codebase real:

• .claude/settings.json com allow e deny explícitos.
• CLAUDE.md com seção "Nunca modificar".
• .claude/agents/ inclui no mínimo code-reviewer e test-writer.
• git push não está em allowlist alguma.
• Um colega revisou a allowlist.
• Você rodou claude --dry-run (ou equivalente na sua versão) numa feature branch primeiro.

Seis itens. Vinte minutos de trabalho. A maioria dos incidentes de produção vem de pular pelo menos três.

---

Próximo artigo: Pipelines multi-agente — encadear sub-agentes, rodá-los em paralelo, e os padrões para "revisar-enquanto-codifica" sem perder a sanidade.