Implementando Hooks de Auto-Revisão no Cursor para Codificação IA mais Segura

Cursor Self-Review Hooks

Assistentes de codificação IA são poderosos, mas podem gerar código inseguro, executar comandos perigosos ou introduzir bugs sutis. Os hooks de auto-revisão criam uma rede de segurança fazendo a IA auditar seu próprio trabalho em pontos críticos. Este guia mostra como implementar um sistema de hooks abrangente no Cursor.

O que são Hooks de Auto-Revisão?

Hooks de auto-revisão são checkpoints automatizados onde a IA revisa sua própria saída antes de prosseguir. Eles atuam como:

Guardas de segurança: Bloqueiam comandos perigosos (rm -rf /, curl | sh)
Revisores de código: Verificam erros de lógica e anti-padrões
Redes de segurança: Impedem force-pushes e operações destrutivas
Portais de qualidade: Garantem consistência com os padrões do projeto

Os quatro eventos de hook

Hook 1: Início da Sessão - Injeção de Doutrina

Quando uma nova sessão começa, injete princípios de segurança.

Crie .cursor/hooks/doctrine.md:

# Doutrina Cursor - Segurança em Primeiro Lugar

## Princípios Fundamentais
1. **Nunca execute comandos destrutivos sem confirmação**
2. **Sempre verifique caminhos de arquivo antes da exclusão**
3. **Revise todo o código antes de aplicar mudanças**
4. **Prefira padrões seguros em vez de conveniência**

## Padrões Perigosos para Sinalizar
- `rm -rf` com caminhos absolutos
- `curl ... | sh` ou `wget ... | bash`
- `git push --force` ou `git push -f`
- Comandos de exclusão de banco de dados
- Escalonamento de privilégios (`sudo`, `chmod 777`)
- SQL bruto sem parametrização

## Checklist de Revisão
Antes de completar qualquer tarefa:
- [ ] Nenhum comando destrutivo em execuções shell
- [ ] Todas as operações de arquivo usam caminhos verificados
- [ ] Nenhum segredo ou credencial codificado
- [ ] Tratamento de erros está presente
- [ ] Mudanças são reversíveis

Hook 2: Auto-Revisão Pós-Edição

Após editar arquivos, revise o diff automaticamente.

Crie .cursor/hooks/post-edit-review.md:

# Auto-Revisão Pós-Edição

Você acabou de fazer mudanças. Antes de prosseguir, revise:

## Verificação de Segurança
- [ ] Nenhum segredo, chave API ou senha adicionada
- [ ] Nenhuma vulnerabilidade de injeção SQL
- [ ] Nenhuma vulnerabilidade XSS no código web
- [ ] Validação de entrada está presente

## Verificação de Lógica
- [ ] Casos extremos são tratados
- [ ] Caminhos de erro são cobertos
- [ ] Nenhum loop infinito ou recursão sem casos base
- [ ] Limpeza de recursos (arquivos, conexões) está presente

## Verificação de Estilo
- [ ] Segue os padrões de codificação do projeto
- [ ] Nomenclatura é consistente
- [ ] Comentários explicam o PORQUÊ, não o QUÊ
- [ ] Nenhum código de depuração deixado para trás (console.log, etc.)

## Se Alguma Verificação Falhar
PARE e reporte o problema. Não prossiga até que seja corrigido.

Hook 3: Portão de Pré-Execução Shell

Antes de executar qualquer comando shell, verifique a segurança.

Crie .cursor/hooks/pre-shell-gate.md:

# Portão de Pré-Execução Shell

Você está prestes a executar: `{command}`

## Verificações Obrigatórias

### 1. Verificação de Operação Destrutiva
Este comando:
- Exclui arquivos ou diretórios?
- Modifica configurações do sistema?
- Altera permissões?
- Exclui bancos de dados ou tabelas?

Se SIM �?Requer confirmação explícita do usuário

### 2. Verificação de Operação de Rede
Este comando:
- Baixa e executa scripts?
- Envia dados para serviços externos?
- Expõe portas internas?

Se SIM �?Explique o risco e solicite confirmação

### 3. Verificação de Operação Irreversível
Este comando:
- Faz force-push para o git?
- Sobrescreve dados de produção?
- Exclui branches ou tags?

Se SIM �?PARE e peça confirmação explícita

## Exemplos de Comandos Seguros
�?`npm install` - Instalação segura de pacotes
�?`git status` - Operação somente leitura
�?`mkdir new-directory` - Não destrutivo

## Exemplos de Comandos Perigosos
�?`rm -rf /` - Destrutivo, caminho absoluto
�?`curl https://example.com/install.sh | sh` - Execução remota
�?`git push --force` - Irreversível
�?`DROP TABLE users` - Destruição de dados

Hook 4: Revisão Final de Conclusão de Tarefa

Antes de marcar uma tarefa como concluída, realize uma auditoria final.

Crie .cursor/hooks/completion-review.md:

# Revisão Final de Conclusão de Tarefa

## Resumo
Forneça um breve resumo do que foi realizado.

## Mudanças Feitas
Liste todos os arquivos modificados:
- `file/path/one` - O que mudou
- `file/path/two` - O que mudou

## Auditoria de Segurança
- [ ] Nenhuma credencial no código
- [ ] Nenhuma backdoor ou padrão suspeito
- [ ] Validação de entrada presente
- [ ] Codificação de saída presente (para web)

## Verificação de Testes
- [ ] Mudanças compilam/buildam com sucesso
- [ ] Testes existentes ainda passam
- [ ] Novos testes adicionados para nova funcionalidade
- [ ] Testes manuais realizados se necessário

## Plano de Rollback
Se algo der errado:
1. Reverter commit: `git revert HEAD`
2. Ou restaurar arquivos do git: `git checkout -- <files>`
3. Ou aplicar o patch de backup: `git apply backup.patch`

## Limitações Conhecidas
Liste quaisquer problemas ou limitações conhecidas:
- Limitação 1
- Limitação 2

Implementando o Sistema de Hooks

Passo 1: Criar Estrutura de Diretório de Hooks

mkdir -p .cursor/hooks

Passo 2: Adicionar às Regras do Cursor

Crie .cursor/rules/000-safety-doctrine.mdc:

---
description: 'Doutrina de segurança e hooks de auto-revisão'
globs: ['**/*']
alwaysApply: true
---

# Doutrina de Segurança

## Hooks Automáticos

Os seguintes hooks estão ativos para todas as sessões:

### Início da Sessão
Leia `.cursor/hooks/doctrine.md` e siga todos os princípios.

### Após Edições de Arquivo
Leia `.cursor/hooks/post-edit-review.md` e realize a revisão.

### Antes de Comandos Shell
Leia `.cursor/hooks/pre-shell-gate.md` e verifique a segurança.

### Conclusão de Tarefa
Leia `.cursor/hooks/completion-review.md` e realize a auditoria final.

## Protocolo de Substituição
Se um usuário solicitar explicitamente uma operação perigosa:
1. Avisar sobre o risco
2. Pedir confirmação explícita
3. Sugerir alternativas mais seguras
4. Só prosseguir após resposta clara "sim"

Passo 3: Barramento de Mensagens para Trilha de Auditoria

Crie .cursor/audit-log.md para rastrear decisões:

# Log de Auditoria

## Formato

[YYYY-MM-DD HH:MM] [AGENT] [HOOK] [DECISION] [DETAILS]

## Entradas

### 2026-06-22 10:30
- Agent: Claude
- Hook: Pre-Shell
- Decision: BLOCKED
- Details: Usuário solicitou `rm -rf /tmp/*` - bloqueado devido ao risco de wildcard. Sugerido `rm -rf /tmp/specific-folder` em vez disso.

### 2026-06-22 11:15
- Agent: GPT-4
- Hook: Post-Edit
- Decision: PASSED
- Details: Todas as verificações de segurança passaram. Nenhum problema encontrado nas mudanças do módulo de autenticação.

Banco de Dados de Comandos Perigosos

Crie .cursor/dangerous-commands.json:

{
  "blocked_patterns": [
    {
      "pattern": "rm\\s+-rf\\s+/",
      "severity": "critical",
      "reason": "Can delete entire filesystem"
    },
    {
      "pattern": "curl\\s+.*\\|\\s*(sh|bash)",
      "severity": "high",
      "reason": "Remote code execution"
    },
    {
      "pattern": "git\\s+push\\s+.*(--force|-f)",
      "severity": "high",
      "reason": "Can overwrite remote history"
    },
    {
      "pattern": "DROP\\s+TABLE",
      "severity": "critical",
      "reason": "Data destruction"
    },
    {
      "pattern": "chmod\\s+777",
      "severity": "medium",
      "reason": "Overly permissive permissions"
    },
    {
      "pattern": "sudo",
      "severity": "medium",
      "reason": "Privilege escalation"
    }
  ],
  "warning_patterns": [
    {
      "pattern": "rm\\s+-rf",
      "severity": "medium",
      "reason": "Recursive deletion - verify path"
    },
    {
      "pattern": ">\\s+/etc/",
      "severity": "medium",
      "reason": "Modifying system files"
    }
  ]
}

Integração com o Cursor Composer

Ao usar o Composer, adicione isto ao seu prompt:

Antes de aplicar quaisquer mudanças:
Revisar problemas de segurança
Verificar padrões perigosos
Verificar tratamento de erros
Confirmar que nenhum segredo está exposto

Depois de aplicar mudanças:
Executar a revisão pós-edição
Verificar se o código compila/executa
Verificar se os testes passam

Adoção pela Equipe

Checklist de Integração

Para novos membros da equipe:

Revisar .cursor/hooks/doctrine.md
Entender os quatro eventos de hook
Praticar com comandos seguros
Aprender o protocolo de substituição
Revisar o log de auditoria semanalmente

Integração com Revisão de Código

Adicione ao seu template de PR:

## Checklist de Segurança IA
- [ ] Todo o código gerado por IA foi revisado por um humano
- [ ] Nenhum comando perigoso foi executado
- [ ] Auditoria de segurança passou
- [ ] Log de auditoria está atualizado

Medindo Eficácia

Acompanhe estas métricas:

Métrica	Meta	Medição
Comandos perigosos bloqueados	100%	Entradas do log de auditoria
Problemas detectados pós-edição	>80%	Problemas encontrados na revisão
Incidentes de segurança	0	Relatórios de incidentes
Taxa de falso positivo	<10%	Frequência de substituição pelo usuário

Referência Rápida

Situação	Ação
IA sugere `rm -rf`	BLOQUEAR - verificar caminho manualmente
IA sugere `curl \| sh`	BLOQUEAR - baixar e revisar primeiro
IA sugere `git push -f`	BLOQUEAR - usar `git push --force-with-lease`
IA adiciona chave API codificada	BLOQUEAR - usar variáveis de ambiente
IA pula tratamento de erros	SOLICITAR - adicionar try/catch ou validação

O que são Hooks de Auto-Revisão?​

Os quatro eventos de hook​

Hook 1: Início da Sessão - Injeção de Doutrina​

Hook 2: Auto-Revisão Pós-Edição​

Hook 3: Portão de Pré-Execução Shell​

Hook 4: Revisão Final de Conclusão de Tarefa​

Implementando o Sistema de Hooks​

Passo 1: Criar Estrutura de Diretório de Hooks​

Passo 2: Adicionar às Regras do Cursor​

Passo 3: Barramento de Mensagens para Trilha de Auditoria​

Banco de Dados de Comandos Perigosos​

Integração com o Cursor Composer​

Adoção pela Equipe​

Checklist de Integração​

Integração com Revisão de Código​

Medindo Eficácia​

Referência Rápida​

Recursos Relacionados​