O ‘delegado confuso’ que engana a nuvem: a falha que persiste na Azure e no Google Cloud

Uma classe de vulnerabilidades conhecida há décadas — o problema do “delegado confuso” (confused deputy) — voltou a ganhar destaque com investigação que demonstra como continua a afetar integrações de fornecedores no Microsoft Azure e no Google Cloud. O conceito é simples e perigoso: um atacante sem privilégios consegue enganar um serviço mais poderoso para que este execute uma ação em seu nome, contornando os controlos de acesso do fornecedor de nuvem. Investigadores do SANS Institute, Brandon Evans e Eric Johnson, mostraram uma variante deste problema numa integração de segurança da nuvem, e o padrão está agora a ressurgir com força no contexto das plataformas de agentes de IA.

O que é o problema do “delegado confuso”

O conceito não é novo. Descrito na literatura de segurança da informação, um delegado confuso é um programa que é enganado por outro — com menos privilégios — para abusar da sua autoridade no sistema. É um tipo específico de escalada de privilégios. Em termos práticos, um ataque de delegado confuso manipula um programa, serviço ou identidade de confiança para que use os seus privilégios legítimos com um fim não autorizado, sem que o atacante precise de deter essas permissões diretamente.

Na nuvem, o risco surge com particular acuidade nas integrações de fornecedores. A AWS descreve há anos este padrão como uma situação em que “uma entidade que não tem permissão para realizar uma ação consegue coagir uma entidade mais privilegiada a realizá-la”. A entidade mais privilegiada costuma ser a plataforma do fornecedor; a entidade sem permissão é o utilizador malicioso dessa plataforma.

A investigação: uma variante cruzada entre nuvens

O caso concreto que ilustra o problema partiu de trabalho de investigação de dois instrutores do SANS. A 7 de fevereiro de 2024, Eric Johnson e Brandon Evans reportaram um problema de delegado confuso que descobriram no Microsoft Defender for Cloud, a ferramenta de gestão de postura de segurança (CSPM) da Azure. O Microsoft Security Response Center classificou a falha como “Crítica” e atribuiu uma recompensa pela sua divulgação.

O que torna esta descoberta relevante é a sua natureza. A vulnerabilidade é semelhante ao padrão documentado pela AWS, mas em vez de ser entre contas, é entre nuvens. Segundo os investigadores, porque o Defender é um serviço multi-inquilino com acesso às contas de nuvem de todos os seus clientes, sob certas condições as descobertas de segurança de um cliente poderiam ser divulgadas a terceiros não autorizados. Por outras palavras, ao conceder ao fornecedor acesso aos dados da nuvem, o cliente delega-lhe privilégios extensos — e, se o serviço não for de inquilino único, este passa a poder aceder a contas usadas por outros clientes.

Os próprios autores sublinham que o problema não se limita a um fornecedor. Notaram que questões semelhantes provavelmente afetam muitos outros fornecedores e recriaram uma aplicação fictícia com uma falha análoga para fins de demonstração e formação.

Como se manifesta em cada nuvem

A análise técnica ajuda a perceber por que razão a falha “persiste” e é difícil de auditar em algumas nuvens. Segundo investigação independente sobre o tema, o delegado confuso na nuvem tem duas variantes: uma que aproveita uma identidade não humana gerida pelo cliente e outra que aproveita uma identidade gerida pelo próprio fornecedor de nuvem. As identidades geridas pelo cliente incluem contas de serviço do GCP, funções IAM da AWS e identidades geridas atribuídas pelo utilizador no Azure; as geridas pelo fornecedor incluem agentes de serviço do GCP, funções ligadas a serviços da AWS e principais de serviço de plataforma do Azure.

Um ponto crítico para quem opera em multi-nuvem é a diferença de transparência entre fornecedores. De acordo com esta análise, a AWS é o único dos três que expõe a sua “maquinaria” de proteção contra o delegado confuso como primitivos de primeira classe e dá algum controlo ao cliente, enquanto as verificações internas do GCP e do Azure permanecem opacas — o cliente só percebe que existem quando uma delas nega o acesso. No Azure, por exemplo, a verificação dispara sempre que uma operação referencia um segundo recurso, e a falha manifesta-se apenas como um erro LinkedAuthorizationFailed.

A ligação com o SSRF e os metadados da nuvem

O delegado confuso relaciona-se de perto com outra técnica muito explorada em ambientes de nuvem: o SSRF (Server-Side Request Forgery). Os serviços de metadados das nuvens correm tipicamente num endereço IP especial, inacessível a partir da Internet mas acessível a partir de qualquer instância no ambiente de nuvem. Na prática, a AWS e a Azure usam o endereço 169.254.169.254, e o Google Cloud recorre a metadata.google.internal ou ao mesmo IP 169.254.169.254. Quando uma aplicação vulnerável a SSRF corre na nuvem, as respostas destes serviços podem incluir credenciais IAM, metadados da instância e scripts de dados de utilizador com segredos, permitindo um comprometimento mais profundo.

O novo capítulo: agentes de IA como “delegados” ideais

Onde a classe de vulnerabilidade ganha maior expressão em 2026 é no domínio da IA agêntica. Ao conceder a um agente de IA acesso às APIs de nuvem, ao correio, ao calendário, aos repositórios de código e às bases de dados, a organização está a “delegar” numa entidade semi-autónoma privilégios amplos em vários serviços. E, ao contrário de uma conta de serviço com âmbito fixo, o comportamento de um agente de IA é influenciado por instruções em linguagem natural que podem ser manipuladas por injeção de prompt, tornando-o um delegado confuso não por erro de configuração, mas pela própria natureza do seu funcionamento.

Um exemplo recente foi documentado no servidor MCP oficial da Microsoft para o Azure DevOps. Segundo a empresa de segurança que o analisou, um atacante com acesso a um único projeto pode esconder instruções dentro de um comentário HTML, invisível na interface do Azure DevOps, que é entregue tal e qual no contexto do agente. Quando a vítima pede ao agente que reveja o pull request, as instruções ocultas sequestram o objetivo do agente e, como este detém as credenciais da vítima, executa ações em projetos que o atacante não conseguiria alcançar sozinho — o delegado confuso clássico, aplicado à IA.

Mitigações concretas

• Menor privilégio. Limitar o que cada identidade humana, de máquina ou de aplicação pode fazer reduz o risco: se um delegado for manipulado, há menos permissões disponíveis para abuso.
• Reduzir a confiança nos fornecedores. Uma vulnerabilidade no fornecedor pode comprometer todo o ambiente de nuvem do cliente, pelo que as organizações devem minimizar o nível de confiança que depositam nos fornecedores aos quais expõem os seus dados.
• Eliminar credenciais de longa duração. A abordagem defendida pelos investigadores passa por substituir credenciais de nuvem de longa duração por Workload Identity Federation entre AWS, Azure e GCP.
• Identidade de carga de trabalho e tokens de curta duração. Para agentes, propõe-se um modelo em que se o agente for comprometido por injeção de prompt, o atacante fica apenas com um token de âmbito mínimo que expira em menos de um minuto e não pode pivotar para outros serviços.
• Proteção contra SSRF. Endurecer o acesso aos serviços de metadados (por exemplo, exigir a versão mais recente do serviço de metadados) e validar rigorosamente qualquer pedido baseado em entrada do utilizador.

Porque importa em Portugal

Para empresas e organizações portuguesas que adotam nuvem pública e, cada vez mais, agentes de IA integrados com dados internos, este tipo de falha tem implicações diretas. Uma escalada de privilégios que atravesse fronteiras entre inquilinos ou entre nuvens pode expor dados pessoais, com consequências ao abrigo do RGPD caso ocorra acesso não autorizado a informação de titulares. Além disso, entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a diretiva NIS2) devem garantir a gestão adequada de riscos na cadeia de fornecimento e nas integrações de serviços de terceiros — precisamente a superfície onde o delegado confuso se manifesta. O CNCS e o CERT.PT recomendam de forma consistente a aplicação do menor privilégio e a gestão robusta de identidades, princípios que estão no centro da mitigação desta classe de vulnerabilidades.

Perguntas frequentes

O que é um ataque de “delegado confuso”?

É uma falha de controlo de acesso em que um programa ou serviço com privilégios é induzido por outra entidade, com menos permissões, a usar a sua autoridade para um fim não autorizado. O atacante não precisa de deter os privilégios diretamente — basta enganar o “delegado”. É considerado um tipo de escalada de privilégios.

Esta falha afeta apenas o Azure e o Google Cloud?

Não. O padrão é transversal às grandes nuvens e à AWS, que o documenta há anos. A investigação recente destaca a Azure e o Google Cloud em parte porque as suas verificações internas de proteção são mais opacas, dificultando a auditoria por parte dos clientes, ao passo que a AWS expõe mais controlos ao utilizador.

Qual é a ligação entre agentes de IA e o delegado confuso?

Um agente de IA recebe credenciais amplas para agir em nome do utilizador em vários serviços. Como o seu comportamento é guiado por linguagem natural, pode ser manipulado por injeção de prompt, tornando-se um delegado confuso que executa ações maliciosas com a identidade e os privilégios da vítima.

Como posso reduzir o risco na minha organização?

Aplique o princípio do menor privilégio, limite a confiança depositada em serviços de fornecedores multi-inquilino, elimine credenciais de longa duração recorrendo a identidades de carga de trabalho com tokens de curta duração e endureça o acesso aos serviços de metadados para prevenir SSRF.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente por investigadores do SANS Institute (Brandon Evans e Eric Johnson), pela Manifold Security, pela BeyondTrust e em documentação técnica pública sobre segurança de nuvem.