Escopo excessivo do agente de serviço padrão do Vertex AI podia permitir acesso não autorizado a buckets do Google Cloud Storage e imagens restritas do Artifact Registry.
| Componente | Vertex AI Agent Engine, Agent Development Kit e agente de serviço P4SA associado a agentes de IA implantados no Google Cloud. |
| Vetor | Chamadas ao agente implantado acionavam o serviço de metadados do Google e expunham credenciais do agente de serviço, identidade do agente, projeto GCP e escopos da máquina hospedeira. |
| Impacto | As credenciais permitiam sair do contexto de execução do agente e obter leitura irrestrita de dados em buckets do Google Cloud Storage no projeto do cliente, além de acesso a repositórios restritos do Artifact Registry. |
| Prioridade | Substituir o agente de serviço padrão por BYOSA, aplicar menor privilégio, revisar escopos OAuth e validar limites de permissão antes de colocar agentes de IA em produção. |
| Artefatos | Foram expostos detalhes de infraestrutura interna, imagens de contêiner relacionadas ao Vertex AI Reasoning Engine e conteúdo de repositórios privados do Artifact Registry. |
| Mitigação | O Google atualizou a documentação sobre recursos, contas e agentes do Vertex AI e recomendou Bring Your Own Service Account com permissões estritamente necessárias. |
Uma falha de desenho e escopo de permissões no Vertex AI criava uma rota de abuso em agentes de inteligência artificial implantados no Google Cloud. O problema estava ligado ao modelo de permissão do serviço e, em especial, ao agente de serviço P4SA, usado por projeto e por produto. Em uma implantação com o Agent Development Kit e o Agent Engine, esse agente de serviço recebia permissões amplas por padrão. Quando uma identidade desse tipo fica disponível dentro do fluxo de execução de um agente de IA, o limite esperado entre o código do agente, o projeto do cliente e recursos gerenciados pela plataforma deixa de ser confiável.
O comportamento observado permitia que chamadas feitas ao agente acionassem o serviço de metadados do Google e revelassem credenciais do agente de serviço. Junto com as credenciais, ficavam visíveis o projeto GCP que hospedava o agente, a identidade do próprio agente e os escopos associados à máquina que o executava. Com esse conjunto de informações, um invasor que controlasse ou comprometesse o agente poderia deixar de operar apenas dentro do contexto lógico da aplicação de IA e passar a executar ações em nome da identidade de serviço exposta.
O impacto técnico confirmado inclui acesso de leitura a dados em buckets do Google Cloud Storage dentro do projeto do cliente. A mesma exposição também alcançava repositórios restritos do Artifact Registry associados à infraestrutura do Vertex AI, incluindo imagens de contêiner privadas vinculadas ao Reasoning Engine. O caso é relevante para equipes que tratam agentes de IA como componentes isolados: a evidência mostra que permissões herdadas por identidades gerenciadas podem transformar uma integração de IA em uma superfície de acesso a dados, artefatos e metadados de infraestrutura.
O fluxo começa com a implantação de um agente criado com o Vertex AI Agent Development Kit e executado pelo Agent Engine. Nesse modelo, o serviço associa o agente a um P4SA, uma identidade gerenciada pelo Google Cloud para operar recursos do produto dentro de um projeto. A fragilidade não depende de um payload específico ou de uma exploração tradicional de memória; ela nasce da combinação entre escopo excessivo, acesso ao serviço de metadados e permissões aproveitáveis fora do limite funcional esperado para o agente.
Após a implantação, qualquer chamada ao agente podia acionar uma consulta ao serviço de metadados do Google. Esse serviço retornava credenciais do agente de serviço, além de informações sobre o projeto, a identidade do agente e os escopos configurados para a máquina hospedeira. Em um cenário defensivo, esses dados deveriam permanecer restritos ao ambiente controlado da plataforma. Quando se tornam acessíveis a um agente mal configurado ou comprometido, passam a funcionar como material de autenticação para ações diretas contra recursos do Google Cloud.
Com as credenciais extraídas, foi possível saltar do contexto de execução do agente para o projeto do cliente. Esse salto enfraquece a expectativa de isolamento entre a lógica do agente e os recursos do projeto. O efeito mais grave descrito foi leitura irrestrita de todos os dados em buckets do Google Cloud Storage daquele projeto. Isso não implica, pelo material disponível, execução remota de código, persistência automática ou movimentação lateral confirmada; o impacto central é a quebra de barreira de identidade e a leitura não autorizada de dados e artefatos acessíveis pela conta de serviço.
O mesmo conjunto de credenciais também expunha recursos no tenant gerenciado pelo Google usado pelo Agent Engine. No caso dos buckets do Google Cloud Storage presentes nesse tenant, as credenciais revelavam informações sobre infraestrutura interna, mas não tinham as permissões necessárias para acessar o conteúdo dos buckets. A exposição mais sensível nesse segundo eixo estava no Artifact Registry: repositórios privados e restritos, visíveis durante a implantação do Agent Engine, podiam ser acessados para baixar imagens de contêiner ligadas ao núcleo operacional do Vertex AI Reasoning Engine.
A superfície afetada concentra-se em ambientes que implantam agentes de IA no Vertex AI usando o Agent Engine e dependem do agente de serviço padrão associado ao produto. O risco aumenta quando o agente recebe permissões amplas, quando seus escopos OAuth não foram revisados e quando a organização assume que o isolamento da plataforma impede o acesso direto a recursos do projeto. Como o problema envolve identidade e autorização, a exposição pode ocorrer mesmo sem exploração de uma vulnerabilidade clássica em binário, endpoint HTTP público ou biblioteca de aplicação.
Os ativos mais sensíveis nesse fluxo são buckets do Google Cloud Storage no projeto do cliente, credenciais temporárias ou utilizáveis do P4SA, metadados do ambiente de execução, repositórios privados do Artifact Registry e imagens de contêiner associadas ao Vertex AI Reasoning Engine. Para equipes de segurança, o ponto crítico é que o agente de IA deve ser tratado como código de produção com identidade própria, e não como uma camada conversacional isolada dos recursos de nuvem.
- Agentes criados com Vertex AI Agent Development Kit e implantados por meio do Agent Engine.
- Projetos GCP em que o agente de serviço padrão mantém permissões amplas além da função operacional do agente.
- Buckets do Google Cloud Storage acessíveis pela identidade
P4SAdentro do projeto do cliente. - Repositórios restritos do Artifact Registry revelados durante a implantação do Agent Engine.
- Imagens privadas de contêiner relacionadas ao Vertex AI Reasoning Engine.
A investigação defensiva deve começar por trilhas de auditoria de identidade e acesso no Google Cloud. O objetivo é verificar se o agente de serviço associado ao Vertex AI realizou leituras de objetos em buckets, listagens anormais de repositórios ou downloads de imagens fora do padrão esperado de implantação. Como a técnica descrita usa credenciais legítimas da conta de serviço, a detecção não deve depender apenas de bloqueios por assinatura; ela precisa comparar comportamento, origem, horário, recurso acessado e necessidade operacional.
Em Google Cloud Storage, eventos de leitura em massa, enumeração de buckets e acesso a objetos por identidades ligadas ao Vertex AI devem ser revisados com prioridade. No Artifact Registry, a defesa deve procurar operações de listagem e download de imagens privadas por agentes de serviço que normalmente não deveriam consumir esses artefatos. Também é importante correlacionar logs de implantação do Agent Engine com acessos subsequentes a repositórios e buckets, porque os repositórios restritos eram revelados durante a implantação e depois podiam ser acessados com as credenciais expostas.
Outra frente é a revisão de configurações de IAM e escopos OAuth. Identidades P4SA com acesso amplo a armazenamento, registro de artefatos ou recursos não necessários ao agente devem ser consideradas prioridade de ajuste. Em ambientes maduros, esses achados devem alimentar controles de postura em nuvem, testes de permissão em pipelines e revisões formais antes de promover agentes de IA para produção.
- Eventos de leitura, listagem ou acesso incomum a buckets do Google Cloud Storage por agentes de serviço do Vertex AI.
- Operações de enumeração ou download em repositórios privados do Artifact Registry associadas ao
P4SA. - Consultas ao serviço de metadados correlacionadas a execução de agentes e uso posterior de credenciais.
- Diferença entre permissões concedidas à identidade do agente e permissões estritamente necessárias para a função do agente.
- Acessos a imagens de contêiner reveladas em logs ou durante fluxos de implantação do Agent Engine.
A mitigação principal é abandonar o uso automático do agente de serviço padrão quando ele concede permissões além do necessário. O Google recomendou Bring Your Own Service Account, permitindo que a organização substitua a identidade padrão por uma conta de serviço própria, controlada e limitada. Essa conta deve receber apenas permissões indispensáveis para a tarefa do agente, com escopos OAuth reduzidos e sem acesso genérico a buckets, registros de artefatos ou recursos administrativos que não façam parte do fluxo funcional.
A correção operacional deve incluir inventário de agentes Vertex AI em execução, mapeamento de contas de serviço associadas, revisão de políticas IAM e validação de acesso efetivo. Em vez de avaliar apenas permissões declaradas, equipes devem testar quais recursos a identidade consegue listar, ler ou baixar. Esse ponto é importante porque a falha descrita mostrou uma diferença entre o papel esperado do agente e o que suas credenciais permitiam acessar quando extraídas do ambiente de execução.
Também é necessário tratar agentes de IA como código de produção. Antes da implantação, a organização deve revisar integridade do código-fonte, dependências, permissões, escopos, logs gerados e rotas de acesso a metadados. Depois da implantação, o agente precisa entrar no mesmo ciclo de monitoramento de aplicações críticas: auditoria de identidade, alertas de acesso a armazenamento, revisão de registro de artefatos e testes controlados de limite de permissão. A atualização da documentação do Google ajuda a esclarecer o papel de recursos, contas e agentes, mas a redução concreta do risco depende da configuração de menor privilégio no projeto de cada cliente.
- Migrar agentes Vertex AI para
BYOSAe remover dependência do agente de serviço padrão quando ele tiver escopo excessivo. - Aplicar menor privilégio em IAM, com permissões específicas para a tarefa do agente e sem leitura ampla de armazenamento.
- Restringir escopos OAuth e revisar se a máquina hospedeira expõe capacidades além da necessidade operacional.
- Auditar acessos recentes do
P4SAa Google Cloud Storage e Artifact Registry. - Validar em ambiente controlado se o agente consegue alcançar buckets, imagens ou repositórios que não deveria acessar.
0 Comentários