Agentes de Segurança com IA

A sua aplicação tem falhas de segurança. Toda aplicação tem. A questão é se você as encontra antes dos seus utilizadores.

É assim que uma falha de segurança parece na prática. Alguém cria uma conta na sua aplicação. Explora um pouco. Muda um número na barra de URL. De repente está a ver os dados privados de outro utilizador. Informações de faturação, documentos guardados, mensagens pessoais. Não porque seja um hacker. Mas porque nada na sua aplicação os impediu.

Esse é o tipo de bug com que a maioria das aplicações SaaS são lançadas. Não é um hack estilo filme. É apenas uma regra que falta e que diz "você só pode ver os seus próprios dados."

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

As cinco falhas com que a maioria das aplicações SaaS são lançadas

Estes são os problemas de segurança mais comuns em aplicações criadas por fundadores a solo, indie hackers e vibe coders. Nenhum deles exige conhecimentos de hacking para ser explorado. Um utilizador curioso com as ferramentas de desenvolvimento do browser consegue encontrar a maioria deles.

1. Utilizadores conseguem ver os dados uns dos outros

Você cria uma tabela na base de dados para guardar dados dos utilizadores. Perfis, documentos, definições, o que for. Por defeito, a maioria das bases de dados não liga quem está a pedir os dados. Se alguém os pede, a base de dados entrega.

A correção é uma regra que diz "só devolve as linhas que pertencem à pessoa que pergunta." Em termos de base de dados, isto chama-se segurança ao nível da linha. Pense nisso como um filtro que adiciona automaticamente "WHERE user_id = a pessoa que está autenticada" a cada consulta. Sem isso, qualquer utilizador autenticado pode pedir os dados de qualquer outra pessoa.

Esta é a falha de segurança mais comum em aplicações SaaS. Um utilizador muda um ID na URL ou abre as ferramentas de desenvolvimento do browser, e consegue ver coisas que não devia.

2. Alguém salta o login e acede diretamente ao seu backend

A sua aplicação tem uma página de login. Por trás do login, há endpoints de API que vão buscar e modificar dados. O frontend envia sempre o token de autenticação em cada pedido. Então você assume que cada pedido tem um token válido.

Mas alguém pode chamar os seus endpoints de API diretamente, sem usar o seu frontend. Pode usar ferramentas como curl ou Postman. Se o seu backend não verifica se há um token de autenticação válido em cada pedido, eles entram. Sem necessidade de login.

3. Chaves secretas à vista no browser

A sua aplicação comunica com serviços externos: processadores de pagamentos, fornecedores de email, APIs de IA. Cada serviço dá-lhe uma chave secreta. Algumas dessas chaves são seguras para expor no browser (como a sua chave publicável do Stripe). Outras não são (como a sua chave secreta do Stripe, a chave da API de email, ou a chave de administrador da base de dados).

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

4. A sua API diz mais do que devia

O endpoint do perfil do utilizador devolve os dados do utilizador para o frontend os mostrar. Mas o backend devolve tudo na linha da base de dados, não apenas o que o frontend precisa. Email, nome completo, IDs internos, estado da subscrição, talvez até hashes de palavras-passe.

Um utilizador chama a sua API e recebe os seus próprios dados. Tudo bem. Mas a resposta inclui 15 campos extra que o frontend nunca usa. Agora eles conhecem a estrutura interna dos seus dados. Pior ainda, se a falha #1 também estiver presente, podem obter esta informação detalhada de todos os utilizadores do seu sistema.

As mensagens de erro também fazem parte disto. Quando algo corre mal, a sua aplicação pode devolver o erro bruto da base de dados: "a coluna 'stripe_customer_id' não existe na tabela 'users'." Isso diz a um atacante exatamente como está estruturada a sua base de dados.

5. Regras de segurança do browser em falta

Os browsers têm funcionalidades de segurança integradas, mas só funcionam se a sua aplicação as ativar. São cabeçalhos HTTP que o seu servidor envia com cada resposta. Dizem ao browser coisas como:

• "Não deixa outros sites incorporar a minha aplicação num frame" (previne clickjacking)
• "Só executa scripts que eu explicitamente aprovei" (previne injeção de código)
• "Só aceita pedidos do meu próprio domínio" (previne ataques cross-site)

Sem esses cabeçalhos, a sua aplicação fica exposta a ataques que os browsers foram concebidos para bloquear. A maioria dos frameworks não os define por defeito.

Por que os scanners de segurança não ajudam

Há ferramentas que analisam o seu código à procura de problemas de segurança. O problema: elas marcam tudo o que parece errado, mesmo quando está correto.

Aqui vai um exemplo. A sua aplicação tem um job em background que processa pagamentos. Os jobs em background não têm um utilizador autenticado, por isso precisam de acesso de administrador à base de dados para funcionar. Um scanner vê "acesso de administrador à base de dados" e marca-o como uma vulnerabilidade crítica. Mas está correto. O job em background precisa desse acesso. Não é um bug, é como a funcionalidade funciona.

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

Numa análise real, isto acontece constantemente. O scanner reporta 87 problemas. Você lê todos eles. 82 são coisas que funcionam como esperado. Os 5 bugs reais estão enterrados num monte de falsos alarmes, e você não consegue perceber qual é qual sem um conhecimento profundo da sua própria base de código.

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

A solução em duas fases

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

.claude/
  commands/
    security.md          # Fase 1: 5 agentes analisam o seu código
    pentest.md           # Fase 2: 3 agentes tentam entrar
  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 (Reportadores): Cinco agentes leem o seu código e verificam as cinco falhas acima. Cada agente foca-se numa área. Também têm acesso à sua base de dados em tempo real, para poderem verificar o que está efetivamente implementado, não apenas o que o código diz. Resultado: um relatório com tudo o que parece errado.

Fase 2 (Exploradores): Três agentes tentam realmente entrar na sua aplicação em execução. Leem o relatório da Fase 1 e tentam explorar cada descoberta. Enviam pedidos reais, tentam ataques reais e registam o que acontece. Se não conseguirem realmente entrar, a descoberta é marcada como falso positivo e removida. Resultado: um relatório validado onde cada descoberta restante tem prova anexada.

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

Fase 1: cinco reportadores

Cada reportador é um agente de IA que se foca num tipo de problema de segurança. Todos correm ao mesmo tempo.

Auditor de Acesso à Base de Dados

Verifica se os utilizadores conseguem ver os dados uns dos outros. Liga-se à sua base de dados em tempo real e analisa as regras de acesso reais, não apenas o código. Encontra tabelas onde os dados dos utilizadores são guardados mas não existe nenhuma regra de "devolve apenas as suas próprias linhas". Também verifica funções da base de dados que têm mais permissões do que deviam.

Auditor de Validação de Entradas

Verifica todos os locais onde a sua aplicação aceita entradas dos utilizadores. Pode alguém escrever código num campo de formulário e fazê-lo executar? Pode alguém enviar uma string cuidadosamente elaborada que engana a sua base de dados para executar comandos? Pode alguém fazer upload de um ficheiro com um nome como ../../etc/passwd e ler ficheiros que não deveria? Este agente testa tudo isso.

Auditor de Login e Sessão

Verifica se o seu sistema de login é sólido. Há endpoints que deviam exigir login mas não exigem? Pode alguém chamar a sua API com um token de login falso ou expirado e ainda assim entrar? Pode um utilizador regular aceder a funcionalidades apenas de administrador ajustando o seu token? Há algo que impeça alguém de tentar milhares de palavras-passe?

Auditor de Fuga de Dados

Verifica o que a sua aplicação revela. As respostas da API devolvem campos extra que o frontend não usa? As mensagens de erro mostram detalhes internos da base de dados? Há chaves secretas no JavaScript do seu frontend que não deviam estar lá? Os dados sensíveis aparecem em URLs onde o histórico do browser ou os logs do servidor os podem capturar?

Auditor de Configuração

Verifica as definições de segurança da sua aplicação. Os cabeçalhos de segurança do browser estão ativos? A sua aplicação diz aos browsers para aceitar pedidos de qualquer site (não devia)? Os cookies de login estão configurados corretamente? Há vulnerabilidades conhecidas nos pacotes de que a sua aplicação depende?

Os cinco correm ao mesmo tempo. Cada um envia as suas descobertas como texto. Nenhum deles altera o seu código. Um orquestrador lê tudo e combina num único relatório.

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

É isto que separa estes agentes de um scanner de segurança normal.

Cada base de código tem coisas que parecem erradas mas estão corretas. Os agentes precisam de saber sobre elas antecipadamente. Caso contrário, vão sinalizá-las sempre, tal como qualquer outro scanner.

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

• Jobs em background que precisam de acesso de administrador à base de dados (não há utilizador autenticado, por isso o acesso de administrador é a única forma)
• Tabelas que armazenam dados públicos e são intencionalmente legíveis por todos
• Padrões de autenticação que vão buscar informações extra do utilizador durante o registo (necessário para coisas como obter o nome de um utilizador do Google)
• Chaves de API públicas que devem estar no browser (como a chave do site para proteção contra bots)
• Tabelas geridas por serviços de terceiros (o seu fornecedor de pagamentos sincroniza dados nas suas próprias tabelas)

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

Esta lista é a coisa mais eficaz que você pode escrever. Comece com 5 a 10 entradas. Depois de cada auditoria, adicione quaisquer falsos positivos que apareçam. Ao terceiro uso, os agentes eliminam 90%+ do ruído antes de chegar a você.

Os agentes também podem ligar-se à sua base de dados em tempo real e verificar o que está efetivamente implementado. O código diz o que devia ser verdade. Uma consulta à base de dados em tempo real mostra o que é verdade. Se um script de migração devia ter adicionado controlos de acesso a uma tabela mas falhou silenciosamente, a consulta ao vivo apanha isso. Isto remove uma categoria inteira de falsos alarmes: situações em que o código parece correto mas o deployment não corresponde.

Âmbito: verificar apenas o que mudou

Executar cinco agentes em toda a sua base de código cada vez é caro. Na maior parte do tempo, você só precisa de verificar o que mudou desde o último relatório.

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

As análises completas são para a primeira auditoria ou após uma grande refatoração. Tudo o resto tem âmbito para as alterações recentes.

Fase 2: três exploradores

A Fase 2 lê o relatório da Fase 1 e tenta realmente entrar na sua aplicação em execução. O servidor de desenvolvimento tem de estar a correr. Estes agentes fazem pedidos reais e tentam ataques reais.

Explorador de API

Chama os seus endpoints de backend diretamente. Tenta os ataques da falha #1 (mudar IDs para aceder aos dados de outros utilizadores), falha #2 (chamar endpoints sem token de login) e falha #3 (enviar caracteres especiais que podem enganar a base de dados). Regista cada pedido e resposta como evidência.

Explorador de Browser

Abre a sua aplicação num browser e tenta ataques das falhas #4 e #5. Escreve código em campos de formulário para ver se executa. Verifica se a sua aplicação pode ser incorporada na página de outro site (o que poderia enganar utilizadores a clicar em coisas). Copia um token de login, termina a sessão e tenta usar o token antigo para ver se ainda funciona.

Explorador de Login

Foca-se inteiramente na sua autenticação. Faz login como utilizador regular e tenta aceder a funcionalidades de administrador. Tenta modificar o token de login para mudar o ID de utilizador ou o nível de permissão. Envia 50 tentativas de login rápidas para ver se há algum limite de taxa. Testa o fluxo de redefinição de palavra-passe à procura de formas de reutilizar tokens.

Cada descoberta precisa de prova. O pedido exato que foi enviado e a resposta exata que voltou. Se um agente não consegue produzir prova de que o ataque funcionou, a descoberta é eliminada. É por isso que a Fase 2 elimina falsos alarmes: o agente tem de explorar o bug, não apenas dizer que pode existir.

O filtro em ação

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

As 82 descobertas eliminadas eram coisas como: acesso de administrador à base de dados num job em background (correto), tabelas públicas sem regras de acesso por utilizador (intencionalmente públicas), um padrão de autenticação específico usado durante o registo (necessário para essa funcionalidade), 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 utilizador dar-se a si próprio acesso de administrador ao atualizar o seu perfil. Outro deixava qualquer pessoa adicionar créditos ilimitados à sua própria conta. Um terceiro era um redirecionamento aberto no fluxo de pagamento que podia enviar utilizadores para um site falso após o checkout. Cada um veio com a alteração de código específica para o corrigir.

Sem a Fase 2, você obtém 87 itens e nenhuma ideia de quais importam. Com a Fase 2, você obtém 5 itens que são comprovadamente reais, com a evidência do ataque anexada.

Como executar

Dois comandos:

/security

Fase 1. Cinco agentes analisam ao mesmo tempo. Por defeito, verifica as alterações desde o último relatório. O relatório guarda em dev/reports/security/. Se encontrar problemas sérios, diz-lhe para executar a Fase 2.

/pentest

Fase 2. Lê o relatório da Fase 1. Inicia o seu servidor de desenvolvimento se ainda não estiver a correr. Três agentes tentam entrar ao mesmo tempo. O relatório validado guarda em dev/reports/pentest/.

Regras para construir isto você mesmo

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

Escreva a sua lista de exceções antes da primeira análise. Cada aplicação tem coisas que parecem erradas mas estão bem. Os agentes precisam dessa lista antecipadamente. Comece com os padrões que você sabe que estão corretos. Adicione falsos positivos de cada execução. A lista estabiliza após 2 ou 3 auditorias.

Dê aos agentes acesso à base de dados real, não apenas ao código. O código diz o que devia ser verdade. A base de dados em tempo real mostra o que é verdade. Se esses não corresponderem, você tem um problema que o código não consegue dizer-lhe.

Separe encontrar de provar. Os agentes da Fase 1 reportam qualquer coisa suspeita. Os agentes da Fase 2 tentam explorá-la. Pôr ambos os trabalhos num único agente cria um conflito. Ou reporta demasiado (com ruído) ou demasiado pouco (perde coisas). Duas fases com trabalhos diferentes produzem melhores resultados.

Exija prova, não opiniões. Nunca peça a um agente "isto é seguro?" Peça-lhe para mostrar o pedido e a resposta que prova que o ataque funcionou. A prova força verificação real. As opiniões convidam atalhos.

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

Inclua o que funcionou. O relatório da Fase 2 deve listar os ataques que falharam. Injeção bloqueada. Execução de script bloqueada. Pedidos cross-site bloqueados. Saber contra o que a sua aplicação se defende é tão valioso como saber contra o que não se defende.

Para além da segurança

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

Revisão de código. Os agentes da Fase 1 sinalizam problemas potenciais. Os agentes da Fase 2 escrevem testes falhados para provar que os problemas são reais. Falsos positivos eliminados da mesma forma.

Performance. Os agentes da Fase 1 identificam consultas lentas à base de dados e bundles de ficheiros grandes. Os agentes da Fase 2 executam benchmarks reais. Uma "consulta lenta" que demora 2 milissegundos em dados reais não é um problema real.

Conformidade. Os agentes da Fase 1 sinalizam padrões de tratamento de dados. Os agentes da Fase 2 rastreiam onde os dados realmente fluem para verificar se as sinalizações 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 semelhante a um que precisa.

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