2026-04-29 00:00
← VoltarA maioria das organizações fica nervosa com a adoção de ferramentas de IA não aprovadas pelos funcionários. O uso de Shadow AI na forma de LLMs, onde os usuários carregam dados confidenciais para ChatGPT, Claude ou uma dúzia de outros chatbots, é uma preocupação legítima. Mas não é o maior. Quando um funcionário conecta um aplicativo de IA ao Google Workspace, Microsoft 365, Salesforce ou qualquer outra plataforma principal, ele cria uma ponte programática persistente entre seu ambiente e terceiros. Essa ponte não desaparece quando o funcionário para de usar o aplicativo. E se esse terceiro for comprometido, a ponte se tornará um caminho direto para seus sistemas. Acabamos de ver esse cenário acontecer com a violação do Vercel. O aplicativo de IA da Context.ai foi testado por um funcionário da Vercel, que concedeu acesso (via OAuth) à sua conta do Google Workspace.
Quando o Context.ai foi violado, Vercel foi pego nas consequências. A confusão da IA é um multiplicador de força para o shadow SaaS Shadow IT não é um problema novo. A maioria das organizações opera fortemente (ou exclusivamente) em SaaS, acessado no navegador, com centenas de aplicativos por empresa. Aplicativos não gerenciados e autoadotados têm sido uma pedra no sapato das equipes de segurança há algum tempo. Mas a disputa da IA é um multiplicador de força. Existem diferentes tipos de Shadow IT que você deve conhecer no contexto de aplicativos de IA: Aplicativos Shadow: aplicativos nos quais os funcionários...
A maioria das organizações fica nervosa com a adoção de ferramentas de IA não aprovadas pelos funcionários. O uso de Shadow AI na forma de LLMs, onde os usuários carregam dados confidenciais para ChatGPT, Claude ou uma dúzia de outros chatbots, é uma preocupação legítima. Mas não é o maior. Quando um funcionário conecta um aplicativo de IA ao Google Workspace, Microsoft 365, Salesforce ou qualquer outra plataforma principal, ele cria uma ponte programática persistente entre seu ambiente e terceiros. Essa ponte não desaparece quando o funcionário para de usar o aplicativo. E se esse terceiro for comprometido, a ponte se tornará um caminho direto para seus sistemas. Acabamos de ver esse cenário acontecer com a violação do Vercel. O aplicativo de IA da Context.ai foi testado por um funcionário da Vercel, que concedeu acesso (via OAuth) à sua conta do Google Workspace.
Quando o Context.ai foi violado, Vercel foi pego nas consequências. A confusão da IA é um multiplicador de força para o shadow SaaS Shadow IT não é um problema novo. A maioria das organizações opera fortemente (ou exclusivamente) em SaaS, acessado no navegador, com centenas de aplicativos por empresa. Aplicativos não gerenciados e autoadotados têm sido uma pedra no sapato das equipes de segurança há algum tempo. Mas a disputa da IA é um multiplicador de força. Existem diferentes tipos de Shadow IT que você deve conhecer no contexto de aplicativos de IA: Aplicativos Shadow: aplicativos nos quais os funcionários se inscreveram e estão usando para fins comerciais sem aprovação comercial. Isso inclui aplicativos registrados com uma conta corporativa ou pessoal. Inquilinos paralelos: aplicativos que os funcionários acessam com contas pessoais, essencialmente criando inquilinos paralelos fora do controle da sua organização, mesmo que você tenha aprovado o próprio aplicativo.
Extensões Shadow: muitos aplicativos de IA vêm com uma extensão equivalente, junto com inúmeras extensões de terceiros que não são confiáveis ou são totalmente maliciosas. As extensões do navegador adicionam outro ângulo à equação, apresentando visibilidade além do aplicativo na atividade do navegador. Integrações shadow: conexões OAuth entre aplicativos que não são conhecidos ou aprovados. Mesmo que um aplicativo em si seja aprovado, conectá-lo diretamente aos seus aplicativos corporativos principais — com todos os dados confidenciais e funcionalidades nele contidos — também não é necessariamente aprovado. No caso Vercel, estamos falando especificamente sobre integrações shadow. Mas tudo isso representa um risco importante para a sua organização. A violação do Vercel: um exemplo clássico de concessões OAuth que deram errado A violação do Vercel ilustra claramente o impacto das integrações de IA sombra. Um funcionário da Vercel conectou um aplicativo de IA – especificamente um produto obsoleto “AI Office Suite” de nível consumidor da Context.ai – em seu locatário do Google Workspace.
Vercel nem era cliente registrado da Context.ai. Provavelmente foi um teste de autoatendimento que foi integrado, pouco usado e esquecido, adicionando um nó invisível à superfície de ataque da organização. Ao adotar o aplicativo Context.ai, o funcionário da Vercel adicionou funcionários e sistemas de terceiros como dependência de segurança. Quando o Context.ai foi posteriormente comprometido (supostamente o resultado de uma infecção por infostealer de um funcionário em busca de cheats do Roblox – sim, é verdade), o invasor conseguiu aproveitar os tokens OAuth armazenados no ambiente do Context.ai para se transformar em contas de clientes downstream. Isso incluía o Google Workspace do funcionário da Vercel, que era uma conta bem autorizada com acesso a painéis internos, registros de funcionários, chaves de API, tokens NPM e tokens GitHub. Vercel não é uma exceção: os invasores estão visando o OAuth em grande escala. A interconectividade generalizada do OAuth não é apenas um problema de aplicativos de IA. Os invasores já exploram isso há algum tempo, e a cadência está se acelerando: em 2025, Scattered Lapsus$ Hunters lançaram ataques à cadeia de suprimentos orientados por OAuth contra locatários do Salesforce e do Google Workspace após violar o Salesloft (especificamente a plataforma Salesloft Drift) e o Gainsight.
Mais de 1.000 organizações foram impactadas – incluindo Google, Cloudflare, Rubr ik, Elastic, Proofpoint, JFrog, Zscaler, Tenable, Palo Alto Networks, CyberArk, BeyondTrust, Qualys e muito mais — com mais de 1,5 bilhão de registros roubados. Os clientes da Snowflake foram afetados após uma violação na empresa de detecção de anomalias de dados Anodot, onde o invasor tentou aproveitar tokens de autenticação roubados para acessar dados do Salesforce, sendo a Rockstar Games uma vítima de alto perfil. Os invasores não estão apenas abusando das conexões OAuth existentes como parte de ataques à cadeia de suprimentos – eles estão usando o phishing focado no OAuth como porta de entrada para os ambientes das vítimas. A campanha do Salesforce do ano passado começou com phishing de código de dispositivo, onde os invasores enganaram as vítimas para que registrassem um aplicativo controlado pelo invasor em seu locatário do Salesforce, concedendo acesso total à API para exfiltração de dados em massa. Desde então, observamos um aumento de 37 vezes nos ataques de phishing de código de dispositivo este ano, com mais de uma dúzia de kits criminosos PhaaS em circulação. O padrão é claro: as integrações OAuth estão se tornando uma das superfícies de ataque mais confiáveis em ambientes corporativos, e cada nova ferramenta de IA que seus funcionários conectam torna a web um pouco mais ampla. Novo relatório: Como os ataques baseados em navegador estão contornando os controles de segurança Os ataques baseados em navegador, desde phishing AITM e ClickFix até aplicativos OAuth maliciosos e sequestro de sessão, estão gerando as maiores violações da atualidade. Aprenda sobre as técnicas mais recentes que os invasores estão usando.
Obtenha sua cópia A expansão do OAuth vai muito além do Google e da Microsoft A violação do Vercel é ilustrativa, mas apenas arranha a superfície do problema. Controlar o OAuth no principal ambiente de nuvem empresarial (como M365 ou Google Workspace) é bastante simples: ambas as plataformas oferecem aos administradores a capacidade de auditar e controlar conexões OAuth. A violação do Vercel poderia ter sido evitada se seus funcionários tivessem sido impedidos de adicionar novas integrações OAuth sem a aprovação do administrador – uma alternância no painel de administração do Google. Ou, se a integração tivesse sido sinalizada em uma auditoria de rotina e removida. Mas fazer isso em todos os aplicativos SaaS é consideravelmente mais difícil. Você não precisa apenas de um inventário abrangente e atualizado, mas também de ser um administrador de aplicativo para cada aplicativo (nem sempre é o caso de aplicativos auto-adotados), e o aplicativo específico precisa fornecer o controle para restringir e remover concessões OAuth em nome dos usuários em seu locatário. Pense em como funciona um aplicativo típico de IA. Se você deseja automatizar fluxos de trabalho de maneira eficaz – extrair dados de um aplicativo, agregá-los e analisá-los em outro, apresentar essas informações em um relatório, painel ou apresentação e depois distribuí-los – são algumas integrações em apenas um fluxo de trabalho.
As conexões MCP usam OAuth para alcançar essa interconectividade da mesma forma que qualquer outro aplicativo SaaS. Costumávamos falar sobre aplicativos de automação como o Zapier como uma mina de ouro para invasores. Bem, os aplicativos de IA estão a caminho de se tornarem ainda mais interconectados, usados com mais frequência e mais flexíveis em termos de como os invasores podem abusar deles. Exemplo ilustrativo da expansão do SaaS OAuth, desde a nuvem corporativa primária até aplicativos principais e SaaS mais amplo. Os aplicativos de IA são destacados em laranja. O que as equipes de segurança devem fazer agora Bloqueie o consentimento do OAuth. Adote uma abordagem de negação padrão para permitir que os usuários consintam com novas integrações em seus principais aplicativos corporativos. Este é o mesmo princípio que recomendamos recentemente para o gerenciamento de extensões de navegador – os usuários não devem ser capazes de introduzir novas relações de confiança sem aprovação.
Audite o que já está conectado. Audite rotineiramente as integrações OAuth já existentes em seu ambiente para garantir que elas ainda sejam definitivamente necessárias. Cada integração expande sua superfície de ataque e pode conceder amplo acesso ao invasor. Pense além do Google e da Microsoft. Controlar o OAuth na nuvem corporativa principal é necessário, mas não suficiente. As conexões SaaS para SaaS são menos visíveis e geralmente têm menos controles. Você precisa de visibilidade das concessões OAuth que acontecem em todos os aplicativos. Lembre-se, este não é exclusivamente um problema de IA sombria, mesmo que a adopção da IA esteja a contribuir significativamente para a expansão.
Como o Push Security pode ajudar Como já estabelecemos, existem algumas peças nesse quebra-cabeça. Push Security pode ajudar com todos eles. O Push observa cada login de aplicativo que seus funcionários fazem em seus navegadores, criando uma imagem abrangente do uso de SaaS e IA em sua organização. Isso inclui como eles estão fazendo login e quão seguro é o login: ele tinha MFA, que tipo de MFA, estava usando uma senha fraca ou comprometida, eles usaram SSO e assim por diante. O Push também rastreia integrações OAuth em seu ambiente e oferece a capacidade de gerenciá-las e removê-las, fornecendo uma plataforma única para visualizar, gerenciar e proteger o uso de aplicativos em sua organização. Analise integrações OAuth, incluindo permissões, contagem de usuários e outros metadados úteis usando Push. Exclua facilmente integrações indesejadas com Push. Isso torna mais fácil revelar vulnerabilidades e possíveis lacunas de controle e fazer algo a respeito.
Mas onde o Push realmente se destaca é na capacidade de observar e bloquear solicitações de conexão OAuth mesmo fora dos seus principais aplicativos corporativos. Usando Push, você pode detectar e bloquear solicitações de integração OAuth à medida que elas passam pelo navegador. Esse nível de controle independente de aplicativos é absolutamente crítico para interromper a expansão da integração OAuth. A plataforma de segurança baseada em navegador da Push também detecta e bloqueia ataques baseados em navegador, como phishing AiTM, preenchimento de credenciais, extensões maliciosas de navegador, phishing de código de dispositivo, ClickFix e sequestro de sessão em tempo real – incluindo os vetores de entrega de infostealer mais proeminentes (a fonte da violação do Context.ai). O Push analisa todas as páginas da web em todas as sessões e guias do navegador em busca de ameaças, em tempo real, sem latência. Saiba mais sobre como proteger Shadow AI com Push e reserve um horário com nossa equipe para uma demonstração ao vivo. Patrocinado e escrito por Push Security.