Vibe coding e segurança: o que vaza sem você ver

Vibe coding é criar um aplicativo conversando com a IA, sem escrever código. Funciona, entrega rápido e já está rodando na sua empresa, provavelmente sem você saber. O problema é o que vem junto: senha visível no navegador, banco de dados aberto e ferramenta interna publicada na internet sem login.

Eu treino time de vendas com IA há anos, no Brasil e fora, e o que mudou nos últimos meses não é a capacidade da ferramenta de vibe coding. É quem está apertando o botão de publicar. Antes era o time de tecnologia, que tinha um processo chato de revisão no meio do caminho. Agora é o coordenador comercial que precisava de um painel de comissão pra ontem.

O que é vibe coding, na prática de quem não programa

Você descreve o que quer em português, a IA monta o aplicativo inteiro e te devolve um link que funciona. É isso. Não tem etapa de arquitetura, não tem revisão de código, não tem ninguém perguntando quem pode ver o quê.

O nome vibe coding vem do jeito como a coisa é feita: você vai pelo que parece certo, testando na tela, sem entender o que está embaixo. Enquanto o resultado é um controle de tarefas pessoal, ninguém se machuca. O risco aparece quando o aplicativo começa a guardar dado de cliente, número de pipeline ou proposta com valor.

E é aí que o vibe coding sai do território de tecnologia e entra no seu. Porque o dado que vaza é dado comercial, e a conversa difícil com o cliente vai ser sua, não do estagiário que montou a tela.

Vale separar duas coisas que costumam ser tratadas como a mesma. Usar IA pra te ajudar a pensar, escrever e analisar é uma discussão de método, e eu já escrevi sobre o uso do ChatGPT na equipe comercial de forma auditada. Usar IA pra construir e publicar um sistema que guarda dado de terceiro é outra discussão, com outro tamanho de risco, e é dessa que este post trata.

A confusão também acontece na outra ponta. Montar um assistente que responde pergunta e puxa informação é uma coisa, e eu detalhei o passo a passo de criar um agente de IA sem ser programador. Publicar um sistema com banco de dados atrás dele é vibe coding, e o cuidado necessário é maior.

Os 4 furos que a Wiz achou em aplicativo de vibe coding

Em setembro de 2025, a equipe de pesquisa da Wiz publicou uma investigação sobre a segurança de aplicativos gerados em plataformas de vibe coding. O achado: uma em cada cinco organizações que constroem nessas plataformas se expõe a risco por configuração errada.

Presta atenção nessa métrica, porque a imprensa traduziu errado e virou “20% dos aplicativos têm falha”. Não é isso. O número é de organizações expostas, não de aplicativos com defeito. A diferença importa: quem está exposto é a empresa, não um arquivo.

Os quatro padrões que eles encontraram repetidamente em aplicativo de vibe coding:

• Autenticação inteira dentro do navegador. A senha fica escrita no código que o navegador baixa. Qualquer pessoa que abra as ferramentas de desenvolvedor lê. Um dos exemplos reais que eles publicaram tinha a senha “marketingdocs2025” cravada no arquivo.
• Chave de API exposta no lado do cliente. A chave da OpenAI, do serviço de e-mail, do que for, viajando junto com a página. Quem achar, usa, e a conta é sua.
• Tabelas de banco de dados abertas pra qualquer um. A regra de permissão do banco ficou permissiva ou nunca foi ligada. Um jogo corporativo vazou dados pessoais e endereços de IP de todos os jogadores exatamente assim.
• Ferramenta interna publicada na internet sem nenhum login. Painel administrativo, base de conhecimento interna, chatbot treinado com informação sensível. Tudo no ar, achável por quem sabe procurar.

Olha a lista de novo pensando na sua operação. O item três é o painel de pipeline que alguém montou. O item quatro é o chatbot que você alimentou com o playbook comercial da casa. O vibe coding não inventou nenhum desses quatro furos. Ele só deixou qualquer pessoa criá-los sem passar por ninguém.

Repara também em quem estava do outro lado dessa pesquisa. A Wiz fez o trabalho junto com a Lovable, uma das maiores plataformas de vibe coding do mundo, que a partir dali mudou a instrução padrão da própria ferramenta e publicou um guia de boas práticas. Ou seja: a plataforma reconheceu o padrão de erro. Isso não é ataque de concorrente, é a indústria admitindo o furo.

90% dos aplicativos de vibe coding publicados têm pelo menos uma falha

Em junho de 2026 saiu o primeiro estudo sistemático de segurança de aplicativos de vibe coding rodando de verdade na internet, feito por pesquisadores independentes junto com a Microsoft e o centro de pesquisa CISPA, na Alemanha. Eles montaram um acervo de 10.517 aplicativos reais, sortearam 200 que estavam publicados e auditaram um por um, com validação humana no fim.

O resultado está no estudo sobre a (in)segurança de aplicativos feitos com vibe coding: dos 200 auditados, 180 tinham pelo menos uma vulnerabilidade, ou seja, 90%. No total foram 1.471 falhas confirmadas, e mais de três quartos delas classificadas como altas ou críticas.

Antes de olhar as falhas, dois números do mesmo estudo que dizem o que essa gente está construindo. Do acervo inteiro, 94% são aplicações web, o tipo de coisa que se acessa por link no navegador. E quase 12% delas estão publicadas, com endereço vivo e alcançável de fora. Não é protótipo guardado na gaveta. É sistema no ar.

A falha mais comum tem nome: controle de acesso quebrado. Apareceu em 75,5% dos aplicativos auditados. Em português de gestor: a tela decide quem pode ver o quê, e a decisão está no lugar errado ou não existe. Logo depois vem falha de criptografia, em 63%, que na prática quase sempre significa segredo guardado onde não devia.

E tem um dado que derruba a desculpa mais comum, a de que aplicativo pequeno é aplicativo seguro. Os repositórios menores tinham a maior densidade de falha por linha de código: 1,62 por mil linhas, contra 0,06 nos maiores. Ferramentinha de escritório não é mais segura por ser pequena. Ela é menos revisada.

Vale registrar também o tempo. A mediana de desenvolvimento desses projetos foi de 9,8 dias, e dois terços deles ficaram prontos em menos de um mês. Sistema grande, feito em duas semanas, sem revisão. O estudo é bem direto sobre o que isso significa: nessa velocidade, quase nenhuma revisão humana acontece antes de publicar.

Por que a IA erra isso mesmo sabendo que está errando

Essa é a parte que muda a conversa de “escolhe uma IA melhor” pra “conserta o processo”.

O mesmo estudo classificou as oito maneiras recorrentes de a falha nascer num projeto de vibe coding. Três delas descrevem exatamente o que acontece quando ninguém revisa:

• Obrigação esquecida. A IA escreve no próprio código que a verificação de senha é temporária e fica pra depois. O depois nunca chega e o aplicativo sobe aceitando qualquer login. Foram 102 casos, e 89% deles graves ou críticos.
• Desenho de demonstração. A IA projeta a coisa pra parecer funcionando, com chave fixa e criptografia de fachada. Não é dívida pra pagar depois, é como a peça foi desenhada. Foram 237 casos.
• Conserto que abre porta. O login para de funcionar, a pessoa pede “arruma isso”, e a IA arruma desligando a verificação. Foram 213 casos. É o vazamento nascendo de um pedido inocente.

O terceiro merece um parágrafo só. Um dos casos documentados no estudo é uma tela de login que passou a aceitar um e-mail e uma senha fixos, escritos no código, porque o serviço de autenticação estava dando erro e alguém pediu pra fazer funcionar. Funcionou. E virou porta dos fundos permanente, com a chave debaixo do tapete.

Agora o achado mais desconfortável de todos. Quando os pesquisadores repetiram os cenários e a IA reintroduziu a falha, em 32% das vezes ela demonstrou saber que aquilo era um risco de segurança, escreveu um aviso em comentário, e entregou o código inseguro de qualquer forma. Ela sabia. Avisou. E fez.

É o mesmo padrão que eu já descrevi na governança de IA em vendas: a máquina cumpre o pedido visível e ignora a obrigação invisível. Sem alguém do lado de fora cobrando a obrigação invisível, essencialmente, você tá jogando.

O prompt que reduz o furo, e o que piora

Aqui o estudo faz uma coisa que raramente se vê: testa o que funciona. Foram 360 execuções controladas, repetindo os mesmos cenários de vibe coding com configurações diferentes.

Na configuração normal, a IA recolocou a falha em 40% das rodadas. Trocando o modelo por um maior, caiu pra 33%. Trocando por um menor, ficou nos mesmos 40%. Modelo melhor ajudou pouco.

O que mexeu de verdade foi a instrução. Pedir que o código estivesse pronto para produção derrubou de 40% para 13% das rodadas. Pedir que a IA revisasse as próprias mudanças derrubou para 18%. Ligar uma instrução de segurança na ferramenta, coisa que dá trabalho e ninguém faz, derrubou para 22%.

E o resultado que ninguém espera: o prompt mais técnico, cheio de detalhe de especificação, subiu a taxa de 40% para 56%. A explicação dos pesquisadores é direta. Quanto mais detalhada a instrução, mais a IA segue a instrução ao pé da letra e menos usa o próprio julgamento de segurança. Especificação minuciosa desliga o senso crítico da máquina.

Traduzindo pra quem vai passar isso pro time: duas frases no fim do pedido valem mais que trocar de ferramenta. “Isso vai para produção” e “revise o que você acabou de fazer”. Custa zero e é a única mudança dessa lista que você consegue implantar hoje à tarde.

Onde o vibe coding encosta na sua operação comercial

Nada disso é hipótese distante, e o vibe coding já entrou na sua operação por baixo. Faz o inventário da sua casa e você vai achar:

• A proposta em página web que o time manda pro cliente, protegida por uma senha que está escrita no próprio código da página.
• O painel de pipeline ou de comissão que alguém montou num fim de semana, ligado direto no banco de dados.
• O chatbot interno alimentado com playbook, tabela de preço e histórico de negociação.
• A calculadora de ROI publicada na internet, que recebe nome, e-mail e faturamento de quem preenche.
• A base exportada do CRM que virou planilha e depois virou aplicativo.

Cada um desses itens é dado comercial. Tabela de preço vazada é margem entregue pro concorrente. Base de cliente vazada é problema de LGPD com nome, sobrenome e prazo de resposta. Histórico de negociação vazado é o seu próximo desconto sendo negociado pelo outro lado com a sua planilha na mão. A régua de o que pode e o que não pode sair da empresa está no post sobre dados sensíveis no ChatGPT.

O caso da proposta com senha é o mais comum e o mais mal resolvido de todos, e ele tem post próprio: os furos do aplicativo com IA na proposta e no painel. Em resumo: a pessoa pede pra IA “proteger a página com uma senha”, a IA faz, a página pede senha, todo mundo fica satisfeito. Só que a senha foi escrita dentro do arquivo que o navegador do cliente baixa. Quem receber o link recebe também a senha, e ela geralmente é a mesma de todas as outras propostas. E se você desconfia de que o time já usa e constrói coisa que você nem sabe que existe, aí a conversa é de shadow AI no comercial.

Tem uma analogia que eu uso pra diagnóstico de funil e serve inteira aqui. Vazamento sem origem conhecida obriga a quebrar a casa toda pra achar. Vazamento localizado se conserta trocando uma peça. A diferença entre os dois casos não é a gravidade do furo, é você saber onde ele está.

E o caminho não é proibir. Proibição não funciona: o time faz igual e não conta, e você perde até a visibilidade que tinha. O caminho é o que eu descrevi ao separar o medo real do medo genérico de IA fora de controle, que é saber o que existe, quem construiu e o que aquilo guarda.

Seis perguntas antes de o time publicar qualquer coisa feita com vibe coding

Você não precisa aprender a programar pra fechar a maior parte do risco. Precisa fazer seis perguntas e não aceitar resposta vaga. Se a pessoa que construiu não souber responder, a peça não sobe.

• Isso está no ar pra qualquer pessoa da internet? Abre o link numa janela anônima, sem estar logado. Se abriu, está público.
• Tem senha? Onde essa senha mora? Se a resposta for “está no código” ou “é uma senha só, igual pra todos”, a peça não guarda dado de cliente.
• Que dado real está aí dentro? Nome, e-mail, telefone, CNPJ, valor, tabela de preço. Dado de teste é uma conversa. Dado real é outra.
• Quem pode ver o quê? O vendedor consegue ver a carteira do colega trocando um número na barra de endereço? Foi essa a falha mais comum do estudo.
• Isso está ligado a alguma conta que gasta dinheiro? Chave de IA, de e-mail, de pagamento. Se estiver, quem achar a chave gasta no seu cartão.
• Quem é o dono disso quando quebrar? Ferramenta sem dono declarado é ferramenta que ninguém desliga na hora do problema.

Seis perguntas, dez minutos. Faz numa reunião de time, uma peça por vez. E anota a resposta em algum lugar, porque a lista das ferramentas de vibe coding que a sua operação usa é o único inventário que ninguém tem.

Se a resposta de alguma pergunta vier errada, a regra é simples e não tem meio-termo: tira o dado real de dentro e deixa a ferramenta rodando com dado de teste, até alguém que entende revisar. A peça continua útil, o risco sai. Ninguém precisa jogar duas semanas de trabalho no lixo. E pra transformar essas seis perguntas em rotina, em vez de lembrete de reunião, o caminho é a política de uso de IA em uma página, que é onde a régua de publicação passa a ter dono.

O ponto que fica

Vibe coding não é o vilão. É produtividade real, e time comercial que aprende a montar a própria ferramenta para de esperar fila de tecnologia pra resolver problema pequeno. Eu defendo isso e ensino isso.

O que não dá é publicar sem revisão e chamar isso de agilidade. Os números existem, são de junho de 2026, e dizem que nove de cada dez aplicativos publicados dessa forma têm pelo menos uma falha. A boa notícia é que a correção mais eficaz medida no estudo não foi ferramenta caríssima nem consultor de segurança: foi alguém pedindo revisão antes de subir. Esse alguém é você.

Perguntas frequentes

O que é vibe coding?

Vibe coding é criar um aplicativo descrevendo o que você quer em linguagem natural para uma IA, que gera e publica o sistema inteiro. O termo foi popularizado em 2025 e descreve um jeito de desenvolver em que a pessoa não revisa o código, só o resultado na tela.

Vibe coding é seguro?

Depende de quem revisa. O estudo de junho de 2026 que auditou 200 aplicativos de vibe coding publicados achou vulnerabilidade em 90% deles, e mais de três quartos das falhas eram altas ou críticas. A ferramenta não é o problema. A ausência de revisão antes de publicar é.

Como reduzir o risco de um aplicativo feito com IA?

Duas instruções medidas no estudo sobre vibe coding tiveram o maior efeito: pedir que o código esteja pronto para produção e pedir que a IA revise as próprias mudanças. A primeira derrubou a reincidência de falha de 40% para 13% das rodadas testadas. Depois disso, checar se a peça está pública, se guarda dado real e quem pode ver o quê.

Trocar por uma IA mais poderosa resolve?

Pouco. No mesmo estudo, o modelo maior reduziu a reincidência de falha de 40% para 33%, e o modelo menor não mudou nada. Instrução e revisão pesaram muito mais que capacidade do modelo.

O gestor comercial precisa entender de programação pra checar vibe coding?

Não. Precisa fazer perguntas de dono: isso está público, que dado real tem aí dentro, quem pode ver o quê, e quem é o responsável quando quebrar. Nenhuma dessas perguntas exige ler código.