10 Padrões de Prompts Perigosos no Claude Code | O Que Evitar e Alternativas Seguras

Você escreve prompts pensando “ele vai entender o que eu quis dizer”? O Claude Code executa instruções literalmente. Instruções vagas ou perigosas produzem resultados indesejados.

Este artigo aborda 10 padrões de prompts perigosos que causaram incidentes reais, junto com alternativas seguras para cada um. Se você reconhecer algum desses padrões após a leitura, mude imediatamente.

---

Padrão 1: “Leia tudo e entenda o projeto inteiro”

Por que é perigoso

❌ "Leia todo este repositório e entenda-o antes de implementar"

Executar isso em um repositório com centenas de arquivos faz o contexto explodir. Dezenas de milhares de tokens são consumidos e o processamento para com o erro Prompt is too long. Se parar no meio da leitura, a implementação prossegue com base em uma compreensão incompleta.

Além disso, se existirem arquivos contendo .env ou chaves secretas, todos são carregados no contexto.

Alternativa segura

✅ "Verifique a estrutura do diretório src/api/ e leia apenas os arquivos relacionados ao auth"
✅ "Leia apenas package.json e README primeiro para ter uma visão geral do projeto"
✅ "Use Grep para encontrar arquivos relacionados à autenticação antes de lê-los"

Ponto-chave: Limite explicitamente o escopo do que deve ser lido. O Claude Code tentará ler amplamente se não for especificado.

---

Padrão 2: “Se houver erro, retentar automaticamente”

Por que é perigoso

❌ "Se houver erro ao chamar a API externa, retentar automaticamente até ter sucesso"

Se um serviço externo estiver fora do ar, ele vai continuar martelando a API em um loop infinito. Há incidentes reais com dezenas de milhares de chamadas em uma hora, com contas chegando a centenas ou milhares de reais. Isso é especialmente comum em jobs batch noturnos que rodam sem serem notados até de manhã.

Alternativa segura

✅ "Se houver erro, retentar no máximo 3 vezes.
   Aguardar 1 segundo antes da 1ª tentativa, 4 segundos antes da 2ª, 16 segundos antes da 3ª.
   Se as 3 falharem, registrar o erro e parar o processamento"

✅ "Use o seguinte código para retentativas:
   withRetry(fn, { maxAttempts: 3, baseDelayMs: 1000 })"

---

Padrão 3: “Conecte diretamente ao BD de produção e verifique”

Por que é perigoso

❌ "Conecte ao BD de produção em DATABASE_URL, verifique a contagem de usuários e faça as correções"

O que começa como “apenas verificar” traz o risco de que as queries de correção subsequentes sejam executadas contra o BD de produção. Se após um SELECT vier acidentalmente um DELETE ou UPDATE, os dados de produção desaparecem. Conectar à produção facilmente aciona operações além do escopo pretendido.

Alternativa segura

✅ "Conecte ao BD de desenvolvimento (DATABASE_URL_DEV) e verifique a contagem de usuários.
   Não conecte à produção"

✅ "Gere a query mas não a execute.
   Eu vou revisá-la e executá-la eu mesmo"

✅ No CLAUDE.md:
"Executar queries contra DATABASE_URL de produção é proibido.
 Verifique primeiro no staging, execute somente após aprovação do usuário"

---

Padrão 4: Colar chaves de API diretamente no prompt

Por que é perigoso

❌ "Use QIITA_TOKEN=abc123def456 para postar no Qiita"
❌ "Use sk-ant-api03-xxxxx para chamar a API da Anthropic"

O conteúdo escrito em um prompt é salvo como histórico de conversa. É passado intacto ao delegar para sub-agentes. Permanece nos logs sob o diretório local .claude/ e pode vazar para o exterior acidentalmente via ferramentas de backup ou compartilhamento de código.

Alternativa segura

✅ "Use QIITA_TOKEN do .env para executar scripts/qiita-publish.mjs"
   ← O valor do token existe apenas no .env; apenas o nome da variável vai no prompt

✅ Leia a partir de variáveis de ambiente no seu script:
   const token = process.env.QIITA_TOKEN;
   if (!token) throw new Error("QIITA_TOKEN não está definido");

---

Padrão 5: “Resolva o conflito e faça push para produção”

Por que é perigoso

❌ "Há um conflito com o branch main. Resolva-o e faça push para produção"

git push --force pode ser escolhido como meio de “resolver o conflito.” Isso arrisca apagar commits de colegas de equipe. Além disso, “push para produção” pode resultar em um push direto que ignora CI/CD.

Alternativa segura

✅ "Verifique o conflito com o main e proponha uma estratégia de merge.
   Aguarde minha aprovação antes de realmente fazer o merge e o push"

✅ No CLAUDE.md:
"git push --force é proibido.
 Se force for necessário, use --force-with-lease e confirme com o usuário"

// .claude/settings.json
{
  "permissions": {
    "deny": [
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ]
  }
}

---

Padrão 6: “Delete todos os arquivos antigos e limpe”

Por que é perigoso

❌ "Delete todos os arquivos de dist/, .cache/ e os logs antigos para limpar"

Como “antigo” é ambíguo, arquivos necessários podem ser deletados. Em particular, diretórios .cache/ podem conter dados críticos específicos do SO ou de ferramentas. Especificar múltiplos diretórios de uma vez resulta em rm -rf dist .cache logs/, que pode se propagar a caminhos não desejados.

Alternativa segura

✅ "Delete apenas o conteúdo do diretório site/dist/.
   Deixe o próprio diretório. Não toque em nenhum outro diretório"

✅ "Me mostre a lista de arquivos a serem deletados antes de deletá-los para que eu possa confirmar.
   Delete após minha aprovação"

---

Padrão 7: “Aprove tudo automaticamente e execute de uma vez”

Por que é perigoso

❌ "Pule todas as confirmações intermediárias e execute tudo até o fim"
❌ "Execute com a opção --dangerously-skip-permissions"

O fluxo de aprovação é um mecanismo de segurança. Pulá-lo deixa o Claude Code prosseguir com o que julga ser “mais eficiente.” Isso pode significar rm -rf, force push ou escritas no BD de produção—tudo sem confirmação.

Alternativa segura

✅ "Liste os passos para esta tarefa primeiro.
   Após minha aprovação, execute um passo de cada vez e confirme o resultado a cada passo"

✅ Para automação, permita apenas operações confiáveis:
   "allow": ["Read(**)", "Glob(**)", "Bash(npm run test)"]

---

Padrão 8: “Atualize as migrations e organize o BD”

Por que é perigoso

❌ "Os arquivos de migration estão uma bagunça. Organize-os e deixe tudo atualizado"

“Organizar” pode ser interpretado como deletar arquivos de migration antigos. Se o histórico de migrations desaparecer, configurar novos ambientes ou fazer rollback se torna impossível. Se um comando do tipo migrate reset for executado, os dados de produção podem ser apagados.

Alternativa segura

✅ "Mostre a lista de arquivos de migration e apenas aponte duplicatas ou problemas.
   Não faça nenhuma alteração"

✅ "Verifique migrations não aplicadas e mostre o SQL que seria executado.
   Execute após minha aprovação"

✅ No CLAUDE.md:
"Não deletar arquivos de migration.
 Sempre obter confirmação do usuário antes de executar migrations contendo ALTER/DROP"

---

Padrão 9: “Atualize todos os pacotes para a versão mais recente”

Por que é perigoso

❌ "Os pacotes npm estão desatualizados. Atualize tudo para a última versão"

npm update ou npm install pacote@latest pode elevar versões principais. Se houver breaking changes, o build local pode passar mas o serviço pode cair após o deploy em produção. Quebras em cascata de dependências também são comuns.

Alternativa segura

✅ "Execute npm outdated e mostre a lista de pacotes que podem ser atualizados.
   Vou revisar separadamente qualquer coisa que eleve uma versão principal"

✅ "Atualize apenas pacotes com vulnerabilidades de segurança (detectadas pelo npm audit)"

✅ "Atualize apenas react e next.js para a última versão menor.
   Não eleve a versão principal"

---

Padrão 10: “Faça deploy primeiro, os testes podem esperar”

Por que é perigoso

❌ "Vou escrever os testes depois, faça o deploy primeiro por agora"
❌ "O CI é lento, pule-o com --no-verify e faça push"

Testes e CI não são “lentos”—eles estão “te protegendo.” O pior padrão é descobrir bugs em produção pela primeira vez após pulá-los. --no-verify desativa tudo incluindo git hooks, então o escaneamento de secrets e lint também são pulados.

Alternativa segura

✅ "Escreva os testes primeiro e faça deploy após passarem.
   Mesmo que a cobertura seja insuficiente, os caminhos principais estão OK"

✅ "Investigue por que o CI é lento e acelere-o aproveitando o cache.
   Não o pule"

✅ No CLAUDE.md:
"--no-verify é proibido.
 Nunca use nenhum meio de pular o CI"

---

Resumo: 3 Princípios para Escrever Prompts Seguros

Princípio 1: Especifique o escopo explicitamente “Tudo”, “todos” e “inteiro” são palavras de perigo. Especifique exatamente o que deve ser lido, alterado e deletado.

Princípio 2: Mantenha as etapas de confirmação Insira “verificar”, “propor” ou “mostrar a lista” antes de “executar”. Especialmente para operações que afetam a produção.

Princípio 3: Nunca coloque segredos nos prompts Chaves de API, senhas e strings de conexão vão no .env. Apenas nomes de variáveis vão nos prompts.

Frase perigosa	Alternativa segura
”Leia tudo"	"Leia apenas o diretório [X]"
"Retentar automaticamente"	"Retentar no máximo 3 vezes, depois parar"
"Conecte ao BD de produção"	"Verifique no BD de dev, eu executo em produção"
"Delete tudo e limpe"	"Delete apenas [X], me mostre a lista primeiro"
"Execute tudo de uma vez"	"Deixe-me confirmar os passos primeiro, depois prossiga”

O Claude Code apenas segue instruções—não tem intenção maliciosa. O perigo está na pessoa que dá instruções vagas. Desenvolver o hábito de escrever instruções específicas e com escopo claramente definido é o caminho mais rápido para prevenir incidentes.

Artigos Relacionados

• 7 Incidentes de Produção Reais com Claude Code e Procedimentos Completos de Recuperação
• O Guia Completo de Melhores Práticas de Segurança do Claude Code
• O Guia Completo de Permissões do Claude Code

Referências

• Guia Oficial de Segurança do Claude Code
• OWASP LLM Application Security