Um app vibe coded exposto é um aplicativo criado com IA, publicado em uma URL pública, sem login ou com proteção mínima, que alguém da empresa colocou no ar sem passar por TI. Em maio de 2026, a empresa de segurança RedAccess disse ter encontrado cerca de 380 mil ativos públicos criados com ferramentas de vibe coding, dos quais cerca de 5 mil continham informação corporativa sensível. Este artigo é para quem responde por tecnologia, segurança ou risco e precisa saber, na prática, como descobrir esses apps, decidir o que fazer com cada um e evitar que o problema volte.
O que a pesquisa da RedAccess mostrou (e o que ela não prova)
A RedAccess, startup israelense de cibersegurança, analisou apps e ativos acessíveis publicamente criados em quatro plataformas: Lovable, Base44, Netlify e Replit. Segundo a cobertura do Security Boulevard, que resume as reportagens da Axios e da WIRED, o CEO Dor Zvi afirmou que cerca de 5 mil desses ativos continham informação corporativa sensível.
Os exemplos que a Axios verificou por conta própria dão a dimensão do tipo de dado em jogo:
- um app de empresa de navegação mostrando quais embarcações iam para quais portos;
- informações financeiras internas de um banco brasileiro;
- conversas de atendimento sem tarjas, de um fornecedor de armários;
- resumos de conversas entre médicos e pacientes em um app hospitalar.
O Tecnoblog noticiou o caso para o público brasileiro e destacou que os apps tinham poucas ou nenhuma barreira: quem achasse a URL acessava o conteúdo.
O que a pesquisa não prova. Os números de 380 mil e 5 mil são alegações da RedAccess; a Axios confirmou apenas os exemplos acima. As plataformas contestaram a leitura: o CEO da Replit, Amjad Masad, disse que um app público ser acessível é "comportamento esperado" e que a configuração de privacidade muda com um clique; Base44 e Lovable afirmaram que o relatório não trazia as URLs necessárias para verificação. Todas argumentaram que app acessível não é, por si só, uma falha ou violação.
Essa discordância é útil para quem decide: o problema não é a plataforma "ter um bug", é o app ter sido publicado com uma intenção (público) diferente da que a empresa precisava (restrito). A responsabilidade pela configuração mora em quem publica, e quem publica, num cenário de shadow IT, é gente fora do radar de TI. Se você quer o detalhe de quem cuida de quê numa plataforma específica, veja responsabilidade compartilhada no Replit.
Por que apps vibe coded viram o novo shadow IT
Shadow IT é qualquer tecnologia usada na empresa sem o conhecimento ou a aprovação de TI. Apps vibe coded herdam o problema clássico e o aceleram por três razões:
- A barreira de criação caiu. Quem não programa agora publica um app em horas. O app nasce no cartão corporativo ou na conta pessoal, não em um pipeline.
- O endereço é público por padrão em parte dos fluxos. Segundo o Security Boulevard, a RedAccess apontou que algumas ferramentas deixam a privacidade como pública e cabe ao usuário trocar manualmente. A própria Replit descreve o acesso público como comportamento esperado de um app publicado. Para o usuário comum, "publicar" soa como "disponibilizar para meu time", não "para a internet".
- Os apps são indexáveis. De acordo com a reportagem do Security Boulevard, muitos apps apareciam em buscadores, o que significa que o atacante não precisa de técnica sofisticada; uma pesquisa pode bastar.
Some a isso a observação da Checkmarx citada na mesma reportagem: a IA pode introduzir lógica insegura, dependências arriscadas, controle de acesso fraco ou segredos expostos mais rápido do que a revisão manual consegue acompanhar. É a mesma tese do shadow AI: proibir não funciona, porque a demanda existe; o que funciona é dar um caminho governado mais fácil que o caminho informal.
Cinco formas de exposição que a auditoria precisa procurar
Nem toda exposição é igual. Classifique o achado antes de decidir a resposta.
| Tipo de exposição | Como aparece | Risco típico |
|---|---|---|
| Sem autenticação | Qualquer pessoa com a URL acessa o app | Vazamento direto de dados exibidos na tela |
| Autenticação superficial | Pede só um e-mail, sem verificar domínio ou senha | Qualquer pessoa digita um e-mail e entra |
| Dados acessíveis por API | A tela exige login, mas a API ou o banco aceita chamadas sem checar permissão | Vazamento de todos os registros, não só os da tela |
| Segredos no código ou no front-end | Chaves de API e tokens visíveis no navegador ou no repositório | Uso indevido de serviços pagos e acesso a sistemas integrados |
| Indexação em buscadores | Página interna aparece em resultado de busca | Descoberta em massa, sem precisar saber a URL |
O terceiro tipo é o mais traiçoeiro: a interface parece protegida, mas a camada de dados não. Por isso a auditoria não pode parar em "a página pede login".
Como auditar: um roteiro em seis passos
Este roteiro é uma recomendação de prática, não uma metodologia padronizada de mercado. Adapte ao tamanho da sua operação.
1. Descubra quem está usando ferramentas de vibe coding
Comece pelo que a empresa já enxerga: faturas de cartão corporativo, relatórios de despesas, logs de login único (SSO) e DNS. Em paralelo, pergunte às áreas, com anistia explícita: "o que vocês já construíram?". Anistia importa: se quem confessa leva bronca, o inventário nunca fica completo. O mesmo princípio vale para o inventário de sistemas de IA, que deve incluir apps vibe coded como categoria própria.
2. Liste as URLs publicadas
Para cada conta ou time encontrado, exporte a lista de apps publicados e seus domínios. Plataformas de vibe coding hospedam apps em domínios próprios, o que facilita o levantamento externo: busque pelo nome da empresa, de produtos e de áreas nesses domínios.
3. Teste o acesso como um desconhecido
Abra cada URL em janela anônima, sem login e fora da rede corporativa. Anote o que aparece. Depois teste a camada de dados: o app expõe endpoints ou consultas que respondem sem sessão? Essa etapa deve ser feita por quem tem autorização para testar o ativo, normalmente segurança da informação ou o próprio dono do app com acompanhamento.
4. Classifique o dado exposto
Cruze cada app com a classificação de dados da empresa. Um app de sorteio de brindes e um app com conversas de clientes pedem respostas totalmente diferentes. Se a empresa ainda não tem classificação, governança de dados para IA é o ponto de partida.
5. Corrija em ordem de risco
- Dados pessoais ou sensíveis expostos: tire do ar ou restrinja o acesso imediatamente; depois investigue.
- Segredos expostos: revogue e gere novos; trocar a chave vem antes de entender como vazou.
- Dados internos não pessoais: restrinja o acesso e agende a revisão.
- Sem dado sensível: registre o app no inventário e siga o fluxo normal de aprovação.
6. Trate como incidente quando houver dado pessoal
Se o app expunha dados pessoais, a LGPD (art. 46) exige medidas de segurança e o art. 48 trata da comunicação de incidente à ANPD e aos titulares quando houver risco ou dano relevante. Acione o encarregado e siga o plano de resposta a incidentes de IA. O detalhe de obrigações está em vibe coding e LGPD.
Prevenção: o que impede o problema de voltar
Auditoria resolve o passado; prevenção resolve o resto. Quatro controles trazem o maior retorno:
- Padrão restrito. Defina na política que todo app interno nasce com acesso restrito à organização e só vira público com aprovação. Em plataformas com controle corporativo, isso se configura no nível da organização, não app a app. O Replit Enterprise, por exemplo, traz SSO, SCIM e RBAC para esse tipo de controle.
- Classes de app. Nem todo app precisa do mesmo rigor. Uma ferramenta pessoal de produtividade sem dado de terceiros dispensa o que um app de atendimento ao cliente exige. A lógica de liberar por classe está em governança de portfólio de vibe coding.
- Checklist de pré-publicação. Antes de ir ao ar: autenticação, controle de acesso na camada de dados, segredos fora do código e revisão do que o app mostra. O passo a passo está em segurança do vibe coding: checklist antes de publicar e, para a camada de qualidade, em testes e QA de apps vibe coded.
- Varredura recorrente. Repita os passos 2 e 3 do roteiro em ciclos fixos (por exemplo, trimestral). A exposição de hoje não é a de ontem: apps novos aparecem toda semana.
O que muda para quem decide
Para a diretoria, três perguntas resumem o risco:
- Sabemos quantos apps criados com IA existem na empresa e quem é o dono de cada um?
- Existe um padrão de acesso restrito e um caminho de aprovação rápido o bastante para as pessoas não o contornarem?
- Se um desses apps vazar, quem é acionado, em quanto tempo e com que plano?
Se a resposta for "não sei" para qualquer uma, o risco já existe, mesmo que ninguém tenha reportado incidente. O custo de descobrir internamente, em uma auditoria combinada com as áreas, é uma fração do custo de descobrir por uma reportagem ou por um pesquisador externo.
A Jetpacks é parceira oficial da Replit no Brasil e conduz imersões e workshops para destravar o vibe coding com governança dentro de grandes empresas. O ponto de partida é o mesmo que descrevemos aqui: mapear o que existe, definir classes e liberar com controle. O panorama completo está no artigo-pilar vibe coding nas empresas: velocidade com governança, e a matriz de ameaças em riscos do vibe coding nas empresas.
FAQ
O que são apps vibe coded expostos?
São aplicativos criados com ferramentas de IA (vibe coding) e publicados em URLs acessíveis pela internet sem autenticação adequada. Podem exibir dados internos ou pessoais para qualquer pessoa que encontre o endereço, inclusive via buscadores.
Apps vibe coded são inseguros por natureza?
Não necessariamente. O risco vem da combinação entre criação sem revisão, publicação sem controle de acesso e ausência de dono. Com padrão restrito, checklist de pré-publicação e revisão proporcional ao risco, apps criados com IA podem ser liberados com segurança. A Checkmarx alerta, porém, que a IA pode introduzir falhas mais rápido do que a revisão manual consegue acompanhar.
Um app público é sempre um vazamento?
Não. Um app pode ser público de propósito, como uma página institucional. O problema surge quando o app público exibe dados que deveriam ser restritos. Foi esse o ponto levantado pelas plataformas na polêmica da RedAccess: acessível não é sinônimo de violação.
Como descobrir quais apps vibe coded minha empresa já tem?
Combine três fontes: sinais financeiros e de identidade (cartão corporativo, SSO, DNS), levantamento externo dos domínios das plataformas e uma consulta direta às áreas com anistia. Registre tudo em um inventário vivo.
Quem na empresa deve fazer a auditoria?
Segurança da informação conduz os testes de acesso; TI mantém o inventário; o encarregado de dados (DPO) entra quando há dado pessoal; as áreas donas dos apps corrigem e respondem. A auditoria funciona melhor quando é uma ação conjunta, não uma caça.
Preciso comunicar a ANPD se um app expôs dados pessoais?
Depende do risco ou dano relevante aos titulares. O art. 48 da LGPD prevê a comunicação à ANPD e aos titulares nesses casos. A avaliação deve ser feita com o encarregado e o jurídico, caso a caso.
Com que frequência repetir a auditoria?
Trimestralmente é um ponto de partida razoável para empresas com uso ativo de vibe coding, ajustando conforme o volume de apps novos. Em ambientes com padrão restrito e inventário integrado, a varredura vira verificação de exceções.
Conclusão: descubra antes que alguém descubra por você
A lição da pesquisa da RedAccess não depende de os números exatos se confirmarem: apps criados por não desenvolvedores são publicados rápido, e o acesso público é um padrão fácil de manter sem perceber. O caminho é simples de enunciar e exige disciplina: descobrir, classificar, corrigir e instalar padrões que evitem a repetição. Se sua empresa quer mapear o que já foi construído e liberar vibe coding com governança, comece pelo diagnóstico gratuito da Jetpacks, uma conversa de 30 a 45 minutos.
Descubra onde a IA gera mais resultado na sua empresa.
Comece com um diagnóstico gratuito: mapa de impacto por área e o desenho de um primeiro piloto medível, sem compromisso.