Dois episódios recentes colocaram em evidência um problema recorrente em plataformas modernas: a fragilidade na gestão de acessos e permissões.

No caso da Lovable, uma vulnerabilidade em sua API permitia que usuários acessassem dados de outros projetos com uma conta comum. Já na Vercel, o incidente teve origem em uma cadeia de suprimentos comprometida, envolvendo uma ferramenta de terceiros integrada ao ambiente corporativo.

Apesar de diferentes do ponto de vista técnico, os dois casos convergem para um mesmo ponto: a exposição de dados sensíveis em ambientes que deveriam operar com isolamento e controle rigoroso.

O que aconteceu com a Lovable

A vulnerabilidade identificada na Lovable é classificada como BOLA (Broken Object Level Authorization), um tipo de falha em que a aplicação não valida corretamente se um usuário tem permissão para acessar determinados dados.

Na prática, o cenário era simples. Um usuário criava uma conta gratuita, realizava chamadas diretas à API e conseguia:

• Acessar projetos de outros usuários;

• Visualizar código-fonte completo;

• Ler históricos de interação com a IA;

• Identificar credenciais expostas dentro do código.

O ponto crítico estava na baixa complexidade da exploração. Não era necessário conhecimento avançado ou técnicas sofisticadas. O acesso acontecia com poucas requisições.

Além disso, havia um agravante: parte dessas informações vinha diretamente das interações com a IA, incluindo estruturas de banco de dados, lógica de negócio e dados potencialmente sensíveis inseridos durante o desenvolvimento.

Resposta da Lovable

A resposta inicial da empresa foi um dos pontos mais sensíveis do caso.

A Lovable afirmou, em um primeiro momento, que não havia ocorrido vazamento de dados. Segundo a empresa, o comportamento observado estava relacionado ao funcionamento de projetos públicos dentro da plataforma.

A justificativa era que, assim como em repositórios públicos, o conteúdo poderia ser acessado por outros usuários. No entanto, essa explicação não considerava que muitos usuários não tinham clareza de que chats e dados internos também estavam incluídos nessa visibilidade.

Com a repercussão, a empresa revisou sua posição e confirmou que houve uma falha ao reativar o acesso aos chats em fevereiro de 2026. O problema surgiu durante mudanças internas no sistema de permissões e o reporte feito via HackerOne não foi escalado corretamente. Segundo a plataforma, a correção foi aplicada após a exposição pública do caso.

A empresa também reconheceu que a documentação não era clara e que a comunicação inicial foi insuficiente para explicar o ocorrido.

O que aconteceu com a Vercel

Diferente da Lovable, o incidente da Vercel não partiu de uma falha direta na aplicação, mas de uma integração externa.

O ponto de entrada foi a ferramenta Context.ai, utilizada por um funcionário. A partir dela, invasores conseguiram acesso à conta corporativa do Google Workspace, explorando permissões OAuth excessivas.

A sequência do ataque indica um cenário mais sofisticado:

1. Comprometimento inicial via malware 

2. Roubo de tokens de autenticação

3. Uso de permissões amplas (“Allow All”)

4. Movimento lateral até ambientes internos da Vercel

Como resultado, houve acesso a variáveis de ambiente e exposição de credenciais de um subconjunto de clientes.

Resposta da Vercel

A empresa afirmou que dados críticos protegidos por criptografia não foram comprometidos, mas o incidente foi suficiente para acionar um processo completo de resposta.

Entre as ações adotadas:

• Rotação de credenciais;

• Auditoria de logs;

• Publicação de indicadores de comprometimento;

• Atualizações contínuas com recomendações técnicas.

O caso também envolveu o grupo hacker ShinyHunters, que alegou estar comercializando os dados obtidos.

Um padrão preocupante

Os dois casos evidenciam problemas diferentes, mas estruturais. No caso da Lovable, a falha estava na ausência de validação adequada entre usuários. Na Vercel, o problema estava na confiança excessiva entre sistemas integrados.

Ambos refletem desafios comuns em ambientes modernos:

• APIs expostas com controle de acesso insuficiente;

• Integrações SaaS com permissões amplas;

• Dependência de terceiros para processamento e análise;

• Falhas em processos de auditoria e resposta a incidentes.

Com a adoção crescente de ferramentas de IA, esses riscos se ampliam. Isso porque dados sensíveis deixam de estar apenas em bancos estruturados e passam a circular também em prompts, logs e interações com modelos.

CodeAdvisor: uma abordagem estruturada para uso corporativo de IA

Diante desse cenário, cresce a necessidade de soluções que tratem IA como parte da infraestrutura crítica e não apenas como ferramenta isolada dentro de times ou projetos específicos.

O CodeAdvisor foi desenvolvido com essa lógica: centralizar o uso de IA dentro de um ambiente corporativo controlado, evitando a fragmentação de ferramentas e reduzindo riscos associados ao uso descentralizado de soluções externas.

A solução foi pensada para uso corporativo amplo, atendendo diferentes áreas e processos da empresa dentro de um mesmo ambiente governado, evitando a adoção de ferramentas isoladas por equipe. O modelo de contratação baseado em consumo (tokens) permite que o uso acompanhe a demanda real, sem a necessidade de licenças fixas por usuário, o que facilita a escala com controle de custos.

O CodeAdvisor também pode ser integrado às IDEs por meio de plugin, acompanhando o fluxo de desenvolvimento e oferecendo suporte em tempo real, sem perder o padrão de segurança e governança aplicado ao restante da organizaçã.

A arquitetura prioriza segurança e governança:

• Execução realizada na conta AWS do próprio cliente e não de empresas terceiras;

• Criptografia em repouso e em trânsito com suporte ao AWS KMS;

• Controle de acesso e segregação de dados por equipe;

• Logs completos para auditoria e rastreabilidade;

• Garantia de que dados não são utilizados para treinar modelos públicos.

Além disso, a integração com o Amazon Bedrock permite utilizar modelos de IA em ambiente controlado, com isolamento de dados e possibilidade de conexão com bases internas da empresa.

Esse modelo reduz a dependência de ferramentas dispersas e cria um padrão único de uso de IA, garantindo visibilidade sobre quem acessa, como utiliza e quais dados estão envolvidos em cada etapa.

À medida que a IA se integra de forma mais profunda aos processos de desenvolvimento e operação das empresas, a evolução tecnológica passa a exigir o mesmo nível de maturidade em segurança. 

O avanço estratégico estará na forma como esse uso é estruturado, com controle, visibilidade e governança desde o início.