Melhores Práticas de Segurança Claude Code para Equipes em 2026

Última atualização: June 28, 2026

Um agente de codificação AI que pode ler seu repo, executar comandos shell e chamar serviços externos é útil exatamente porque tem alcance. Esse mesmo alcance é o risco. Um prompt lido incorretamente, uma allowlist desleixada ou um servidor MCP não confiável podem vazar um token ou apagar um branch. Este guia é para o desenvolvedor ou líder de plataforma que deseja usar Claude Code no trabalho diário e em CI sem entregar as chaves da produção.

Resposta rápida: como as equipes mantêm o Claude Code seguro?

Execute o agente com o menor privilégio possível e revise o que ele faz. Na prática, isso significa cinco coisas:

• Comece em um modo de permissão restritivo e conceda ferramentas através de uma allowlist estreita, não um "sempre permitir" abrangente.
• Mantenha segredos fora do contexto do modelo: sem chaves coladas e uma regra deny para .env e caminhos de segredo.
• Verifique cada servidor MCP antes de conectá-lo, já que um servidor não confiável pode ler dados e agir em seu nome.
• Trate o conteúdo web recuperado como entrada não confiável que pode carregar instruções de prompt-injection.
• Em CI, forneça ao agente um token de escopo de leitura e vida curta e nunca exponha credenciais de produção.

O restante deste artigo transforma cada uma dessas regras em configurações concretas, com uma tabela de riscos, uma referência de permissões e um cenário de CI que você pode copiar.

Como os modos de permissão e allowlists realmente funcionam?

Claude Code pergunta antes de executar uma ferramenta pela primeira vez. Você decide se essa decisão deve ser lembrada, limitada ou ignorada. O modo de permissão define a linha de base:

• default solicita em uso inicial de cada ferramenta ou comando.
• plan é somente leitura: o agente pode ler arquivos e propor um plano, mas não pode editar ou executar comandos. Use para revisão.
• acceptEdits aceita automaticamente edições de arquivo, mas ainda solicita comandos shell.
• bypassPermissions ignora todos os prompts. Trate como sandbox apenas.

Os controles duráveis residem em .claude/settings.json sob permissions, com regras allow, ask e deny. As regras são limitadas por ferramenta e padrão, então você concede exatamente o que uma tarefa precisa:

{
  "permissions": {
    "allow": ["Read", "Edit", "Bash(npm test:*)", "Bash(git diff:*)"],
    "ask": ["Bash(git push:*)", "WebFetch"],
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(curl:*)", "Bash(rm -rf:*)"]
  }
}

Uma regra deny sempre vence sobre allow, razão pela qual os caminhos de segredo acima permanecem ilegíveis mesmo que uma regra ampla Read exista. A Anthropic documenta a sintaxe completa das regras e precedência na documentação de identidade e gerenciamento de acesso do Claude Code.

Evite --dangerously-skip-permissions fora de um container descartável. Ele remove o único ponto de verificação humana que captura um rm ruim ou uma chamada de rede inesperada. Se você deseja velocidade sem esse risco, prefira uma allowlist apertada para que comandos rotineiros sejam executados sem intervenção, enquanto qualquer coisa nova ainda pause para você.

Referência de Risco e Mitigação

A maioria dos incidentes rastreia até um punhado de padrões. Mapeie cada um a um controle antes de escalar o agente em uma equipe.

A estrutura aqui segue o OWASP Top 10 for LLM Applications, que aponta prompt injection, manuseio inseguro de saída e agência excessiva como os principais riscos do agente.

Referência de Permissões e Escopo

Esta tabela é a folha de cola que eu dou aos novos membros da equipe. Ela cobre as configurações que alteram o raio de explosão de uma única execução.

Verificando servidores MCP antes de conectá-los

Os servidores MCP estendem o agente com novas ferramentas: um cliente de banco de dados, uma integração de tickets, um navegador. Cada um que você adiciona é código que pode ler contexto e realizar ações. Um servidor não confiável é a maneira mais rápida de transformar um agente útil em um caminho de exfiltração de dados, então a barra para conectá-lo deve ser a mesma barra que você aplicaria a qualquer dependência com acesso à rede.

Antes de adicionar um servidor, responda a cinco perguntas:

1. Quem o publica e se a fonte é pública e mantida?
2. Que escopos ele solicita: somente leitura, ou escrita e rede?
3. Que dados ele pode ver depois de conectado: apenas este repo, ou toda a sua máquina?
4. As credenciais são limitadas em escopo e vida curta, ou é um token admin de longa duração?
5. Você pode fixar uma versão para que uma atualização automática não possa ampliar silenciosamente seu acesso?

Conecte servidores com o menor escopo que realiza o trabalho, e mantenha servidores capazes de escrita ou voltados para produção fora de configs compartilhadas ou CI. Para mecânicas de configuração e um guia mais profundo, veja nosso guia de integração Claude Code MCP. O post Dicas de produtividade do Claude Code cobre como manter essa pegada pequena sem desacelerar você.

Mantendo segredos fora do alcance do modelo

O segredo mais limpo é aquele que o modelo nunca vê. Não cole chaves API no prompt e não peça ao agente para "ler a chave da configuração e usá-la". Deixe as credenciais vivas no ambiente e faça referência a elas por nome para que o valor permaneça fora da transcrição.

Três hábitos cobrem a maior parte do risco:

• Adicione uma regra deny para .env, *.pem e qualquer diretório secrets/ para que o agente não possa lê-los nem por acidente.
• Use um scanner de segredos pre-commit (como gitleaks ou git secrets) para que uma chave vazada falhe no commit, e não na auditoria.
• Rotacione imediatamente qualquer coisa que seja exposta, depois verifique os logs e o histórico. A rotação é o único conserto que realmente fecha a janela.

Se uma chave já chegou a uma transcrição ou um commit, assuma que está comprometida e rotacione-a. Pesquisar o histórico git com git log -S ajuda você a encontrar onde ela pousou.

Cenário: habilitando Claude Code em CI sem credenciais de produção

Uma equipe deseja que o Claude Code revise pull requests no GitHub Actions. O objetivo é comentários de revisão automatizados, com zero capacidade de implantar, escrever em main ou tocar no banco de dados de produção.

Aqui está a configuração que mantém o trabalho útil, mas contido:

• Execute sem cabeça com claude -p em modo plan para que o agente leia o diff e escreva um comentário, mas nunca edite arquivos ou execute comandos de build.
• Conceda apenas contents: read e pull-requests: write. Sem job de deploy, sem escopo de infraestrutura.
• Use o GITHUB_TOKEN de vida curta do job, não um token pessoal, e nunca coloque chaves de produção de banco de dados ou nuvem no ambiente desse job.
• Adicione uma lista deny para caminhos de segredo e curl de saída, para que uma tentativa de prompt-injection dentro do diff do PR não possa exfiltrar nada.
• Fixe a versão da ação e do Claude Code, e proteja qualquer passo de deploy atrás de um ambiente separado e aprovado por humanos.

permissions:
  contents: read
  pull-requests: write
steps:
  - run: claude -p "Review the diff for security issues" --permission-mode plan
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

O job de revisão vê o código e publica feedback. Ele não pode alcançar a produção porque as credenciais de produção nunca estão no escopo. O visão geral de segurança do Claude Code da Anthropic descreve essa postura de menor privilégio para execuções automatizadas e sem cabeça.

O que você nunca deve colar em um agente de codificação AI?

Algumas entradas não pertencem perto de uma transcrição, porque qualquer coisa no contexto pode ser ecoada, registrada ou agida:

• Chaves API ativas, URLs de banco de dados com senhas ou credenciais raiz da nuvem.
• PII do cliente ou dados regulamentados que você não colocaria em um ticket de suporte.
• Chaves privadas de assinatura, certificados ou arquivos .pem.
• Strings de conexão completas de produção quando uma réplica de leitura ou fixture local seria suficiente.

Quando o agente precisar de acesso, forneça um caminho para uma credencial limitada em escopo através do ambiente em vez do segredo em si. Mesmo resultado, raio de explosão muito menor.

Auditoria, hooks e revisão contínua

O menor privilégio define o piso; a revisão o mantém lá. Leia o plano do agente antes de aprovar um passo arriscado, e leia o diff antes de commitar. Para mudanças maiores, a mesma disciplina que torna refatoração assistida por IA segura se aplica aqui: passos pequenos e revisáveis superam uma única execução gigante sem supervisão.

Adicione guardrails determinísticos com hooks. Um hook PreToolUse pode inspecionar um comando e bloqueá-lo antes que ele execute, que é como você força regras que o modelo nunca deve anular, como recusar qualquer escrita em um caminho protegido. Combine isso com um rastro de auditoria para que você possa responder o que o agente fez, quando e em nome de quem.

Uma lista de verificação rápida recorrente para a equipe:

• Revisar as listas allow e deny de .claude/settings.json em um cronograma, não apenas na configuração inicial.
• Re-verificar servidores MCP após grandes atualizações de versão.
• Confirmar se os jobs de CI ainda rodam em modo plan e não carregam segredos de produção.
• Rotacionar tokens em uma cadência e após qualquer exposição suspeita.
• Manter um CLAUDE.md que declare o inegociável: sem force-push para main, sem acesso direto ao DB de prod, sem segredos nos prompts.

Para o fluxo de trabalho mais amplo sobre tudo isso, o guia definitivo do Claude Code percorre a configuração de ponta a ponta.

Conclusão principal

A segurança para agentes de codificação AI é o mesmo pensamento de menor privilégio que você já aplica a contas de serviço, escrito como regras de permissão. Comece restritivo, expanda com uma allowlist estreita, negue caminhos de segredo, verifique servidores MCP como dependências, trate conteúdo recuperado como não confiável e mantenha credenciais de produção fora de qualquer job que o agente possa alcançar. Faça isso e Claude Code permanece um par rápido de mãos, e não uma porta aberta.