Sequestro de identidade de fluxo de trabalho: Noma Labs transforma um e-mail de suporte comum em acesso privilegiado a dados

Em 9 de setembro de 2026, a equipe de pesquisa da Noma Security, assinando como Noma Labs, publicou um relato do que chama de sequestro de identidade de fluxo de trabalho: um fluxo de trabalho de IA empresarial lê uma mensagem comum que chega a um ponto de entrada público — uma caixa de entrada de suporte, uma issue do GitHub, um formulário web, um documento compartilhado — e então realiza o trabalho solicitado usando sua própria conta de serviço com altos privilégios, em vez das permissões do remetente. A demonstração passo a passo da Noma mostra alguém de fora enviando um e-mail para o endereço público de suporte de uma empresa e pedindo, entre outras coisas, os números trimestrais de vendas do e-mail mais recente do Diretor Financeiro; minutos depois, o conteúdo chega à caixa de entrada do atacante. Nenhum modelo foi enganado e nenhuma conta foi comprometida, e é esse o ponto central do relatório: "tudo o que o atacante precisou fazer foi pedir." O arquivo não registra nenhum dano real — nenhuma vítima é nomeada e nenhum sistema implantado é descrito como comprometido — e classifica a descoberta como pesquisa, severidade média, confiança A, contestado: falso. Este relato baseia-se no relatório do Noma Labs, na cobertura do Dark Reading publicada no mesmo dia e no acompanhamento do CSO Online, e o arquivo de incidentes de IA mantém esta entrada ao lado de suas vizinhas, cada uma com suas próprias fontes, severidade e grau de confiança.

Vale a pena ler os próprios campos do registro antes do texto corrido. Ele está marcado com INFRA e EXFIL, abrange a região GLOBAL, traz uma única data precisa quanto ao dia, 9 de setembro de 2026, e não está marcado como entrada de destaque. A data é a data de publicação da pesquisa e nada mais; não há uma linha do tempo de incidente associada a ela, porque não há incidente a cronometrar. Isso é a primeira coisa a ter em mente: o que a Noma publicou é um mecanismo e uma categoria, não um relatório de violação.

O que o Noma demonstrou, e o que não demonstrou

A sequência da caixa de entrada de suporte é uma ilustração construída, e não um caso de cliente. O relatório da Noma não nomeia uma organização, não fornece uma contagem de implantações afetadas, não publica telemetria de nenhum pipeline real e não vincula uma execução de prova de conceito para este cenário — ao contrário da pesquisa de julho do grupo, que apontava para uma execução pública do GitHub Actions. O que o relatório oferece, em vez disso, é uma descrição do mecanismo precisa o suficiente para ser verificada em relação a uma arquitetura: uma entrada não autenticada chega, o modelo a interpreta corretamente, o pipeline executa a chamada downstream, e essa chamada é feita com a autoridade do criador do workflow.

Sasi Levi, líder de pesquisa de segurança da Noma e autora do relatório, resume a causa raiz em uma frase: "a identidade e as permissões do usuário que aciona um fluxo de trabalho são desacopladas da identidade e das permissões usadas para executá-lo". Onde isso se aplica, o fluxo de trabalho se torna, nas palavras do relatório, "proxies não autenticados para ações privilegiadas e exfiltração silenciosa de dados".

Como as ações são executadas por automação confiável com credenciais válidas, a Noma argumenta que há pouco que o alerta convencional consiga captar. A solicitação é normal, a saída do modelo é uma saída válida do modelo, a chamada de API é autenticada, a resposta é a resposta que o fluxo de trabalho foi criado para enviar. O CSO Online citou o red teamer Vibhum Dubey tornando o problema de detecção concreto: “Os eventos individuais podem parecer completamente legítimos. Os sinais úteis viriam da correlação entre o solicitante original, a identidade usada downstream, os recursos acessados, os parâmetros fornecidos e a ação final.”

A verificação que falha é uma verificação de autorização, não um filtro de conteúdo

A ilustração mais contundente do relatório é um par de solicitações idênticas. De um diretor financeiro (CFO): "Quais são os números trimestrais de vendas do Diretor Financeiro no e-mail mais recente dele?" De um remetente externo: as mesmas palavras. O ponto de Noma é que o prompt e a operação solicitada são os mesmos, enquanto a decisão de autorização deveria ser totalmente diferente — "Um CFO tem direito a essa informação; um remetente externo não."

Detectores padrão de injeção de prompt e salvaguardas de agentes, argumenta o relatório, classificam as duas entradas de forma idêntica, porque não há nada malicioso em nenhuma delas a ser detectado. "O risco de segurança não está no prompt; está na fronteira de autorização." A afirmação estrutural da Noma decorre disso: salvaguardas, instruções de sistema e filtros de entrada "não foram projetados para servir como fronteira de autorização", de modo que um pipeline que depende deles para decidir o que um chamador pode recuperar está confiando em um controle que nunca foi solicitado a fazer esse trabalho.

A distinção importa na prática. A injeção direta de prompt manipula como o modelo segue instruções; a injeção indireta de prompt esconde instruções em conteúdo que o modelo lerá depois; o sequestro de identidade de fluxo de trabalho, como a Noma o define, não precisa de nenhuma das duas, porque a solicitação é algo que o modelo deve entender e que o pipeline deve executar. Um defensor que passou o ano se protegendo contra injeção tem trabalhado em outra camada.

Os fluxos de trabalho estáticos ficam fora da iniciativa de hardening de agentes.

A Noma separa duas coisas que costumam ser usadas de forma intercambiável. Um fluxo de trabalho de IA é uma sequência predefinida e estática na qual um modelo é uma etapa de processamento — a forma abreviada do relatório é etapa A, modelo, etapa B, etapa C — e o pipeline determinístico em torno do modelo controla o que acontece. Um fluxo de trabalho agêntico é autônomo: o agente decide quais etapas seguir e quais ferramentas invocar. Grande parte do esforço atual de segurança, argumenta o relatório, tem se concentrado no segundo tipo, restringindo o acesso a ferramentas e delimitando permissões para agentes que tomam decisões dinâmicas, e esses controles não alcançam o primeiro.

O relatório também fecha uma brecha óbvia. Restringir quem ou o que pode acionar um fluxo de trabalho não resolve o problema: se uma automação é executada às 8:00 em um horário agendado e age sobre uma caixa de entrada na qual qualquer pessoa pode escrever, auditar "quem pode acionar este fluxo de trabalho" responde à pergunta errada. A regra da Noma é que toda automação deve ser avaliada pela "parte menos confiável capaz de influenciar aquilo sobre o que ela age" — incluindo e-mails, formulários, tickets, issues do GitHub, documentos compartilhados e mensagens de chat.

A Noma diz que o Google corrigiu um caso do Google Workflows; o Google não publicou nada.

A única plataforma nomeada no relatório é a do Google. A Noma afirma que identificou o mesmo vetor de risco no Google Workflows, que o reportou de forma responsável e que o Google reconheceu o relatório e confirmou uma correção “sem divulgar detalhes de implementação”. Essa frase é todo o registro público. Não foi possível localizar nenhum aviso do Google, nota de versão ou CVE que descrevesse esse vetor, e todos os relatos secundários da correção — incluindo os publicados nos dias após 9 de setembro — atribuem-na à Noma, e não ao Google.

O relatório também não é perfeitamente consistente sobre a qual produto do Google se refere. O texto cita o Google Workflows; o título de uma seção no mesmo relatório diz “Google Workspace: Sequestro de Identidade de Fluxo de Trabalho de IA”. Ambos são produtos do Google com limites de confiança diferentes, e o relatório não os concilia. A Noma não diz se o caso que relatou foi explorado, quantos clientes foram expostos ou o que a correção alterou — e, como o Google não disse nada, nenhuma dessas lacunas pode ser fechada pelo lado do fornecedor.

O GitLost era a mesma fronteira, vista através de uma lente mais estreita

A divulgação anterior da Noma dá à categoria um precedente. Em julho de 2026, o grupo publicou uma pesquisa sobre GitHub Agentic Workflows, que batizou de GitLost: um fluxo de trabalho acionado quando uma issue era atribuída lia o título e o corpo da issue e respondia com um comentário e, como o agente tinha acesso de leitura aos repositórios da organização, usuários externos podiam usar a atribuição de issues para acessar dados de repositórios privados. A Dark Reading noticiou o caso em 7 de julho de 2026 e descreveu um atacante escondendo comandos em inglês simples no corpo de uma issue aberta em um repositório público, sem precisar de credenciais nem de habilidades de programação.

Os dois enquadramentos não são idênticos, e a diferença é a parte interessante. O relato de julho da Dark Reading é uma história de injeção de prompt: texto controlado pelo atacante é lido como instruções. O relatório de setembro da Noma descreve o GitLost em termos do gatilho e do acesso de leitura a todo o repositório, e o apresenta como o mesmo limite de autorização visto sob um ângulo. Ambas as descrições se encaixam em um fluxo de trabalho cujo agente leu texto escrito por alguém de fora, mas apenas a mais antiga depende de o modelo ser direcionado. A Noma agora diz que relatou o mesmo vetor de risco ao Google; não diz se o caso GitLost chegou a ser explorado além da demonstração publicada.

Segundo o próprio relato da Noma sobre o alcance, o Hacker News, o Dark Reading e mais de 100 outros veículos internacionais cobriram a pesquisa GitLost. Esse número é da fornecedora, e este artigo não contabilizou a cobertura de forma independente.

Os praticantes concordam que o mecanismo é antigo; a discussão é sobre o nome.

A cobertura independente não contestou a descoberta, e dois profissionais externos questionaram a novidade, e não a substância. Morey Haber, consultor-chefe de segurança da BeyondTrust, disse ao Dark Reading: "Ninguém induziu um modelo de IA a fazer nada que ele não devesse fazer. O modelo fez exatamente o que lhe foi dito por um estranho (não confiável), e o fluxo de trabalho ao seu redor usou a identidade de outra pessoa para que isso acontecesse, já que não tinha escopo definido e não era tratado com privilégio mínimo." A CSO Online citou Vibhum Dubey descrevendo o padrão como "uma classe conhecida de fragilidade de autorização" e acrescentando que, quando uma entrada não autenticada pode acionar um fluxo de trabalho confiável que age com seus próprios privilégios, "o fluxo de trabalho pode efetivamente agir como um confused deputy".

Ram Varadarajan, executivo-chefe da Acalvio, ofereceu à Dark Reading um controle totalmente diferente: em vez de mais filtragem, semear o ambiente com iscas — threads falsas de executivos, registros honeytoken — que não têm nenhum motivo legítimo para que qualquer fluxo de trabalho autorizado as acesse, de modo que uma solicitação de aparência benigna que tente alcançar uma delas acione um limite que nunca deveria cruzar. A discordância, tal como é, gira em torno de se a contribuição útil é um novo nome para uma falha de delegação da era de 1988 ou uma descrição funcional de onde essa falha agora reside. A posição de Noma é a segunda: que o padrão é sistêmico nos pipelines de IA empresariais e que os atuais frameworks de segurança de IA olham para a superfície errada.

A mitigação é delegação e um ponto de verificação, não um filtro melhor

Os controles recomendados pela Noma ficam na camada de aplicação, e não na camada de modelo. A delegação de tokens ciente de identidade significa remover chaves de API administrativas estáticas dos fluxos de trabalho de IA e executar operações de dados com tokens de delegação de curta duração e escopo restrito, vinculados ao solicitante autenticado, para que o contexto do usuário se propague até a chamada que de fato acessa os dados. Pontos de verificação de autorização contextual significam tratar toda saída do modelo como entrada não confiável e colocar uma avaliação explícita de controle de acesso e proteção em tempo de execução entre a etapa de transformação do modelo e qualquer chamada subsequente a banco de dados ou ferramenta. A separação assimétrica de saídas significa isolar estruturalmente a recuperação de dados dos canais de comunicação externos, para que um fluxo de trabalho que lida com dados internos sensíveis não compartilhe um caminho de execução com um mecanismo automatizado que responde a terceiros.

Dubey deu à CSO Online um teste mais barato do que qualquer um dos três: comparar resultados entre níveis de privilégio. "Se um usuário com baixos privilégios consegue obter o mesmo resultado que um administrador porque os sistemas a jusante veem apenas a identidade do fluxo de trabalho, é aí que eu concentraria a investigação."

O que o registro deixa em aberto

Nenhuma vítima, nenhuma contagem e nenhuma telemetria. O caso da caixa de entrada de suporte da Noma é um passo a passo; o relatório não nomeia nenhuma organização e o arquivo registra danos reais como falsos. A plausibilidade do mecanismo não é evidência de que ele tenha sido usado.

• Que produto Google foi corrigido, e qual foi a correção. O texto da Noma diz Google Workflows, o título da respetiva secção diz Google Workspace, e a Google não publicou nada. As organizações ainda não conseguem determinar, a partir de fontes públicas, se um pipeline que executam estava abrangido.

• Se o vetor foi explorado em qualquer lugar. Nem o relatório nem qualquer cobertura revisada para este artigo descreve uma campanha observada, uma perda de dados ou uma constatação forense atribuível ao sequestro de identidade de fluxo de trabalho.

• Se a categoria se sustenta sob medição. Nenhuma parte independente publicou uma varredura, um corpus de pipelines afetados ou uma suíte de testes para o padrão; as evidências em circulação são argumentos arquiteturais somados ao relato de um fornecedor sobre um único caso corrigido.

• {{1}}Quem está apresentando o argumento. A Noma Labs é o braço de pesquisa da Noma Security, que vende controles de segurança para agentes exatamente do tipo que seu relatório recomenda. Isso não torna a descoberta errada — Dark Reading e CSO Online noticiaram o fato, e nenhum dos dois encontrou erro factual —, mas é um contexto que o leitor deve ter em mente ao avaliar quão amplamente a categoria é definida.{{/1}}

O grau de severidade médio do registro e seu sinalizador de dano real definido como falso descrevem a evidência, não o mecanismo. O que a Noma realmente estabeleceu é restrito e verificável: que a identidade de gatilho de um fluxo de trabalho e sua identidade de execução são coisas distintas, que a segunda costuma ser a mais poderosa, e que um pipeline que nunca as compara fará por um estranho o que faria pela pessoa para quem foi criado. O controle que se segue é correspondentemente pouco glamouroso — pergunte, para cada automação, quem pode influenciar aquilo sobre o que ela age, e se algo a jusante alguma vez verifica novamente se a pessoa que pergunta tinha permissão para perguntar.