Not in the middle: why a Context AI–style breach against Caiioo would yield nothing useful

Esta é uma tradução automática do documento original em inglês. Em caso de conflito entre esta tradução e a versão original em inglês, a versão em inglês prevalecerá. Ler a versão original em inglês

Fora do meio: por que uma violação no estilo Context AI contra o Caiioo não renderia nada útil

2026-04-22 · Caiioo Team

Em 19 de abril de 2026, a Vercel divulgou que a ferramenta de IA de terceiros de um único funcionário havia sido comprometida e que o token OAuth comprometido foi usado para entrar nos ambientes internos da Vercel. Um subconjunto limitado de clientes teve variáveis de ambiente não sensíveis expostas. Variáveis de ambiente criptografadas/sensíveis não foram afetadas.

A ferramenta era a Context AI. O funcionário concedeu a ela acesso amplo de "Permitir Tudo" ao seu Google Workspace corporativo. Essa única concessão OAuth, mantida nos servidores da Context AI, foi o ponto de alavancagem para tudo o que se seguiu.

Um ator de ameaça no BreachForums listou separadamente o que afirma serem 580 registros de funcionários da Vercel à venda por US$ 2 milhões. A Vercel não verificou essa listagem.

O incidente não terminou. Mas a lição arquitetônica já está clara e é útil para qualquer pessoa que esteja avaliando um espaço de trabalho de IA.

O formato do ataque

O modelo SaaS-AI coloca um fornecedor no meio de cada concessão OAuth que você fornece.

Quando você instala uma ferramenta de produtividade de IA de terceiros e clica na tela de consentimento OAuth, o token de acesso e o token de atualização emitidos pelo Google (ou Microsoft, ou qualquer provedor de identidade) não permanecem no seu dispositivo. Eles são entregues aos servidores do fornecedor, porque a IA que precisa deles roda na nuvem do fornecedor. A infraestrutura do fornecedor mantém um conjunto de tokens continuamente atualizados para cada um de seus usuários, com escopo para as permissões "Permitir Tudo" que a maioria dos usuários aceitou sem ler.

Esse armazenamento centralizado de tokens é precisamente o que os invasores visam. Comprometer o fornecedor uma única vez dá acesso ao Workspace de milhares de clientes. O próprio boletim da Vercel alerta que os efeitos a jusante podem atingir "centenas de usuários em muitas organizações".

Relatórios rastreiam a cadeia original até um funcionário da Context AI cujo dispositivo pessoal foi comprometido em fevereiro de 2026, supostamente por meio de um exploit de jogo Roblox baixado que carregava o malware infostealer Lumma Stealer. Esse malware exfiltrou as credenciais do Google Workspace e da AWS do funcionário, que por sua vez desbloquearam o cofre de tokens OAuth. Um dispositivo pessoal infectado, um cofre SaaS corporativo, centenas de Workspaces afetados.

Três razões arquiteturais pelas quais uma violação no estilo Context AI contra a Caiioo não resultaria em nada útil

A Caiioo é um workspace poderoso e focado em privacidade, com um orquestrador de agentes e uma interface de chat que funciona em um painel lateral. "Privacy-first" descreve uma postura arquitetural específica, não uma frase de marketing. Existem três propriedades concretas em funcionamento.

1. Seus tokens OAuth do Workspace são armazenados criptografados no seu dispositivo, não em nossos servidores

Quando você conecta uma conta Google ou Microsoft na Caiioo, você verá a tela de consentimento OAuth padrão do Google com os escopos que você está concedendo. Até aqui, isso parece idêntico à autorização da Context AI.

A diferença estrutural é o que acontece com os tokens que saem desse fluxo de consentimento. O access token e o refresh token emitidos pelo Google são armazenados criptografados no seu dispositivo — no Keychain no macOS e iOS, no Keystore do Android no Android, no armazenamento seguro do navegador na extensão. Eles não são armazenados no banco de dados central da caiioo. Não temos um cofre de tokens guardando-os em seu nome.

Quando o orquestrador de agentes precisa ler seu calendário ou pesquisar sua caixa de entrada, a chamada de API vai do seu dispositivo diretamente para o Google, com o token do armazenamento seguro do seu dispositivo anexado. Nossa infraestrutura não está no caminho dos dados para nenhum conteúdo do seu Workspace.

Você mesmo pode verificar isso no código-fonte: src/shared/auth/connections-manager.ts é onde as conexões OAuth do Google/Microsoft são persistidas. Os registros OAuthConnection, incluindo os campos accessToken e refreshToken, são gravados através do adaptador de armazenamento local — não transmitidos para um armazenamento de tokens central.

2. O barramento de mensagens do relay é criptografado de ponta a ponta

Quando os componentes da Caiioo em diferentes dispositivos precisam se coordenar — sua extensão de navegador falando com seu app desktop, seu telefone falando com seu servidor doméstico, a UI do painel lateral invocando uma ferramenta que roda nativamente no macOS — eles o fazem através de um relay que hospedamos em relay.pebbleflow.ai. O relay é o ponto de encontro que permite que seus dispositivos se encontrem através das redes.

Esse relay é criptografado de ponta a ponta. Os dispositivos de cada usuário realizam uma troca de chaves através do envelope do relay e, a partir daí, as mensagens entre seus dispositivos são texto cifrado do ponto de vista do relay. O relay pode roteá-las, mas não pode lê-las.

Isso não é apenas uma intenção. O Durable Object que gerencia as conexões WebSocket, cloud/relay/src/user-relay.ts, está documentado como: "Gerencia conexões WebSocket para um único usuário. Lida com mensagens criptografadas E2E (opacas para o relay) e troca de chaves." Os caminhos de código que lidam com o tipo de mensagem ENCRYPTED são explicitamente comentados: "Mensagem criptografada para cliente específico (não podemos lê-la)." O relay não é arquiteturalmente capaz de inspecionar o conteúdo das mensagens que encaminha.

3. O relay é single-tenant por usuário, por construção

O relay da Caiioo é construído sobre Cloudflare Durable Objects. Cada usuário recebe sua própria instância de UserRelay — uma peça separada de computação e armazenamento isolada em tempo de execução. Não existe um banco de dados multi-tenant compartilhado contendo o estado da sessão ao vivo de cada usuário, porque não existe nenhum banco de dados multi-tenant para essa função. O relay de cada usuário é um objeto separado.

Isso importa porque elimina o modo de falha de alvo único compartilhado. Mesmo que um invasor encontrasse uma maneira de comprometer o Durable Object de um usuário, ele não ganharia acesso lateral aos dados de nenhum outro usuário — não há um armazenamento de suporte compartilhado para realizar um movimento lateral. Cada usuário é, estruturalmente, seu próprio locatário (tenant).

O que está e o que não está em nosso banco de dados central

Operamos um banco de dados central (Cloudflare D1) para coisas que precisam ser centrais. A honestidade importa aqui. O banco de dados armazena:

  • Identidade da conta: seu e-mail, sua senha com hash se você usar login por e-mail/senha, o ID do provedor retornado pelo Google/Apple/Microsoft se você usar um botão de login social.
  • Estado de faturamento: seu ID de cliente Stripe, nível de assinatura, chave de licença e status da assinatura.
  • Chaves de API por usuário para provedores de inferência de IA (OpenRouter, especificamente). Estas são credenciais de provedores de inferência — distintas dos seus tokens OAuth do Workspace. Elas existem para o fluxo de créditos gerenciados e para usuários que desejam trazer sua própria chave OpenRouter para usar nos recursos de IA do caiioo.
  • Lista de ativação de dispositivos para aplicação de licença.
  • Logs de auditoria, mantidos para requisitos de evidência SOC 2.
  • Uma tabela de roteamento para webhooks de entrada opcionais (WhatsApp, Telegram, etc.) — usada apenas se você configurou essas integrações de mensagens.

O banco de dados não armazena:

  • Seus tokens OAuth do Workspace (Gmail, Agenda, Drive, Microsoft 365). Eles estão apenas no seu dispositivo.
  • O conteúdo das suas conversas. O orquestrador de agentes roda no seu painel lateral; as conversas vivem no seu armazenamento local.
  • Seus dados do Workspace — e-mails, eventos de agenda, arquivos do Drive. Eles são lidos diretamente do Google/Microsoft para o seu dispositivo, nunca passando por nossa infraestrutura.
  • O conteúdo de qualquer mensagem que flua pelo relé WebSocket. O relé vê apenas texto cifrado.

Uma violação do nosso banco de dados central exporia a identidade da conta/faturamento, logs de auditoria e a coluna de chaves de inferência do OpenRouter. Não renderia tokens do Workspace, conteúdo de conversas ou dados do Workspace, porque eles não estão lá para serem levados.

As ressalvas honestas

Este é um modelo de ameaça diferente, não um escudo mágico. Algumas qualificações que preferimos que você ouça de nós do que descubra mais tarde.

A troca de código OAuth toca brevemente em nosso relay. O Google (e Microsoft, GitHub, Slack) exige que o client_secret do OAuth seja apresentado na etapa de troca de token, e esse segredo não pode ser enviado no código do cliente. Portanto, nosso relay stateless anexa o client_secret e encaminha seu código de autorização para o Google em troca dos tokens reais. Os tokens retornam através do relay e são imediatamente devolvidos ao seu dispositivo para armazenamento. Eles não são persistidos em nossa infraestrutura. Esta é a mesma razão pela qual todos os aplicativos nativos integrados ao Google que você já usou possuem algum componente de servidor — é uma restrição do Google, não uma escolha de design da caiioo.

Endpoints personalizados permitem que você ignore completamente nosso cliente OAuth. A Caiioo suporta a configuração de endpoints OAuth personalizados, o que significa que um usuário disposto a provisionar seu próprio cliente OAuth no Google Cloud Console (ou o equivalente no Microsoft Entra) pode evitar os escopos OAuth da Caiioo e a etapa de troca do nosso relay por completo. Uma vez configurado, o fluxo de autenticação ocorre entre o seu dispositivo e o Google, sem a Caiioo em nenhum ponto do ciclo. Não apresentamos isso como uma configuração voltada ao consumidor porque a maioria dos usuários não precisa dela e a arquitetura padrão já mantém seus dados do Workspace fora de nossos servidores. Mas ela existe, e a implementação será familiar para qualquer pessoa que já tenha configurado um cliente OAuth no Google Cloud Console anteriormente.

O comprometimento do dispositivo ainda importa. Se o seu laptop for comprometido, seus tokens também serão. O modelo local-first move a superfície de ataque do "cofre do fornecedor" para o seu "endpoint". Essa é uma superfície menor e mais defensável, mas não é zero.

O "Sign in with Google" de nível de login é separado do acesso ao Workspace. Se você fizer login na própria Caiioo com Google ou Apple, esse fluxo é apenas de identidade e cria uma conexão básica vinculada à sua conta. Não é o mesmo caminho que o fluxo de acesso ao Workspace descrito acima e não concede à AI acesso à sua caixa de entrada ou calendário.

Ataques de supply-chain na própria Caiioo ainda são concebíveis. Um canal de atualização comprometido poderia, em princípio, enviar um código que exfiltra tokens do seu dispositivo. Mitigamos isso com assinatura de código e notarização em todas as plataformas que distribuímos, mas a mitigação é diferente do modelo de cofre do fornecedor — assim como a economia dos atacantes.

Como verificar você mesmo

A resposta honesta é que a alegação de privacidade de um fornecedor em uma página de marketing não pode ser provada a um cético. Portanto, veja aqui como confirmar o que afirmamos usando suas próprias ferramentas.

Execute um monitor de rede enquanto usa o caiioo. Little Snitch no macOS, GlassWire no Windows ou Wireshark em qualquer sistema. Use o Caiioo normalmente por uma hora. O tráfego que você verá, com o significado de cada conexão:

Destino Quando O que significa
oauth2.googleapis.com, gmail.googleapis.com, calendar.googleapis.com, www.googleapis.com Sempre que o agente lê seus dados do Workspace Seu dispositivo falando diretamente com o Google com seu token local. Não estamos neste caminho.
login.microsoftonline.com, graph.microsoft.com Se você conectou o Microsoft 365 Mesma estrutura, seu dispositivo para a Microsoft.
api.anthropic.com, openrouter.ai, api.openai.com, generativelanguage.googleapis.com, localhost:11434 (Ollama) Quando você envia um chat ou executa uma ferramenta que usa um LLM Seu dispositivo falando com qualquer provedor de AI que você configurou. Não estamos neste caminho.
relay.pebbleflow.ai (HTTPS) Brevemente, durante a configuração inicial do OAuth do Workspace e durante a renovação periódica do token A troca de código OAuth stateless. Os tokens passam, mas não são persistidos no lado do servidor.
relay.pebbleflow.ai (HTTPS) Periodicamente Validação de licença, busca de notas de atualização / conteúdo do guia do usuário, dados de inteligência do modelo, verificações de status de assinatura.
relay.pebbleflow.ai (HTTPS) Quando você carrega o site ou visualiza o status da conta conectada Tráfego padrão de API.
relay.pebbleflow.ai (WebSocket) Continuamente, se você tiver múltiplos componentes Caiioo instalados (extensão + desktop app, ou mobile + desktop) A ponte de capacidade que permite que seus dispositivos falem entre si. Criptografado de ponta a ponta. Vemos apenas o texto cifrado.
relay.pebbleflow.ai/api/messaging/... Apenas se você configurou integrações de mensagens (WhatsApp, Telegram, Slack de entrada) Roteamento de webhook para mensagens recebidas.

O que você não verá, nunca:

  • Seus dados do Workspace (e-mails, eventos de agenda, arquivos do Drive) fluindo para relay.pebbleflow.ai. Essas chamadas vão do seu dispositivo diretamente para *.googleapis.com.
  • O conteúdo da sua conversa fluindo para relay.pebbleflow.ai. O orquestrador roda no seu painel lateral; o histórico do chat fica no seu armazenamento local.
  • Suas chaves de API de provedores de AI fluindo para relay.pebbleflow.ai. Elas residem no seu dispositivo. (A exceção: se você usar o fluxo de créditos gerenciados, estará usando uma subconta do OpenRouter alocada pelo servidor, e a chamada de inferência ainda será feita a partir do seu dispositivo.)

Se você algum dia vir uma solicitação do seu dispositivo para nossa infraestrutura que não se encaixe na tabela acima, isso é uma descoberta. Informe-nos, e nós explicaremos ou corrigiremos.

O que fazer se você for um cliente Vercel ou Context AI

As orientações publicadas pela Vercel, Context AI e pela comunidade de pesquisa de segurança convergiram para uma lista de verificação consistente:

  1. Rotacione cada segredo armazenado como uma variável de ambiente Vercel não criptografada. Variáveis criptografadas/sensíveis foram relatadas como não afetadas, mas a rotação é barata.
  2. Audite as concessões OAuth de terceiros da sua equipe no Google Workspace (e Microsoft 365, se aplicável). Revogue qualquer coisa que você não reconheça e trate qualquer ferramenta à qual você concedeu escopos amplos de "Permitir Tudo" como uma credencial que você precisa substituir.
  3. Reforce o consentimento futuro. Prefira ferramentas que solicitem escopos de menor privilégio e prefira espaços de trabalho cuja arquitetura não exija que você entregue tokens de longa duração.

A terceira é a mudança estrutural, e a que este incidente continua recomendando silenciosamente.

Experimente o Caiioo

Se a lição do incidente Vercel/Context AI é que a localização dos seus tokens OAuth determina o seu raio de impacto quando o fornecedor é invadido, a resposta é escolher um espaço de trabalho que não os retenha.

O Caiioo é um espaço de trabalho poderoso e focado em privacidade, com um orquestrador de agentes e interface de chat que roda em um painel lateral. Disponível como extensão de navegador, app nativo para macOS, app nativo para iOS, app nativo para Android e app de desktop para Windows e Linux. Comece GRATIS.

Fontes: