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

Ceci est une traduction automatique du document original en anglais. En cas de divergence entre cette traduction et la version originale anglaise, la version anglaise fera foi. Consulter la version originale en anglais

Pas d'intermédiaire : pourquoi une faille de type Context AI contre Caiioo ne donnerait rien d'utile

2026-04-22 · Caiioo Team

Le 19 avril 2026, Vercel a révélé que l'outil d'IA tiers d'un seul employé avait été compromis, et que le jeton OAuth compromis avait été utilisé pour pivoter vers les environnements internes de Vercel. Un sous-ensemble limité de clients a vu ses variables d'environnement non sensibles exposées. Les variables d'environnement chiffrées/sensibles n'ont pas été affectées.

L'outil était Context AI. L'employé lui avait accordé un accès large « Tout autoriser » à son Google Workspace d'entreprise. Cette unique autorisation OAuth, conservée sur les serveurs de Context AI, a été le point de levier pour tout ce qui a suivi.

Un acteur malveillant sur BreachForums a séparément listé ce qu'il prétend être 580 dossiers d'employés de Vercel à vendre pour 2 millions de dollars. Vercel n'a pas vérifié cette annonce.

L'incident n'est pas terminé. Mais la leçon architecturale est déjà claire, et elle est utile pour quiconque évalue un espace de travail IA.

La forme de l'attaque

Le modèle SaaS-AI place un fournisseur au milieu de chaque autorisation OAuth que vous lui donnez.

Lorsque vous installez un outil de productivité IA tiers et que vous validez l'écran de consentement OAuth, le jeton d'accès et le jeton de renouvellement émis par Google (ou Microsoft, ou tout fournisseur d'identité) ne restent pas sur votre appareil. Ils sont transmis aux serveurs du fournisseur, car l'IA qui en a besoin s'exécute dans le cloud du fournisseur. L'infrastructure du fournisseur détient un ensemble de jetons continuellement renouvelés pour chacun de ses utilisateurs, limités aux autorisations « Tout autoriser » que la plupart des utilisateurs ont acceptées sans lire.

Ce stockage centralisé de jetons est précisément ce que les attaquants ciblent. Compromettre le fournisseur une seule fois donne accès au Workspace de milliers de clients. Le propre bulletin de Vercel avertit que les effets en aval pourraient toucher des « centaines d'utilisateurs dans de nombreuses organisations ».

Les rapports retracent la chaîne d'origine jusqu'à un employé de Context AI dont l'appareil personnel a été compromis en février 2026, apparemment via un exploit de jeu Roblox téléchargé qui contenait le malware infostealer Lumma Stealer. Ce malware a exfiltré les identifiants Google Workspace et AWS de l'employé, ce qui a ensuite déverrouillé le coffre-fort de jetons OAuth. Un appareil personnel infecté, un coffre-fort SaaS d'entreprise, des centaines de Workspaces compromis en aval.

Trois raisons architecturales pour lesquelles une faille de type Context AI contre Caiioo ne produirait rien d'utile

Caiioo est un espace de travail puissant, axé sur la confidentialité, doté d'un orchestrateur agentique et d'une interface de chat qui s'exécute dans un panneau latéral. « Privacy-first » décrit une posture architecturale spécifique, et non un argument marketing. Trois propriétés concrètes sont à l'œuvre.

1. Vos jetons OAuth Workspace sont stockés chiffrés sur votre appareil, pas sur nos serveurs

Lorsque vous connectez un compte Google ou Microsoft dans Caiioo, vous verrez l'écran de consentement OAuth standard de Google avec les périmètres (scopes) que vous accordez. Jusqu'ici, cela semble identique à l'autorisation de Context AI.

La différence structurelle réside dans ce qu'il advient des jetons issus de ce flux de consentement. Le jeton d'accès (access token) et le jeton de rafraîchissement (refresh token) émis par Google sont stockés chiffrés sur votre appareil — dans le Keychain sur macOS et iOS, dans le Keystore d'Android sur Android, dans le stockage sécurisé du navigateur pour l'extension. Ils ne sont pas stockés dans la base de données centrale de caiioo. Nous ne possédons pas de coffre-fort de jetons les conservant en votre nom.

Lorsque l'orchestrateur agentique doit lire votre calendrier ou effectuer une recherche dans votre boîte de réception, l'appel API part de votre appareil directement vers Google, avec le jeton provenant du stockage sécurisé de votre appareil. Notre infrastructure n'est pas sur le chemin des données pour le contenu de votre Workspace.

Vous pouvez le vérifier vous-même dans le code source : src/shared/auth/connections-manager.ts est l'endroit où les connexions OAuth Google/Microsoft sont persistées. Les enregistrements OAuthConnection, incluant les champs accessToken et refreshToken, sont écrits via l'adaptateur de stockage local — et non transmis à un magasin de jetons central.

2. Le bus de messages du relais est chiffré de bout en bout

Lorsque les composants Caiioo sur différents appareils doivent se coordonner — votre extension de navigateur communiquant avec votre application de bureau, votre téléphone communiquant avec votre serveur domestique, l'interface du panneau latéral invoquant un outil qui s'exécute nativement sur macOS — ils le font via un relais que nous hébergeons à l'adresse relay.pebbleflow.ai. Le relais est le point de rendez-vous qui permet à vos appareils de se trouver mutuellement à travers les réseaux.

Ce relais est chiffré de bout en bout. Les appareils de chaque utilisateur effectuent un échange de clés via l'enveloppe du relais, et dès lors, les messages entre vos appareils sont du texte chiffré du point de vue du relais. Le relais peut les router mais ne peut pas les lire.

Ce n'est pas une simple intention. Le Durable Object qui gère les connexions WebSocket, cloud/relay/src/user-relay.ts, est documenté comme suit : "Gère les connexions WebSocket pour un utilisateur unique. Gère les messages chiffrés E2E (opaques pour le relais) et l'échange de clés." Les chemins de code qui gèrent le type de message ENCRYPTED sont explicitement commentés : "Message chiffré vers un client spécifique (nous ne pouvons pas le lire)." Le relais n'est pas architecturalement capable d'inspecter le contenu des messages qu'il transmet.

3. Le relais est mono-tenant par utilisateur, par construction

Le relais de Caiioo est construit sur les Durable Objects de Cloudflare. Chaque utilisateur dispose de sa propre instance UserRelay — une unité de calcul et de stockage distincte et isolée au moment de l'exécution. Il n'y a pas de base de données multi-tenant partagée contenant l'état des sessions en direct de chaque utilisateur, car il n'y a aucune base de données multi-tenant pour ce rôle. Le relais de chaque utilisateur est un objet distinct.

Ceci est crucial car cela élimine le mode de défaillance par cible partagée unique. Même si un attaquant trouvait un moyen de compromettre le Durable Object d'un utilisateur, il n'obtiendrait pas d'accès latéral aux données d'un autre utilisateur — il n'y a pas de magasin de stockage partagé pour effectuer un pivot. Chaque utilisateur est, structurellement, son propre locataire (tenant).

Ce qui se trouve et ne se trouve pas dans notre base de données centrale

Nous exploitons une base de données centrale (Cloudflare D1) pour les éléments qui doivent être centralisés. L'honnêteté est primordiale ici. La base de données stocke :

  • L'identité du compte : votre e-mail, votre mot de passe haché si vous utilisez la connexion e-mail/mot de passe, l'ID de fournisseur renvoyé par Google/Apple/Microsoft si vous utilisez un bouton de connexion sociale.
  • L'état de facturation : votre ID client Stripe, le niveau d'abonnement, la clé de licence et le statut de l'abonnement.
  • Les clés API par utilisateur pour les fournisseurs d'inférence IA (OpenRouter, spécifiquement). Ce sont des identifiants de fournisseur d'inférence — distincts de vos jetons OAuth Workspace. Ils existent pour le flux de crédits gérés et pour les utilisateurs qui souhaitent apporter leur propre clé OpenRouter pour l'utiliser sur les fonctionnalités d'IA de Caiioo.
  • La liste d'activation des appareils pour l'application des licences.
  • Les journaux d'audit, conservés pour les exigences de preuve SOC 2.
  • Une table de routage pour les webhooks entrants optionnels (WhatsApp, Telegram, etc.) — utilisée uniquement si vous avez configuré ces intégrations de messagerie.

La base de données ne stocke pas :

  • Vos jetons OAuth Workspace (Gmail, Calendar, Drive, Microsoft 365). Ceux-ci sont uniquement sur votre appareil.
  • Le contenu de vos conversations. L'orchestrateur d'agents s'exécute dans votre panneau latéral ; les conversations vivent dans votre stockage local.
  • Vos données Workspace — e-mails, événements de calendrier, fichiers Drive. Ceux-ci sont lus directement de Google/Microsoft vers votre appareil, sans jamais passer par notre infrastructure.
  • Le contenu de tout message circulant via le relais WebSocket. Le relais ne voit que du texte chiffré.

Une faille de notre base de données centrale exposerait l'identité du compte/facturation, les journaux d'audit et la colonne des clés d'inférence OpenRouter. Elle ne livrerait pas de jetons Workspace, de contenu de conversation ou de données Workspace, car ils n'y figurent pas.

Les mises en garde honnêtes

Il s'agit d'un modèle de menace différent, pas d'un bouclier magique. Voici quelques précisions que nous préférons vous communiquer nous-mêmes plutôt que de vous laisser les découvrir plus tard.

L'échange de code OAuth transite brièvement par notre relais. Google (ainsi que Microsoft, GitHub, Slack) exige que le client_secret OAuth soit présenté lors de l'étape d'échange de jetons, et ce secret ne peut pas être intégré dans le code client. Par conséquent, notre relais sans état (stateless) joint le client_secret et transmet votre code d'autorisation à Google en échange des jetons réels. Les jetons reviennent via le relais et sont immédiatement renvoyés à votre appareil pour stockage. Ils ne sont pas conservés dans notre infrastructure. C'est la raison pour laquelle chaque application native intégrée à Google que vous avez utilisée possède un composant serveur — c'est une contrainte de Google, pas un choix de conception de caiioo.

Les points de terminaison personnalisés vous permettent de contourner entièrement notre client OAuth. Caiioo permet de configurer des points de terminaison OAuth personnalisés, ce qui signifie qu'un utilisateur acceptant de configurer son propre client OAuth dans Google Cloud Console (ou l'équivalent Microsoft Entra) peut éviter totalement les périmètres (scopes) OAuth de Caiioo et l'étape d'échange de notre relais. Une fois configuré, le flux d'authentification se déroule entre votre appareil et Google, sans que Caiioo n'intervienne à aucun moment. Nous ne présentons pas cela comme un paramètre grand public car la plupart des utilisateurs n'en ont pas besoin et l'architecture par défaut maintient déjà vos données Workspace hors de nos serveurs. Mais cette option existe, et la mise en œuvre sera familière à quiconque a déjà configuré un client OAuth dans Google Cloud Console.

La compromission de l'appareil reste un enjeu. Si votre ordinateur portable est compromis, vos jetons le sont aussi. Le modèle "local-first" déplace la surface d'attaque du « coffre-fort du fournisseur » vers « votre point de terminaison ». C'est une surface plus petite et plus facile à défendre, mais elle n'est pas nulle.

La « Connexion avec Google » au niveau de l'authentification est distincte de l'accès à Workspace. Si vous vous connectez à Caiioo lui-même avec Google ou Apple, ce flux concerne uniquement l'identité et crée une connexion de base limitée à votre compte. Ce n'est pas le même chemin que le flux d'accès à Workspace décrit ci-dessus, et cela n'accorde pas à l'AI l'accès à votre boîte de réception ou à votre calendrier.

Des attaques sur la chaîne d'approvisionnement de Caiioo lui-même sont toujours envisageables. Un canal de mise à jour compromis pourrait en principe diffuser un code qui exfiltre les jetons de votre appareil. Nous atténuons ce risque par la signature de code et la notarisation sur chaque plateforme que nous livrons, mais l'atténuation est différente du modèle de coffre-fort fournisseur — tout comme l'est l'économie des attaquants.

Comment le vérifier par vous-même

La réponse honnête est que la promesse de confidentialité d'un fournisseur sur une page marketing ne peut être prouvée à un sceptique. Voici donc comment confirmer ce que nous affirmons en utilisant vos propres outils.

Lancez un moniteur réseau tout en utilisant caiioo. Little Snitch sur macOS, GlassWire sur Windows, ou Wireshark sur n'importe quel système. Utilisez Caiioo normalement pendant une heure. Voici le trafic que vous verrez, avec la signification de chaque connexion :

Destination Quand Ce que cela signifie
oauth2.googleapis.com, gmail.googleapis.com, calendar.googleapis.com, www.googleapis.com Chaque fois que l'agent lit vos données Workspace Votre appareil communique directement avec Google avec votre token local. Nous ne sommes pas sur ce chemin.
login.microsoftonline.com, graph.microsoft.com Si vous avez connecté Microsoft 365 Même configuration, de votre appareil vers Microsoft.
api.anthropic.com, openrouter.ai, api.openai.com, generativelanguage.googleapis.com, localhost:11434 (Ollama) Lorsque vous envoyez un chat ou exécutez un outil utilisant un LLM Votre appareil communique avec le fournisseur AI que vous avez configuré. Nous ne sommes pas sur ce chemin.
relay.pebbleflow.ai (HTTPS) Brièvement, lors de la configuration initiale OAuth de Workspace et lors du rafraîchissement périodique des tokens L'échange de code OAuth sans état. Les tokens transitent mais ne sont pas conservés côté serveur.
relay.pebbleflow.ai (HTTPS) Périodiquement Validation de licence, récupération des notes de mise à jour / guides d'utilisation, données de model-intelligence, vérification du statut d'abonnement.
relay.pebbleflow.ai (HTTPS) Lorsque vous chargez le site web ou consultez le statut des comptes connectés Trafic API standard.
relay.pebbleflow.ai (WebSocket) En continu, si vous avez plusieurs composants Caiioo installés (extension + application desktop, ou mobile + desktop) Le pont de capacités qui permet à vos appareils de communiquer entre eux. Chiffré de bout en bout. Nous ne voyons que du texte chiffré.
relay.pebbleflow.ai/api/messaging/... Uniquement si vous avez configuré des intégrations de messagerie (WhatsApp, Telegram, Slack entrant) Routage Webhook pour les messages entrants.

Ce que vous ne verrez jamais :

  • Vos données Workspace (e-mails, événements de calendrier, fichiers Drive) circulant vers relay.pebbleflow.ai. Ces appels vont de votre appareil directement vers *.googleapis.com.
  • Le contenu de vos conversations circulant vers relay.pebbleflow.ai. L'orchestrateur s'exécute dans votre panneau latéral ; l'historique de chat est dans votre stockage local.
  • Vos clés API de fournisseurs AI circulant vers relay.pebbleflow.ai. Elles résident sur votre appareil. (L'exception : si vous utilisez le flux de crédits gérés, vous utilisez un sous-compte OpenRouter alloué par le serveur, et l'appel d'inférence est toujours effectué depuis votre appareil.)

Si jamais vous voyez une requête de votre appareil vers notre infrastructure qui ne correspond pas au tableau ci-dessus, c'est une anomalie. Signalez-le nous, et nous l'expliquerons ou la corrigerons.

Que faire si vous êtes client de Vercel ou de Context AI

Les conseils publiés par Vercel, Context AI et la communauté de recherche en sécurité ont convergé vers une liste de contrôle cohérente :

  1. Renouvelez chaque secret stocké en tant que variable d'environnement Vercel non chiffrée. Les variables chiffrées/sensibles n'auraient pas été affectées, mais le renouvellement est peu coûteux.
  2. Auditez les autorisations OAuth tierces de votre équipe sur Google Workspace (et Microsoft 365, le cas échéant). Révoquez tout ce que vous ne reconnaissez pas, et traitez tout outil auquel vous avez accordé des portées larges « Tout autoriser » comme un identifiant que vous devez remplacer.
  3. Renforcez le consentement futur. Privilégiez les outils qui demandent des portées de moindre privilège, et préférez les espaces de travail dont l'architecture ne vous oblige pas à remettre des jetons de longue durée.

Le troisième point est le changement structurel, et celui que cet incident ne cesse de recommander discrètement.

Essayer Caiioo

Si la leçon de l'incident Vercel/Context AI est que l'emplacement de vos jetons OAuth détermine votre rayon d'impact lorsque le fournisseur est piraté, la réponse est de choisir un espace de travail qui ne les détient pas.

Caiioo est un espace de travail puissant et respectueux de la vie privée, doté d'un orchestrateur d'agents et d'une interface de chat qui s'exécute dans un panneau latéral. Disponible en tant qu'extension de navigateur, application native macOS, application native iOS, application native Android et application de bureau pour Windows et Linux. Commencer gratuitement.

Sources :