Dit is een machinevertaling van het originele Engelstalige document. In het geval van een conflict tussen deze vertaling en de originele Engelse versie, is de Engelse versie doorslaggevend. Lees de originele Engelse versie

---

Niet in het midden: waarom een inbreuk in de stijl van Context AI op Caiioo niets bruikbaars zou opleveren

2026-04-22 · Caiioo Team

Op 19 april 2026 maakte Vercel bekend dat de AI-tool van een derde partij van een enkele medewerker was gecompromitteerd, en dat het gecompromitteerde OAuth-token was gebruikt om binnen te dringen in de interne omgevingen van Vercel. Bij een beperkte subset van klanten werden niet-gevoelige omgevingsvariabelen blootgesteld. Versleutelde/gevoelige omgevingsvariabelen bleven onaangetast.

De tool was Context AI. De medewerker had deze brede "Alles toestaan"-toegang verleend tot hun zakelijke Google Workspace. Die enkele OAuth-toestemming, bewaard op de servers van Context AI, was het hefboompunt voor alles wat volgde.

Een kwaadwillende op BreachForums heeft afzonderlijk een lijst geplaatst van wat naar eigen zeggen 580 Vercel-medewerkersgegevens zijn, te koop voor $2 miljoen. Vercel heeft die vermelding niet geverifieerd.

Het incident is nog niet voorbij. Maar de architecturale les is al duidelijk, en het is een nuttige les voor iedereen die een AI-werkplek evalueert.

De vorm van de aanval

Het SaaS-AI-model plaatst een leverancier in het midden van elke OAuth-toestemming die u geeft.

Wanneer u een AI-productiviteitstool van een derde partij installeert en door het OAuth-toestemmingsscherm klikt, blijven het toegangstoken en het vernieuwingstoken die zijn uitgegeven door Google (of Microsoft, of een andere identiteitsprovider) niet op uw apparaat staan. Ze worden afgeleverd bij de servers van de leverancier, omdat de AI die ze nodig heeft in de cloud van de leverancier draait. De infrastructuur van de leverancier bevat een continu vernieuwde set tokens voor elk van hun gebruikers, afgestemd op de "Alles toestaan"-machtigingen waar de meeste gebruikers doorheen klikten zonder te lezen.

Die gecentraliseerde tokenopslag is precies waar aanvallers zich op richten. Door de leverancier één keer te compromitteren, krijgt men Workspace-toegang voor duizenden klanten. Vercels eigen bulletin waarschuwt dat de gevolgen stroomafwaarts "honderden gebruikers in vele organisaties" kunnen raken.

Verslaggeving herleidt de oorspronkelijke keten naar een medewerker van Context AI wiens persoonlijke apparaat in februari 2026 werd gecompromitteerd, naar verluidt via een gedownloade Roblox-game-exploit die Lumma Stealer-infostealer-malware bevatte. Die malware exfiltreerde de Google Workspace- en AWS-inloggegevens van de medewerker, die op hun beurt de OAuth-tokenkluis ontgrendelden. Eén geïnfecteerd persoonlijk apparaat, één zakelijke SaaS-kluis, honderden stroomafwaartse Workspaces.

Drie architecturale redenen waarom een inbreuk in de stijl van Context AI op Caiioo niets bruikbaars zou opleveren

Caiioo is een krachtige, privacy-eerst werkruimte met een agentic orchestrator en chatinterface die in een zijpaneel draait. "Privacy-eerst" beschrijft een specifieke architecturale houding, geen marketingtekst. Er zijn drie concrete eigenschappen aan het werk.

1. Uw Workspace OAuth tokens worden versleuteld op uw apparaat opgeslagen, niet op onze servers

Wanneer u een Google- of Microsoft-account koppelt in Caiioo, ziet u het standaard OAuth-toestemmingsscherm van Google met de scopes die u verleent. Tot zover ziet dit er identiek uit aan het autoriseren van Context AI.

Het structurele verschil is wat er gebeurt met de tokens die uit die toestemmingsflow voortkomen. Het access token en refresh token die Google uitgeeft, worden versleuteld opgeslagen op uw apparaat — in Keychain op macOS en iOS, in Android's Keystore op Android, in de beveiligde opslag van de browser in de extensie. Ze worden niet opgeslagen in de centrale database van Caiioo. We hebben geen token-kluis die ze namens u beheert.

Wanneer de agentic orchestrator uw agenda moet lezen of uw inbox moet doorzoeken, gaat de API-aanroep rechtstreeks van uw apparaat naar Google, met het token uit de beveiligde opslag van uw apparaat bijgevoegd. Onze infrastructuur bevindt zich niet in het datapand voor uw Workspace-inhoud.

U kunt dit zelf verifiëren in de broncode: src/shared/auth/connections-manager.ts is de plek waar Google/Microsoft OAuth-verbindingen worden opgeslagen. De OAuthConnection-records, inclusief de velden accessToken en refreshToken, worden weggeschreven via de lokale opslagadapter — niet verzonden naar een centrale token-opslag.

2. De message bus van de relay is end-to-end versleuteld

Wanneer Caiioo-componenten op verschillende apparaten moeten coördineren — uw browser-extensie die communiceert met uw desktop-app, uw telefoon die praat met uw thuisserver, de zijpaneel-UI die een tool aanroept die lokaal op macOS draait — doen ze dat via een relay die we hosten op relay.pebbleflow.ai. De relay is het ontmoetingspunt dat uw apparaten in staat stelt elkaar over netwerken heen te vinden.

Die relay is end-to-end versleuteld. De apparaten van elke gebruiker voeren een sleuteluitwisseling uit via de relay-envelop, en vanaf dat moment zijn berichten tussen uw apparaten cijfertekst vanuit het perspectief van de relay. De relay kan ze routeren, maar niet lezen.

Dit is niet slechts een streven. Het Durable Object dat WebSocket-verbindingen afhandelt, cloud/relay/src/user-relay.ts, is gedocumenteerd als: "Beheert WebSocket-verbindingen voor een enkele gebruiker. Handelt E2E versleutelde berichten af (ondoorzichtig voor relay) en sleuteluitwisseling." De codepaden die het ENCRYPTED berichttype afhandelen, zijn expliciet voorzien van commentaar: "Versleuteld bericht naar specifieke client (we kunnen het niet lezen)." De relay is architecturaal niet in staat om de inhoud van de berichten die hij doorstuurt te inspecteren.

3. De relay is single-tenant per gebruiker, door constructie

De relay van Caiioo is gebouwd op Cloudflare Durable Objects. Elke gebruiker krijgt zijn eigen UserRelay-instantie — een afzonderlijk, op runtime geïsoleerd stuk rekenkracht en opslag. Er is geen gedeelde multi-tenant database die de live sessiestatus van elke gebruiker bevat, omdat er voor die rol helemaal geen multi-tenant database bestaat. De relay van elke gebruiker is een afzonderlijk object.

Dit is belangrijk omdat het de single-shared-target foutmodus elimineert. Zelfs als een aanvaller een manier zou vinden om het Durable Object van één gebruiker te compromitteren, zouden ze geen zijwaartse toegang krijgen tot de gegevens van een andere gebruiker — er is geen gedeelde opslag om naar over te stappen. Elke gebruiker is, structureel gezien, zijn eigen tenant.

Wat wel en niet in onze centrale database staat

We beheren een centrale database (Cloudflare D1) voor zaken die centraal moeten zijn. Eerlijkheid is hier belangrijk. De database slaat het volgende op:

• Accountidentiteit: uw e-mailadres, uw gehashte wachtwoord als u e-mail/wachtwoord-login gebruikt, de provider-ID geretourneerd door Google/Apple/Microsoft als u een social-login knop gebruikt.
• Facturatiestatus: uw Stripe-klant-ID, abonnementstype, licentiesleutel en abonnementsstatus.
• API-sleutels per gebruiker voor AI-inferentieproviders (specifiek OpenRouter). Dit zijn inloggegevens voor inferentieproviders — los van uw Workspace OAuth-tokens. Deze bestaan voor de beheerde-tegoed-flow en voor gebruikers die hun eigen OpenRouter-sleutel willen meenemen voor gebruik in de AI-functies van caiioo.
• Apparaat-activatielijst voor licentiehandhaving.
• Audit-logs, bewaard voor SOC 2-bewijsvereisten.
• Een routeringstabel voor opt-in inkomende webhooks (WhatsApp, Telegram, etc.) — alleen gebruikt als u die berichtintegraties hebt geconfigureerd.

De database slaat het volgende niet op:

• Uw Workspace OAuth-tokens (Gmail, Agenda, Drive, Microsoft 365). Deze staan alleen op uw apparaat.
• De inhoud van uw gesprekken. De agent-orchestrator draait in uw zijpaneel; gesprekken leven in uw lokale opslag.
• Uw Workspace-gegevens — e-mails, agenda-afspraken, Drive-bestanden. Deze worden rechtstreeks van Google/Microsoft naar uw apparaat gelezen en passeren nooit onze infrastructuur.
• De inhoud van berichten die door de WebSocket-relay stromen. De relay ziet alleen cijfertekst.

Een inbreuk op onze centrale database zou account-/facturatiegegevens, audit-logs en de kolom met OpenRouter-inferentiesleutels blootstellen. Het zou geen Workspace-tokens, gespreksonderwerpen of Workspace-gegevens opleveren, omdat die er simpelweg niet in staan.

De eerlijke kanttekeningen

Dit is een ander dreigingsmodel, geen magisch schild. Een paar nuanceringen die we liever zelf vertellen dan dat u ze later ontdekt.

De OAuth code-exchange raakt kortstondig onze relay. Google (en Microsoft, GitHub, Slack) vereisen dat de OAuth client_secret wordt gepresenteerd tijdens de token-exchange stap, en dat geheim kan niet worden meegeleverd in client-code. Daarom voegt onze stateless relay de client_secret toe en stuurt uw autorisatiecode door naar Google in ruil voor de daadwerkelijke tokens. De tokens komen terug via de relay en worden onmiddellijk naar uw apparaat gestuurd voor opslag. Ze worden niet opgeslagen in onze infrastructuur. Dit is dezelfde reden waarom elke native app met Google-integratie die u ooit heeft gebruikt een servercomponent heeft — het is een beperking van Google, geen ontwerpkeuze van caiioo.

Custom endpoints stellen u in staat onze OAuth-client volledig te omzeilen. Caiioo ondersteunt het configureren van custom OAuth-endpoints, wat betekent dat een gebruiker die bereid is zijn eigen OAuth-client in Google Cloud Console (of het Microsoft Entra-equivalent) in te richten, de OAuth-scopes van Caiioo en de exchange-stap van onze relay volledig kan vermijden. Eenmaal geconfigureerd vindt de auth-flow plaats tussen uw apparaat en Google, zonder dat Caiioo ergens in de loop voorkomt. We bieden dit niet aan als een standaardinstelling voor consumenten omdat de meeste gebruikers het niet nodig hebben en de standaardarchitectuur uw Workspace-gegevens al van onze servers houdt. Maar de optie bestaat, en de implementatie zal bekend voorkomen voor iedereen die eerder een OAuth-client heeft ingesteld in Google Cloud Console.

Apparaatcompromittering blijft van belang. Als uw laptop gehackt is, zijn uw tokens dat ook. Local-first verplaatst het aanvalsoppervlak van de "kluis van de leverancier" naar "uw endpoint". Dat is een kleiner en beter verdedigbaar oppervlak, maar het is niet nul.

"Sign in with Google" op inlogniveu staat los van Workspace-toegang. Als u bij Caiioo zelf inlogt met Google of Apple, is die flow uitsluitend voor identiteitscontrole en creëert deze een Basic-verbinding die beperkt is tot uw account. Dit is niet hetzelfde pad als de hierboven beschreven Workspace-toegang-flow en geeft de AI geen toegang tot uw inbox of agenda.

Supply-chain aanvallen op Caiioo zelf blijven denkbaar. Een gecompromitteerd updatekanaal zou in principe code kunnen verzenden die tokens van uw apparaat exfiltreert. We beperken dit risico met code signing en notarization op elk platform waarop we leveren, maar de beveiliging is anders dan bij het vendor-vault model — en dat geldt ook voor de economische motieven van aanvallers.

Hoe u dit zelf kunt verifiëren

Het eerlijke antwoord is dat de privacyclaims van een leverancier op een marketingpagina niet bewezen kunnen worden aan een scepticus. Daarom leest u hier hoe u onze claims kunt bevestigen met uw eigen tools.

Gebruik een netwerkmonitor terwijl u Caiioo gebruikt. Little Snitch op macOS, GlassWire op Windows, of Wireshark op elk ander systeem. Gebruik Caiioo een uur lang op de normale manier. Het verkeer dat u zult zien, met de betekenis van elke verbinding:

Bestemming	Wanneer	Wat het betekent
oauth2.googleapis.com, gmail.googleapis.com, calendar.googleapis.com, www.googleapis.com	Telkens wanneer de agent uw Workspace-gegevens leest	Uw apparaat communiceert rechtstreeks met Google via uw on-device token. Wij bevinden ons niet in dit pad.
login.microsoftonline.com, graph.microsoft.com	Als u Microsoft 365 heeft gekoppeld	Dezelfde structuur: uw apparaat naar Microsoft.
api.anthropic.com, openrouter.ai, api.openai.com, generativelanguage.googleapis.com, localhost:11434 (Ollama)	Wanneer u een chat verzendt of een tool uitvoert die een LLM gebruikt	Uw apparaat communiceert met de AI-provider die u heeft geconfigureerd. Wij bevinden ons niet in dit pad.
relay.pebbleflow.ai (HTTPS)	Kortstondig, tijdens de initiële Workspace OAuth-configuratie en tijdens periodieke token-verversing	De stateless OAuth code-exchange. Tokens passeren hier, maar worden niet aan de serverzijde opgeslagen.
relay.pebbleflow.ai (HTTPS)	Periodiek	Licentievalidatie, ophalen van release-notes / handleidingen, model-intelligence data, controles van abonnementstatus.
relay.pebbleflow.ai (HTTPS)	Wanneer u de website laadt of de status van gekoppelde accounts bekijkt	Standaard API-verkeer.
relay.pebbleflow.ai (WebSocket)	Continu, als u meerdere caiioo-componenten heeft geïnstalleerd (extensie + desktop app, of mobiel + desktop)	De capability bridge die uw apparaten met elkaar laat communiceren. End-to-end encrypted. Wij zien alleen cijfertekst.
relay.pebbleflow.ai/api/messaging/...	Alleen als u messaging-integraties heeft geconfigureerd (WhatsApp, Telegram, Slack inbound)	Webhook-routing voor inkomende berichten.

Wat u nooit zult zien:

• Uw Workspace-gegevens (e-mails, agenda-afspraken, Drive-bestanden) die naar relay.pebbleflow.ai stromen. Die aanroepen gaan van uw apparaat rechtstreeks naar *.googleapis.com.
• Uw conversatie-inhoud die naar relay.pebbleflow.ai stroomt. De orchestrator draait in uw zijpaneel; de chatgeschiedenis bevindt zich in uw lokale opslag.
• Uw AI-provider API-keys die naar relay.pebbleflow.ai stromen. Deze staan op uw apparaat. (Uitzondering: als u de managed-credits flow gebruikt, gebruikt u een door de server toegewezen OpenRouter-subaccount, en de inference-aanroep wordt nog steeds vanaf uw apparaat gedaan.)

Als u ooit een verzoek van uw apparaat naar onze infrastructuur ziet dat niet in de bovenstaande tabel past, dan is dat een bevinding. Meld het ons, en we zullen het uitleggen of oplossen.

Wat u moet doen als u een klant bent van Vercel of Context AI

De gepubliceerde richtlijnen van Vercel, Context AI en de beveiligingsonderzoeksgemeenschap zijn samengekomen in een consistente checklist:

1. Roteer elk geheim dat is opgeslagen als een niet-versleutelde Vercel-omgevingsvariabele. Versleutelde/gevoelige variabelen zijn naar verluidt niet aangetast, maar rotatie is goedkoop.
2. Controleer de OAuth-toestemmingen van derden van uw team op Google Workspace (en Microsoft 365, indien van toepassing). Trek alles in wat u niet herkent, en behandel elke tool waaraan u brede "Alles toestaan"-machtigingen hebt verleend als een inloggegeven dat u moet vervangen.
3. Verstrak toekomstige toestemming. Geef de voorkeur aan tools die machtigingen met de minste privileges aanvragen, en geef de voorkeur aan werkplekken waarvan de architectuur niet vereist dat u tokens met een lange levensduur overhandigt.

De derde is de structurele stap, en degene die dit incident stilletjes blijft aanbevelen.

Probeer Caiioo

Als de les van het incident met Vercel/Context AI is dat de locatie van uw OAuth-tokens uw impactradius bepaalt wanneer de leverancier wordt gehackt, dan is het antwoord om een werkruimte te kiezen die ze niet beheert.

Caiioo is een krachtige, privacy-eerst werkruimte met een agent-orchestrator en chatinterface die in een zijpaneel draait. Beschikbaar als browserextensie, native macOS-app, native iOS-app, native Android-app en desktop-app voor Windows en Linux. Aan de slag voor GRATIS.