Guia de segurança do Claude Code: permissões, MCP, sandboxing

Chatbots tradicionais ficam atrás de uma API, então o pior que podem fazer é alucinar. Já um agente de codificação em IA entra no seu repositório, no seu terminal e (muitas vezes) nas suas credenciais de cloud, ficando muito mais perto de ambientes privilegiados de desenvolvedor do que qualquer coisa que costumávamos chamar de chatbot.

A questão é: como usar o Claude Code com segurança sem perder velocidade? Com as permissões certas, controles MCP e sandboxing ajustados no ponto, você chega lá.

Neste artigo, vou explicar como o modelo de segurança do Claude Code realmente funciona, onde você precisa prestar atenção e as práticas que mantêm tudo útil sem dar mais acesso do que você pretendia.

Se você é totalmente novo em Claude e Claude Code, inscreva-se no nosso curso gratuito Claude Code 101 para aprender o básico em uma tarde.

Entendendo o modelo de segurança do Claude Code

Antes de ajustar qualquer regra, é importante ter um modelo mental do que o Claude Code realmente controla.

São cinco partes móveis: um sistema de permissões que decide o que é permitido, controles de acesso a ferramentas que delimitam capacidades individuais, permissões MCP para integrações externas, sandboxing para isolamento em nível de SO e auditabilidade para revisão posterior. Cada uma resolve um problema diferente, mas elas se somam.

Sistema de permissões

O sistema de permissões é a camada estática.

Você declara o que o Claude pode fazer em settings.json, usando três listas: allow, ask e deny. As regras são avaliadas primeiro o deny, depois ask e por fim allow, e a primeira correspondência vence. Uma regra de deny bloqueia a chamada mesmo que uma regra allow mais ampla também a contemplasse.

Se nenhuma regra corresponder, o Claude volta ao defaultMode da sessão (falamos dos modos na próxima seção).

Controles de acesso a ferramentas

As permissões se aplicam às ferramentas, não ao agente como um todo.

O Claude Code tem seu próprio conjunto de ferramentas nativas, por exemplo Bash para comandos de shell, Read, Edit e Write para operações no sistema de arquivos, WebFetch para requisições HTTPS, WebSearch para buscas, entre outras. Cada regra nomeia uma ferramenta e (opcionalmente) um especificador entre parênteses, como Bash(git commit:*) ou Read(./.env).

É assim que o princípio do menor privilégio funciona. Você pode permitir Bash(npm run:*) para testes sem dar ao Claude acesso total ao shell.

Permissões MCP

Servidores MCP estendem o Claude Code com ferramentas para as quais ele não foi originalmente projetado.

Cada servidor traz seu próprio conjunto de ferramentas (um servidor GitHub adiciona ferramentas de pull request, um servidor de banco de dados adiciona ferramentas de consulta e assim por diante). O sistema de permissões também os cobre, mas com outra sintaxe — as regras usam o formato mcp__servername__toolname em vez do especificador entre parênteses.

O ponto aqui é que o MCP praticamente dobra a pergunta, porque você não está só decidindo o que o Claude pode fazer no seu shell, e sim o que ele pode fazer em cada sistema externo conectado a ele.

Sandboxing

Sandboxing é a proteção em nível de sistema operacional por baixo da ferramenta Bash.

As regras de permissão dizem ao Claude o que ele deve fazer. O sandboxing reforça o que ele pode fazer, restringindo o acesso ao sistema de arquivos e as chamadas de rede de saída no nível do SO. No macOS funciona nativamente via Seatbelt. No Linux e WSL2, é preciso instalar bubblewrap e socat antes.

As duas camadas funcionam de forma semelhante, mas cobrem cenários diferentes. As permissões impedem o Claude de tentar algo, e o sandboxing impede a tentativa de ter sucesso caso uma injeção de prompt convença o Claude a tentar mesmo assim.

Auditabilidade

A última peça é conseguir ver o que aconteceu.

O comando /permissions lista todas as regras ativas e o arquivo de configuração de onde cada uma veio, para você responder "por que o Claude executou isso?". Hooks (PreToolUse, PostToolUse e outros) permitem registrar cada chamada de ferramenta no seu próprio sistema. Para times, exportadores OpenTelemetry enviam dados de uso e de chamadas de ferramentas para o stack de observabilidade que você já usa.

Permissões e controle de acesso no Claude Code

A maior parte da segurança vem das configurações de permissão, então é aqui que você vai investir mais tempo ajustando.

Acesso a arquivos

Por padrão, o Claude pode ler e editar arquivos no diretório de onde você o iniciou.

A leitura é controlada pela ferramenta Read, e a edição por Edit e Write. Cada uma aceita um padrão de caminho entre parênteses, usando a sintaxe do gitignore. Por exemplo, Read(**/.env) corresponde a todo arquivo .env em qualquer profundidade, e Edit(src/**) corresponde a tudo dentro de src/.

Um deny em Read cobre as ferramentas de arquivo do próprio Claude Code (Read, Grep, Glob, LS), mas é só uma melhor tentativa. Um script Python ou Node executado via Bash ainda pode abrir o arquivo, porque essa leitura ocorre pelo shell e não pela ferramenta Read do Claude. Se um segredo é crítico, combine o deny de Read com um deny de Bash para cat, head e tail nesses caminhos.

Para estender o acesso além do diretório de trabalho, use additionalDirectories em settings.json. Assim você dá ao Claude acesso a uma biblioteca compartilhada fora do seu repo ou a um arquivo de configuração no seu diretório home, sem derrubar totalmente a barreira do diretório de trabalho.

Execução de comandos

A ferramenta Bash é a que você precisa delimitar com mais cuidado.

Uma regra Bash sem escopo permite todos os comandos. Uma regra como Bash(npm run:*) permite apenas invocações correspondentes. O padrão dois-pontos-asterisco é o que você deve usar aqui, e o Claude Code entende operadores de shell, então uma regra como Bash(safe-cmd:*) não corresponde a safe-cmd && rm -rf /.

Alguns comandos rodam sem prompt em qualquer modo, pois são tratados como somente leitura por padrão. A lista inclui ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd e formas somente leitura do git. Você não pode reduzir essa lista manualmente, mas pode adicionar uma regra ask ou deny para qualquer um deles e sobrescrever o padrão.

Para tudo o que não é pré-aprovado, o Claude pede confirmação no modo padrão. O prompt mostra o comando exato e permite aprová-lo uma vez, aprovar todas as chamadas futuras que coincidirem com um padrão ou negar.

Modos de permissão

As regras de permissão são estáticas, mas os modos de permissão mudam o comportamento de chamadas sem correspondência.

Existem cinco:

• default: pede no primeiro uso de cada ferramenta.

• acceptEdits: aprova automaticamente edições de arquivos no diretório de trabalho e ainda controla comandos de shell. Útil quando você confia nas edições, mas não no shell.

• plan: o Claude lê e analisa, mas não pode editar arquivos nem executar comandos. É o modo certo para revisão de código ou sessões de planejamento.

• dontAsk: nega automaticamente qualquer coisa que não esteja explicitamente na lista allow.

• bypassPermissions: ignora todos os prompts. Só é seguro em ambientes totalmente isolados, como um container ou VM.

Você pode alternar entre os três modos principais com Shift+Tab durante a sessão, ou selecionar um como padrão em settings.json:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

Para times, configurações gerenciadas oferecem uma camada que o usuário não pode sobrescrever. O arquivo segue o mesmo formato JSON e fica em um caminho do sistema:

• /Library/Application Support/ClaudeCode/managed-settings.json no macOS

• /etc/claude-code/managed-settings.json no Linux

• C:\ProgramData\ClaudeCode\managed-settings.json no Windows

Regras de deny nas configurações gerenciadas valem para todos os projetos da máquina, o que permite impor regras como "ninguém lê arquivos .env" ou "ninguém usa bypassPermissions" em toda a organização.

O princípio por trás de tudo isso é o menor privilégio, o mesmo que você aplicaria a qualquer service account. 

Você deve começar com o menor conjunto de permissões que permite o trabalho acontecer e ampliá-las só quando bater em um bloqueio. A própria orientação da Anthropic vai na mesma linha — revise as mudanças que o Claude faz, audite suas regras com /permissions e mantenha as configurações específicas do projeto versionadas para que o time esteja alinhado sobre o que o Claude pode fazer.

Sandboxing no Claude Code

Quanto mais você permite que o Claude rode de forma autônoma, mais o sandboxing faz sentido.

A ferramenta Bash tem a maior exposição, já que comandos de shell podem ler qualquer arquivo que você pode ler e modificar qualquer coisa para a qual tenham permissão de escrita. O sandboxing impõe limites em nível de SO para cada comando Bash e seus processos filhos, para que o Claude opere com mais liberdade dentro da fronteira sem você aprovar cada chamada. A Anthropic fez isso justamente para dar suporte a execuções autônomas mais seguras.

Um detalhe importante: o sandbox cobre apenas o Bash e seus processos filhos. Ele não restringe as ferramentas Read, Edit ou Write, que continuam passando pelo sistema de permissões.

Sandboxing nativo

O sandbox nativo é integrado ao Claude Code e é ativado com /sandbox.

No macOS, o sandbox usa o framework Seatbelt embutido e não há nada para instalar. No Linux e WSL2, você instala bubblewrap para isolamento do sistema de arquivos e socat para o proxy de rede. Windows nativo não é suportado, então rode o Claude Code dentro de uma distribuição WSL2.

A fronteira do sistema de arquivos é simples de entender. Leituras funcionam em qualquer lugar, exceto em caminhos negados, e escritas só funcionam dentro do diretório de trabalho e dos caminhos adicionais que você permitir. Se tentar escrever em ~/.bashrc de dentro do sandbox, você receberá "Operation not permitted" antes mesmo do Claude saber que falhou.

A fronteira de rede é um pouco diferente. O tráfego de saída passa por um servidor proxy fora do sandbox, que verifica cada requisição contra sua lista de allowedDomains. Novos domínios disparam um prompt de permissão para você ver exatamente o que o Claude está tentando acessar.

Uma configuração funcional fica assim:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

No uso interno da Anthropic, o sandboxing reduz prompts de permissão em 84%.

Containers de desenvolvimento

Dev containers são o próximo nível de isolamento.

A Anthropic possui um devcontainer de referência para o Claude Code que configura um ambiente Ubuntu, monta seu repo e fornece um shell para o agente trabalhar. A vantagem sobre o sandbox nativo é a reprodutibilidade, porque todo mundo no time recebe o mesmo ambiente, com as mesmas ferramentas e a mesma configuração.

A desvantagem é a sobrecarga. 

Você adiciona build de container, montagem de arquivos e (às vezes) um ciclo de feedback mais lento ao usar containers. Para um único desenvolvedor, o sandbox nativo geralmente basta. Para times ou CI, esse setup compensa.

Isolamento baseado em Docker

Para sessões autônomas de longa duração, o Docker pode ampliar ainda mais a fronteira do sandbox.

Normalmente, o setup fica assim:

• Imagem base mínima: remova gerenciadores de pacotes e ferramentas de rede que a tarefa não precisa.
• Usuário sem privilégios: o Claude nunca roda como root, então não pode modificar arquivos do sistema nem instalar pacotes globais.
• Sistema de arquivos raiz somente leitura: monte a raiz do container como somente leitura, com apenas diretórios de saída específicos graváveis.
• Proxy de saída: roteie a rede de saída por um proxy que permita o registro de pacotes (npm, PyPI) e negue o restante, para que comandos como npm install funcionem, mas um curl arbitrário não.
• Limites de recursos: defina limites de CPU, memória e I/O para que um processo não derrube o host.

Docker Sandboxes dão a cada sandbox sua própria microVM com um daemon Docker privado. O daemon do host nem vê os sandboxes no docker ps. A fronteira fica mais próxima de uma VM do que de um container, fechando a maioria dos caminhos de escape de container que preocupam os desenvolvedores.

Estratégias de sandboxing para empresas

Para organizações, a questão é como empilhar técnicas de sandbox, não se deve usá-las.

Veja como a maioria aborda isso:

• Regras de permissão ficam em managed-settings.json e não podem ser sobrescritas por desenvolvedores individuais.

• Sandboxing nativo roda por baixo da camada de permissões.

• Dev containers ou Docker rodam por baixo disso.

• Para cenários de maior confiança (acesso a produção, tratamento de segredos), uma VM dedicada sem montagem do filesystem do host é a última camada.

O Claude Code na web é uma versão gerenciada da mesma ideia. Cada sessão roda em uma VM gerenciada pela Anthropic, credenciais sensíveis como tokens do git ficam fora do sandbox em um proxy, e a fronteira é aplicada pela infraestrutura.

Segurança MCP no Claude Code

O MCP é a parte do Claude Code que cresce mais rápido.

Cada servidor MCP que você conecta multiplica o que o Claude pode fazer — e também a superfície que uma injeção de prompt ou uma dependência comprometida consegue alcançar. 

Por exemplo:

• Um servidor MCP do GitHub dá ao Claude acesso a pull requests.
• Um servidor MCP de banco de dados dá acesso ao seu schema e a consultas.
• Um servidor do Slack dá acesso aos seus canais.

Nada disso é um problema por si só, mas significa que o MCP precisa de governança própria. Conteúdos trazidos por uma ferramenta MCP (uma página web ou resposta de API) podem conter instruções injetadas que o Claude executa como se você as tivesse digitado. Além disso, cada servidor adiciona uma credencial e um caminho de autenticação que precisam ser gerenciados separadamente.

Permissões de ferramentas

Ferramentas MCP usam uma convenção de nomes diferente das ferramentas nativas.

O formato é mcp__servername__toolname, sem especificador entre parênteses. Por exemplo, mcp__github__create_pull_request permite que o Claude chame exatamente essa ferramenta, e um deny em mcp__github__delete_repo bloqueia a perigosa. As listas allow, ask e deny funcionam da mesma forma que para Bash ou Read.

As mesmas regras de precedência se aplicam — primeiro deny, depois ask e por fim allow. Um deny em mcp__github__delete_* nas configurações gerenciadas vale para todos os projetos da máquina.

Permissões de recursos

Servidores MCP podem expor recursos além de ferramentas.

Um recurso é um dado que o servidor disponibiliza para o Claude ler (um arquivo em um servidor de gestão de projetos ou uma linha em um servidor de banco de dados). O acesso a recursos passa pela mesma verificação de confiança que as chamadas de ferramentas, e a primeira conexão a um servidor MCP executa uma etapa de verificação de confiança antes que qualquer ferramenta ou recurso fique acessível.

O padrão certo é tratar recursos como outra ferramenta. Se você não concederia a credencial, não conceda acesso ao recurso.

Servidores MCP aprovados

O Anthropic Directory lista conectores que a Anthropic revisou de acordo com seus critérios de listagem.

Para organizações, uma boa prática é usar uma allowlist interna. Existem duas configurações que dão esse controle:

• allowedMcpServers: um padrão glob de servidores que os desenvolvedores podem adicionar aos projetos (por exemplo, company-* para permitir apenas servidores mantidos internamente).

• deniedMcpServers: um padrão de servidores que não podem ser adicionados, mesmo que o desenvolvedor tente.

Para servidores obrigatórios que devem estar presentes em toda sessão, um arquivo managed-mcp.json nas configurações gerenciadas é a forma de distribuí-los. Desenvolvedores não podem remover nem modificar as entradas.

Uma configuração a evitar em repositórios compartilhados é enableAllProjectMcpServers, que aprova automaticamente todo servidor MCP definido em .mcp.json. É conveniente para trabalho solo e perigoso para qualquer coisa versionada, porque um PR malicioso pode adicionar um novo servidor em .mcp.json e fazê-lo rodar sem prompt.

Acesso a ferramentas com menor privilégio

O mesmo princípio das permissões do Bash, só que aplicado ao MCP.

A pergunta inicial é qual credencial cada servidor usa. Um servidor MCP de banco de dados deve conectar a um read-replica com acesso somente leitura, não ao primário com direitos de escrita. Um servidor MCP de API deve usar um token com escopo para o menor conjunto necessário de endpoints, não um token pessoal com acesso total à organização. E assim por diante.

Subagentes são outra forma de delimitar acesso MCP. Uma definição de subagente em .claude/agents/ pode declarar exatamente a quais ferramentas ele tem acesso (usando a sintaxe mcp:<server>:<tool>), então um "deploy-agent" recebe o servidor de infraestrutura e um "review-agent" recebe apenas Read, Grep e Glob. O agente não consegue chamar ferramentas que não recebeu.

Governança MCP

Para um time ou organização usando o Claude Code em escala, o MCP precisa do mesmo formato de governança que qualquer outra integração de produção.

Isso significa um registro de servidores aprovados com donos nomeados, trilhas de auditoria ponta a ponta das invocações de ferramentas (quais ferramentas MCP foram chamadas, por quem, com quais parâmetros) e uma revisão periódica da lista de aprovações. Os exportadores OpenTelemetry no Claude Code fornecem os dados de auditoria em um formato que se encaixa no stack de observabilidade que você já opera.

Para organizações maiores, um gateway MCP centralizado é a versão mais limpa disso. 

Desenvolvedores se conectam ao gateway em vez de registrar servidores individuais. O gateway cuida da autenticação, aplica controle de acesso baseado em papéis no nível de ferramenta e emite uma trilha de auditoria única. Também resolve a proliferação de credenciais, pois um conjunto de credenciais no gateway substitui cada desenvolvedor portando uma cópia de cada chave de API.

Gestão de segredos e dados sensíveis

O Claude Code pode ler tudo o que você pode ler, o que torna segredos acessíveis.

Por padrão, o Claude Code pode ler todo arquivo que sua conta de usuário pode. Isso inclui arquivos .env no seu projeto, credenciais da AWS em ~/.aws/, chaves privadas SSH em ~/.ssh/, tokens do GitHub no seu arquivo rc do shell e variáveis de ambiente em qualquer subprocesso criado pelo Claude. Isso é normal e projetado assim.

Mantenha segredos fora do workspace

O primeiro passo é garantir que segredos não estejam no diretório que o Claude está lendo.

.env são os mais comuns. Ficam na raiz do projeto, são carregados por toda ferramenta de desenvolvimento e contêm exatamente os valores que você não quer no contexto do Claude (URLs de banco e chaves de API). 

Aqui vão alguns padrões úteis:

• Mova segredos para um diretório fora da árvore de trabalho, por exemplo ~/.config/myapp/secrets.env, e carregue-os por meio de um gerenciador de ambiente ou uma configuração direnv que aponte para o arquivo externo.

• Para trabalho containerizado, mantenha uma pasta .secrets/ fora do bind mount para que o arquivo fique invisível de dentro do container.

• Adicione Read(**/.env) e Read(**/.env.*) à sua lista permissions.deny e combine com denies Bash(cat:*/.env) para que um script de shell não leia o que a ferramenta Read não pode.

Use um gerenciador de segredos

Para qualquer coisa além de projetos de demonstração, o lugar certo para segredos é um gerenciador de segredos.

O padrão é o mesmo, independentemente do fornecedor (1Password, AWS Secrets Manager, HashiCorp Vault, Doppler, Infisical). Segredos ficam no gerenciador. Seu shell ou runtime os obtém sob demanda e os expõe apenas para o processo que precisa deles. O Claude nunca vê o valor real.

Especificamente para o Claude Code, isso significa definir CLAUDE_CODE_SUBPROCESS_ENV_SCRUB para remover credenciais da Anthropic e de provedores de nuvem dos subprocessos, ou usar sandbox.credentials para desconfigurar variáveis específicas para comandos sandboxed. O primeiro impede que o Claude passe seu ANTHROPIC_API_KEY para um script de build, e o segundo cobre o caso mais amplo de qualquer variável de ambiente sensível chegar a um comando de shell.

Restrinja o acesso ao repositório

A terceira opção é no nível do repo.

Se um desenvolvedor não precisa de acesso de escrita a configurações apenas de produção, a sessão do Claude Code dele também não precisa. Parece óbvio, mas o padrão de muitos times é que desenvolvedores têm mais acesso do que usam rotineiramente, e o Claude herda tudo isso.

Aqui vão dois passos práticos:

• Separe configurações de produção em um repo próprio, com acesso mais restrito, para que o ambiente de dev onde o Claude trabalha nem tenha os segredos de produção para começo de conversa.

• Use tokens com escopo para qualquer serviço com que o Claude interaja. Por exemplo, um token do GitHub para revisão de código não precisa de repo:delete.

Segurança do Claude Code para times

Um desenvolvedor solo pode alterar o settings.json como quiser. Um time não pode, porque a segurança geral é tão forte quanto a configuração mais fraca na máquina mais fraca. Para implantações em times e organizações, o Claude Code tem uma camada separada de controles que um admin distribui e usuários individuais não podem sobrescrever.

Configurações gerenciadas

As configurações gerenciadas são a base.

O arquivo fica em um caminho do sistema que requer acesso de administrador para escrita:

• /Library/Application Support/ClaudeCode/managed-settings.json no macOS

• /etc/claude-code/managed-settings.json no Linux

• C:\ProgramData\ClaudeCode\managed-settings.json no Windows

As configurações deste arquivo têm precedência sobre as de nível de usuário e de projeto. Uma regra de deny aqui vale para todos os projetos da máquina, e o desenvolvedor não consegue removê-la editando o próprio settings.json. A maioria das organizações distribui o arquivo via MDM (Mobile Device Management) ou pelo mesmo canal de configuração usado para outras ferramentas de dev.

Aqui estão algumas configurações importantes na camada gerenciada:

• permissions.deny para caminhos sensíveis e comandos perigosos

• defaultMode definido como default ou plan (nunca bypassPermissions)

• allowManagedPermissionRulesOnly: true para travar o conjunto de permissões

• enableAllProjectMcpServers: false para exigir aprovação explícita de MCP

• Configuração do exportador OpenTelemetry para logging

Políticas de permissão compartilhadas

Se o time concorda sobre o que o Claude pode fazer, essa decisão deve estar sob controle de versão.

As configurações no nível do projeto ficam em .claude/settings.json na raiz do repo. Qualquer coisa versionada aqui se aplica a quem rodar o Claude nesse repo. O arquivo é o lugar certo para allows e denies específicos do projeto.

Com isso em mente, há uma divisão entre configurações gerenciadas e de projeto que você precisa conhecer:

• Configurações gerenciadas contêm a política da organização (ninguém usa bypassPermissions, ninguém lê .env).

• Configurações de projeto contêm convenções de fluxo de trabalho (os testes deste repo rodam com npm test; o script de deploy deste repo é restrito).

Governança do time

Para uma implantação em time, a camada de políticas precisa de um dono.

Times que rodam o Claude Code em escala geralmente têm um pequeno grupo — normalmente segurança e engenharia de plataforma — que cuida das configurações gerenciadas, da allowlist de MCP, dos scripts de hooks e do pipeline de OpenTelemetry. O mesmo grupo revisa pedidos de exceção e ajusta a política conforme surgem novos casos de uso.

Procure ter estas peças documentadas:

• Quais repos estão no escopo e quais não estão, com modos por nível de risco (um repo com dados regulados provavelmente roda o Claude em modo plan, enquanto um repo de site de marketing pode rodar em acceptEdits).
• Quem pode conceder exceções e como elas são rastreadas.
• Uma cadência de revisão (trimestral é comum) em que o time revisita regras de permissão, servidores MCP e dados de incidentes.

Registro de auditoria

O Claude Code emite eventos OpenTelemetry para cada decisão de ferramenta, conexão de servidor MCP, mudança de modo de permissão e requisição de API. Nenhum dado flui até que um admin configure o endpoint OTLP nas configurações gerenciadas.

Veja um bloco mínimo de configurações gerenciadas para telemetria:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

Por padrão, o conteúdo do prompt e os parâmetros das ferramentas são excluídos da exportação, então os eventos coletados são metadados, não a conversa completa. Para incluir o texto dos prompts, defina OTEL_LOG_USER_PROMPTS=1. Para incluir argumentos das ferramentas (geralmente o que você quer para auditoria), defina OTEL_LOG_TOOL_DETAILS=1. Ambas as decisões têm implicações de privacidade, então a maioria dos times as trata como escolhas de política e configura o backend de telemetria para filtrar ou redigir antes do armazenamento.

Monitoramento de uso

O mesmo fluxo OpenTelemetry por trás da auditoria também sustenta o monitoramento de uso.

O Claude Code exporta métricas de tokens usados, custo por requisição, contagem de sessões e taxas de decisões de ferramentas. Agregadas, elas mostram quais times extraem mais valor, quais fluxos geram mais rejeições e quais modelos puxam mais custo. Backends como Datadog, Honeycomb, SigNoz, Elastic e Splunk ingerem o formato OTLP padrão.

Um pico de eventos permission_decision com decision=deny pode significar que o Claude está tentando demais, mas também pode indicar que as regras allow do time estão apertadas demais.

Erros comuns de segurança no Claude Code

Um pequeno conjunto de más configurações aparece na maioria dos incidentes com Claude Code. Vou mostrar quais são e como lidar com elas.

Permissões amplas demais

A forma mais rápida de enfraquecer o sistema de permissões é permitir demais.

Prompts por comando adicionam atrito, e a solução fácil é um allow amplo Bash(*) ou configurar defaultMode: bypassPermissions. Ambos desfazem a maior parte do que o sistema de permissões oferece.

Delimite regras de allow para ferramentas e comandos específicos que você realmente usa (por exemplo, Bash(npm test:*) e Bash(git status)) e deixe o restante cair no prompt. Você recebe mais prompts no começo, mas em poucas sessões terá permitido os comandos que usa e os prompts praticamente param.

Acesso MCP irrestrito

O segundo erro é conectar servidores MCP sem verificar quais credenciais usam ou o que conseguem alcançar.

Isso costuma acontecer porque alguém ativa enableAllProjectMcpServers, conecta alguns servidores do diretório público de MCP e nunca volta para revisá-los. Quando um servidor com credencial fraca vaza algo sensível, a conexão já está tão enterrada na configuração que ninguém lembra de tê-la aprovado.

A correção é a mesma das permissões. Use uma allowlist explícita via allowedMcpServers, um managed-mcp.json interno para os servidores necessários a todos e uma cadência de revisão dessa lista.

Sem sandboxing

Se o sandboxing estiver desligado, o sistema de permissões é a única barreira entre o Claude e seu filesystem.

Isso é aceitável para sessões interativas curtas, nas quais você aprova cada comando. Não é para execuções autônomas, sessões em que você ampliou regras allow ou qualquer trabalho que toque em código de fontes externas.

/sandbox ativa o recurso. Se as dependências não estiverem instaladas, o menu mostra quais instalar para sua plataforma. Uma vez ligado, os prompts de permissão caem e o SO pega os casos que suas regras allow não cobrem.

Aceitar mudanças no automático

acceptEdits é conveniente e perigoso ao mesmo tempo.

Quando o Claude está reescrevendo uma função e você está acompanhando, o auto-accept é ok. Quando o Claude está iterando por 30 arquivos ao longo de uma hora, você tende a parar de ler os diffs e começar a confiar no agente. É aí que os problemas podem acontecer.

Dois hábitos para adotar:

• Sempre faça commit antes de deixar o Claude rodar autonomamente, para que o rollback esteja a um git reset de distância.

• Revise o diff antes de cada commit assinado pelo Claude, não o diff cumulativo no fim da sessão.

Ignorar trilhas de auditoria

Um time rodando o Claude Code sem telemetria não tem como responder à pergunta "qual sessão fez isso?". Os eventos se acumulam localmente em cada máquina e ficam lá. A primeira vez que você precisa de uma trilha de auditoria é também o pior momento para descobrir que não a configurou.

O mínimo útil é exportar eventos tool_decision, permission_decision e api_request para o stack de observabilidade que o time já usa. A partir daí, você constrói dashboards e alertas conforme surgem necessidades.

Conclusão

O pior cenário para um chatbot é uma resposta ruim. Para um agente de codificação, é um comando de shell rodando em produção com as suas credenciais.

É por isso que os três pilares importam:

• Permissões decidem o que o Claude tem permissão para fazer
• Controles MCP decidem quais sistemas externos ele pode alcançar
• Sandboxing decide o que acontece quando os dois primeiros não são suficientes

Cada um cobre uma falha que os outros não cobrem. Juntos, definem a fronteira real dentro da qual o Claude trabalha.

Se você quer se certificar em IA generativa, aqui estão comparativos, cursos de destaque, dicas de preparação e FAQs das melhores certificações em IA generativa de 2026.