Vulnerabilidade no Vertex AI expõe dados e artefatos privados do Google Cloud
O Vertex AI, plataforma de inteligência artificial do Google Cloud, está no centro de uma descoberta preocupante feita pelos pesquisadores da Unit 42, time de segurança da Palo Alto Networks. Uma vulnerabilidade identificada no modelo de permissões da plataforma pode transformar agentes de IA em verdadeiras ameaças internas, capazes de expor credenciais sensíveis e comprometer ambientes inteiros na nuvem.
A falha está ligada ao excesso de permissões concedidas por padrão a um componente chamado P4SA, o agente de serviço associado a cada projeto. Quando um agente é implantado via Agent Engine, esse mecanismo automaticamente expõe informações críticas, incluindo as credenciais do agente de serviço, o projeto no Google Cloud que hospeda o agente e os escopos da máquina responsável pela execução.
Em outras palavras, um agente que deveria trabalhar para você pode, na prática, estar trabalhando contra você sem que ninguém perceba.
De acordo com Ofir Shaty, pesquisador da Unit 42, um agente mal configurado ou comprometido pode se tornar um agente duplo que aparenta cumprir sua função original enquanto, nos bastidores, exfiltra dados sensíveis, compromete infraestrutura e cria backdoors nos sistemas mais críticos de uma organização. O pior é que isso não exige um ataque sofisticado. Basta um agente mal configurado ou comprometido para que um invasor consiga se mover lateralmente dentro do ambiente cloud, acessar dados armazenados, repositórios privados e até mapear a cadeia de fornecimento de software interna do Google. 😬
O que é o P4SA e por que ele é o centro do problema
Para entender a gravidade da situação, é preciso dar um passo atrás e entender o papel do P4SA dentro da arquitetura do Vertex AI. O P4SA, que significa Per-Project, Per-Product Service Agent, é um componente criado automaticamente pelo Google Cloud sempre que um novo projeto utiliza os serviços do Vertex AI. Ele funciona como uma identidade de serviço, ou seja, uma espécie de usuário automatizado que tem permissão para executar tarefas dentro da plataforma em nome do projeto.
O problema começa justamente aí: esse agente de serviço recebe um conjunto de permissões bastante amplo por padrão, o que, em teoria, facilita a operação dos recursos da plataforma, mas na prática abre uma janela perigosa quando algo sai do controle.
Quando um desenvolvedor implanta um agente de IA utilizando o Agent Engine e o Agent Development Kit (ADK) do Vertex AI, o P4SA entra em cena com todas as suas permissões já configuradas. Isso significa que o agente implantado herda, de forma automática, acesso a uma série de recursos do ambiente no Google Cloud, sem que o desenvolvedor precise configurar nada manualmente.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
Essa automação, que existe para facilitar a vida de quem desenvolve, acaba sendo exatamente o ponto que os pesquisadores da Unit 42 identificaram como crítico: o agente passa a ter acesso a credenciais que deveriam ser protegidas, incluindo tokens de autenticação, informações sobre o projeto hospedeiro e os escopos de execução da máquina virtual responsável por rodar o agente.
O que torna esse cenário ainda mais preocupante é o fato de que a exposição não depende de uma brecha técnica complexa ou de um exploit elaborado. A vulnerabilidade existe na própria lógica de funcionamento do sistema. Qualquer agente que seja comprometido, seja por uma injeção de prompt malicioso, seja por uma configuração equivocada do desenvolvedor, consegue aproveitar esse excesso de permissões para executar ações que vão muito além do escopo original para o qual foi criado. É como entregar a chave-mestra de um prédio inteiro para alguém que só deveria ter acesso à sala de reuniões do terceiro andar. 🔑
Como a exploração dessa falha funciona na prática
Os pesquisadores da Unit 42 demonstraram que a exploração dessa vulnerabilidade no Vertex AI pode acontecer de maneiras distintas, e nenhuma delas exige um nível elevado de sofisticação técnica.
O primeiro caminho documentado envolve o próprio fluxo padrão de implantação do agente. Após o deploy via Agent Engine, qualquer chamada ao agente invoca o serviço de metadados do Google, expondo automaticamente as credenciais do agente de serviço, o projeto GCP que hospeda o agente, a identidade do agente e os escopos da máquina que o executa. Isso acontece sem nenhuma ação adicional do atacante, bastando que ele tenha acesso ao contexto de execução do agente.
O segundo vetor identificado é a chamada injeção de prompt indireta. Nesse cenário, um agente de IA que processa dados externos, como documentos, e-mails ou páginas da web, pode receber instruções maliciosas embutidas nesses conteúdos. O agente, sem saber que está sendo manipulado, executa as instruções como se fossem parte de sua tarefa normal, e nesse processo acaba expondo as credenciais do P4SA para o atacante. O problema aqui é que agentes modernos são projetados justamente para consumir e interpretar grandes volumes de dados externos, o que aumenta significativamente a superfície de ataque.
O terceiro vetor é ainda mais direto: um modelo de IA que foi previamente comprometido e carregado no ambiente do Google Cloud. Isso é possível porque o Vertex AI permite que usuários façam upload de modelos customizados para a plataforma. Se um modelo malicioso for carregado, ele pode, durante sua execução, acessar o endpoint de metadados da instância, que é um serviço interno do Google Cloud que fornece informações sobre o ambiente de execução. Esse endpoint, quando consultado a partir de dentro do ambiente, retorna dados como tokens de acesso temporários e outras informações sensíveis do P4SA.
Movimentação lateral e acesso a buckets do Cloud Storage
A Unit 42 demonstrou que foi possível utilizar as credenciais roubadas para saltar do contexto de execução do agente de IA para o projeto do cliente, minando efetivamente as garantias de isolamento e permitindo acesso irrestrito de leitura a todos os buckets do Google Cloud Storage dentro daquele projeto. Esse nível de acesso transforma o agente de IA de uma ferramenta útil em uma potencial ameaça interna, conforme descrito pelos próprios pesquisadores.
A movimentação lateral é especialmente perigosa porque permite que o invasor saia do contexto isolado do agente e comece a interagir com outros recursos do projeto no Google Cloud. Dependendo das permissões que o P4SA carrega, isso pode incluir acesso a buckets do Cloud Storage, leitura de repositórios privados no Artifact Registry, consulta a bancos de dados, execução de pipelines de machine learning e até mapeamento da estrutura interna de dependências de software do projeto. Em ambientes corporativos, esse tipo de acesso pode representar uma violação catastrófica, expondo propriedade intelectual, dados de clientes e infraestrutura crítica de uma só vez. 😰
Exposição de artefatos internos do Google e repositórios privados
Mas a coisa não para por aí. Como o Agent Engine do Vertex AI roda dentro de um projeto de tenant gerenciado pelo próprio Google, as credenciais extraídas também concediam acesso aos buckets do Cloud Storage dentro desse tenant, revelando detalhes adicionais sobre a infraestrutura interna da plataforma. Os pesquisadores notaram, no entanto, que neste caso as credenciais não tinham as permissões necessárias para de fato acessar o conteúdo dos buckets expostos.
Ainda assim, as mesmas credenciais do P4SA permitiram acesso a repositórios restritos do Artifact Registry pertencentes ao Google, que foram revelados durante o deploy do Agent Engine. Um atacante poderia aproveitar esse comportamento para baixar imagens de container de repositórios privados que constituem o núcleo do Vertex AI Reasoning Engine. Mais do que isso, as credenciais comprometidas não apenas permitiam o download das imagens listadas nos logs durante o deploy, mas também expunham o conteúdo completo dos repositórios do Artifact Registry, incluindo diversas outras imagens restritas.
Segundo a Unit 42, obter acesso a esse código proprietário não só expõe a propriedade intelectual do Google, como também fornece ao atacante um mapa para encontrar novas vulnerabilidades. O Artifact Registry mal configurado revela uma falha adicional no gerenciamento de controle de acesso para infraestrutura crítica, permitindo que um invasor mapeie a cadeia de fornecimento de software interna do Google, identifique imagens depreciadas ou vulneráveis e planeje ataques subsequentes.
O que o Google fez depois da descoberta
Assim que a Unit 42 reportou a vulnerabilidade ao Google seguindo o processo responsável de divulgação, o time de segurança do Google Cloud reconheceu o problema e iniciou as correções necessárias. O Google implementou controles adicionais sobre as permissões concedidas pelo P4SA, com o objetivo de restringir o escopo de acesso que os agentes implantados via Agent Engine recebem por padrão. A ideia central das mudanças é aplicar o princípio do menor privilégio, ou seja, garantir que cada componente tenha acesso apenas ao que é estritamente necessário para cumprir sua função, e nada além disso.
Além das correções no modelo de permissões, o Google atualizou sua documentação oficial para explicar claramente como o Vertex AI utiliza recursos, contas e agentes. As recomendações incluem:
- Utilizar o Bring Your Own Service Account (BYOSA) para substituir o agente de serviço padrão
- Aplicar o princípio do menor privilégio (PoLP) para garantir que o agente tenha apenas as permissões necessárias para executar a tarefa em questão
- Revisar periodicamente as permissões associadas ao P4SA de cada projeto
- Evitar o uso de modelos de terceiros sem uma análise cuidadosa de proveniência e origem
- Implementar camadas adicionais de monitoramento e auditoria sobre as ações executadas por agentes de IA em produção
- Configurar alertas no Cloud Logging e no Security Command Center para detectar comportamentos anômalos
Vale destacar que a postura do Google diante dessa descoberta foi considerada responsiva pela própria Unit 42. O Google não apenas reconheceu o problema como válido, mas também colaborou com os pesquisadores durante o processo de análise e correção. Esse tipo de parceria entre times de segurança independentes e grandes provedores de nuvem é fundamental para que o ecossistema de inteligência artificial evolua com mais segurança, especialmente agora que os agentes de IA estão sendo adotados em larga escala por empresas de todos os tamanhos. 🤝
O que desenvolvedores e equipes de segurança precisam saber agora
Mesmo com as correções implementadas pelo Google, essa descoberta serve como um alerta importante para qualquer equipe que esteja desenvolvendo ou operando agentes de IA sobre o Google Cloud. O fato de uma plataforma amplamente utilizada como o Vertex AI ter apresentado esse tipo de falha mostra que a segurança de ambientes baseados em agentes de IA não pode ser tratada como algo que o provedor resolve sozinho. É uma responsabilidade compartilhada, e parte dela recai diretamente sobre as equipes que constroem e mantêm esses sistemas no dia a dia.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
Um dos pontos mais importantes que essa pesquisa evidencia é a necessidade de revisar as permissões padrão de todos os componentes de serviço utilizados em projetos de IA. Muitas vezes, as configurações padrão de plataformas cloud são pensadas para facilitar a adoção e reduzir a fricção no onboarding, mas isso pode criar situações onde recursos críticos ficam mais expostos do que deveriam. Auditar regularmente quais permissões estão ativas, quais são realmente necessárias e o que pode ser revogado sem impactar o funcionamento dos sistemas é uma prática que deveria fazer parte do ciclo de vida de qualquer projeto em produção.
Como o próprio pesquisador Ofir Shaty destacou, conceder permissões amplas a agentes por padrão viola o princípio do menor privilégio e representa uma falha de segurança perigosa by design. As organizações devem tratar o deploy de agentes de IA com o mesmo rigor aplicado a código novo em produção: validar limites de permissões, restringir escopos OAuth ao mínimo necessário, revisar a integridade das fontes e conduzir testes de segurança controlados antes de colocar qualquer coisa no ar.
Outro aspecto que merece atenção é o tratamento de dados externos consumidos por agentes de IA. Como a injeção de prompt indireta foi um dos vetores identificados pela Unit 42, é fundamental que as equipes implementem camadas de sanitização e validação sobre os dados que os agentes processam, especialmente quando esses dados vêm de fontes externas ou de usuários finais. Além disso, monitorar o comportamento dos agentes em tempo real, verificando se estão fazendo chamadas inesperadas a endpoints internos ou acessando recursos fora do seu escopo habitual, pode ser a diferença entre detectar uma exploração cedo ou descobrir o problema tarde demais. 🔍
Por que essa descoberta importa para o futuro dos agentes de IA
O caso do Vertex AI ilustra um padrão que provavelmente veremos se repetir com cada vez mais frequência à medida que agentes de IA se tornam componentes centrais de infraestruturas corporativas. Diferente de aplicações tradicionais, agentes de IA operam com um grau de autonomia que amplifica tanto seu potencial produtivo quanto os riscos associados. Um agente que tem permissão para ler documentos, acessar APIs e executar ações no ambiente cloud carrega consigo uma superfície de ataque que não existia na geração anterior de software.
Essa pesquisa reforça a importância de que provedores de nuvem, desenvolvedores e equipes de segurança trabalhem juntos para criar frameworks de governança específicos para agentes de IA. Não basta aplicar as mesmas práticas de segurança que já existem para microsserviços ou containers. Agentes de IA introduzem variáveis novas, como a capacidade de interpretar e agir sobre dados de forma autônoma, que exigem controles igualmente novos e adaptados a essa realidade.
A descoberta da Unit 42 é mais um lembrete de que a inteligência artificial, por mais poderosa e útil que seja, traz consigo uma nova camada de desafios de segurança que ainda estamos aprendendo a gerenciar. E quanto mais cedo as equipes internalizarem isso, melhor preparadas estarão para lidar com o que vem por aí.
