Segurança em Ferramentas de AI Coding: o alerta que todo dev precisa ouvir

Se você usa Cursor, Windsurf, Claude Code ou qualquer ferramenta de AI coding no seu dia a dia — este artigo é para você.

A frase que organiza tudo o que vem abaixo é esta: a ferramenta roda com as SUAS permissões, não com as dela. Ela não precisa de nenhuma falha para ler o seu .env, o seu ~/.ssh ou o token que o gh guardou. Ela já pode, do mesmo jeito que você pode.

Nota de procedência, porque o assunto é justamente confiar em fonte: a versão anterior deste post abria com três estatísticas de terceiros (pontos numa discussão do Hacker News, um percentual de uma consultoria, uma demonstração acadêmica), todas citadas sem link. Eu não consegui rastrear nenhuma delas até a fonte, então elas saíram. Não substituí por outras: o argumento abaixo é estrutural e não precisa de estatística nenhuma para ficar de pé.

O modelo de permissão do seu editor

O ponto de partida não é um bug, é o desenho: no VSCode e nos editores derivados dele, extensão roda como você. Não há isolamento entre extensões, não há caixa de areia por padrão, e não existe uma lista de permissões que a extensão precise pedir antes de ler um arquivo. Se você consegue ler, ela consegue.

O caminho de abuso que decorre disso é sempre o mesmo:

Uma extensão aparentemente legítima (um tema, um snippet helper) solicitava permissões mínimas
Uma vez instalada, ela escaneava ~/.config/gh/, ~/.ssh/ e arquivos de ambiente
Tokens do GitHub, chaves SSH e credenciais de cloud eram exfiltrados para um servidor remoto
Com os tokens, atacantes faziam push de código malicioso em repositórios privados

O que isso tem a ver com ferramenta de AI coding? Tudo. Ferramentas como Cursor e Windsurf são extensões ou modificações do VSCode, elas rodam com as mesmas permissões que qualquer extensão. Se uma extensão de tema pode acessar seus tokens, uma AI tool também pode.

O que “acesso total” quer dizer, na prática

O modo de instalação mais comum dessas ferramentas é o irrestrito, porque é o que funciona na primeira tentativa. Vale olhar de frente o que ele autoriza:

Ler qualquer arquivo do projeto (incluindo .env com senhas)
Modificar arquivos sem aprovação explícita
Acessar terminais e executar comandos arbitrários
Fazer push para repositórios remotos
Instalar dependências que podem conter malware

O problema é cultural: a conveniência venceu a segurança. “Só mais rápido” virou “dá acesso total mesmo”. E no ecossistema de AI coding, onde o valor percebido é a velocidade, a segurança fica em segundo plano.

Os riscos reais

Vazamento de tokens e credenciais

Toda vez que você usa uma AI tool, o contexto enviado pode incluir:

# Exemplo: variáveis de ambiente que NUNCA devem ir para o prompt
GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG+bPxRfiCYEXAMPLEKEY
DATABASE_URL=postgresql://admin:senha123@prod-db:5432/mydb

Mesmo que a ferramenta não envie intencionalmente, muitas AI coding tools enviam o contexto completo do workspace para processamento. Um .env esquecido no diretório de trabalho pode vazar credenciais de produção.

Código proprietário em servidores de terceiros

Quando você usa Claude Code, Copilot, Cursor ou Windsurf, trechos do seu código são enviados para servidores das empresas para gerar sugestões. Isso pode ser:

Código de cliente: expondo lógica de negócio proprietária
Algoritmos core: a vantagem competitiva do seu produto
Bancos de dados e schemas: revelando a arquitetura interna
Chaves de API e endpoints internos: abrindo vetores de ataque

Algumas ferramentas oferecem modos “offline” ou “anônimos”, mas o padrão é envio para cloud.

Supply chain attack via AI

Este é um risco emergente e talvez o mais perigoso. Imagine:

Um pacote npm legítimo é comprometido
A AI tool, treinada em dados públicos que incluem esse pacote, sugere usá-lo
O desenvolvedor aceita sem questionar
O código malicioso entra no seu projeto via dependência recomendada pela AI

E o vetor não para na dependência que existe: o modelo também sugere pacote que não existe. Se ele erra o nome de forma consistente, alguém pode registrar esse nome, e a sugestão errada vira um pacote real, escrito por um estranho, que você instala confiando na ferramenta. O ataque não depende de o modelo ter sido comprometido; depende só de ele errar de um jeito previsível.

Boas práticas para manter o código seguro

1. Permissões mínimas (princípio do menor privilégio)

Configure suas AI tools com o mínimo de acesso necessário:

Cursor / Windsurf:

Desative permissão para executar comandos de terminal automaticamente
Restrinja o escopo de arquivos que a ferramenta pode ler
Ative modo “review before apply” para qualquer modificação

Claude Code:

Use a flag --dangerously-skip-permissions com moderação (nunca em produção)
Prefira o modo interativo onde cada ação requer confirmação
Configure allowedTools no claude.json para limitar o que a ferramenta pode fazer

Copilot:

Use a política de “excluded paths” para ignorar arquivos sensíveis
Configure o modo “anônimo” para código de clientes

2. Nunca inclua secrets no workspace da AI

# Crie um .env.example sem valores reais
# E mantenha .env no .gitignore

# Regra de ouro: se a AI tool pode ler, não coloque secrets lá

Use gerenciadores de secrets (1Password CLI, Doppler, AWS Secrets Manager, Vault da HashiCorp) para injetar credenciais no ambiente de execução, não no código.

3. Revise TODO código gerado por AI

Nunca aceite código de AI sem revisão humana. Pontos críticos:

Autenticação e autorização: a AI pode implementar algo que parece seguro mas tem falhas
Sanitização de input: SQL injection, XSS, command injection
Manipulação de arquivos: paths arbitrários, diretórios sensíveis
Criptografia: a IA tende a usar algoritmos inseguros ou implementações caseiras

Regra prática: Se você não entende completamente o código que a AI gerou, não faça merge.

4. Mantenha suas ferramentas atualizadas

O bug do VSCode foi corrigido em horas, mas só protege quem atualizou. Configure:

Atualizações automáticas para editor e extensões
Verificações regulares de versão das AI tools
Acompanhamento de CVEs relacionadas ao ecossistema (siga @GitHubSecurity, @vscode, e os security advisories das ferramentas)

5. Isole ambientes de desenvolvimento

Use containers ou máquinas virtuais para projetos sensíveis:

# Dockerfile.dev: ambiente isolado para AI coding seguro
FROM node:20-slim

# Sem tokens de produção no container
# Use variáveis de ambiente injetadas via docker-compose ou orquestrador

# Limite de rede
# --network=host só se absolutamente necessário

# Volume montado só para o código necessário
# Nada de ~/.ssh, ~/.config dentro do container

Para projetos de clientes, considere um ambiente separado onde a AI tool não tem acesso à rede corporativa ou a repositórios de produção.

6. Configure políticas de segurança do GitHub

Habilite branch protection rules para branches principais
Use CODEOWNERS para exigir revisão de código de membros específicos do time
Ative push protection para não permitir push de secrets
Configure Dependabot para alertar sobre dependências vulneráveis (inclusive as sugeridas pela AI)

Ferramentas e configurações para manter o código seguro

Extensões e plugins

Ferramenta	Propósito
Secret Scanner (GitHub)	Detecta secrets no código
TruffleHog	Escaneia repositórios por credenciais vazadas
GitLeaks	Verifica secrets em commits
Semgrep	Regras de segurança para AI-generated code
Socket.dev	Detecta supply chain attacks em npm/pip

Configuração prática para Cursor/Windsurf

// .cursorrules ou .windsurfrules
{
  "security": {
    "blockCommands": ["rm -rf", "curl | bash", "eval"],
    "allowedPaths": ["src/", "tests/"],
    "blockedPaths": [".env", ".ssh", "secrets/", "config/prod/"],
    "requireApproval": ["fileWrite", "commandExecution", "npmInstall"]
  }
}

CI/CD seguro com AI

Adicione etapas de segurança no pipeline que escaneiam especificamente código gerado ou modificado por AI:

# .github/workflows/security.yml
name: AI Code Security Scan
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scan for secrets
        uses: trufflesecurity/trufflehog@v3
      - name: Check for vulnerable dependencies
        run: npm audit --audit-level=high
      - name: SAST scan
        uses: github/codeql-action/analyze@v3

Conclusão

Ferramentas de AI coding não vão desaparecer — e nem deveriam. Elas aumentam produtividade de forma real. Mas o entusiasmo por velocidade não pode ignorar segurança.

O modelo de permissão do editor, o modo irrestrito que virou padrão de instalação, a cadeia de suprimentos que passa por uma sugestão, tudo aponta para a mesma conclusão: segurança em ferramenta de AI coding é responsabilidade de quem a usa, não de quem a fez.

Trate AI tools como trataria um estagiário talentoso mas inexperiente: dê acesso supervisionado, revise o trabalho, e nunca compartilhe senhas.

É assim que eu trabalho nos meus próprios repositórios: segredo fora do diretório do projeto, varredura automatizada rodando no CI a cada mudança, e nada de credencial de produção na máquina onde eu escrevo código. Nenhuma dessas três coisas me atrasa. E as três existem porque a ferramenta não tem como saber o que ela não deveria ver.

Douglas Haruo, engenheiro de software há 15 anos, cinco deles em risco e fraude numa fintech de pagamentos. haruo.dev