Análise · security · 02/09/2026
O que o caso Moltbook ensina sobre segurança em código gerado por IA
A exposição de dados e credenciais mostra por que aplicações desenvolvidas com IA precisam passar por análise de vulnerabilidades, revisão dos controles de acesso e testes de segurança antes de chegar à produção.
Rener Menezes
Em fevereiro de 2026, pesquisadores da Wiz tornaram pública a descoberta de uma falha no Moltbook, rede social criada para agentes de IA. Segundo a equipe, uma configuração incorreta do Supabase permitia acesso não autenticado de leitura e escrita a todos os dados da plataforma. A revisão mapeou cerca de 4,75 milhões de registros, entre eles 1,5 milhão de tokens de autenticação de agentes, 35 mil endereços de e-mail e 4.060 conversas privadas; algumas mensagens continham credenciais de terceiros, incluindo chaves da OpenAI em texto simples.
Os pesquisadores também relataram que os 1,5 milhão de agentes registrados estavam associados a aproximadamente 17 mil proprietários humanos, uma proporção de 88 para 1, e que as credenciais expostas permitiam assumir contas de agentes. A Wiz informou o problema ao responsável pelo Moltbook, acompanhou sucessivas correções até o bloqueio do acesso e declarou ter apagado os dados consultados na pesquisa. O ajuste foi concluído em poucas horas.
O contexto da construção importa. O fundador do Moltbook havia afirmado publicamente que não escreveu uma linha do código da plataforma e que a IA transformou sua arquitetura em produto. Isso não prova que a IA causou a falha. Mostra algo mais útil: mudar quem produz o código não muda quem responde pela fronteira de acesso quando o produto chega à produção.
O caso não é sobre uma chave visível
A Wiz encontrou no JavaScript do cliente os dados de conexão e uma chave pública do Supabase. O próprio relatório ressalva que sua presença no navegador não caracteriza, sozinha, uma vulnerabilidade. A plataforma prevê esse uso quando o backend aplica políticas adequadas de Row Level Security (RLS).
No Moltbook, segundo os pesquisadores, essa linha de defesa não estava configurada. A chave que a interface precisava conhecer alcançava o banco sem a separação esperada entre identidades, tabelas e operações. Botões escondidos, filtros no cliente e rotas não exibidas não poderiam compensar essa ausência: quem repetisse a chamada diretamente contornaria a experiência visual sem contornar controle algum.
A distinção é importante porque segurança não consiste em retirar do navegador tudo que é público. Consiste em limitar o que cada identidade pode fazer com o que necessariamente é público. Confundir exposição de configuração com falha de autorização gera alarmes no lugar errado e deixa a fronteira real sem prova.
A responsabilidade não cabe no prompt
Um modelo consegue gerar uma tela de login, uma consulta e até uma política de RLS. Ele não conhece, por padrão, as regras que só a organização pode definir: quem pertence a qual cliente, quais papéis podem alterar um registro, quando uma operação exige privilégio administrativo e quais dados jamais devem chegar ao cliente.
Essas decisões formam o modelo de autorização. Se não aparecem no requisito, o código pode executar o fluxo demonstrado e ainda aceitar tudo que não foi expressamente negado. O risco não está apenas em uma resposta incorreta da IA. Está na possibilidade de uma equipe confundir funcionamento com autorização e liberar uma arquitetura cuja regra de acesso nunca foi declarada.
Responsabilidade, aqui, não significa que uma única pessoa precise revisar cada linha. Significa que a organização mantém uma cadeia de decisão identificável: alguém define as invariantes, a arquitetura as transforma em controles, os testes tentam violá-las e a liberação exige evidência de que continuam válidas. A IA pode participar de todas essas etapas; não pode ser o sujeito ao qual a decisão é atribuída.
Autorização precisa ser testada pelo que nega
Em uma aplicação com dados compartilhados, a política deve acompanhar cada linha e cada operação. Leitura, inserção, atualização e exclusão podem exigir regras diferentes. Uma tabela nova precisa nascer fechada, funções privilegiadas devem permanecer no servidor e mudanças de esquema não podem remover proteção silenciosamente.
O teste decisivo não é apenas confirmar que o usuário A lê o próprio registro. É demonstrar que A não lê nem altera o registro de B, que uma identidade de outra organização não atravessa a separação entre clientes, que um usuário anônimo não herda poderes autenticados e que uma credencial pública não executa operações administrativas.
Isso muda a prioridade da revisão. Uma falha de autorização conectada a dados de produção merece tratamento diferente de um achado isolado sem caminho explorável. A equipe precisa relacionar interface, identidade, credencial, API, política e dado para explicar não apenas que existe um erro, mas o que ele permite alcançar.
Produção exige uma prova de fronteira
Código por prompt reduz o custo de construir. Não reduz o custo de compreender a confiança distribuída pela aplicação. Antes da liberação, a organização precisa saber quais clientes e serviços chegam ao banco, quais poderes acompanham cada credencial, onde leitura e escrita são autorizadas e como essa separação foi verificada fora do caminho feliz da interface.
O caso Moltbook tornou visível uma falha conhecida em uma escala nova. A resposta não é rejeitar software construído com IA nem presumir que todo valor presente no frontend seja secreto. É tratar autorização como propriedade independente da funcionalidade e exigir evidência antes de conectar a demonstração ao dado real. O código pode nascer de um prompt; a decisão de quem acessa o quê continua humana e institucional.