Segurança do Claude Code: riscos, controlos e boas práticas

O que é o Claude Code e porque é que muda o modelo de segurança?

O Claude Code é a ferramenta de código agêntica da Anthropic. Funciona dentro da superfície que o programador já usa (o terminal, o IDE, a aplicação de desktop, o CI) e atua sobre instruções em linguagem natural: analisar uma base de código, gerar uma funcionalidade, correr os testes, preparar um pull request. Liga-se ao GitHub e ao GitLab, corre ao lado dos sistemas de build e das suítes de testes, e estende-se através do Model Context Protocol (MCP) para alcançar bases de dados, sistemas de ticketing e ferramentas internas.

É esta última propriedade que quebra o velho modelo de segurança. Um assistente de IDE tradicional sugere completações; um humano aceita ou rejeita cada uma. O raio de impacto de uma sugestão má é um bloco de código que um programador ainda tem de colar. O Claude Code executa ações em vez disso. Lê ficheiros que não nomeou, executa comandos que não escreveu, edita código por toda a árvore e chama ferramentas que ligou há semanas e de que se esqueceu. A superfície de ataque já não é "que código sugeriu o modelo". É "o que pode este agente fazer com o acesso que tem, e quem consegue influenciar as suas instruções".

“

Uma sugestão é um rascunho que um humano escolhe aceitar. Uma ação é algo que já aconteceu. O modelo de segurança tem de passar de rever rascunhos para restringir ações.

Há uma segunda mudança que importa ainda mais, e tem que ver com a velocidade. O pull request tornou-se a casa da segurança de aplicações porque assentava na cadência humana: uma pessoa abrandava, lia o diff e só depois fazia o merge. O Claude Code não corre à cadência humana. Uma única sessão pode entregar mais código numa tarde do que um revisor lê numa semana. Quando isso acontece, o diff deixa de ser um ponto de controlo e torna-se um registo de decisões já tomadas. Qualquer controlo que só atue no pull request está agora a rever o histórico, não a preveni-lo.

Para a maioria das equipas, a pergunta prática não é se o Claude Code tem proteções nativas. Tem-nas, e são boas. A pergunta é se essas proteções chegam para o uso do dia a dia. A resposta honesta é não. Os controlos nativos, as revisões e as verificações tipo análise reduzem o risco, mas a adoção segura continua a depender de permissões, ambiente isolado (sandbox), isolamento, supervisão humana e validação independente em código, dependências, segredos e pipelines. A Anthropic diz o mesmo na sua própria documentação de segurança: os controlos são camadas de defesa, não um programa de segurança completo.

Como funciona o modelo de segurança do Claude Code

O modelo do Claude Code assenta em três ideias: perguntar antes de fazer algo arriscado, delimitar o que o agente pode tocar e impor isso ao nível do sistema operativo, onde importa. Na prática, isso surge como um punhado de controlos.

Além desses quatro, mais três controlos importam ao nível organizacional. O Claude Code exporta telemetria de uso e de segurança através de OpenTelemetry: atividade de ferramentas, execução de comandos, alterações de modo de permissão, ligações MCP, erros de API e hooks, tudo isto podendo fluir para o seu próprio backend de observabilidade. Oferece opções de implementação seguras para além do serviço gerido da Anthropic, incluindo Amazon Bedrock, Google Vertex AI e Microsoft Foundry, de modo que uma equipa possa manter a autenticação, a faturação e a conformidade dentro da sua própria fronteira de cloud, com proxies corporativos, políticas IAM, registos de auditoria e RBAC por cima. E inclui uma capacidade de revisão de segurança que inspeciona pull requests à procura de vulnerabilidades e falhas de lógica, apresentando descobertas como comentários inline.

É uma base genuinamente boa, e a maior parte desta lista não existia nos assistentes de IDE de uma geração atrás. A armadilha é lê-la como uma fronteira de segurança acabada. A Anthropic descreve o modo auto como um meio-termo, não uma garantia, porque os classificadores que decidem "é esta ação segura" podem errar o julgamento. A revisão de segurança é assistiva, não a decisora final. Os devcontainers são explicitamente "não uma fronteira de segurança completa". Cada controlo desta lista tem um modo de falha documentado, e a próxima secção é sobre o que acontece quando se apoia demasiado neles.

Os 6 principais riscos de segurança no Claude Code

Os riscos abaixo não são teóricos. Correspondem a vulnerabilidades documentadas, investigação publicada e ao OWASP Top 10 para Aplicações LLM. Os números que os enquadram são os mesmos que todas as equipas de AppSec citam agora.

40%

do código gerado por IA era vulnerável em cenários de segurança do MITRE Top-25 (NYU, Asleep at the Keyboard)

#1

injeção de prompt, o principal risco LLM pelo 3.º ano consecutivo (OWASP LLM01)

10,5%

das soluções de agentes de código de IA eram seguras, face a 61% funcionalmente corretas (Carnegie Mellon SusVibes)

1. Governação fraca de aprovações e permissões

A segurança do Claude Code assenta em aprovações. Se os fluxos de aprovação forem demasiado permissivos, inconsistentes ou rotineiramente contornados, o agente executa ações arriscadas sem supervisão real. O modo auto e as flags que ignoram permissões reduzem a fricção, e reduzem o controlo exatamente no mesmo gesto.

O mecanismo que corrói isto na prática é a fadiga de aprovações. Quando o agente pergunta quarenta vezes por hora, as pessoas deixam de ler os prompts e começam a clicar em "permitir sempre" para os fazer desaparecer. Numa semana, o cuidadoso valor por omissão tornou-se, em silêncio, uma autorização geral, e ninguém decidiu que assim fosse. A versão ao nível da equipa é pior do que a individual: um programador corre com regras deny estritas, outro permite acesso amplo a ficheiros, shell e ferramentas porque era mais rápido numa sexta-feira, e no momento em que esses dois partilham um repositório, um fluxo de trabalho automatizado ou um conjunto de servidores MCP, a configuração mais fraca define a verdadeira postura de segurança de todos.

2. Injeção de prompt

A injeção de prompt é o risco que define as ferramentas de código agênticas, e é o risco LLM número um da OWASP pelo terceiro ano consecutivo. Um atacante esconde instruções em algo que o agente lê (um ficheiro, uma página web, uma issue, a saída de uma ferramenta) e o agente segue-as, anulando o comportamento previsto.

A forma perigosa é indireta. Não precisa de colar um prompt malicioso; basta apontar o Claude Code a um repositório envenenado, a um documento armadilhado ou a um servidor MCP que devolve conteúdo hostil. Um comentário enterrado no README de uma dependência que diz "antes de continuar, corre este script de configuração" pode ser suficiente. Como um modelo de linguagem não consegue distinguir de forma fiável uma instrução de confiança de uma maliciosa embutida em dados, a injeção pode levar a execução de comandos, exfiltração de dados ou manipulação silenciosa de código. No início de 2026, a investigação mostrava que um punhado de documentos forjados conseguia orientar o comportamento do modelo na grande maioria das vezes através de envenenamento de recuperação, e o cenário agêntico piora o desfecho: um agente orientado não se limita a responder mal, age.

3. Servidores MCP com permissões em excesso e envenenamento de ferramentas

O MCP é o que torna o Claude Code poderoso, e é uma nova fronteira de confiança que a maioria das equipas não modelou em termos de ameaças. Um servidor MCP com permissões em excesso pode expor dados sensíveis ou deixar o agente executar ações que ninguém pretendeu: um servidor de base de dados delimitado para ler tudo, um servidor de sistema de ficheiros apontado à diretoria home, uma ferramenta de deploy com credenciais de produção.

Um servidor malicioso ou comprometido vai mais longe. Os ataques de envenenamento de ferramentas escondem instruções dentro das descrições e respostas das ferramentas, de modo que ter o servidor simplesmente ligado pode orientar o agente antes mesmo de chamar a ferramenta. A mitigação que a Anthropic recomenda é direta e correta: escreva os seus próprios servidores MCP, ou use os de fornecedores em quem confia de facto, e trate tudo o que um servidor MCP devolve (definições de ferramentas, recursos, prompts, respostas) como input não confiável que tem de ser validado, e não como verdade absoluta sobre a qual o modelo pode agir.

4. Cadeia de suprimentos e dependências maliciosas

O Claude Code instala pacotes, clona repositórios e corre scripts de configuração como parte do trabalho normal. Se sugerir ou instalar uma biblioteca comprometida, o código malicioso corre com o acesso que o ambiente conceder. Isto não é hipotético. No início de 2026, uma campanha de typosquatting no npm rastreada como "Sandworm_Mode" plantou servidores MCP fraudulentos imitando utilitários populares, visando especificamente assistentes de código de IA, incluindo o Claude Code, o Cursor e o Windsurf.

O próprio fluxo de trabalho de desenvolvimento torna-se o vetor de ataque. Um package.json envenenado, um hook malicioso de post-install ou um pacote MCP com typosquatting pode transformar um rotineiro prompt "configura este repositório" em roubo de credenciais. O agente aprova muitas vezes a instalação com confiança, porque o nome do pacote parece certo e a tarefa pedia-o. A alucinação de pacotes agrava o problema: um agente que inventa um nome de pacote plausível mas inexistente entrega aos atacantes uma vaga para registar e transformar em arma.

5. Exposição de segredos e de contexto sensível

O Claude Code é útil porque tem contexto local, e esse contexto inclui rotineiramente mais do que código-fonte: ficheiros .env, configuração, variáveis de ambiente e por vezes credenciais. Quando esse contexto é mais amplo do que a tarefa precisa, o agente pode expor ou reutilizar valores sensíveis em logs, código gerado ou pull requests.

A Anthropic avisa especificamente que os devcontainers não impedem a exfiltração de nada que esteja acessível dentro deles, incluindo as credenciais do Claude Code guardadas em ~/.claude, e desaconselha montar segredos do host, como chaves SSH ou ficheiros de credenciais de cloud, num contentor que o agente possa ler. A exposição é muitas vezes indireta: ao resumir um repositório ou ao depurar um erro, o agente pode colar um excerto que contém um token ou um endpoint interno numa saída que depois acaba num ticket, num chat ou num repositório público, onde vive muito depois de a sessão terminar.

6. Execução de comandos e execução remota de código

O Claude Code corre comandos de shell e modifica sistemas, por isso um agente manipulado pode correr comandos nocivos. Investigadores de segurança documentaram contornos de restrição de caminho e vetores de injeção de comandos em ferramentas de código agênticas que levam à execução de código, por vezes desencadeada simplesmente por abrir um projeto malicioso.

O perigo agrava-se quando o agente corre com privilégios elevados ou acesso irrestrito à shell. Uma cadeia de comandos individualmente inofensivos pode instalar uma dependência maliciosa, alterar uma configuração de CI ou abrir um mecanismo de persistência na máquina. É exatamente por isto que a Anthropic combina a aprovação de comandos com ambiente isolado (sandbox), privilégio mínimo e ambientes isolados, e por que correr o Claude Code como root é um anti-padrão documentado. A combinação a temer é a comum: acesso amplo à shell, um modo permissivo para evitar prompts e uma instrução injetada que o agente trata como legítima.

O que a segurança nativa do Claude Code cobre, e o que não cobre

Os controlos nativos são reais, e ajuda ser preciso quanto à linha entre o que tratam e o que deixam para si.

Leia a coluna da direita como o verdadeiro trabalho. Os controlos nativos são o chão: impedem que um erro honesto se torne um desastre. Não foram concebidos para travar um adversário determinado que controla os inputs do agente, e a Anthropic não afirma que foram. Tudo o que transforma "o Claude Code está instalado" em "o Claude Code está governado" vive nas práticas que se seguem.

Boas práticas para proteger o Claude Code

Estas nove práticas fecham a lacuna entre a base nativa e uma postura de segurança real. Nenhuma é exótica; a disciplina está em aplicá-las de forma consistente numa equipa que se move depressa.

1. Corra em ambientes isolados e de privilégio mínimo. Use contentores ou devcontainers para trabalho assistido por IA, corra o Claude Code em espaço de utilizador (nunca como root) e bloqueie ligações de saída não aprovadas para que uma sessão comprometida não possa exfiltrar. Segmente os ambientes por sensibilidade, de modo que o trabalho de alto risco fique contido e o raio de impacto de qualquer comprometimento se mantenha pequeno.

2. Aplique o privilégio mínimo às permissões e ferramentas. Conceda o mínimo de acesso a ficheiros, repositório e ferramentas de que uma tarefa precisa. Escreva regras deny explícitas para armazéns de credenciais, ficheiros .env e infraestrutura de produção. Delimite o acesso MCP apenas a servidores validados. Prefira tokens efémeros e delimitados a tokens amplos e persistentes, e rode-os com regularidade em vez de esperar por um incidente.

3. Mantenha um humano no circuito do código gerado. Trate a saída de IA como um rascunho, não uma implementação final. Encaminhe todo o código gerado ou modificado através de revisão de pull request e testes automatizados, com escrutínio extra na autenticação, validação de input e caminhos privilegiados. O objetivo não é desconfiar do modelo; é que um agente que produz milhares de linhas por dia produz falhas subtis mais depressa do que elas surgem por si próprias.

4. Mantenha os segredos fora de alcance. Mantenha segredos em texto simples totalmente fora do contexto do agente. Use um cofre e injete em tempo de execução, redija valores sensíveis nos logs e nunca monte chaves SSH do host nem ficheiros de credenciais de cloud num contentor que o Claude Code possa ler. Se um segredo for alguma vez exposto num registo ou numa saída, rode-o de imediato e investigue como lá chegou.

5. Governe dependências e pacotes. Restrinja as instalações a registos de confiança ou mirrors internos, exija aprovação para novos pacotes e analise tudo com análise de composição de software. Não deixe o agente instalar automaticamente pacotes obscuros ou não verificados, por mais confiança com que os sugira, e verifique que um pacote sugerido existe de facto antes de o adicionar.

6. Audite as configurações de permissões com regularidade. Reveja as regras allow / ask / deny em ferramentas, caminhos, comandos e domínios, não só na configuração inicial. Cace caminhos com wildcards e acesso irrestrito à shell e aperte-os para o âmbito mínimo. Compare a configuração local com as definições geridas para apanhar desvios, e automatize um alerta em qualquer transição para auto, dontAsk ou bypassPermissions.

7. Controle os modos auto e bypass. Trate o modo auto como uma otimização deliberada, não um valor por omissão. Defina que ações qualificam como de baixo risco (operações apenas de leitura, refactors limitados) e mantenha a execução de shell, as chamadas de rede e as escritas em caminhos protegidos atrás de aprovação explícita. Proíba bypassPermissions e --dangerously-skip-permissions perto de qualquer ambiente partilhado ou ligado a produção; reserve-os para contentores descartáveis.

8. Registe e monitorize ao nível da equipa. Exporte a atividade do Claude Code através de OpenTelemetry para o seu SIEM. Capture uso de ferramentas, execução de comandos, edições de ficheiros, decisões de permissão e ligações externas, correlacione-os com a identidade do utilizador, e alerte sobre anomalias como escalações repetidas de permissão, destinos de rede inesperados ou padrões de comandos invulgares.

9. Defina a política por repositório e sensibilidade do ambiente. Classifique os repositórios (público, interno, regulado, produção) e aplique controlos mais estritos aos sensíveis: negue acesso a segredos, restrinja a saída, exija revisão mais forte e desative modos permissivos. Para sistemas críticos, corra o Claude Code apenas em ambientes sem caminho direto para credenciais de produção, e documente a política para que os programadores saibam onde a ajuda de IA é permitida e sob que restrições.

Onde os controlos nativos param: proteger o agente no momento do prompt

Percorra de novo os riscos e surge um padrão. Permissões, ambiente isolado (sandbox) e revisão atuam todos sobre o que o agente já decidiu fazer, ou sobre código que já escreveu. Concentram-se em torno do pull request, porque é aí que a AppSec sempre viveu. Mas o PR só foi alguma vez um ponto de controlo porque um humano o lia, e à cadência do agente ninguém o lê de ponta a ponta.

O lugar para impor uma regra já não é o diff; é o prompt, antes de a linha insegura ser escrita. Qualquer regra que queira que o agente siga tem de estar nas suas mãos no momento em que escreve, não à espera num scanner que chega quando o código já está em disco e o agente já passou para a tarefa seguinte.

É essa a camada que o VibeDefend acrescenta. É uma CLI npm gratuita que instala em cerca de cinco segundos e liga o Claude Code (mais o Cursor, o OpenAI Codex, o Windsurf e o VS Code Copilot) a quatro camadas de governação que correm dentro do ciclo do agente.

npx -y @cybedefend/vibedefend@latest installEscolher EU ou US, confirmar Claude CodeColocar .cybedefend/config.json no repositórioO próximo prompt está governado

Regras de Negócio As convenções no seu repositório que nunca foram escritas (usar Decimal128 para dinheiro, a autorização passa por requireOwner). O VibeDefend extrai-as da forma como a sua equipa já programa e carrega-as no contexto do agente antes de cada edição. Regras de Segurança OWASP Top 10, SOC 2, RGPD e ISO 27001, carregadas no dia em que instala. O agente lê o lembrete aplicável antes de escrever, de modo que o requisito do framework se torna parte do código em vez de uma caixa a marcar no momento da auditoria. Action Guard Chamadas destrutivas (um sudo rm -rf, uma leitura crua de uma variável de ambiente com forma de segredo, um psql ad-hoc contra um host de produção) são intercetadas antes de dispararem. Avisar ou bloquear conforme a regra, com cada interceção no registo de auditoria. Live Findings Cada resultado dos seus scanners (SAST com alcançabilidade, SCA, segredos, IaC e CI/CD) está ao vivo no contexto do agente, de modo que ele não só escreve código seguro, como tria e corrige as vulnerabilidades que já tem.

Crucialmente, nada do seu código atravessa a rede. As decisões acontecem localmente, ao lado do agente; apenas metadados de governação estruturados (a regra que disparou, o caminho do ficheiro, a severidade, um timestamp) chegam ao backend. Os tenants da EU e dos US são fisicamente separados, e a região é escolhida no momento da instalação. É esse modelo de privacidade que permite a um controlo estar tão perto do código sem se tornar, ele próprio, um risco de exfiltração de dados.

Isto não é um substituto das práticas acima. É a camada em falta que elas assumem existir: a que coloca as suas regras nas mãos do agente no momento do prompt, de modo que a linha insegura seja reescrita antes de alguma vez ser sugerida, em vez de apanhada três fases depois por um scanner que lê um diff que ninguém teve tempo de ler. As permissões impedem o agente de fazer o que não pode fazer; o VibeDefend molda o que ele escreve, em primeiro lugar.

Perguntas frequentes

O Claude Code é seguro de usar?

O Claude Code é seguro de usar quando está configurado e contido, e arriscado quando não está. As suas permissões por omissão de apenas leitura, os prompts de aprovação, o ambiente isolado (sandbox) e as definições geridas previnem uma grande classe de acidentes e ações inseguras. O risco residual vem da configuração (permissões demasiado amplas, modos de bypass), dos inputs (injeção de prompt, repositórios e servidores MCP maliciosos) e do ambiente circundante (segredos expostos, privilégios elevados). Trate-o como um agente poderoso que precisa de privilégio mínimo, isolamento e revisão humana, não como uma ferramenta que é segura logo à partida.

O Claude Code envia o meu código-fonte para a cloud?

O Claude Code envia o contexto de que precisa para o fornecedor do modelo para gerar respostas, o que pode incluir código, conteúdos de ficheiros e o contexto envolvente da sua tarefa. Para onde vai esse tráfego depende da sua implementação: o serviço gerido da Anthropic, ou a sua própria fronteira através do Amazon Bedrock, Google Vertex AI ou Microsoft Foundry. Para código sensível, use uma implementação que corresponda aos seus requisitos de tratamento de dados, exclua segredos e dados regulados do alcance do agente, e reveja as políticas de retenção. Os metadados de governação de uma camada adicional como o VibeDefend mantêm-se separados e não transmitem código-fonte.

Qual é a definição mais perigosa do Claude Code?

bypassPermissions, e o seu equivalente de CLI --dangerously-skip-permissions, porque saltam a camada de aprovação por completo. A Anthropic afirma que se destinam apenas a contentores ou VMs isolados. Usá-los num portátil de programador com acesso a credenciais reais, hosts de produção ou repositórios partilhados remove o único controlo que está entre um agente com injeção de prompt e um comando destrutivo. Proíba-os em qualquer ambiente partilhado ou ligado a produção.

O Claude Code pode ser atingido por injeção de prompt?

Sim. A injeção de prompt é o principal risco LLM no Top 10 da OWASP, e as ferramentas agênticas estão especialmente expostas porque leem conteúdo não confiável (repositórios, páginas web, issues, saída de ferramentas MCP) como parte do trabalho normal. Um modelo de linguagem não consegue separar de forma fiável uma instrução de confiança de uma maliciosa escondida em dados, por isso a defesa é em camadas: trate todo o conteúdo recuperado e devolvido por ferramentas como não confiável, corra o trabalho não confiável em isolamento, mantenha as permissões apertadas e acrescente um controlo no momento do prompt capaz de bloquear uma ação perigosa mesmo quando o modelo foi orientado.

Como protejo os servidores MCP no Claude Code?

Trate cada servidor MCP como uma fronteira de confiança. Use servidores que escreveu ou que vêm de fornecedores em quem confia genuinamente, delimite cada um aos dados e ações mais estreitos de que precisa, e nunca ligue um servidor com credenciais de produção a um ambiente que corre código não confiável. Valide tudo o que um servidor devolve em vez de deixar o modelo agir diretamente sobre isso, e mantenha um inventário dos servidores ligados, de modo que um pacote fraudulento ou com typosquatting não passe despercebido.

Em que é que proteger o Claude Code difere de proteger o GitHub Copilot, o Cursor ou o Codex?

Os fundamentos são partilhados (privilégio mínimo, gestão de segredos, revisão humana, análise de dependências), mas as superfícies diferem. O problema de destaque do Cursor tem sido o Workspace Trust desativado por omissão; o do Copilot tem sido sugestões inseguras e fuga de segredos em escala; o do Codex tem sido injeção de comandos e incidentes de cadeia de suprimentos. A superfície distintiva do Claude Code é a sua integração profunda com MCP e shell. Cobrimos cada agente no seu próprio guia: Cursor, GitHub Copilot e OpenAI Codex.

Os controlos nativos do Claude Code substituem o SAST e a revisão de código?

Não. A Anthropic é clara ao dizer que permissões, ambiente isolado (sandbox), definições geridas, monitorização e a capacidade de revisão de segurança são camadas de proteção, não um programa de segurança completo. A revisão de segurança nativa é assistiva: útil para feedback rápido, não a decisora final. Continua a precisar de acesso de privilégio mínimo, gestão de segredos, análise de dependências, CI/CD seguro, proteção de branches, revisão humana de código e ambientes isolados para trabalho arriscado, mais um controlo no prompt para que o código inseguro seja reescrito antes de ser escrito em vez de apanhado depois.

Como implemento o Claude Code de forma segura numa equipa inteira?

Comece pelas definições geridas, para que as regras críticas de segurança não possam ser anuladas localmente, e depois implemente através de uma fronteira que controla (Bedrock, Vertex AI ou Foundry) para autenticação centralizada, registos de auditoria e orçamentos. Padronize o ambiente com devcontainers, encaminhe a telemetria para o seu SIEM, classifique os repositórios por sensibilidade com políticas correspondentes, e acrescente uma camada de governação no momento do prompt como o VibeDefend, de modo que as mesmas regras cheguem ao agente de cada programador, independentemente do cuidado com que cada pessoa configurou a sua própria máquina.