Vertex AI sob ameaça um agente mal configurado pode tornar-se agente duplo e roubar credenciais na nuvem

Uma equipe de pesquisadores em segurança colocou em evidência uma zona cega em Vertex AI do Google Cloud que merece atenção imediata de qualquer equipe que esteja desenvolvendo agentes de inteligência artificial na nuvem. O problema não é uma falha anecdótica: permite que um agente mal configurado ou comprometido atue como um “agente duplo”, conservando sua aparência legítima enquanto extrai credenciais, dados e vetores de ataque dentro do ambiente na nuvem.

O achado, publicado por especialistas de Unit 42 de Palo Alto Networks, aponta para o modelo de permissões que o Google aplica aos agentes implantados com Vertex AI, em particular ao chamado serviço "Per-Project, Per-Product Service Agent" (P4SA). Por padrão, este agente recebe permissões bastante amplas, o que abre uma porta perigosa: se um atacante conseguir executar código que consulte o serviço metadata do Google Cloud do contexto do agente, você pode obter as credenciais associadas e, a partir daí, mover-se lateralmente dentro do projeto.

De forma técnica, ao lançar um agente com Agent Engine de Vertex AI, qualquer chamada que o agente faça ao serviço metadata pode revelar não só o token do serviço, mas também informações do projeto GCP que aloja o agente, a identidade do próprio agente e os escores do host onde está sendo executado. Com essas credenciais, os pesquisadores conseguiram saltar do contexto isolado do agente para recursos do projeto do cliente. Na prática, isso significou acesso de leitura sem restrições a dados armazenados no Google Cloud Storage dentro desse projeto, o que converte uma ferramenta de ajuda em um risco de tipo insider.

A exposição não se limitou ao projeto do cliente. Como o Agent Engine pode operar em projetos de inquilino geridos pelo Google, as credenciais também deixaram ver metadados e referências a buckets que fazem parte da infraestrutura interna da plataforma. Embora em alguns casos essas credenciais não tenham permissões para baixar diretamente esses buckets, eles permitiram descobrir rotas e repositórios protegidos.

Uma consequência especialmente preocupante foi a possibilidade de acesso a artefatos privados em Artifact Registry que foram registrados nos logs durante a implantação do Agent Engine. Com essa visibilidade, um atacante poderia baixar imagens de contêineres que fazem parte do núcleo do motor de raciocínio Vertex AI, e até obter acesso ao conteúdo de outros repositórios privados. O acesso a esse código proprietário não só implica uma perda de propriedade intelectual, mas também facilita um atacante mapear a cadeia de fornecimento de software da plataforma e localizar imagens obsoletas ou vulneráveis para as explorar posteriormente.

O Google reagiu atualizando sua documentação oficial para explicar com maior clareza como Vertex AI usa contas, recursos e agentes, e indica medidas que os clientes devem aplicar. Entre as recomendações figura substituir o agente por defeito por uma conta de serviço própria (Bring Your Own Service Account, BYOSA) e aplicar de forma estrita o princípio de menor privilégio para que o agente disponha apenas das capacidades necessárias para a sua missão. Na documentação do Vertex AI podem ser consultados detalhes sobre agentes e Engine, e no guia de boas práticas do IAM estão os padrões para limitar permissões e espes: Vertex AI — Agents e Boas práticas do IAM no Google Cloud.

De uma perspectiva de segurança operacional, este caso oferece lições claras. A primeira é que não basta tratar um agente da IA como um objeto inofensivo: a sua implantação deve submeter-se aos mesmos controles que qualquer microserviço ou aplicação nova em produção. Limitar o scopes OAuth, auditar as interações com a metadata, revisar as permissões atribuídas a contas de serviço e testar o comportamento do agente em condições controladas são passos indispensáveis antes de tirar um agente à produção.

Outra recomendação prática é fazer uso de contas de serviço geridas pela própria equipe, configuradas com permissões mínimas e rotação de chaves; isso evita depender de agentes com privilégios demasiado amplos por defeito. Também é aconselhável monitorar e alertar sobre usos incomuns da metadata e sobre blocos de leitura em massa no Cloud Storage ou acessos a repositórios privados que não sejam justificados.

Este incidente também sublinha a importância de proteger a cadeia de fornecimento de software em ambientes cloud. O acesso a imagens de contêineres e artefatos privados pode servir a um atacante como plano para reproduzir o ambiente, buscar falhas e preparar ataques mais profundos. Documentação de Artifact Registry e controlos de acesso mais rigorosos podem mitigar parte desse risco: Artifact Registry — Documentação.

Em suma, o aparecimento deste vetor mostra que a segurança na era da IA na nuvem não é apenas uma questão de modelos e dados: também depende de como são geridas identidades, permissões e implantaçãos. As recomendações dos pesquisadores podem ser resumidas num conselho prático para equipamentos de segurança e operações: tratar cada agente como se fosse nova infraestrutura de produção, auditar suas permissões e eliminar qualquer privilégio que não seja imprescindível.

Se você quiser aprofundar o relatório técnico e a pesquisa original, a análise dos especialistas está disponível na web. Unit 42, e é boa ideia rever a documentação oficial do Google Cloud sobre agentes e gestão de identidade para aplicar as mitigações recomendadas.