Funcionários estão deixando de usar só prompts e passaram a construir aplicações completas com IA, conectando-as a sistemas corporativos e publicando-as na web sem envolver Segurança ou TI; essa prática ampliou muito a superfície de risco porque muitos desses apps ficam públicos, sem controles básicos, expondo dados sensíveis e escapando à visibilidade das ferramentas tradicionais.
O que começou como colar instruções em chatbots virou algo maior: pessoas criando aplicações inteiras com IA e ligando-as direto a sistemas de produção, muitas vezes publicando-as sem passar por Segurança ou TI.
Esse movimento transformou um artefato que era um prompt em um produto completo, e a superfície de risco cresceu junto.
Uma investigação identificou centenas de milhares de ativos públicos em plataformas de “vibe coding”, com milhares parecendo corporativos e mais de dois mil expondo dados sensíveis sem controles básicos de acesso.
Essas aplicações, algumas até concedendo privilégios administrativos por padrão, ficaram no ar em vários continentes e setores, sem necessidade de exploração para representar um risco.
Diferente do antigo Shadow IT, aqui o aplicativo é customizado, os dados são carregados especificamente e as integrações são conexões diretas aos sistemas de registro, frequentemente publicadas em subdomínios das plataformas de desenvolvimento.
Os construtores não são necessariamente mal-intencionados: são colaboradores resolvendo problemas reais com ferramentas que permitem entregar soluções muito rápido.
As próprias plataformas também não são o problema central — elas atendem ao que seus usuários pediram — o que faltou foram guardrails técnicos e comportamentais que cobrissem o pós-construção.
Um ponto crítico é que muitas ferramentas de segurança tradicionais operam em camadas diferentes e acabam deixando lacunas onde essas aplicações surgem.
EDR identifica o processo do navegador, não o artefato que está sendo montado dentro dele, então a atividade muitas vezes tem a mesma telemetria de navegação comum.
DLP monitora canais conhecidos e não enxerga movimentos de dados entre nuvens por APIs; CASB tende a tratar toda a plataforma como um único SaaS aprovado, ocultando aplicações individuais.
Firewall e SASE/SSE veem conexões com o domínio da plataforma, mas carecem do contexto de “aplicação como objeto de negócio” e frequentemente não cobrem dispositivos não gerenciados.
Ou seja, essas soluções não estão falhando isoladamente; o problema é que os sinais ficam fragmentados e não se juntam numa visão governável.
Para cobrir essa lacuna é preciso atuar na camada onde tudo acontece: a sessão web.
O processo de construir, autorizar via OAuth, movimentar dados e publicar é todo um evento de sessão, e controles nessa camada conseguem ver o caminho completo e atribuir ações a pessoas e instâncias de aplicação.
Uma abordagem prática sugerida é começar pela descoberta: perguntar aos colaboradores o que eles construíram e tratar isso como inventário, não como auditoria punitiva.
Em seguida, mapear cada aplicação descoberta — quais sistemas ela acessa, por qual mecanismo (OAuth, API key, upload manual) e se é publicamente acessível — sendo a acessibilidade pública o sinal mais acionável no curto prazo.
Também é indicado estabelecer um caminho sancionado: nomear plataformas aprovadas, definir categorias de dados aceitáveis e um padrão mínimo de autenticação para reduzir atrito e incentivar a comunicação.
É importante entender que não se trata de um trabalho único; a postura madura exige descoberta contínua na camada de sessão, já que novas aplicações aparecem regularmente.
Existem abordagens de segurança que buscam visibilidade sem agentes na camada de sessão, cobrindo qualquer navegador e dispositivo — inclusive não gerenciados — e que podem ser implantadas rapidamente para transformar sinais dispersos em governança efetiva sobre apps gerados por IA.
