Domingo, onze da noite. Você passou o fim de semana montando o app de orçamentos da empresa, só conversando com a ferramenta. O cliente deixa nome, telefone e o que precisa, e o pedido chega organizado. Amanhã cedo o link vai para a carteira inteira. É o seu primeiro app feito com IA, e ele funciona.
A cena é hipotética, mas a pergunta que falta nela é bem real: quem mais consegue ver esses cadastros? Funcionar e estar pronto para receber dados de clientes são coisas diferentes. A ferramenta fez o que você pediu. Porém, ninguém pediu para ela trancar a porta.
Não quero que você desista de criar com IA. Quero que você publique com quatro checagens feitas, as mesmas do Reel de hoje, com o lugar onde clicar no Lovable, no Bolt, no Replit e no Supabase.
Por que um app feito com IA pode expor dados de clientes
Lovable, Bolt e Replit deixam qualquer pessoa criar um site ou app conversando, sem programar. Muitos desses apps guardam as informações no Supabase, que é, em termos simples, o lugar onde o app guarda os dados dos seus clientes. O risco não está em usar essas ferramentas, e sim em publicar sem conferir quem tem acesso a quê.
Em fevereiro de 2026, a empresa de segurança Wiz relatou o caso do Moltbook, uma rede social criada desse jeito. Segundo a Wiz, o Moltbook deixou 35 mil e-mails expostos, além de conversas privadas, e quem achasse a falha conseguia ler e alterar os dados. O problema foi corrigido depois do aviso dos pesquisadores.
Além disso, não se trata de um descuido isolado. A empresa de segurança Theori analisou 28 apps criados por ferramentas de IA que programam sozinhas e encontrou 434 falhas verificadas, segundo o relatório do estudo e a reportagem da Help Net Security de 23/07/2026. Entre as mais frequentes, falta de limite contra uso abusivo, chaves secretas no lugar errado e falhas de permissão que aumentam conforme o app cresce. A amostra é pequena e não foi comparada com apps escritos por pessoas. Ainda assim, mostra por onde começar.
Checagem 1: peça à própria ferramenta uma varredura de segurança
Primeiro, peça à ferramenta que revise o que ela mesma fez. Os caminhos abaixo vêm da documentação oficial, conferida em 05/10/2026. Como os menus mudam, procure nomes parecidos se não achar exatamente estes.
- Lovable: no projeto, clique em More e depois em Security. Run quick scan faz a revisão rápida; Run deep scan, a aprofundada, também lê a lógica do app atrás de chaves esquecidas e permissões erradas. As duas são gratuitas, segundo a página de segurança do Lovable; as correções pedidas no chat podem consumir créditos.
- Bolt: clique em Publish, no canto superior direito, e em Run security audit. Essa auditoria completa é dos planos pagos, informa o Bolt. No plano gratuito, o ícone Database, no alto, leva a uma opção Security que confere só a configuração dos dados (Bolt).
- Replit: abra Tools, Security Center e Run scan. Level 1 é gratuito e confere peças prontas, sem ler a lógica do app. Para isso, escolha Level 2 e Run scan with Agent: exige plano pago e pode haver cobrança pelo assistente, segundo o Replit.
Depois de cada varredura, corrija o que apareceu, confira se o app continua funcionando e rode de novo.
O que a varredura pega e o que não pega
A varredura pode apontar permissões abertas, chaves deixadas onde um visitante consegue copiar e problemas conhecidos nas peças prontas do app. O quanto ela pega depende da ferramenta e da modalidade.
Por outro lado, continua precisando de alguém olhar: se as permissões batem com a rotina da empresa, se um cliente alcança os dados de outro, o que acontece quando alguém usa o app de má-fé e o que está configurado fora do alcance da ferramenta.
Ou seja, resultado limpo quer dizer que aquela análise não achou problema, não que o app está seguro. O próprio Lovable avisa que os seus recursos não substituem uma revisão completa quando há dados sensíveis.
Checagem 2: no Supabase, cada cliente só vê o que é dele
O caso Moltbook ilustra esta checagem. Lá, a chave encontrada no site era a pública, aquela que pode ficar à vista. O problema foi outro: faltavam as regras que dizem quem pode ler o quê. Em outras palavras, a porta de entrada era a certa, mas o arquivo estava aberto.
Para conferir o seu app, entre no painel do Supabase, escolha o projeto, clique em Advisors e abra a aba Security, o Security Advisor (Supabase). Procure alertas como “RLS disabled in public” ou “Permissive RLS policy”. RLS é o nome técnico das regras que definem o que cada pessoa pode ver ou alterar. Na prática, um alerta desses indica que uma lista de dados pode estar acessível a quem não deveria.
Exemplo ilustrativo: numa clínica hipotética, a lista de agendamentos sem essas regras poderia deixar um curioso ver a agenda de todos os pacientes.
Agora, um cuidado: não saia apertando botões para fechar tudo. Uma regra mal feita pode travar o app, e uma regra que libera tudo continua perigosa, alerta o Supabase. O seu papel é achar o alerta e levar a quem mantém o sistema, com uma pergunta simples: cada cliente só vê o que é dele? Depois da correção, rode o Security Advisor de novo.
Checagem 3: a chave secreta fica fora do site
O Supabase usa dois tipos de chave. A publicável, que começa com “sb_publishable_” (ou a antiga “anon”), pode ficar no site, desde que as regras da checagem 2 estejam certas. A secreta, que começa com “sb_secret_” (ou a antiga “service_role”), é a senha mestra do app: passa por cima das regras de acesso, explica o Supabase.
Por isso, a secreta nunca vai para o site, para o chat da ferramenta, para um print ou para um grupo de WhatsApp. Fica só do lado que a empresa controla. Para ver quais chaves existem, abra o projeto no Supabase, clique em Settings e no menu de chaves do projeto (Keys).
Chave visível nem sempre é vazamento: a publicável foi feita para ficar à vista. Se aparecer a secreta, aí sim é hora de agir.
Vazou a chave secreta? Os primeiros minutos
- Chame quem mantém o app e descubra de qual serviço é a chave.
- Desative a chave vazada. No Supabase, crie a substituta, atualize os serviços que a usam e exclua a secreta vazada ou desative a antiga service_role. Criar uma chave nova não desliga a antiga, segundo o Supabase. Se o vazamento está acontecendo, desligue logo, mesmo que algo pare por um tempo.
- Não confie em apagar. Tirar a mensagem do ar não desfaz as cópias já feitas.
- Guarde a nova no lugar protegido do serviço, nunca numa configuração que o site entrega ao visitante.
- Investigue o que foi acessado. O que foi copiado não volta, mas saber o que saiu orienta os próximos passos.
- Chave de outro serviço, como pagamento ou e-mail, se desativa no próprio serviço.
Checagem 4: projeto e conversas só para quem precisa
Aqui mora uma confusão comum. Deixar o projeto privado não esconde o app publicado nem conserta as checagens 2 e 3. Quem entra onde você constrói e lê as conversas com a IA é uma coisa; quem visita o app pronto é outra.
- Lovable: no projeto, clique em Share e revise Project access, os convidados e os links de convite. Desde 22/04/2026, os projetos ficam privados para o seu espaço de trabalho em todos os planos, segundo o Lovable, e as conversas do projeto seguem esse acesso. Confira também, em Project settings, Sharing, a opção Public remixing, que deixa outras pessoas copiarem o projeto.
- Bolt: em Share, Project Access, troque “Anyone with the link” por No access e retire quem não precisa estar lá (Bolt). Como o chat é compartilhado com os participantes do projeto, proteger a conversa é limitar quem participa.
- Replit: clique em Invite, revise pessoas e grupos e escolha None para tirar o acesso de quem não precisa (Replit). Já o app publicado tem controle próprio: Publish, Who can access your app.
Quando chamar alguém de segurança
As quatro checagens reduzem o risco de erros comuns. Mesmo assim, não garantem segurança, e nenhuma varredura garante. Para um cardápio, um portfólio ou uma página de contato, elas tendem a bastar como primeiro passo.
Chame alguém que entenda de segurança antes de publicar quando o app:
- guarda dados pessoais de clientes, como CPF, endereço ou histórico de compras;
- recebe pagamentos ou se conecta a outros sistemas da empresa;
- tem áreas diferentes para clientes, equipe e administração;
- já está no ar e você não sabe responder às quatro checagens.
É aqui que eu entro. Eu construo sistemas próprios com IA para empresas e começo pelo uso: quem acessa, que dados entram e o que acontece se eles saírem. Depois, olho com você o que foi feito, aponto o que precisa mudar e ajusto dentro de um escopo combinado. Não é selo nem garantia, e sim a segunda leitura de quem constrói sistemas assim.
Seu app guarda dados de clientes? Antes de publicar, traga ele para uma conversa gratuita de 30 minutos comigo. Se fizer sentido seguir, o próximo passo é uma proposta com escopo claro.
O lançamento pode esperar um dia. O cadastro do seu cliente, depois de exposto, não volta.