🔓 Permission modes
O Claude Code opera em diferentes modos de permissão que determinam o nível de autonomia do agente em cada sessão. Entender esses modos é fundamental para calibrar o equilíbrio entre velocidade e controle. Modo muito restritivo paralisa a produtividade; modo muito aberto cria riscos reais.
Os 4 modos principais
- Confirm (padrão) — toda ação de escrita, execução ou delete pede confirmação. Máximo controle.
- Auto-accept — ações pré-aprovadas na allowlist rodam sem confirmação. Equilíbrio produtividade/controle.
- Plan mode — agente planeja e lista todas as ações antes de executar qualquer uma. Bom para tarefas complexas.
- Bypass (--dangerously-skip-permissions) — sem confirmação alguma. Apenas em pipelines CI/CD controlados.
💡 Marco — estratégia prática
Marco usa confirm para tarefas novas e auto-accept para operações rotineiras (npm install, leitura de docs, edição em /src/). Plan mode para deploys e mudanças de schema. Bypass nunca em desenvolvimento local — só no CI do GitHub Actions.
⚙️ Allowlist e denylist
O settings.json é o arquivo de configuração central de permissões do Claude Code. Com ele, você define quais tools e comandos Bash o agente pode executar sem pedir confirmação — a allowlist — e quais estão explicitamente proibidos — a denylist. A granularidade é impressionante: você pode liberar npm run test mas proibir npm publish.
Exemplos de configuração
- // Allowlist — roda sem confirmação
- "Bash(npm run test)", "Bash(npm run lint)"
- "Read(src/**)", "Edit(src/**)", "Edit(docs/**)"
- // Denylist — nunca executa
- "Bash(npm publish)", "Bash(git push --force)"
- "Bash(rm -rf *)", "Edit(/secrets/**)"
Ergonomia vs segurança
O objetivo da allowlist é reduzir friction para operações seguras e repetitivas. Não é sobre dar liberdade ilimitada — é sobre não pedir confirmação para coisas que você já sabe que são seguras. A denylist é absoluta: essas ações nunca acontecem, independente do contexto.
🌐 Jurisdição de agente
Cada agente especializado tem um território — o conjunto de recursos que ele está autorizado a acessar e modificar. CFO Bot toca /finance/. CMO Bot toca /marketing/. Researcher Bot lê tudo mas escreve apenas em /research/. Essa separação não é só organização — é a definição formal de jurisdição que determina o raio de impacto de cada agente.
Jurisdição por especialidade — Marco
- Product Bot — lê/escreve /products/, /catalog/. Nunca toca /orders/ ou /payments/.
- Order Bot — lê/escreve /orders/. Lê (só) /products/. Nunca acessa /customers/ PII.
- Analytics Bot — lê tudo em modo read-only. Escreve apenas em /reports/.
- Support Bot — lê /orders/, /customers/ (com PII). Nunca modifica orders sem aprovação.
- Dev Bot — acesso completo a /src/, /tests/. Zero acesso a /data/ de produção.
💡 Jurisdição como contrato
A jurisdição não é só restrição — é também clareza. Quando o CFO Bot sabe que seu território é /finance/, ele pode operar com confiança total nesse domínio. E você sabe exatamente o que pode acontecer de errado. Jurisdição clara = blast radius previsível.
🤚 Aprovação humana obrigatória
O conceito de "jagged intelligence" (Brynjolfsson & McAfee) descreve como a IA é brilhante em muitas coisas e surpreendentemente fraca em outras — e você não sabe onde está o buraco até cair. Para ações de alto impacto ou irreversíveis, aprovação humana não é opcional. É a única forma de garantir que erros sejam detectados antes de se tornarem catástrofes.
🚨 Ações que sempre precisam de aprovação
- •Pagamentos e transferências — qualquer valor acima de threshold definido.
- •Deletes irreversíveis — arquivos, registros de banco, assets de produção.
- •Comunicações externas — emails para clientes, posts em redes sociais, webhooks.
- •Force pushes e merges em main — alterações diretas em produção.
- •Alterações de permissão — mudanças no próprio settings.json ou CLAUDE.md.
Implementação prática
Configure hooks no settings.json que interceptam ações de alto risco e exigem uma string específica de confirmação antes de prosseguir. O agente pode preparar tudo, mas a execução só acontece após o humano digitar "CONFIRMO: [ação específica]".
🚪 Sandboxing
O sandboxing é a técnica de isolar o agente em um ambiente controlado onde os erros ficam contidos e o rollback é trivial. No contexto do Claude Code, as principais estratégias de sandbox são git worktrees (branch isolado do trabalho), containers Docker e ambientes efêmeros de staging. Em todos os casos, o princípio é o mesmo: agente opera em cópia, não no original.
Estratégias de sandbox
- Git worktree — agente trabalha em branch separado. Main não é afetado até o PR ser aprovado.
- Docker container — ambiente isolado com acesso apenas ao que você montou. Descartável.
- Staging environment — agente opera em ambiente de teste com dados anonimizados.
- Read-only mounts — dados de produção montados como read-only; agente lê mas não escreve.
💡 Worktree como sandbox padrão
Para desenvolvimento, git worktree é a forma mais simples de sandbox. O agente cria uma branch, trabalha nela, você revisa o diff e faz merge se aprovado. Se algo der errado, você deleta a branch. Zero impacto em produção. A skill superpowers:using-git-worktrees automatiza esse fluxo.
📜 Princípio do menor privilégio
O least privilege é o princípio de segurança mais antigo e mais confiável: todo agente começa sem permissão alguma e você libera apenas o que é estritamente necessário para a tarefa. É o oposto do "vou dar tudo e depois restrinjo" — que na prática nunca acontece. Começar restrito e abrir gradualmente é mais seguro, mais rastreável e mais fácil de auditar.
✗ Anti-padrão comum
- ✗Dar permissão total no início para "facilitar"
- ✗Nunca revisar permissões depois que "funcionou"
- ✗Um agente com acesso a todos os sistemas
- ✗Bypass mode como padrão de desenvolvimento
✓ Padrão correto
- ✓Começa com deny-by-default
- ✓Libera permissão quando a tarefa exige
- ✓Revoga após tarefa concluída
- ✓Audita permissões periodicamente
Gradual unlock — o processo correto
1. Identifique exatamente o que a tarefa precisa. 2. Adicione só essa permissão na allowlist. 3. Execute. 4. Se tudo correu bem, mantenha. 5. Trimestralmente, revise permissões acumuladas e remova o que não é mais usado. Permissões não usadas são risco sem benefício.
📋 Resumo do Módulo
Próximo Módulo:
2.5 — Governança como first-class citizen