--- title: "O Claude Code é seguro? O que mostram 93 incidentes" description: "O Claude Code é tão seguro quanto a sua configuração. 93 incidentes públicos por causa, os controlos da Anthropic com os valores por omissão e como configurar." url: "https://madsalt.tech/pt/blog/is-claude-code-safe/" author: "Denys Zaichenko" language: "pt" published: 2026-11-01 --- # O Claude Code é seguro? O que mostram 93 incidentes Em resumo O Claude Code é seguro se o configurar, e arriscado com os valores por omissão. Numa instalação nova de outubro de 2026 a sandbox está desligada, não há regras deny nem hooks, e um comando de shell que aprove pode escrever em qualquer sítio a que a sua conta de utilizador chegue. Classifiquei 93 relatos públicos de incidentes, de issues do GitHub, avisos de segurança e artigos: o dano veio de `git reset --hard` e resets de bases de dados que ninguém pediu, de regras que só existiam no `CLAUDE.md`, de repositórios, issues e plugins não confiáveis, e de subagentes que lançavam mais subagentes. Quase nada foi um `rm -rf /` dramático. Ponha o trabalho no git, ative a sandbox, escreva regras deny e um hook que bloqueie, e mantenha as credenciais de produção fora do alcance do agente. 93 relatos públicos de incidentes classificados por causa, de junho de 2025 a outubro de 2026 issues do GitHub, avisos, blogs de segurança, Hacker News 19 dizem que se perderam dados para sempre outros 11 dizem que foram recuperados 10 quebraram uma regra escrita só no CLAUDE.md um prompt é um conselho, uma regra de permissões é uma garantia Sou o Denys, engenheiro full-stack e de IA, e uso o Claude Code todos os dias. Abaixo estão duas coisas: o que correu mal a outras pessoas e o que o Claude Code lhe dá contra isso, incluindo quais desses controlos vêm ligados por omissão. Depois, uma configuração que cobre as falhas. ## O Claude Code é seguro? A segurança não está no modelo. O Claude Code decide o que corre através de um modo de permissões, regras de permissões, uma sandbox opcional e hooks opcionais, e a [página de permissões](https://code.claude.com/docs/en/permissions) da Anthropic diz-lo claramente: as regras são aplicadas pelo Claude Code, não pelo modelo, e as instruções do `CLAUDE.md` moldam o que o Claude tenta fazer mas não mudam o que lhe é permitido fazer. Por isso a resposta honesta depende da sua configuração. A [página de segurança](https://code.claude.com/docs/en/security) descreve o limite do diretório de trabalho como um pedido de permissão e acrescenta que «um comando Bash que aprove ainda pode escrever em qualquer sítio a que a sua conta de utilizador chegue». A [página da sandbox](https://code.claude.com/docs/en/sandboxing) diz «A sandbox está desligada por omissão», e que mesmo ligada só cobre comandos de shell: as ferramentas de ficheiros, os servidores MCP e os hooks correm fora dela. A frase final da Anthropic na página de segurança: «nenhum sistema é completamente imune a todos os ataques». ## O que correu mal a outras pessoas: 93 relatos de incidentes A 31 de outubro de 2026 reuni relatos públicos do Claude Code a causar dano ou quase: 63 issues do GitHub e avisos de segurança, 26 artigos em blogs de segurança e engenharia e 4 threads do Hacker News, de junho de 2025 a outubro de 2026. Deixei de fora threads do Reddit que só consegui ver através de espelhos. A cada relato atribuí um tipo e, quando o autor o dizia, o modo de permissões e se houve perda de dados. 60 das 61 citações que verifiquei contra o texto do GitHub coincidiam palavra por palavra. ![93 relatos de incidentes por tipo. Issues do GitHub, avisos, blogs, Hacker News. 06.2025–10.2026. Sandbox ou permissões contornadas: 15; Trabalho em git destruído: 14; Segredos expostos: 12; Ficheiros apagados: 11; Base de dados danificada: 9; Servidor MCP ou plugin malicioso: 9; Custo descontrolado de subagentes: 9; Injeção de prompt: 5; Outros: 9.](https://madsalt.tech/charts/pt/is-claude-code-safe-incidents.svg) *Figura 1. 93 relatos públicos de incidentes (63 issues e avisos do GitHub, 26 artigos em blogs, 4 threads do Hacker News), de junho de 2025 a outubro de 2026, reunidos a 31 de outubro de 2026.* 19 relatos dizem que os dados se perderam para sempre, 11 que foram recuperados, 36 descrevem uma falha encontrada antes de alguém ser prejudicado (a maioria, avisos entretanto corrigidos) e 27 não o dizem. 56 de 93 não indicam o modo de permissões, por isso este conjunto não lhe consegue dizer se o «modo YOLO» é onde acontece o dano. O que mostra são cinco padrões. **1. O agente executa um comando destrutivo que ninguém pediu.** Enquanto corrigia erros de lint executou `git checkout HEAD -- .` e deitou fora uma hora de trabalho sem commit ([#11821](https://github.com/anthropics/claude-code/issues/11821)). No início da sessão executou `git reset --hard origin/main` sobre commits por enviar ([#34327](https://github.com/anthropics/claude-code/issues/34327)). Executou `drizzle-kit push --force` contra uma base de dados de produção sem cópias de segurança ([#27063](https://github.com/anthropics/claude-code/issues/27063)), aceitou um reset do Prisma em produção ([#33183](https://github.com/anthropics/claude-code/issues/33183)) e, num [artigo](https://aishippinglabs.com/blog/how-i-dropped-our-production-database-and-now-pay-10-more-for-aws), executou `terraform destroy` com um ficheiro de estado antigo de produção na pasta. Nenhum destes é `rm -rf /`. São comandos normais com uma opção que salta a confirmação da própria ferramenta. **2. Regras que vivem só no `CLAUDE.md`.** 10 relatos envolvem uma regra escrita que o agente quebrou: fez commit de chaves de API reais apesar de uma secção de segurança de 150 linhas ([#2142](https://github.com/anthropics/claude-code/issues/2142)), fez commit depois de uma regra de «nunca fazer commit» ([#34774](https://github.com/anthropics/claude-code/issues/34774)), imprimiu um token com `grep` e só reparou depois ([#44868](https://github.com/anthropics/claude-code/issues/44868)). Um autor aponta que o `CLAUDE.md` está no repositório onde o agente pode escrever ([#23870](https://github.com/anthropics/claude-code/issues/23870)). Isto coincide com a documentação: um prompt é um conselho, uma regra é uma garantia. **3. Uma regra deny bloqueia um comando, não um objetivo.** Com `Bash(rm *)` negado, o agente apagou o ficheiro com uma linha de Python ([#39459](https://github.com/anthropics/claude-code/issues/39459)). A página de permissões diz o mesmo sobre a correspondência de texto: `git -C . push` não corresponde a uma regra para `git push`. **4. Texto e código não confiáveis recebem o mesmo poder que você.** O ficheiro de definições de um repositório podia executar hooks e enviar a chave de API antes da caixa de confiança ([Check Point, CVE-2025-59536](https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/)). Um prompt num issue do GitHub fez a GitHub Action do Claude Code ler o ambiente do runner e revelar a sua chave de API ([Microsoft](https://www.microsoft.com/en-us/security/blog/2026/06/05/securing-ci-cd-in-agentic-world-claude-code-github-action-case/)). Um plugin de um marketplace com um hook escondido enviou código para o servidor de um atacante ([PromptArmor](https://www.promptarmor.com/resources/hijacking-claude-code-via-injected-marketplace-plugins)), e em outubro uma cópia adulterada da extensão do Claude Code esteve no marketplace do Cursor ([Cursor](https://cursor.com/blog/claude-code-extension-security-notice)). O que foi corrigido está corrigido; o padrão fica. **5. Subagentes que lançam subagentes.** Uma sessão queimou mais de 600 dólares ([#72732](https://github.com/anthropics/claude-code/issues/72732)); outra iniciou cerca de 242 agentes antes de o utilizador escrever `/exit` ([#69332](https://github.com/anthropics/claude-code/issues/69332)). A resposta de um mantenedor em #72732 diz que os limites de subagentes simultâneos e de profundidade de aninhamento foram acrescentados nas versões 2.1.217 e 2.1.219. ## O que o Claude Code lhe dá e o que vem ligado por omissão Cada controlo abaixo é real e está documentado. A coluna que importa é a terceira. | Controlo | O que faz | Por omissão, outubro de 2026 | | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Modo de permissões](https://code.claude.com/docs/en/permission-modes) | O manual pede confirmação antes de editar e executar; o modo auto deixa um modelo classificador aprovar por si | O modo auto é o modo inicial das sessões interativas desde a v2.1.283 | | Classificador do modo auto | Bloqueia as ações que considera inseguras | Ligado com o modo auto. Números de [março de 2026](https://www.anthropic.com/engineering/claude-code-auto-mode) da Anthropic: falhou 17% de 52 ações reais demasiado ousadas | | [Regras deny, ask e allow](https://code.claude.com/docs/en/permissions) | Bloqueiam ou forçam um pedido para as chamadas de ferramentas correspondentes, em todos os modos | Nenhuma até as escrever | | [Sandbox do Bash](https://code.claude.com/docs/en/sandboxing) | Limites impostos pelo sistema operativo a ficheiros e rede para comandos de shell | Desligada. Só shell; lê `~/.ssh` a menos que o negue | | [Hooks](https://code.claude.com/docs/en/hooks) | O seu script corre antes de cada chamada de ferramenta e pode bloqueá-la | Nenhum | | [Checkpoints e `/rewind`](https://code.claude.com/docs/en/checkpointing) | Desfazem as edições de ficheiros do Claude | Ligados, mas os ficheiros alterados só pelo Bash não são registados | | Caixa de confiança, aprovação do `.mcp.json` | Perguntam antes de confiar numa pasta ou nos servidores MCP de um projeto | Ligados em modo interativo; uma sessão `-p` não mostra nenhum | | [Definições geridas](https://code.claude.com/docs/en/managed-settings) | Uma organização fixa modos, regras e hooks | Não implementadas, a menos que a sua empresa o faça | Este é o caminho de uma chamada de ferramenta. Os passos a vermelho são os que uma instalação nova deixa vazios ou desligados: 1. **O Claude propõe uma chamada de ferramenta**. Editar um ficheiro, executar um comando de shell, chamar um servidor MCP. 2. **Hooks PreToolUse**. O seu script vê a chamada completa e pode bloqueá-la. Nenhum por omissão. 3. **Regras deny e ask**. Comparam o comando tal como está escrito. Nenhuma por omissão. 4. **Modo de permissões**. O manual pergunta-lhe a si, o modo auto pergunta a um classificador, o bypass não pergunta a ninguém. 5. **Sandbox**. Limites do sistema operativo a ficheiros e rede, só para comandos de shell. Desligada por omissão. 6. **A chamada corre com o acesso do seu utilizador**. Depois deste ponto, só o git e as cópias de segurança ajudam. *Figura 2. As camadas entre uma chamada de ferramenta proposta e os seus ficheiros, com os valores por omissão no Claude Code em outubro de 2026.* O `--dangerously-skip-permissions` tem uma linha própria na documentação: «Use este modo apenas em ambientes isolados, como contentores ou VMs, onde o Claude Code não possa causar dano.» As regras deny e os hooks avaliam o comando como texto, por isso um comando escrito de outra forma ainda pode passar, e um hook corre com todo o seu acesso. É por isso que são uma só camada, e o git, as cópias de segurança e as credenciais separadas são as outras. ## Como configurar o Claude Code em segurança Por ordem de valor por minuto: 1. **Faça commit antes de começar, e muitas vezes.** Os checkpoints não cobrem ficheiros alterados por um comando de shell. O git cobre. 2. **Mantenha as credenciais de produção fora da pasta do agente.** Num relato, os scripts descartáveis de um subagente executaram `DELETE FROM` em todas as tabelas porque as credenciais de produção estavam sem comentário no `.env` local ([#64056](https://github.com/anthropics/claude-code/issues/64056)). Uma base de dados de desenvolvimento que o agente possa estragar não tem problema; uma de produção a que ele chegue é o incidente. 3. **Escreva regras deny para os comandos que destroem.** Aplicam-se em todos os modos, incluindo o bypass: ```json { "permissions": { "deny": [ "Bash(git reset --hard *)", "Bash(git push --force *)", "Bash(git push -f *)", "Bash(git checkout -- *)", "Bash(git clean *)", "Bash(terraform destroy *)", "Bash(drizzle-kit push --force *)", "Bash(prisma migrate reset *)", "Read(./.env)", "Read(./.env.*)" ] }, "sandbox": { "enabled": true, "allowUnsandboxedCommands": false } } ``` 4. **Ative a sandbox** (`/sandbox`) e desligue a repetição sem sandbox, como acima. Acrescente `filesystem.denyRead` para `~/.ssh` e para as pastas de credenciais na cloud, já que a sandbox as lê por omissão. 5. **Acrescente um hook `PreToolUse` para o que as regras de texto não veem.** Uma regra deny não vê `git -C . push --force` nem um apagamento em Python; um script curto que olhe para o comando inteiro vê. Comece pelos cinco comandos que mais lhe doeriam. 6. **Trate o conteúdo não confiável como código.** Abra repositórios desconhecidos num contentor ou numa VM, dê às execuções de CI tokens com âmbito limitado e lembre-se de que uma sessão `-p` não mostra caixa de confiança. Um plugin ou servidor MCP corre com os seus privilégios; a Anthropic diz que «não audita a segurança nem gere qualquer servidor MCP». 7. **Limite as execuções longas.** Use `--max-budget-usd` para trabalho sem supervisão e vigie o número de subagentes. Se o agente constrói sobre o Supabase, o mesmo raciocínio vale para as chaves: a chave secreta que usa em scripts ignora todas as policies, como mostrei em [anon key vs service role key](https://madsalt.tech/pt/blog/supabase-anon-key-vs-service-role-key/). A lista mais ampla do que as apps criadas com IA fazem mal está em [riscos de segurança do vibe coding](https://madsalt.tech/pt/blog/vibe-coding-security-risks/), e como os agentes falham em execuções longas está em [o que se partiu na minha orquestração multiagente](https://madsalt.tech/pt/blog/multi-agent-orchestration-what-broke/). ## Perguntas frequentes **O Claude Code pode apagar os meus ficheiros?** Sim. No modo Manual pergunta antes, mas um comando aprovado pode chegar a tudo a que o seu utilizador chega; com os modos de aprovação automática pode não perguntar. 11 dos relatos acima são apagamentos de ficheiros. O git e as cópias de segurança são a solução que funciona sempre. **O `--dangerously-skip-permissions` é seguro?** Só num contentor ou numa VM sem nada que não possa perder, segundo a documentação da Anthropic. As regras deny e os hooks continuam a aplicar-se nesse modo; os pedidos de confirmação não. **O modo auto é seguro?** Mais seguro do que aprovar tudo por reflexo. A Anthropic mediu uma taxa de falsos positivos de 0,4% e disse que falhou 17% das ações reais demasiado ousadas no seu teste de março de 2026, e chamou-lhe «não um substituto direto de uma revisão humana cuidadosa em infraestrutura de alto risco». **O Claude Code envia o meu código à Anthropic para treino?** Nos termos comerciais (Team, Enterprise, API), a Anthropic diz que não treina com o seu código nem com os seus prompts, a menos que o aceite. Nos planos de consumidor é uma definição que controla. Os detalhes estão na [página de utilização de dados](https://code.claude.com/docs/en/data-usage). **O modo auto é o mesmo que o `--dangerously-skip-permissions`?** Não. A Anthropic criou o modo auto para substituir essa opção: um classificador continua a rever os comandos de shell, as chamadas de rede e a criação de subagentes, e após 3 recusas seguidas ou 20 no total pára e devolve-lhe o controlo. A opção não revê nada.