Segurança

Um agente que lê seus arquivos, executa comandos e modifica código no seu sistema é uma faca de dois gumes. Bem usado, multiplica produtividade. Mal usado, ou comprometido por prompt injection, vira vetor de incidente. O Claude Code traz guardrails padrão, mas a responsabilidade de configurar permission modes, sandboxing e proteções segue sendo do desenvolvedor.

Os Riscos

1. Prompt Injection

Qualquer conteúdo externo (issues do GitHub, código de terceiros, output de comando, página web fetchada) pode conter instruções maliciosas tentando manipular o agente.

2. Exfiltração de Dados

Agente comprometido pode tentar mandar secrets, código proprietário ou dados sensíveis pra fora.

3. Modificação Não Autorizada

Agente edita arquivo crítico de configuração, deleta dados, modifica deploy, faz commit não-autorizado.

4. Execução de Comandos Maliciosos

rm -rf, curl | bash de URL não confiável, escalação de privilégios.

Permission Modes

A primeira linha de defesa. Trocadas em tempo real com Shift+Tab:

Modo	Comportamento
default	Pede aprovação pra ações que modificam o sistema
acceptEdits	Aceita edits sem perguntar, ainda pede pra Bash
plan	Plan mode: só lê e analisa, não modifica nada
auto	Classificador IA decide (bloqueia escalação, infra desconhecida)
dontAsk	Não pede aprovação, mas respeita allowlists/denylists
bypassPermissions	Pula tudo (use com cuidado extremo)

bypassPermissions

Vulgo "yolo mode". Pula todos os checks de segurança. Útil em sandbox isolado (container, VM, worktree). Nunca em diretório com código de produção, credenciais reais, ou no seu home.

Auto Mode

Modelo classificador separado revisa cada comando antes de rodar. Bloqueia o que parece arriscado: escalação de escopo, infra desconhecida, ações dirigidas por conteúdo hostil. Bom equilíbrio quando você confia na direção geral mas não quer clicar em todo prompt.

Permission Rules

/permissions ou settings configuram allowlist e denylist:

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm test)",
      "Bash(git status)",
      "Bash(git log *)",
      "Bash(git diff *)",
      "Read",
      "Glob",
      "Grep"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl * | bash)",
      "Edit(.env*)",
      "Edit(**/secrets/**)"
    ]
  }
}

Allowlist permite comando rodar sem prompt. Denylist bloqueia mesmo se o usuário aprovaria.

Sandboxing

/sandbox ou sandbox.enabled: true ativa isolamento OS-level: restringe filesystem e rede, deixando o Claude trabalhar mais livre dentro de limites definidos.

{
  "sandbox": {
    "enabled": true
  }
}

Em sandbox, mesmo se o agente tentasse algo malicioso (ou foi induzido por prompt injection), o impacto fica contido.

.cursorignore Equivalente

Pra Claude Code, controle de acesso a arquivos sensíveis vai via permission rules:

{
  "permissions": {
    "deny": [
      "Read(.env*)",
      "Read(**/secrets/**)",
      "Read(**/*.key)",
      "Read(**/*.pem)",
      "Read(**/credentials/**)",
      "Edit(.env*)",
      "Edit(**/secrets/**)"
    ]
  }
}

Arquivos que você nunca quer que o Claude leia ou edite:

• .env* com variáveis sensíveis
• Chaves privadas (*.key, *.pem)
• Credenciais e tokens
• Arquivos de banco com dados reais
• PII (informação pessoal identificável)

Sandbox via Worktree

Pra trabalho experimental ou tarefas em paralelo, use worktree isolado:

claude -w feature-auth
# Cria worktree em <repo>/.claude/worktrees/feature-auth

Cada worktree é uma cópia independente do repo. Trabalho experimental do Claude fica isolado da sua branch principal.

Hooks pra Defesa em Profundidade

Hooks como camada determinística de proteção:

Bloquear rm -rf

#!/bin/bash
COMMAND=$(jq -r '.tool_input.command')

if echo "$COMMAND" | grep -qE 'rm -rf|rm -fr'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "rm -rf bloqueado por política"
    }
  }'
else
  exit 0
fi

Bloquear edição em paths protegidos

#!/bin/bash
FILE=$(jq -r '.tool_input.file_path')

if [[ "$FILE" =~ \.env|secrets/|credentials/ ]]; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Arquivo protegido"
    }
  }'
else
  exit 0
fi

Audit log de comandos sensíveis

#!/bin/bash
COMMAND=$(jq -r '.tool_input.command')
echo "$(date -Iseconds) $USER $COMMAND" >> ~/.claude/audit.log
exit 0

Network e Web Requests

O Claude Code restringe requisições de rede arbitrárias por padrão. Tools fazem requisições só pra:

• GitHub (integrações com repo)
• Direct link retrieval
• Web search providers

Isso protege contra:

• Exfiltração de dados pra APIs não autorizadas
• Vazamento de secrets pra servidores controlados por atacante
• Comunicação com infra suspeita

WebFetch e WebSearch passam pelo permission system. Domínios frequentes podem ir pra allowlist via /permissions.

MCP: Atenção Redobrada

Servidores MCP podem ter qualquer comportamento. Cada nova conexão precisa de aprovação explícita, e cada chamada de tool MCP também passa pelo permission system.

Boas práticas com MCP

• Aprove só conexões de fontes confiáveis (oficial Anthropic, comunidades reconhecidas, código que você revisou)
• Revise código de servidores MCP terceiros antes de instalar
• Monitore comportamento via /mcp
• Em ambientes sensíveis, prefira CLIs (gh, aws, etc) sobre MCP custom

Hook pra audit MCP

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "mcp__.*",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"$(date -Iseconds) MCP call\" >> ~/.claude/mcp-audit.log"
          }
        ]
      }
    ]
  }
}

Managed Settings (Organização)

Pra times e empresas, settings managed forçam configurações que usuários não conseguem desabilitar:

Concern	Onde configurar
Bloquear tools, comandos, paths específicos	permissions.deny
Forçar sandbox isolation	sandbox.enabled
Env vars e API provider	env
Método de autenticação e org lock	forceLoginMethod, forceLoginOrgUUID
Guidelines de código e qualidade	Managed CLAUDE.md
Reminders de compliance	Managed CLAUDE.md

Settings são enforcement técnico. CLAUDE.md é guidance comportamental (sugestiva). Use settings managed pro que precisa de garantia.

Distribua via MDM, Group Policy, Ansible.

Workspace Trust

Pra repos não confiáveis, o ideal é não rodar Claude Code interativo neles. Se precisar revisar código de fonte desconhecida, faça em ambiente isolado:

• Container Docker descartável
• VM dedicada
• Worktree isolado com sandbox ativo
• Web environment (claude.ai/code rodando em VM da Anthropic)

Long-lived Tokens

Pra scripts e CI:

claude setup-token

Gera token OAuth de longa duração. Trate como secret:

• Nunca commite no git
• Use secret manager (GitHub Secrets, AWS Secrets Manager, Vault)
• Rotacione periodicamente
• Revogue imediatamente se vazar

Best Practices

Sempre revise comandos sensíveis

Auto-aprovar tudo é cômodo até dar ruim. Quando o Claude pede pra rodar algo destrutivo, leia. Você é a última linha de defesa.

Use git como rede de segurança

Commits frequentes. Branch isolado pra trabalho experimental. git stash antes de mudanças arriscadas. Checkpoints do Claude não substituem git.

.claude/settings.local.json pra preferências individuais

Configurações sensíveis (allowlists pessoais, paths que você libera só na sua máquina) ficam aqui. Não vão pro git.

.gitignore rigoroso

Garanta que .env, secrets, credenciais e o próprio CLAUDE.local.md estão no .gitignore. Se o Claude (mesmo correto) commitar um secret junto com outras mudanças, isso vira incidente.

Audit periódico

Revise periodicamente:

• Hooks configurados (/hooks)
• MCP servers ativos (/mcp)
• Skills e commands (/agents)
• Settings managed que mudaram

Pra organizações

• Settings managed pra políticas obrigatórias
• Workspace dedicado no Claude Console pra cost tracking centralizado
• Rate limits per-user adequados ao tamanho do time
• Audit logs centralizados via hooks

Reportando Vulnerabilidades

Encontrou uma vulnerabilidade? Reporte pra Anthropic via canais oficiais. A documentação tem o processo formal de responsible disclosure.

Checklist de Segurança

Antes de usar Claude Code em produção:

• Permission rules configuradas (allow/deny)
• Sandbox habilitado se aplicável
• Hooks de audit log para comandos sensíveis
• .gitignore cobrindo .env, secrets, CLAUDE.local.md
• Permission rules bloqueando leitura/edição de arquivos sensíveis
• Git em dia, commits frequentes
• MCP servers revisados e aprovados conscientemente
• Settings managed (se org) com políticas críticas
• Tokens de longa duração armazenados em secret manager
• Auto mode ou permission rules pra reduzir auto-aprovação inconsciente

Conclusão

Segurança no Claude Code é defesa em camadas:

1. Permission modes controlam o nível geral de aprovação
2. Permission rules definem allow/deny granular
3. Hooks garantem checks determinísticos
4. Sandbox isola filesystem e rede
5. Settings managed forçam políticas em time
6. Git e backups são a rede final

Cada camada tem custo (latência, prompts adicionais, complexidade). O ponto certo depende do contexto: trabalho exploratório em projeto pessoal vs deploy em sistema crítico de produção têm regimes diferentes. O importante é configurar conscientemente, não acabar em bypassPermissions por preguiça e descobrir o problema depois.

---

Próximo: Recursos e Próximos Passos

Referências:

• Permissions
• Permission Modes
• Sandboxing
• Settings