Por Que Seu Assistente de IA para Código É uma Brecha de Segurança (e Como Resolver)

Semana passada, descobri que deixava uma IA rodar comandos livres no meu computador há meses. Ela acessava credenciais do AWS, chaves SSH, repositórios privados do GitHub e tudo mais no meu diretório home. O pior? Nem passei pela cabeça o risco, só porque o ferramenta era prática e nada deu errado até então.

Esse é o raciocínio que apaga bancos de dados em produção.

A Facilidade Engana e Expõe

A verdade dura: a maioria das IAs para codificação tem acesso total, como se fosse um engenheiro sênior no primeiro dia. Ninguém daria SSH irrestrito a um contratado novo, mas entregamos isso a um LLM sem pestanejar.

Não é maldade. É descuido. Elas ajudam tanto que esquecemos o poder real. Um prompt malicioso em um repo clonado, um objetivo desalinhado ou um comando inocente podem vazar credenciais para um servidor inimigo. E você nem percebe.

Felizmente, ferramentas como Claude Code trazem controles de segurança sólidos. A maioria só ignora ativá-los.

O Perigo do Modo Padrão

Por padrão, muitas IAs rodam em modo "auto". Executam comandos sem perguntar, exceto o que está bloqueado explicitamente. Eficiente? Veja o que rola na prática:

Sem uma lista de bloqueios, a IA pode:

• Fazer curl para qualquer URL
• Baixar arquivos com wget
• Conectar via ssh em servidores remotos
• Abrir conexões com nc
• Ler todos os .env do projeto
• Acessar ~/.aws/credentials, ~/.ssh, ~/.gnupg
• Fazer push direto nos repositórios

Tudo quieto. Sem aviso. Sem pedir.

Um Modelo de Segurança em Três Camadas

Você precisa de controle fino. Nem tudo exige aprovação, mas ações críticas sim. Veja como estruturar:

Camada 1: Bloqueio Total

Comece negando acesso a credenciais:

{
  "deny": [
    "Read(~/.ssh/**)",
    "Read(~/.aws/**)",
    "Read(~/.gnupg/**)",
    "Read(~/.azure/**)",
    "Read(~/.kube/**)",
    "Read(~/.npmrc)",
    "Read(~/.git-credentials)",
    "Read(*.env)",
    "Read(.env.*)",
    "Bash(curl *)",
    "Bash(wget *)",
    "Bash(nc *)",
    "Bash(ssh *)"
  ]
}

É sua barreira inicial. Nada passa, ponto final. A ferramenta bloqueia no nível do sistema.

Camada 2: Ponto de Revisão

Peça aprovação para ações reversíveis, mas arriscadas:

{
  "ask": [
    "Bash(git push *)",
    "Bash(git commit *)",
    "Bash(git merge *)",
    "Bash(git reset *)",
    "Bash(npm publish *)",
    "Bash(docker push *)"
  ]
}

A IA pode precisar disso — push de código, publish de pacotes —, mas você aprova antes. Mantém a produtividade sem surpresas.

Camada 3: Via Livre

Libere o que é seguro:

{
  "allow": [
    "Bash(npm run *)",
    "Bash(git status *)",
    "Bash(git diff *)",
    "Bash(git log *)",
    "Bash(ls *)",
    "Read(src/**)",
    "Read(tests/**)"
  ]
}

Esses rodam sem parar. Não alteram nada crítico ou são inofensivos.

Escolhendo o Modo Padrão Certo

Com listas prontas, defina o comportamento geral. Três opções:

1. auto - Roda tudo não bloqueado em silêncio. Rápido, mas confie na sua lista de denies.

2. acceptEdits - Lê livremente, sugere mudanças, mas pede para comandos bash fora da allow. Equilibrado.

3. ask - Pergunta antes de qualquer risco. Mais lento, ideal para máxima cautela.

Para equipes, acceptEdits é o melhor. Produtivo e consciente.

Exemplo de Configuração Pronta para Produção

Aqui vai uma config real e segura:

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)",
      "Read(~/.azure/**)",
      "Read(~/.kube/**)",
      "Read(~/.npmrc)",
      "Read(~/.git-credentials)",
      "Read(~/.config/gh/**)",
      "Read(*.env)",
      "Read(.env.*)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(nc *)",
      "Bash(ssh *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(git commit *)",
      "Bash(npm publish *)",
      "Bash(docker push *)"
    ],
    "allow": [
      "Bash(npm run *)",
      "Bash(npm install *)",
      "Bash(npm test *)",
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "defaultMode": "acceptEdits"
  }
}

Dá liberdade para testes e análise de código, mas trava roubo de credenciais ou pushes sem ok.

Duas Abordagens para Contextos Diferentes

Uso aliases no shell:

# Padrão: segurança equilibrada
alias cc="claude --permission-mode auto"

# Modo debug: confiança total (raro)
alias ccd="claude --permission-mode dangerously-skip-permissions"

cc cobre 95% do dia a dia. ccd só em emergências, com decisão consciente.

O Problema Afeta Todo o Setor

Não é só Claude Code. Copilot, Devin, Cursor, ChatGPT com execução — todos têm essa exposição ao rodar shell. A vantagem? Claude oferece controles granulares. Outros forçam tudo ou nada.

Impacto na Sua Infraestrutura

Em times, isso vira obrigação. Desenvolvedores não pensam nisso até o desastre.

Faça:

• Exija deny lists em configs compartilhadas
• Bloqueie arquivos de credenciais no filesystem
• Use tokens temporários, não chaves eternas
• Controle rede contra vazamentos
• Treine o time sobre produtividade vs. risco

Resumo Final

Assistentes de IA para código valem ouro. Mas exigem configuração. Os controles estão aí — use-os.

Dedique 15 minutos agora. Monte deny para credenciais. Ask para deploys. Escolha um default sensato. Aí sim, relaxe com produtividade segura.

"Nada ruim rolou ainda" não é plano de segurança.