Agentes de Segurança com IA

Seu app tem brechas de segurança. Todo app tem. A questão é se você as encontra antes dos seus usuários.

Na prática, uma brecha parece assim. Alguém cria uma conta no seu app. Explora um pouco. Muda um número na barra de URL. De repente está vendo os dados privados de outro usuário. Informações de cobrança, documentos salvos, mensagens pessoais. Não porque seja hacker. Porque nada no seu app impediu.

Esse é o tipo de bug com que a maioria dos apps SaaS são lançados. Não é um hack estilo filme. É só uma regra faltando que diz "você só pode ver os seus próprios dados."

Este post explica um sistema que detecta esses bugs automaticamente. Dois comandos. Oito agentes de IA. A fase 1 encontra tudo que parece errado. A fase 2 tenta de fato invadir e prova quais problemas são reais. Só os bugs confirmados chegam ao relatório final.

As cinco brechas com que a maioria dos apps SaaS são lançados

Esses são os problemas de segurança mais comuns em apps criados por fundadores solo, indie hackers e vibe coders. Nenhum deles exige habilidades de hacking para explorar. Um usuário curioso com as ferramentas de desenvolvedor do browser encontra a maioria deles.

1. Usuários conseguem ver os dados uns dos outros

Você cria uma tabela no banco de dados para armazenar dados dos usuários. Perfis, documentos, configurações, o que for. Por padrão, a maioria dos bancos não liga para quem está pedindo os dados. Se alguém pede, o banco entrega.

A correção é uma regra que diz "só devolve as linhas que pertencem a quem está perguntando." Em termos de banco de dados, isso se chama segurança em nível de linha. Pense nisso como um filtro que adiciona automaticamente "WHERE user_id = o usuário logado" em toda consulta. Sem isso, qualquer usuário logado pode pedir os dados de qualquer outra pessoa.

Essa é a brecha de segurança mais comum em apps SaaS. Um usuário muda um ID na URL ou abre as ferramentas de desenvolvedor do browser e consegue ver coisas que não deveria.

2. Alguém pula o login e acessa seu backend diretamente

Seu app tem uma página de login. Por trás do login, existem endpoints de API que buscam e modificam dados. O frontend sempre envia o token de autenticação em cada requisição. Então você assume que toda requisição tem um token válido.

Mas alguém pode chamar seus endpoints de API diretamente, sem usar seu frontend. Pode usar ferramentas como curl ou Postman. Se seu backend não verifica um token de autenticação válido em cada requisição, essa pessoa entra. Sem precisar de login.

3. Chaves secretas expostas no browser

Seu app fala com serviços externos: processadores de pagamento, provedores de email, APIs de IA. Cada serviço dá uma chave secreta. Algumas dessas chaves são seguras para expor no browser (como sua Stripe publishable key). Outras não são (como sua Stripe secret key, chave de API de email ou chave admin do banco de dados).

Se uma chave secreta parar no código do seu frontend, qualquer pessoa pode abrir as ferramentas de desenvolvedor do browser, encontrá-la e usá-la. Podem enviar emails da sua conta, cobrar cartões de crédito ou acessar seu banco de dados com permissões de administrador.

4. Sua API diz mais do que deveria

Seu endpoint de perfil de usuário retorna os dados do usuário para o frontend exibir. Mas o backend retorna tudo na linha do banco de dados, não só o que o frontend precisa. Email, nome completo, IDs internos, status da assinatura, talvez até hashes de senha.

Um usuário chama sua API e recebe os próprios dados. Tudo bem. Mas a resposta inclui 15 campos extras que o frontend nunca usa. Agora ele conhece a estrutura interna dos seus dados. Pior: se a brecha 1 também existir, pode puxar essa informação detalhada de todo usuário do sistema.

Mensagens de erro também fazem parte disso. Quando algo dá errado, seu app pode retornar o erro bruto do banco: "column 'stripe_customer_id' does not exist in table 'users'." Isso diz a um atacante exatamente como seu banco está estruturado.

5. Regras de segurança do browser ausentes

Browsers têm recursos de segurança embutidos, mas só funcionam se seu app os ativar. São cabeçalhos HTTP que seu servidor envia com cada resposta. Eles dizem ao browser coisas como:

• "Não deixa outros sites incorporar meu app em um frame" (previne clickjacking)
• "Só executa scripts que eu explicitamente aprovei" (previne injeção de código)
• "Só aceita requisições do meu próprio domínio" (previne ataques cross-site)

Sem esses cabeçalhos, seu app fica exposto a ataques que os browsers foram feitos para bloquear. A maioria dos frameworks não os configura por padrão.

Por que scanners de segurança não ajudam

Existem ferramentas que varrem seu código atrás de problemas de segurança. O problema: elas sinalizam tudo que parece errado, mesmo quando está correto.

Um exemplo. Seu app tem um background job que processa pagamentos. Background jobs não têm usuário logado, então precisam de acesso admin ao banco de dados para funcionar. Um scanner vê "acesso admin ao banco" e sinaliza como vulnerabilidade crítica. Mas está correto. O background job precisa desse acesso. Não é um bug, é como o recurso funciona.

Isso se chama falso positivo. O scanner sinalizou algo que parece perigoso mas na verdade está bem.

Numa varredura real, isso acontece o tempo todo. O scanner reporta 87 problemas. Você lê todos eles. 82 são coisas funcionando como esperado. Os 5 bugs reais estão enterrados num monte de falsos alarmes, e você não consegue distinguir um do outro sem conhecimento profundo do seu próprio codebase.

O problema central: ferramentas de segurança não entendem sua lógica de negócio. Elas não sabem que seu background job precisa de acesso admin. Não sabem que sua tabela "ideas" é intencionalmente pública. Não sabem que seu fluxo de onboarding usa um padrão de autenticação específico de propósito. Elas só veem padrões que parecem perigosos e sinalizam.

A solução em duas fases

O pipeline são dois slash commands do Claude Code. Cada um dispara um time de agentes de IA que trabalham ao mesmo tempo.

.claude/
  commands/
    security.md          # Fase 1: 5 agentes varrem seu código
    pentest.md           # Fase 2: 3 agentes tentam invadir
  agents/
    security-auditor.md  # Regras que todos os agentes da Fase 1 seguem
dev/
  reports/
    security/            # Relatórios da Fase 1
    pentest/             # Relatórios da Fase 2

Fase 1 (Repórteres): Cinco agentes leem seu código e verificam as cinco brechas acima. Cada agente foca em uma área. Também têm acesso ao seu banco de dados ao vivo, para checar o que está de fato em produção, não só o que o código diz. Resultado: um relatório listando tudo que parece errado.

Fase 2 (Exploradores): Três agentes tentam de fato invadir seu app em execução. Leem o relatório da Fase 1 e tentam explorar cada achado. Enviam requisições reais, tentam ataques reais e registram o que acontece. Se não conseguirem de fato invadir, o achado é marcado como falso positivo e removido. Resultado: um relatório validado onde cada achado restante tem prova anexada.

O filtro entre as duas fases é o que faz isso funcionar. A Fase 1 captura tudo suspeito. A Fase 2 prova o que é real. Os falsos alarmes morrem na Fase 2 em vez de desperdiçar seu tempo.

Fase 1: cinco repórteres

Cada repórter é um agente de IA que foca em um tipo de problema de segurança. Todos rodam ao mesmo tempo.

Auditor de Acesso ao Banco de Dados

Verifica se usuários conseguem ver os dados uns dos outros. Conecta ao seu banco de dados ao vivo e analisa as regras de acesso reais, não só o código. Encontra tabelas onde dados de usuários são armazenados mas nenhuma regra de "devolve só as suas linhas" existe. Também verifica funções do banco com mais permissões do que deveriam ter.

Auditor de Validação de Entrada

Verifica todos os lugares onde seu app aceita input de usuários. Alguém pode digitar código num campo de formulário e fazê-lo executar? Pode enviar uma string elaborada que engana seu banco a rodar comandos? Pode fazer upload de um arquivo com nome como ../../etc/passwd e ler arquivos que não deveria? Esse agente testa tudo isso.

Auditor de Login e Sessão

Verifica se seu sistema de login é sólido. Existem endpoints que deveriam exigir login mas não exigem? Alguém pode chamar sua API com um token falso ou expirado e ainda assim entrar? Um usuário regular pode acessar recursos apenas de admin ajustando o token? Existe algo impedindo alguém de tentar milhares de senhas?

Auditor de Vazamento de Dados

Verifica o que seu app revela. Respostas de API estão retornando campos extras que o frontend não usa? Mensagens de erro estão mostrando detalhes internos do banco? Existem chaves secretas no JavaScript do frontend que não deveriam estar lá? Dados sensíveis estão aparecendo em URLs onde histórico do browser ou logs do servidor podem capturá-los?

Auditor de Configuração

Verifica as configurações de segurança do seu app. Os cabeçalhos de segurança do browser estão ativados? Seu app está dizendo aos browsers para aceitar requisições de qualquer site (não deveria)? Seus cookies de login estão configurados corretamente? Existem vulnerabilidades conhecidas nos pacotes que seu app usa?

Os cinco rodam ao mesmo tempo. Cada um envia seus achados como texto. Nenhum deles muda seu código. Um orquestrador lê tudo e combina em um único relatório.

A chave para menos falsos alarmes: consciência da lógica de negócio

É isso que separa esses agentes de um scanner de segurança comum.

Todo codebase tem coisas que parecem erradas mas estão corretas. Os agentes precisam saber sobre elas com antecedência. Caso contrário, vão sinalizá-las toda vez, igual a qualquer outro scanner.

A definição do agente inclui uma seção chamada "Exceções Documentadas." É uma lista de padrões que os agentes devem reconhecer e pular. Coisas como:

• Background jobs que precisam de acesso admin ao banco de dados (não há usuário logado, então acesso admin é o único jeito)
• Tabelas que armazenam dados públicos e são intencionalmente legíveis por todos
• Padrões de autenticação que buscam informações extras do usuário durante o cadastro (necessário para pegar o nome de um usuário do Google, por exemplo)
• Chaves de API públicas que devem ficar no browser (como sua site key para proteção contra bots)
• Tabelas gerenciadas por serviços de terceiros (seu provedor de pagamentos sincroniza dados nas próprias tabelas)

Cada exceção é específica: quando o padrão aparece e por que está correto. O agente verifica a lista de exceções antes de gerar um achado. Se um padrão corresponder, pula. Sem falso alarme.

Essa lista é a coisa mais eficaz que você pode escrever. Comece com 5 a 10 entradas. Após cada auditoria, adicione os falsos positivos que aparecerem. Na terceira execução, os agentes eliminam 90%+ do ruído antes de chegar a você.

Os agentes também podem conectar ao seu banco de dados ao vivo e verificar o que está de fato em produção. O código diz o que deveria ser verdade. Uma consulta ao banco ao vivo mostra o que é verdade. Se um script de migração deveria ter adicionado controles de acesso a uma tabela mas falhou silenciosamente, a consulta ao vivo pega isso. Isso remove uma categoria inteira de falsos alarmes: casos onde o código parece correto mas o deploy não bate.

Escopo: verificar só o que mudou

Rodar cinco agentes em todo o codebase toda vez é caro. Na maioria das vezes, você só precisa verificar o que mudou desde o último relatório.

O comando cuida disso automaticamente. Analisa a data do último relatório de segurança, encontra todos os arquivos que mudaram desde então e só manda esses arquivos para os agentes. Se nada relevante para segurança mudou, sai cedo.

Varreduras completas são para a primeira auditoria ou após uma grande refatoração. Todo o resto tem escopo para as mudanças recentes.

Fase 2: três exploradores

A Fase 2 lê o relatório da Fase 1 e tenta de fato invadir seu app em execução. O servidor dev precisa estar rodando. Esses agentes fazem requisições reais e tentam ataques reais.

Explorador de API

Chama seus endpoints de backend diretamente. Tenta os ataques da brecha 1 (mudar IDs para acessar dados de outros usuários), brecha 2 (chamar endpoints sem token de login) e brecha 3 (enviar caracteres especiais que podem enganar o banco). Registra cada requisição e resposta como evidência.

Explorador de Browser

Abre seu app num browser e tenta ataques das brechas 4 e 5. Digita código em campos de formulário para ver se executa. Verifica se seu app pode ser incorporado na página de outro site (o que poderia enganar usuários a clicar em coisas). Copia um token de login, faz logout e tenta usar o token antigo para ver se ainda funciona.

Explorador de Login

Foca inteiramente na sua autenticação. Faz login como usuário regular e tenta acessar recursos de admin. Tenta modificar o token de login para mudar o ID de usuário ou o nível de permissão. Envia 50 tentativas de login rápidas para ver se existe rate limiting. Testa o fluxo de recuperação de senha procurando formas de reutilizar tokens.

Cada achado precisa de prova. A requisição exata que foi enviada e a resposta exata que voltou. Se um agente não consegue produzir prova de que o ataque funcionou, o achado é descartado. É por isso que a Fase 2 elimina falsos alarmes: o agente precisa de fato explorar o bug, não apenas dizer que ele pode existir.

O filtro em ação

Numa auditoria real de um app SaaS em produção, os números ficaram assim:

Os 82 achados eliminados eram coisas como: acesso admin ao banco num background job (correto), tabelas públicas sem regras de acesso por usuário (intencionalmente públicas), um padrão de autenticação específico usado durante o cadastro (necessário para aquele recurso), mensagens de erro verbosas que só aparecem em modo de desenvolvimento (não em produção).

Os 5 bugs confirmados eram reais. Um deixava qualquer usuário dar a si mesmo acesso de admin ao atualizar o perfil. Outro deixava qualquer pessoa adicionar créditos ilimitados à própria conta. Um terceiro era um redirecionamento aberto no fluxo de pagamento que poderia enviar usuários para um site falso depois do checkout. Cada um veio com a mudança de código específica para corrigir.

Sem a Fase 2, você tem 87 itens e não sabe quais importam. Com a Fase 2, você tem 5 itens que são comprovadamente reais, com a evidência do ataque anexada.

Como rodar

Dois comandos:

/security

Fase 1. Cinco agentes varrem ao mesmo tempo. Por padrão verifica mudanças desde o último relatório. Relatório salvo em dev/reports/security/. Se encontrar problemas sérios, indica para rodar a Fase 2.

/pentest

Fase 2. Lê o relatório da Fase 1. Inicia seu servidor dev se ainda não estiver rodando. Três agentes tentam invadir ao mesmo tempo. Relatório validado salvo em dev/reports/pentest/.

Regras para construir isso você mesmo

O padrão funciona com qualquer banco de dados, qualquer framework, qualquer provedor de autenticação. Eis o que faz funcionar.

Escreva sua lista de exceções antes da primeira varredura. Todo app tem coisas que parecem erradas mas estão bem. Os agentes precisam dessa lista com antecedência. Comece com os padrões que você sabe que estão corretos. Adicione falsos positivos de cada execução. A lista estabiliza depois de 2 ou 3 auditorias.

Dê acesso ao banco de dados real, não só ao código. O código diz o que deveria ser verdade. O banco ao vivo mostra o que é verdade. Se esses não batem, você tem um problema que o código não consegue te contar.

Separe encontrar de provar. Agentes da Fase 1 reportam qualquer coisa suspeita. Agentes da Fase 2 tentam explorar. Colocar os dois trabalhos num único agente cria conflito. Ou reporta demais (barulhento) ou de menos (perde coisas). Duas fases com trabalhos diferentes produzem resultados melhores.

Exija prova, não opiniões. Nunca peça a um agente "isso está seguro?" Peça para mostrar a requisição e a resposta que prova que o ataque funcionou. Prova força verificação real. Opiniões convidam atalhos.

Todo achado precisa de uma correção. Não "considere melhorar sua segurança." A linha específica a mudar e o que mudar para. Um achado sem correção é um achado que fica numa pasta para sempre.

Inclua o que funcionou. O relatório da Fase 2 deve listar ataques que falharam. Injeção bloqueada. Execução de script bloqueada. Requisições cross-site bloqueadas. Saber do que seu app se defende é tão valioso quanto saber do que não se defende.

Além da segurança

O padrão de duas fases (encontrar tudo, depois provar o que é real) funciona para mais do que segurança.

Code review. Agentes da Fase 1 sinalizam problemas potenciais. Agentes da Fase 2 escrevem testes falhando para provar que os problemas são reais. Falsos positivos eliminados do mesmo jeito.

Performance. Agentes da Fase 1 identificam consultas lentas e bundles grandes. Agentes da Fase 2 rodam benchmarks reais. Uma "consulta lenta" que leva 2 milissegundos em dados reais não é um problema real.

Compliance. Agentes da Fase 1 sinalizam padrões de tratamento de dados. Agentes da Fase 2 rastreiam para onde os dados realmente fluem para verificar se os sinais importam. Uma função que processa dados analíticos anônimos não precisa de tratamento de consentimento de privacidade, mesmo que o padrão pareça com um que precisa.

Mesma ideia central sempre. Dê contexto suficiente para os agentes entenderem por que o código existe. Separe encontrar de provar. Filtre o ruído antes de chegar a você.