Segurança em AI Coding: Boas Práticas para Claude Code (2026)

confira os nomes dos comandos e os modos de permissão na documentação do Claude Code antes de confiar neles.

Por que AI coding exige uma mentalidade de segurança diferente

O autocomplete da velha guarda só sugeria texto. Um agente de AI coding como o Claude Code é uma criatura fundamentalmente diferente: ele lê o seu repositório inteiro, roda comandos de shell de verdade, edita arquivos e chama ferramentas externas (MCP, web fetch, GitHub). Empilhe essas três capacidades e você tem uma superfície de ataque que o linting e o code review tradicionais nunca foram feitos para pegar.

A forma mais fácil de imaginar isso — emprestada de uma análise da Backslash Security (18 de setembro de 2025) — é tratar o agente como "um estagiário muito rápido com acesso root". Esse estagiário digita código dez vezes mais rápido que você, mas também pode dar um rm -rf no diretório errado, colar uma chave de API em um commit ou seguir obedientemente um "comando" escondido dentro de uma issue do GitHub que acabou de ler. Ele não é malicioso; só não tem contexto sobre o que é perigoso.

O insight-chave: o risco não é "a IA escreve código ruim". O risco mora nos privilégios (o que o agente pode fazer na sua máquina) e na confiança na entrada (em quem o agente acredita). Então a estratégia de segurança certa não é "ler cuidadosamente cada linha sugerida" — é construir guardrails sistemáticos: limitar privilégios, isolar o ambiente, controlar os dados que entram e saem e sempre manter um humano na decisão final. O resto deste artigo é como fazer cada camada, uma de cada vez.

Os 6 principais riscos de segurança do AI coding

Antes de corrigir qualquer coisa, você precisa saber contra o que está se defendendo. Aqui estão as seis categorias de risco que você mais encontra na prática, cada uma com um cenário concreto:

Esses seis riscos se mapeiam quase um a um nas seis boas práticas abaixo. Você não precisa fazer tudo de uma vez — mas, se pular uma camada, saiba exatamente qual risco está aceitando.

Boa prática 1 - Gerenciar segredos e dados sensíveis

Princípio raiz: um segredo não deve existir em nenhum lugar onde o agente consiga lê-lo em texto puro. Há quatro camadas de defesa, da mais barata à mais sólida:

1. Mantenha os segredos fora do repositório. Deixe o .env fora do Git com o .gitignore e prefira um gerenciador de segredos (Vault, Doppler, 1Password CLI, as variáveis de ambiente da sua CI) em vez de arquivos soltos. Você deveria fazer isso mesmo sem IA — a IA só piora as consequências.

2. Mantenha arquivos sensíveis fora do contexto do agente. A abordagem na documentação de segurança do Claude Code é usar permissions.deny com uma regra Read() no .claude/settings.json — o agente não terá permissão para ler arquivos que casem com o padrão:

{
 "permissions": {
 "deny": [
 "Read(./.env)",
 "Read(./.env.*)",
 "Read(./**/secrets/**)",
 "Read(./**/*.pem)",
 "Read(./**/*.key)"
 ]
 }
}

(Alguns guias mais antigos mencionam um arquivo .claudeignore. Se a sua versão da CLI ainda der suporte a ele, ótimo, mas permissions.deny com Read() é a abordagem recomendada pela documentação oficial.)

3. Varredura automática de segredos. Não confie no olho humano. Integre o gitleaks (ou git-secrets, TruffleHog) a um hook de pre-commit e à CI para bloquear qualquer commit que contenha uma chave antes que ela saia da sua máquina:

# pre-commit: block the commit if a secret is detected
gitleaks protect --staged --redact --verbose

4. Rotacione quando algo vazar. Se uma chave chegou ao contexto ou a um commit, trate-a como permanentemente comprometida — apagar o commit não basta, porque a chave pode já estar em logs/modelo/histórico. O procedimento certo: revogar a chave antiga -> emitir uma nova -> atualizar o gerenciador de segredos -> checar os logs de acesso em busca de anomalias. Prepare um runbook de rotação antes de precisar dele.

Boa prática 2 - Controlar permissões e rodar em uma sandbox

Esta é a camada de maior ROI. O Claude Code tem vários modos de permissão que decidem o que o agente pode fazer por conta própria:

Um aviso direto: o bypassPermissions (e a flag --dangerously-skip-permissions) é exatamente o que parece — perigoso. A palavra "dangerously" no nome é proposital. Nunca ligue isso onde você tem segredos reais, acesso a produção ou repositórios de clientes. Se precisar rodar o agente sem supervisão (jobs em lote, CI), faça isso dentro de uma sandbox, não na sua máquina principal.

No settings.json, aplique o menor privilégio: permita o que é seguro por padrão, pergunte para qualquer coisa arriscada e negue de vez o que nunca deveria rodar sozinho. Um template pronto para colar:

{
 "permissions": {
 "allow": [
 "Read(./src/**)",
 "Bash(npm run test:*)",
 "Bash(git status)",
 "Bash(git diff:*)"
 ],
 "ask": [
 "Bash(git push:*)",
 "Bash(npm install:*)",
 "Write(./src/**)"
 ],
 "deny": [
 "Bash(rm -rf:*)",
 "Bash(curl:*)",
 "Bash(sudo:*)",
 "Read(./.env)",
 "Read(./.env.*)"
 ]
 }
}

Isole com um contêiner. A forma mais forte de limitar o raio de dano é rodar o agente dentro de um devcontainer/Docker — monte só os diretórios de que ele precisa, corte acesso de rede desnecessário e mantenha as credenciais de produção de fora. Mesmo que o agente sofra prompt injection e rode um comando ruim, ele só consegue destruir a caixa, não a sua máquina. Para um mergulho mais fundo na configuração de permissões, veja o guia sobre como configurar as permissões do Claude Code com segurança.

Ou use a sandbox nativa (mais leve que o Docker). O Claude Code tem um comando /sandbox — isolamento em nível de SO, sem imagem para buildar e sem devcontainer para configurar: o Seatbelt embutido no macOS, bubblewrap + socat no Linux/WSL2. Ele isola o sistema de arquivos e a rede de forma parecida com um contêiner, mas inicia mais rápido e não precisa de instalação do Docker — uma boa opção quando você quer isolamento rápido para uma única tarefa (auditar um repositório desconhecido, rodar código não confiável) sem levantar um devcontainer completo. Observação: esta é uma camada diferente dos modos de permissão — um modo de permissão controla sobre o que o agente é perguntado antes de agir, enquanto a sandbox controla o que o agente de fato consegue fazer mesmo que rode um comando ruim. As duas se complementam, não se substituem. Um contêiner ainda é a escolha mais forte para um ambiente de desenvolvimento duradouro e de configuração complexa; a sandbox nativa serve para isolamento rápido e temporário. Veja a configuração completa em sandboxing do Claude Code.

Boa prática 3 - Bloquear prompt injection e conteúdo não confiável

Prompt injection é o risco mais característico e mais subestimado. O mecanismo: o agente não distingue de forma limpa entre as suas instruções e os dados que ele lê. Se esses dados contiverem uma frase imperativa, o agente pode tratá-la como uma tarefa a executar.

Fontes comuns de conteúdo não confiável:

• Issues / PRs / comentários no GitHub escritos por gente de fora.
• Páginas web que o agente busca quando você pede para ele "ler a doc nesta URL".
• Saída de um servidor MCP ou de uma ferramenta de terceiros.
• Arquivos de um repositório que você acabou de clonar mas ainda não leu.

Quatro princípios de mitigação, sem teoria complicada:

1. Nada de auto-aprovar ao lidar com entrada externa. No momento em que o agente começa a ler uma issue/página web/saída de MCP, volte a perguntar passo a passo — não deixe acceptEdits/bypass rodando.
2. Use o modo plan com fontes desconhecidas. Deixe o agente ler e propor, mas bloqueie a execução até você aprovar.
3. Isole. Lide com dados não confiáveis em uma sandbox sem segredos, como na boa prática 2.
4. Desconfie de "comandos educados". Se alguma saída de repente "sugere" que o agente rode um comando, instale um pacote ou leia um arquivo desconhecido — pare e leia com atenção. Esse é um sinal clássico de injection.

A documentação de segurança da Anthropic tem uma seção dedicada à defesa contra prompt injection; o princípio geral é manter o agente no modo de menor privilégio possível sempre que ele tocar em dados que você não controla.

O modo auto tem a própria defesa contra injection. Desde 08/2026, o modo auto é o modo inicial padrão nos planos Pro/Max/Team — o que torna isso diretamente relevante para a maioria dos leitores agora, e não só um caso de canto. O mecanismo: o classificador que revisa as ações no modo auto lê apenas as suas mensagens, as chamadas de ferramentas e o CLAUDE.md — ele nunca lê os resultados das ferramentas. Uma camada separada, do lado do servidor, varre os resultados das ferramentas em busca de conteúdo hostil antes de o Claude conseguir lê-los. Esta é uma defesa parcial, não uma garantia absoluta — não trate o modo auto como motivo para pular os quatro princípios de mitigação acima.

Boa prática 4 - Sempre revisar o código gerado por IA

A regra inegociável: nunca faça merge de código de IA sem um humano no loop. A alta velocidade da geração de código facilita cair no "merge cego" — e é aí que a maioria das vulnerabilidades chega à produção.

O problema sutil é o AI slop: código que parece caprichado, tem nomes de variáveis bonitos, tem comentários e roda no happy path — mas pula a validação de entrada, deixa uma SQL injection aberta, cravou valores no código (hardcode) ou trata mal um edge case de segurança. Ele "parece certo", então escapa de um revisor apressado. Para saber como detectá-lo e evitá-lo, veja como evitar o AI slop ao revisar código.

Ligue o security-guidance para o Claude checar o próprio código enquanto escreve. Este é um plugin nativo que roda automaticamente, sem nada para você lembrar de invocar: 3 camadas se disparam sozinhas — (1) casamento de padrões instantâneo toda vez que o Claude edita um arquivo (sem chamada de modelo, de graça, pega padrões claros como eval(, os.system, dangerouslySetInnerHTML); (2) uma revisão em segundo plano no fim do turno, por padrão no Opus 4.7; (3) uma revisão agêntica mais profunda no momento do commit/push, que também lê os callers e sanitizers relacionados. Instale com /plugin install security-guidance@claude-plugins-official; personalize suas próprias regras via .claude/claude-security-guidance.md e .claude/security-patterns.yaml. Ele não bloqueia escritas nem commits — só traz os achados à tona para o Claude corrigir. Diferente do /security-review (item 2 abaixo), que é uma varredura única sob demanda, o security-guidance é uma camada contínua rodando em segundo plano ao longo de toda a sua sessão. Para uma varredura profunda, gratuita e com múltiplos agentes, veja o plugin claude-security no nosso artigo de auditoria de segurança.

Um fluxo de revisão prático:

1. Leia o diff, não a descrição. O agente dizer "adicionei validação" não significa que ele fez certo. Verifique no diff.
2. Rode o /security-review — o comando de revisão de segurança embutido no Claude Code — para varrer rapidamente as vulnerabilidades comuns (injection, segredos hardcoded, falta de auth) antes de revisar na mão.
3. Priorize as áreas sensíveis: autenticação, autorização, tratamento de entrada do usuário, queries no banco, comandos de shell, operações de arquivo.
4. Rode os testes e o seu linter/SAST como em qualquer outro PR — a IA não te dá dispensa da CI.

Para projetos que exigem mais rigor, monte um fluxo completo de auditoria de segurança para o Claude Code que rode em uma agenda, não só de forma pontual.

Boa prática 5 - Avaliar servidores MCP, plugins e usar hooks como guardrails

Todo servidor MCP ou plugin que você habilita é código de terceiros rodando com os privilégios do agente. Um servidor "conveniente", mas malicioso, pode ler arquivos, fazer chamadas de rede e exfiltrar dados sem você ver. Os princípios:

• Só habilite servidores confiáveis — prefira fontes oficiais com código público que você possa ler.
• Leia o código antes de instalar servidores menos conhecidos, especialmente os com amplo acesso a rede ou arquivos.
• Menor privilégio para MCP, assim como para o Bash — conceda só o escopo realmente necessário.

Para entender como o MCP funciona antes de avaliá-lo, leia o que é o MCP e como ele funciona.

Um hook PreToolUse como guardrail de última linha. Esta é uma camada subutilizada, mas muito poderosa: o hook roda antes de o agente executar uma ferramenta e pode bloquear de vez. Por exemplo, bloqueando padrões de comando perigosos:

#!/usr/bin/env bash
# .claude/hooks/pre-tool-use-guard.sh
# Read the JSON payload from stdin, block dangerous commands
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command // ""')

if echo "$cmd" | grep -Eq 'rm -rf|curl .*\| *(ba)?sh|:\(\)\{|dd if='; then
 echo "Blocked: dangerous command rejected by guardrail." >&2
 exit 2 # a non-zero exit code => Claude Code cancels the action
fi
exit 0

Registre esse hook para o evento PreToolUse no settings.json. A vantagem sobre depender só do deny: um hook permite lógica dinâmica (regex, checagem de variáveis, logging) e é uma rede de segurança mesmo que você habilite um modo frouxo sem querer.

O checklist de segurança do AI coding (copie e use agora)

Todas as boas práticas condensadas em uma lista acionável. Imprima ou cole no README do seu projeto:

1. [ ] Segredos: .env no .gitignore, use um gerenciador de segredos, sem chaves em texto puro no repositório.
2. [ ] Negar leituras: permissions.deny bloqueia Read() para .env, *.pem, *.key e diretórios de segredos.
3. [ ] Varredura: gitleaks (ou equivalente) roda no pre-commit e na CI.
4. [ ] Rotação: existe um runbook para revogar + reemitir chaves quando uma vaza.
5. [ ] Permissões: o settings.json segue o menor privilégio (allow/ask/deny), sem bypassPermissions fora de uma sandbox.
6. [ ] Sandbox: tarefas arriscadas rodam em Docker/devcontainer sem credenciais de produção.
7. [ ] Prompt injection: mude para o modo plan/ask ao lidar com issues, buscas na web ou saída de MCP.
8. [ ] Revisão: leia o diff + rode o /security-review + CI/SAST antes do merge, nunca faça merge no escuro.
9. [ ] MCP/plugin: só habilite servidores confiáveis cujo código você leu, com o escopo mínimo concedido.
10. [ ] Hooks: um guardrail PreToolUse bloqueia comandos destrutivos.
11. [ ] Revisão automática: o plugin security-guidance está ligado, revisando automaticamente toda vez que o Claude edita um arquivo.
12. [ ] Sandbox: o /sandbox está ligado para tarefas que precisam de um isolamento mais leve que o Docker.

Os limites reais e quando NÃO entregar para a IA

Sendo honesta: cada guardrail acima reduz o risco, não o apaga. Alguns limites que vale dizer com clareza.

A IA não substitui a modelagem de ameaças humana. Ela não entende o seu contexto de negócio, o quão sensíveis são os seus dados ou as consequências legais de um vazamento. A decisão "isto é seguro para automatizar" ainda é sua.

Não deixe o agente tocar em produção ou em segredos reais. Não conecte o agente a um banco de dados de produção, não conceda credenciais com acesso de escrita à infraestrutura e não o deixe fazer deploy livremente. Erros aqui não têm volta.

A fadiga de aprovação é um risco de verdade. Quando as perguntas de permissão aparecem com frequência demais, as pessoas começam a clicar em "permitir" no reflexo — derrotando justamente a defesa que montaram. A solução: ajuste o allow para as operações que são genuinamente seguras, de modo que as perguntas apareçam só para o que vale a pena considerar, em vez de desligar todas para acabar com a chateação.

Em resumo: use a IA para ir rápido, mas mantenha as decisões irreversíveis nas mãos humanas. Os guardrails existem para você ir rápido com confiança, não para você parar de pensar.

Padronize a segurança com um kit pronto

Escrever cada hook PreToolUse, cada template de settings.json e cada skill de revisão do zero para cada projeto fica cansativo — especialmente quando você quer um time inteiro no mesmo padrão. Um jeito de economizar tempo é um kit pronto que empacota skills de revisão de segurança e fluxos de guardrail para o Claude Code. O kit AgentKit para Claude Code reúne um conjunto de skills de revisão/fluxo para você não reconstruir do zero; se quiser ver se ele encaixa, você pode conferir os preços do AgentKit (20% de desconto pelo link) (Engineer Kit $99, o site não lista mensalidade, com atualizações vitalícias). Ainda assim, você deve ler e adaptar ao seu projeto — nenhum kit substitui entender o seu próprio modelo de ameaças.

Perguntas frequentes (FAQ)

Dá para usar AI coding com segurança em projetos reais?

Sim, se você montar os guardrails certos: mantenha os segredos fora de alcance, aplique permissões de menor privilégio, rode em uma sandbox e revise todo o código antes do merge. O risco vem de privilégios amplos demais e de entrada não confiável, não de usar IA em si. Sem guardrails o risco é alto; com eles, é controlável.

O Claude Code manda o meu código para algum lugar?

O Claude Code envia o contexto de que precisa para a API da Anthropic para processamento — é assim que ele funciona. Para limitar a exposição, use permissions.deny para bloquear a leitura de arquivos sensíveis, confira a política de retenção de dados na documentação da Anthropic e, para código extremamente sensível, isole-o em um ambiente dedicado.

Como impeço que chaves de API vazem pelo agente?

Três camadas: (1) nada de chaves em texto puro no repositório, use um gerenciador de segredos; (2) permissions.deny para bloquear o Read() em .env e arquivos de chave; (3) gitleaks no pre-commit e na CI para bloquear commits que contenham segredos. Se uma vazar, revogue e rotacione na hora — apagar o commit não basta.

Devo habilitar o bypassPermissions?

Quase nunca, numa máquina de trabalho de verdade. O bypassPermissions e o --dangerously-skip-permissions removem todas as camadas de aprovação — use-os só em uma sandbox isolada, sem segredos nem acesso a produção. Para o dia a dia, fique no default; ajuste o allow para reduzir as perguntas em vez de desligar todas.

Quanta revisão é suficiente para o código de IA?

Leia o diff em vez de confiar na descrição do agente, rode o /security-review, rode CI/SAST e testes como em qualquer PR e examine com cuidado as áreas sensíveis (auth, entrada, banco, shell). Fique de olho no AI slop — código que parece certo mas pula validação ou erra um edge case de segurança.

Dá para usar AI coding em projetos de cliente (com NDA)?

Só se o contrato permitir e você isolar bem: um workspace separado por cliente, nunca abra o agente sobre um diretório que guarde o código de outro cliente, sem credenciais reais no escopo, e confira os termos do NDA sobre envio de dados a serviços de terceiros antes de começar.

O modo auto se defende sozinho contra prompt injection?

Em parte. O classificador que revisa as ações no modo auto lê apenas as suas mensagens, as chamadas de ferramentas e o CLAUDE.md — ele nunca lê os resultados das ferramentas; uma camada separada, do lado do servidor, varre os resultados das ferramentas em busca de conteúdo hostil antes de o Claude lê-los. Esta é uma defesa parcial, não uma garantia absoluta — você ainda deve aplicar os quatro princípios de mitigação (nada de auto-aprovar em entrada desconhecida, use o modo plan, isole, desconfie de "comandos educados") ao lidar com conteúdo não confiável.

Conclusão e próximos passos

Segurança em AI coding não é um recurso que você liga ou desliga — são seis camadas de guardrails: segredos, permissões, sandbox, bloqueio de prompt injection, revisão de código e avaliação de MCP + hooks. Comece pelas duas camadas de maior ROI — permissions.deny para segredos e um settings.json de menor privilégio — e depois acrescente o resto com o tempo. Cole o checklist acima no README do seu projeto para o time todo seguir um só padrão.

Leia a seguir: como configurar permissões com segurança e uma auditoria de segurança completa. Se você quer um conjunto de skills de segurança pronto para o time todo, você pode dar uma chance ao AgentKit (20% de desconto pelo link) — mas sempre leia e adapte ao seu próprio modelo de ameaças.