Concessões de OAuth para Agentes de IA Agora São Indicadores de Compromisso

Quando a Vercel publicou um indicador de comprometimento para o incidente de segurança que divulgou em 19 de abril de 2026, o indicador que publicou foi um ID de cliente OAuth do Google Workspace: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. A instrução acompanhando para a comunidade mais ampla foi que administradores do Google Workspace e proprietários de contas deveriam verificar imediatamente o uso desse aplicativo.

Esse é um tipo particular de IOC, e implica um tipo particular de superfície de detecção. Um hash de arquivo pergunta se algo está presente em seus discos. Um ID de cliente pergunta se uma autorização existe em seu diretório, e quem a emitiu. A segunda pergunta é mais difícil para a maioria das organizações responderem rapidamente, porque as concessões em questão foram emitidas um funcionário de cada vez, através de telas de consentimento, por pessoas que se entendiam como instalando uma ferramenta de IA útil em vez de integrar um fornecedor.

A autorização é onde uma ferramenta de IA realmente se integra

Um assistente de IA raramente é perigoso por causa do que o modelo diz. Ele é perigoso por causa do que está autorizado a alcançar. A integração não é o modelo — é um token com um escopo, sentado no banco de dados de outra pessoa, válido até que uma pessoa específica o retire explicitamente.

O boletim da Vercel descreve a cadeia de forma clara. O incidente "originou-se com um comprometimento do Context.ai, uma ferramenta de IA de terceiros usada por um funcionário da Vercel." O atacante usou esse acesso para assumir a conta individual do Google Workspace do funcionário, o que levou à conta da Vercel desse funcionário, depois a uma mudança para um ambiente da Vercel, e a partir daí a enumeração e descriptografia de variáveis de ambiente que não estavam marcadas como sensíveis. A Vercel caracteriza a origem como "uma pequena ferramenta de IA de terceiros cujo aplicativo OAuth do Google Workspace foi o objeto de um comprometimento mais amplo, potencialmente afetando seus centenas de usuários em muitas organizações." Trabalhando com GitHub, Microsoft, npm e Socket, a equipe de segurança da Vercel confirmou que nenhum pacote npm publicado pela Vercel havia sido comprometido. O Google Mandiant e a polícia foram envolvidos.

Como a Vercel conta, a cadeia começa fora dos próprios sistemas da Vercel, em uma autorização que havia sido legitimamente concedida.

O padrão tem um precedente, e o precedente deixou um recibo

Essa forma não é nova. O centro de confiança da Salesloft carrega as descobertas do Mandiant sobre a intrusão Drift de 2025, e as frases operativas são quase clínicas: o ator da ameaça "acessou o ambiente AWS da Drift e obteve tokens OAuth para as integrações tecnológicas dos clientes da Drift," depois "usou os tokens OAuth roubados para acessar dados via integrações da Drift." Uma atualização anterior da Salesloft data a exfiltração resultante de instâncias do Salesforce de clientes de 8 a 18 de agosto de 2025; o Mandiant coloca a intrusão mais ampla entre 22 de março e 5 de setembro de 2025.

A instrução de remediação é a parte que vale a pena ler duas vezes. Para concessões que a Salesloft controlava centralmente, agiu em nome de seus clientes: "rotacionou todas as chaves de cliente gerenciadas centralmente, o que invalidou todos os tokens afetados." Para as integrações que os clientes gerenciavam por conta própria via chave de API, a orientação era que os clientes poderiam "ver uma lista de suas integrações conectadas atuais nas configurações do Admin da Drift," e que "essas ações precisarão ser realizadas diretamente dentro do aplicativo do fornecedor de terceiros."

Há a indicação arquitetônica, declarada pelo fornecedor no meio de seu próprio incidente. Onde existia um ponto de estrangulamento, a revogação era uma operação realizada uma vez, centralmente. Onde não existia, a revogação era uma lista, um navegador e uma pessoa trabalhando através de consoles de terceiros enquanto o incidente ainda estava aberto.

Por que a desativação ocupa o primeiro lugar entre os riscos de identidade não humana

O OWASP Non-Human Identities Top 10 — um projeto incubador do OWASP, publicado para 2025 e classificado por explorabilidade, prevalência, detectabilidade e impacto — coloca NHI1: Desativação Inadequada em primeiro lugar, definindo-a como "a desativação ou remoção inadequada de identidades não humanas (NHIs) como contas de serviço e chaves de acesso quando não são mais necessárias." O terceiro na mesma lista é NHI3: NHI de Terceiros Vulnerável, que descreve diretamente a forma do Context.ai: uma integração de terceiros que, uma vez comprometida, pode ser "explorada para roubar essas credenciais ou abusar das permissões concedidas."

Essa classificação decorre de uma assimetria estrutural em vez de gravidade apenas. A desativação humana funciona porque tem um gatilho — uma data de término, um tíquete, um trabalho de desprovisionamento de diretório que é acionado em uma mudança de status. Uma concessão OAuth emitida para uma ferramenta de IA não produz um evento equivalente. O funcionário que a autorizou pode ainda trabalhar lá. A ferramenta pode ainda estar em uso diário por outra equipe. A concessão não expira sozinha, a propriedade dela muitas vezes não é atribuída, e nos dois incidentes acima o sinal de que deveria ser retirada chegou como um boletim de segurança de um fornecedor que uma equipe de segurança não havia necessariamente catalogado.

Essa é a versão desconfortável: para concessões emitidas dessa forma, o gatilho de revogação tende a ser a divulgação de outra pessoa.

O que um ponto de estrangulamento muda, e o que não muda

A web obteve gateways de API. O tráfego obteve firewalls de aplicativos web. A identidade obteve proxies cientes de identidade. Cada uma dessas mudanças aconteceu pela mesma razão: as integrações escalaram mais rápido do que a governança por integração poderia acompanhar, então a indústria construiu um ponto de estrangulamento. O acesso a ferramentas de agentes está escalando da mesma forma — muitos clientes de agentes contra muitos servidores de ferramentas, cada conexão autenticada separadamente, cada credencial armazenada separadamente, cada chamada invisível para a equipe de segurança por padrão.

Um ponto de estrangulamento não torna um fornecedor comprometido seguro, e não desfaz uma exfiltração. O que muda é o custo das três perguntas que você precisa responder sob pressão de tempo: quais concessões existem, quem as emitiu e quão rapidamente podem ser retiradas. Essas são perguntas de inventário e revogação em vez de perguntas de detecção, o que significa que podem ser respondidas com antecedência, calmamente, antes que um ID de cliente apareça no boletim de alguém.

Como a Waxell lida com isso

O Waxell MCP Gateway é um endpoint MCP governado por inquilino que clientes de agentes apontam em vez de configurar servidores upstream individualmente. Sua página de produto nomeia o problema nos mesmos termos que este post tem utilizado: "a desativação requer perseguir credenciais através de 5 a 15 consoles de administração de SaaS," e "nenhuma lista central de quais servidores MCP sua equipe conectou."

Dois mecanismos são importantes para o modo de falha acima. O primeiro é a atribuição: cada chamada de ferramenta intermediada pelo gateway é resolvida para uma identidade de usuário real em vez de uma conta de serviço, com modos de autenticação por upstream que incluem OAuth em nome de, onde o gateway intermedia o fluxo e armazena um token de atualização criptografado em KMS que nunca é retornado ao cliente agente; uma conta de serviço compartilhada configurada no nível da organização; ou um token traga-seu-próprio mantido no corretor de credenciais. O segundo é a revogação: desativar a conta de uma pessoa na Waxell retira as concessões OAuth por upstream que esse usuário possuía através do gateway, em uma transação em vez de uma perseguição por ferramenta, e o log de auditoria registra o evento de revogação, o timestamp, o ator e a lista de upstreams desfeitos.

Junto a isso, o motor de políticas avalia uma chamada intermediada antes do despacho e avalia o resultado novamente no caminho de volta, usando ações de políticas documentadas agrupadas em controle de acesso, proteção de dados, orçamento e abuso, e defesa da cadeia de suprimentos, com um deny fixo > require_approval > redact