Falha no Vertex AI do Google Cloud pode expor dados sensíveis
Pesquisadores de segurança identificaram uma vulnerabilidade preocupante no Vertex AI Agent Engine, componente da plataforma de IA do Google Cloud, que abre espaço para o acesso indevido a dados confidenciais e para a ampliação do impacto de ataques dentro de ambientes em nuvem corporativos.
O problema está diretamente ligado às permissões padrão atribuídas aos agentes de IA implantados no Vertex AI. Em vez de operarem com o mínimo de privilégios necessário, esses agentes acabam herdando acessos amplos por meio da conta de serviço padrão utilizada pelo ambiente, conhecida como P4SA (Principal for Service Accounts). Esse desenho de permissões transforma agentes de IA em potenciais vetores de abuso caso sejam explorados por um invasor.
Durante testes conduzidos por pesquisadores, foi possível extrair credenciais associadas ao agente de IA que utilizava a P4SA. A partir desse ponto, o atacante conseguiu “escapar” do contexto isolado da aplicação de IA e interagir com outros recursos do projeto do cliente dentro do Google Cloud. Na prática, isso significa que uma brecha localizada em um único agente de IA poderia ser usada como trampolim para movimentação lateral no ambiente.
Com as credenciais em mãos, um invasor teria capacidade de ler dados armazenados em buckets do Google Cloud Storage, acessar repositórios considerados restritos no Artifact Registry e até baixar imagens de contêiner relacionadas ao Vertex AI Reasoning Engine. Esses contêineres podem revelar detalhes de configuração, bibliotecas utilizadas e, em alguns casos, segredos ou caminhos internos úteis para aprofundar a exploração.
A análise técnica também mostrou que, em determinados cenários, seria possível mapear componentes internos do ambiente em nuvem, compreendendo melhor a arquitetura do projeto e identificando rotas alternativas para escalonar privilégios. Além disso, foram encontrados arquivos sensíveis expostos em projetos gerenciados pelo próprio Google associados às instâncias dos agentes, o que aumenta a superfície de risco.
Após a divulgação responsável da falha aos engenheiros de segurança do Google, a empresa implementou medidas adicionais de proteção. Segundo o Google, novos controles foram aplicados para impedir modificações em imagens-base de produção utilizadas na infraestrutura do Vertex AI. Essa restrição ajuda a mitigar cenários mais graves, como tentativas de comprometer a cadeia de suprimentos entre diferentes clientes da plataforma, um tipo de ataque em que a contaminação de um componente compartilhado pode afetar diversos locatários ao mesmo tempo.
Ao limitar a possibilidade de alteração dessas imagens-base, o Google reduz significativamente a chance de que um atacante, após explorar a falha, consiga implantar backdoors persistentes ou adulterar componentes fundamentais da plataforma em larga escala. Ainda assim, o incidente reforça a necessidade de revisão contínua de permissões padrão e de modelos de acesso utilizados por serviços gerenciados de IA.
Por que essa falha é especialmente crítica em ambientes de IA
Plataformas de IA em nuvem, como o Vertex AI, costumam operar sobre grandes volumes de dados sensíveis: documentos internos, registros de clientes, códigos proprietários, modelos treinados com informações confidenciais e assim por diante. Quando agentes de IA são integrados a fluxos críticos de negócio, qualquer vulnerabilidade que permita abusar de suas permissões se torna um ponto de entrada estratégico para atacantes.
Além disso, muitos times tratam recursos de IA como “caixas-pretas” oferecidas pelo provedor, confiando nas configurações padrão sem revisar em detalhe as contas de serviço, papéis de IAM e escopos de acesso. Isso cria um cenário ideal para abusos quando alguma falha de desenho é encontrada: um atacante explora um único componente de IA e, a partir dele, alcança diversas outras partes do ambiente em nuvem.
O papel das contas de serviço e da P4SA
No Google Cloud, contas de serviço são identidade técnica usada por aplicações e serviços para interagir com outros recursos na nuvem. A P4SA, utilizada por padrão em determinados componentes gerenciados, é projetada para garantir que esses serviços funcionem sem necessidade de configuração manual extensa.
O problema surge quando essa conta padrão recebe permissões mais amplas do que o estritamente necessário ou quando desenvolvedores assumem que, por ser “gerenciada pelo provedor”, ela é automaticamente segura em qualquer contexto. Na vulnerabilidade identificada, a combinação de:
– uso da P4SA como identidade padrão dos agentes de IA
– possibilidade de extração de credenciais ligadas a essa conta
– e permissões relativamente amplas associadas ao projeto
criou uma cadeia de risco capaz de transformar um agente de IA em porta de entrada para dados e recursos críticos.
Possíveis impactos para empresas usuárias do Vertex AI
Dependendo da forma como cada organização estruturou seus projetos e permissões no Google Cloud, as consequências de um ataque explorando essa falha poderiam incluir:
– exposição de dados confidenciais armazenados em buckets de Cloud Storage;
– acesso indevido a repositórios privados no Artifact Registry, incluindo imagens de contêiner críticas;
– revelação de detalhes internos da infraestrutura, facilitando ataques subsequentes;
– risco de comprometimento de pipelines de CI/CD, caso imagens adulteradas sejam utilizadas em produção;
– possibilidade de roubo ou engenharia reversa de modelos de IA, afetando propriedade intelectual.
Ainda que o Google tenha adotado medidas para mitigar o vetor identificado, o episódio evidencia como permissões padrão, se não forem constantemente revisadas, podem se tornar o elo fraco de arquiteturas em nuvem que aparentavam estar bem protegidas.
Medidas que as organizações podem adotar
Mesmo diante de correções aplicadas pelo provedor, é fundamental que empresas usuárias do Google Cloud e, em especial, do Vertex AI, revisem sua própria postura de segurança. Algumas ações recomendadas incluem:
1. Revisar contas de serviço usadas por agentes de IA
Verificar quais identidades técnicas estão associadas aos agentes do Vertex AI e quais papéis (roles) de IAM estão sendo atribuídos. Sempre que possível, substituir permissões amplas por papéis customizados com acesso mínimo.
2. Aplicar o princípio de privilégio mínimo (least privilege)
Garantir que agentes de IA só consigam acessar exatamente os recursos necessários para sua função. Se o agente apenas precisa ler dados de um bucket específico, não faz sentido ter permissão genérica para todos os buckets do projeto.
3. Segmentar projetos e ambientes
Isolar ambientes de desenvolvimento, teste e produção em projetos diferentes, reduzindo o impacto de uma eventual exploração em um único contexto. Dessa forma, mesmo que um agente seja comprometido, o invasor encontra barreiras adicionais para chegar até sistemas críticos.
4. Monitorar acessos e comportamentos anômalos
Ativar logs detalhados e alertas para acessos suspeitos a buckets, registros de artefatos e imagens de contêiner. A detecção precoce de operações incomuns pode impedir que um atacante consolide o controle sobre o ambiente.
5. Revisar periodicamente permissões padrão oferecidas por serviços gerenciados
Não assumir que configurações padrão são automaticamente seguras para qualquer cenários. Avaliar, com suporte de equipes de segurança, se os níveis de acesso realmente condizem com o perfil de risco aceitável pela organização.
Pentest com IA x Pentest Autônomo: lições desse caso
A descoberta da falha no Vertex AI também conecta-se a uma discussão crescente na área de cibersegurança: o uso de IA em testes de intrusão (pentest). Há, hoje, duas abordagens principais:
– Pentest com apoio de IA: profissionais humanos utilizam ferramentas de IA para automatizar partes do processo, como análise de grandes volumes de logs, geração de payloads de teste ou correlação de vulnerabilidades. A decisão estratégica continua nas mãos do analista.
– Pentest autônomo com IA: sistemas de IA são configurados para conduzir testes de forma quase independente, explorando superfícies de ataque, gerando exploits e tentando escalar privilégios sem intervenção humana constante.
A vulnerabilidade no Vertex AI mostra que, se ferramentas de IA (inclusive as defensivas) operam com permissões excessivas ou identidades mal configuradas, elas podem se tornar alvos valiosos para invasores. Ao mesmo tempo, soluções de pentest com IA bem projetadas podem ajudar a identificar exatamente esse tipo de falha de desenho, simulando o que um atacante real faria em um ambiente de nuvem.
Organizações que investem em testes de intrusão com apoio de IA conseguem, em geral, mapear mais rapidamente combinações perigosas de permissões, contas de serviço e configurações padrão que passariam despercebidas em auditorias manuais tradicionais.
Crescente interesse em cibersegurança ofensiva e Threat Intelligence
O contexto dessa falha também dialoga com outra tendência: o aumento de investimentos em empresas focadas em cibersegurança ofensiva, que já ultrapassa a marca de bilhões de dólares globalmente. O mercado percebe que não basta fortalecer defesas estáticas; é preciso pensar como o atacante, antecipar cenários e explorar, de forma controlada, as mesmas brechas que criminosos buscariam.
Nesse cenário, a demanda por serviços de Threat Intelligence também cresce de forma consistente. Inteligência de ameaças permite que empresas entendam como grupos maliciosos estão atuando, quais tecnologias estão sendo visadas (incluindo plataformas de IA em nuvem) e quais técnicas estão em alta para exploração de vulnerabilidades em contas de serviço ou cadeias de suprimentos.
Ao combinar Threat Intelligence com práticas de pentest contínuo – com e sem apoio de IA -, as organizações conseguem detectar falhas semelhantes às encontradas no Vertex AI antes que sejam exploradas em ataques reais.
O que esse incidente ensina sobre segurança em nuvem
A falha identificada no Vertex AI Agent Engine reforça alguns pontos essenciais sobre segurança em ambientes de nuvem:
– Configurações padrão não são neutras: elas podem simplificar a adoção, mas também carregar permissões que não se alinham ao nível de risco tolerado por cada negócio.
– Serviços gerenciados exigem confiança, mas também verificação: mesmo grandes provedores podem apresentar brechas de desenho ou de implementação.
– Identidades técnicas são tão críticas quanto contas de usuários: contas de serviço mal protegidas ou excessivamente privilegiadas podem abrir portas para ataques de grande impacto.
– IA é alvo e ferramenta ao mesmo tempo: agentes e motores de IA precisam ser protegidos com o mesmo rigor aplicado a bancos de dados e sistemas de autenticação, ao mesmo tempo em que soluções baseadas em IA podem fortalecer a detecção e resposta a incidentes.
Caminho adiante para empresas e provedores
Para provedores de nuvem, o caso serve como alerta para revisão contínua de modelos de permissão, especialmente em serviços de IA que ganham adoção massiva. É necessário equilibrar facilidade de uso e segurança, reduzindo ao máximo privilégios padrão e oferecendo ferramentas claras para que clientes entendam o que cada conta de serviço pode ou não fazer.
Para as empresas usuárias, o desafio é tratar a segurança de IA e de nuvem como parte integrante da estratégia de negócio. Isso significa envolver times de segurança desde o desenho de soluções com IA, definir políticas rígidas para acesso a dados sensíveis utilizados no treinamento de modelos e garantir que cada agente, conta de serviço e pipeline opere com o menor conjunto de permissões possível.
No fim, a vulnerabilidade no Vertex AI não é apenas um problema técnico pontual: ela ilustra como a combinação de IA, nuvem e configurações padrão pode criar riscos inesperados. Quem aprender com esse episódio e revisar hoje seus modelos de acesso estará em posição muito mais segura diante das próximas ondas de inovação – e dos próximos vetores de ataque que certamente virão.