Segurança no Claude Code para empresas: permissões, sandbox e segredos

Segurança no Claude Code para empresas: permissões, sandbox e segredos

Para usar o Claude Code com segurança numa empresa, combine três camadas: permissões explícitas (o que o agente pode ler, executar e alterar), isolamento (onde ele roda e o que alcança na rede e no disco) e proteção de credenciais (o agente nunca deve ver segredos de produção). Comece restritivo, registre o que foi aprovado e amplie só com evidência de uso real.

O Claude Code é uma ferramenta que lê código, executa comandos e edita arquivos. Isso é o que o torna útil, e também o que exige disciplina. Este guia reúne as decisões que um responsável técnico ou dono de operação precisa tomar antes de liberar o uso para a equipe.

Principais pontos

• Trate o Claude Code como um colaborador com acesso ao terminal: dê o menor acesso que permita fazer o trabalho e revise o que ele pede para executar.
• Use regras de permissão em três níveis (permitir, perguntar, negar) e mantenha a configuração da empresa em um arquivo versionado e gerenciado, não na máquina de cada pessoa.
• Rode o agente em ambiente isolado (sandbox, contêiner ou máquina de desenvolvimento descartável) sem acesso a produção.
• Mantenha segredos fora do alcance do agente: arquivos de ambiente bloqueados, credenciais de curta duração e escopo mínimo.
• Desconfie de conteúdo externo (páginas, issues, documentos, servidores MCP): ele pode conter instruções maliciosas.

Qual é o risco real ao usar o Claude Code numa empresa?

O risco não está no modelo "ficar mal-intencionado". Está em três situações comuns: o agente executa um comando destrutivo por engano, o agente lê um segredo e o repete em um log ou em um commit, ou o agente segue uma instrução escondida em um conteúdo que ele leu. As duas últimas são formas conhecidas de falha em aplicações com modelos de linguagem, descritas no OWASP Top 10 para aplicações de LLM.

Por isso a pergunta útil não é "o Claude Code é seguro?", e sim "o que ele consegue fazer se errar ou for enganado?". Se a resposta for "apagar a pasta do projeto numa máquina descartável", o risco é administrável. Se for "alterar o banco de produção com uma credencial de administrador", o desenho está errado, independentemente da ferramenta.

Existe também a dimensão de dados pessoais. Se o repositório ou os arquivos de teste contêm dados de clientes, o trabalho com o agente passa a ser tratamento de dados. A ANPD é a referência oficial no Brasil, e o time jurídico ou o encarregado de dados deve opinar sobre o que pode entrar no contexto do agente. Quem opera canais como o WhatsApp encontra a mesma questão, tratada em LGPD no WhatsApp com IA: consentimento, base legal e registro.

Como configurar permissões: negar, perguntar, permitir

O Claude Code trabalha com regras de permissão que podem ser definidas em arquivos de configuração, em níveis diferentes: pessoal, do projeto e gerenciado pela organização. A lógica útil para empresas é simples: o que for perigoso fica negado, o que for ambíguo exige confirmação, e só o que for rotineiro e reversível é permitido sem perguntar. Confirme sempre a sintaxe e os nomes exatos na documentação oficial da Anthropic para a versão que sua equipe usa, porque esses detalhes mudam.

Uma forma prática de classificar ações:

• Permitir sem perguntar: leitura de arquivos do projeto, execução de testes, linters e formatadores, comandos de consulta ao controle de versão (status, diff, log).
• Perguntar sempre: instalação de dependências, escrita fora da pasta do projeto, chamadas de rede, commits e criação de branches, qualquer comando que altere configuração.
• Negar sempre: leitura de arquivos de ambiente e de chaves, comandos de exclusão recursiva, push forçado, acesso a pastas de credenciais do usuário, comandos que chamem sistemas de produção.

Três cuidados fazem diferença:

• Mantenha a configuração da empresa em um arquivo de política gerenciado, para que ninguém consiga afrouxar as regras localmente sem que isso seja visível. O arquivo do projeto, versionado no repositório, serve para regras específicas daquele código.
• Evite o modo que pula todas as confirmações fora de um ambiente isolado e descartável. Ele pode ser razoável dentro de um contêiner sem rede e sem segredos, mas nunca em uma máquina que tenha acesso a coisas importantes.
• Revise periodicamente as regras permitidas. Regras de permissão tendem a crescer por conveniência ("aprovei uma vez, deixei para sempre") e ninguém as poda.

Essa lógica de menor privilégio não é exclusiva de IA. O guia de autorização do OWASP descreve princípios como negar por padrão e aplicar o mínimo privilégio, que servem como régua para revisar sua configuração. Para decidir quais ações exigem aprovação humana em fluxos mais amplos, veja o template de política de aprovação para agentes de IA.

Sandbox e isolamento: onde o agente deve rodar?

Permissões dizem o que o agente pode pedir. Isolamento limita o estrago quando uma permissão é concedida por engano ou quando o agente é induzido a algo indevido. As duas camadas se complementam, e a segunda não depende de ninguém clicar corretamente em cada confirmação.

O Claude Code oferece recursos de isolamento para a execução de comandos, que restringem acesso a arquivos e à rede. Verifique na documentação oficial quais plataformas e opções existem na sua versão. Além disso, a própria empresa pode montar o isolamento por conta própria. As opções mais comuns, da mais simples à mais forte:

• Pasta de trabalho dedicada, com cópia do repositório e sem acesso ao restante do disco.
• Contêiner de desenvolvimento com apenas o código montado, sem as credenciais do usuário.
• Máquina virtual ou ambiente em nuvem descartável, criado por tarefa e destruído depois.
• Rede restrita por lista de destinos permitidos, para que o agente não consiga enviar dados para endereços desconhecidos.

O critério de escolha é o que existe na máquina onde o agente roda. Um notebook pessoal com chaves SSH, sessões de nuvem logadas e arquivos de clientes pede isolamento forte. Um contêiner novo, com um repositório de teste e nenhuma credencial, tolera regras mais frouxas.

Vale separar também os ambientes por finalidade: um para explorar e escrever código, outro (com humano no controle) para qualquer coisa que toque integrações reais. O agente não deveria ter caminho de rede até produção a partir do ambiente onde ele experimenta.

Como proteger segredos e credenciais?

O erro mais caro costuma ser o mais banal: uma chave com permissão ampla guardada em um arquivo de ambiente na raiz do projeto, que o agente lê para "entender a configuração". A partir daí, o segredo pode aparecer em uma resposta, em um log, em um commit ou em um contexto compartilhado.

Uma política mínima de segredos para uso do Claude Code:

• Bloqueie por regra de negação a leitura de arquivos de ambiente, chaves privadas e pastas de credenciais. Não confie apenas em pedir ao agente que não os leia.
• Use arquivos de exemplo (sem valores reais) para documentar variáveis. O agente entende a estrutura sem ver o segredo.
• Dê ao ambiente de desenvolvimento credenciais próprias, de escopo mínimo e acesso apenas a dados de teste. Nunca reutilize chaves de produção.
• Prefira credenciais de curta duração e revogáveis. Se uma chave vazar, o impacto deve ser pequeno e a troca, rápida.
• Ative varredura de segredos no repositório e no pipeline, para pegar o que escapar antes de chegar ao histórico.
• Quando a integração usar OAuth, siga o fluxo documentado pelo provedor, com escopos mínimos. A documentação de OAuth 2.0 do Google é um exemplo claro de como pedir apenas os escopos necessários.
• Tenha um procedimento escrito de rotação: quem troca a chave, onde, e como se confirma que a antiga parou de funcionar.

Se um segredo chegou a ser exibido ao agente, trate como comprometido e rotacione. Não vale apostar que ninguém verá o histórico da conversa.

Prompt injection e ferramentas externas: o que muda?

Quando o Claude Code lê uma página da web, uma issue, um documento anexado ou a resposta de uma ferramenta, esse texto entra no contexto e pode conter instruções. Um comentário aparentemente inocente em um arquivo pode pedir que o agente envie dados para fora ou execute um comando. Esse padrão é a injeção de prompt, e o guia de prevenção do OWASP lista medidas de defesa em camadas.

Na prática, para equipes:

• Trate todo conteúdo externo como não confiável, mesmo quando vem de um repositório da própria empresa que aceita contribuições de terceiros.
• Combine entrada não confiável com poucas ações possíveis. Se o agente lê issues públicas, ele não deveria ter permissão de rede nem acesso a segredos naquela mesma sessão.
• Aprove manualmente qualquer comando que envie dados para fora (curl, upload, push para repositório remoto desconhecido).
• Instale somente servidores MCP e extensões de fontes que a empresa avaliou, com lista de aprovados. Cada servidor amplia o que o agente consegue fazer e o que ele consegue ler.
• Revise os parâmetros e escopos de cada ferramenta conectada. Uma ferramenta de "ler tickets" que também permite "fechar tickets" tem mais poder do que o necessário.

O mesmo raciocínio vale para agentes que ficam expostos a mensagens de clientes, como os de WhatsApp. O checklist de segurança do OpenClaw Gateway mostra como pensar em evidência antes de expor um agente a entradas externas.

Plano de implantação em etapas

Um roteiro simples para liberar o uso com controle, sem tentar resolver tudo de uma vez:

• Primeira etapa, mapear: liste quem vai usar, em quais repositórios, em quais máquinas e com quais credenciais disponíveis. Registre também se há dados pessoais nos repositórios.
• Segunda etapa, limitar: defina o arquivo de política gerenciado com as regras de negar, perguntar e permitir. Bloqueie arquivos de ambiente. Escolha o ambiente isolado padrão.
• Terceira etapa, preparar credenciais: crie chaves de desenvolvimento com escopo mínimo, ative varredura de segredos e documente a rotação.
• Quarta etapa, pilotar: escolha um repositório de baixo risco e um grupo pequeno. Defina antes o que seria um sucesso e o que seria um motivo para parar. Para estruturar a medição, use o guia de como medir um piloto de automação com IA.
• Quinta etapa, transferir e decidir: entregue a configuração, o runbook e os responsáveis. Com os registros do piloto em mãos, decida entre expandir, ajustar ou encerrar.

Essa sequência segue o método que usamos em projetos de IA: mapear o processo atual, limitar dados e ações, pilotar um fluxo real com registros e uma métrica combinada, e só então transferir e decidir. Para o lado organizacional da adoção (papéis, treinamento, revisão de código), veja o guia de adoção do Claude Code para equipes.

Cenário ilustrativo: duas configurações para a mesma tarefa

Imagine, como exemplo, uma empresa de logística com um sistema interno de rastreio e uma pessoa desenvolvedora que pede ao Claude Code para corrigir um erro em um módulo de integração com transportadoras.

Na primeira configuração, o agente roda no notebook da pessoa, que tem sessão de nuvem ativa, chaves SSH e um arquivo de ambiente com a credencial de produção da transportadora. Todas as confirmações foram liberadas "para ir mais rápido". Se o agente ler um comentário malicioso em uma dependência, ele tem caminho para dados e ações reais.

Na segunda configuração, o agente roda em um contêiner com apenas o repositório, sem as chaves do usuário e com rede restrita. O arquivo de ambiente real está bloqueado por regra, existe apenas um arquivo de exemplo, e a credencial de teste só acessa um ambiente de homologação. Comandos de instalação e de rede pedem confirmação. A tarefa é a mesma, a produtividade é parecida, e o pior caso muda de "incidente com dados de operação" para "reiniciar o contêiner".

Esse contraste é a razão de começar pelo isolamento e pelos segredos, antes de discutir qualquer ajuste fino de permissões.

Perguntas frequentes

É seguro usar o Claude Code com código-fonte da empresa? Depende do que a empresa define como aceitável para dados e propriedade intelectual, e dos termos do plano contratado. Leia a documentação oficial e os termos da Anthropic sobre tratamento de dados, envolva jurídico e segurança, e restrinja os repositórios do piloto ao que já foi avaliado.

Posso confiar apenas nas confirmações que o Claude Code pede? Não. Confirmações dependem de atenção humana, e o cansaço de aprovar dezenas de pedidos leva a cliques automáticos. Use as confirmações como uma camada, e some regras de negação, isolamento e credenciais de escopo mínimo, que funcionam mesmo quando alguém aprova sem ler.

O que fazer se um segredo foi exposto na sessão do agente? Considere a credencial comprometida e rotacione imediatamente, sem esperar investigação. Depois, verifique logs de uso da chave, remova o valor de qualquer arquivo ou histórico onde apareceu e ajuste a regra que permitiu a leitura para que não se repita.

Preciso de uma política diferente para quem não é desenvolvedor? Sim, em geral mais restritiva. Pessoas de operações ou marketing que usam o agente para automações e planilhas devem trabalhar em pastas dedicadas, sem acesso a credenciais e com aprovação humana para qualquer ação que altere sistemas ou envie mensagens a clientes.

Fontes

• OWASP: Top 10 for LLM Applications
• OWASP: LLM Prompt Injection Prevention Cheat Sheet
• OWASP: Authorization Cheat Sheet
• ANPD: Autoridade Nacional de Proteção de Dados