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

Detta är en maskinöversättning av det engelska originaldokumentet. Vid eventuella avvikelser mellan denna översättning och den engelska originalversionen ska den engelska versionen ha företräde. Läs den engelska originalversionen

Inte i mitten: varför ett dataintrång i stil med Context AI mot Caiioo inte skulle ge något användbart

2026-04-22 · Caiioo Team

Den 19 april 2026 avslöjade Vercel att en enskild anställds AI-verktyg från tredje part hade komprometterats, och att den komprometterade OAuth-tokenen hade använts för att ta sig in i Vercels interna miljöer. En begränsad delmängd av kunder fick icke-känsliga miljövariabler exponerade. Krypterade/känsliga miljövariabler påverkades inte.

Verktyget var Context AI. Den anställde hade gett det bred "Tillåt alla"-åtkomst till sitt företags Google Workspace. Det enda OAuth-medgivandet, som lagrades på Context AIs servrar, var hävstångspunkten för allt som följde.

En hotaktör på BreachForums har separat listat vad de påstår är 580 poster om Vercel-anställda till försäljning för 2 miljoner dollar. Vercel har inte verifierat den listningen.

Incidenten är inte över. Men den arkitektoniska läxan är redan tydlig, och den är användbar för alla som utvärderar en AI-arbetsyta.

Attackens utformning

SaaS-AI-modellen placerar en leverantör i mitten av varje OAuth-medgivande du ger den.

När du installerar ett AI-produktivitetsverktyg från tredje part och klickar dig igenom OAuth-samtyckesskärmen, stannar inte den åtkomsttoken och refresh-token som utfärdats av Google (eller Microsoft, eller någon identitetsleverantör) på din enhet. De levereras till leverantörens servrar, eftersom den AI som behöver dem körs i leverantörens moln. Leverantörens infrastruktur har en kontinuerligt uppdaterad uppsättning tokens för var och en av deras användare, omfattade av de "Tillåt alla"-behörigheter som de flesta användare klickade igenom utan att läsa.

Det centraliserade token-lagret är precis vad angripare siktar på. Att kompromettera leverantören en gång ger dig Workspace-åtkomst för tusentals kunder. Vercels egen bulletin varnar för att följdeffekterna kan beröra "hundratals användare i många organisationer".

Rapportering spårar den ursprungliga kedjan tillbaka till en Context AI-anställd vars personliga enhet komprometterades i februari 2026, enligt uppgift via en nedladdad Roblox-spel-exploit som bar på skadlig kod av typen Lumma Stealer. Denna skadliga kod exfiltrerade den anställdes Google Workspace- och AWS-inloggningsuppgifter, vilket i sin tur låste upp OAuth-tokenvalvet. En infekterad personlig enhet, ett företags SaaS-valv, hundratals drabbade Workspaces i nästa led.

Tre arkitektoniska skäl till varför ett intrång i Context AI-stil mot Caiioo inte skulle ge något användbart

Caiioo är en kraftfull, integritetsfokuserad arbetsyta med en agentbaserad orkestrerare och ett chattgränssnitt som körs i en sidopanel. "Integritet först" beskriver en specifik arkitektonisk hållning, inte en marknadsföringsfras. Det finns tre konkreta egenskaper som verkar här.

1. Dina Workspace OAuth-tokens lagras krypterade på din enhet, inte på våra servrar

När du ansluter ett Google- eller Microsoft-konto i Caiioo ser du Googles standardiserade OAuth-samtyckesskärm med de behörigheter du beviljar. Hittills ser detta identiskt ut med att auktorisera Context AI.

Den strukturella skillnaden är vad som händer med de tokens som kommer ut ur det samtyckesflödet. Den access token och refresh token som Google utfärdar lagras krypterade på din enhet — i Keychain på macOS och iOS, i Androids Keystore på Android, och i webbläsarens säkra lagring i tillägget. De lagras inte i caiioos centrala databas. Vi har inget token-valv som förvarar dem åt dig.

När den agentbaserade orkestreraren behöver läsa din kalender eller söka i din inkorg, går API-anropet från din enhet direkt till Google, med din tokens från din enhets säkra lagring bifogad. Vår infrastruktur befinner sig inte i datavägen för något av ditt Workspace-innehåll.

Du kan verifiera detta själv i källkoden: src/shared/auth/connections-manager.ts är där Google/Microsoft OAuth-anslutningar sparas. OAuthConnection-poster, inklusive fälten accessToken och refreshToken, skrivs via den lokala lagringsadaptern — de överförs inte till ett centralt token-lager.

2. Relay-tjänstens meddelandebuss är änd-till-änd-krypterad

När caiioo-komponenter på olika enheter behöver koordinera — ditt webbläsartillägg som talar med din skrivbordsapp, din telefon som talar med din hemserver, eller sidopanelens UI som anropar ett verktyg som körs nativt på macOS — gör de det via en relay som vi är värdar för på relay.pebbleflow.ai. Denna relay är mötesplatsen som låter dina enheter hitta varandra över olika nätverk.

Denna relay är änd-till-änd-krypterad. Varje användares enheter utför ett nyckelutbyte via relay-höljet, och därefter är meddelanden mellan dina enheter chiffertext ur relay-tjänstens perspektiv. Relay-tjänsten kan dirigera dem men inte läsa dem.

Detta är inte en vision, det är verklighet. Det Durable Object som hanterar WebSocket-anslutningar, cloud/relay/src/user-relay.ts, är dokumenterat som: "Manages WebSocket connections for a single user. Handles E2E encrypted messages (opaque to relay) and key exchange." Kodvägarna som hanterar meddelandetypen ENCRYPTED är explicit kommenterade: "Encrypted message to specific client (we can't read it)." Relay-tjänsten är arkitektoniskt oförmögen att inspektera innehållet i de meddelanden den vidarebefordrar.

3. Relay-tjänsten är single-tenant per användare, genom konstruktion

caiioos relay är byggd på Cloudflare Durable Objects. Varje användare får sin egen UserRelay-instans — en separat, körtidsisolerad del av beräkning och lagring. Det finns ingen delad multi-tenant-databas som håller varje användares live-sessionsstatus, eftersom det inte finns någon multi-tenant-databas alls för den rollen. Varje användares relay är ett separat objekt.

Detta är viktigt eftersom det eliminerar felscenariot med ett enda delat mål. Även om en angripare skulle hitta ett sätt att kompromettera en användares Durable Object, skulle de inte få lateral åtkomst till någon annan användares data — det finns inget delat datalager att röra sig vidare genom. Varje användare är, strukturellt sett, sin egen hyresgäst (tenant).

Vad som finns och inte finns i vår centrala databas

Vi driver en central databas (Cloudflare D1) för saker som behöver vara centrala. Ärlighet är viktigt här. Databasen lagrar:

  • Kontoidentitet: din e-post, ditt hashade lösenord om du använder e-post/lösenordsinloggning, det leverantörs-ID som returneras av Google/Apple/Microsoft om du använder en knapp för social inloggning.
  • Faktureringsstatus: ditt Stripe-kund-ID, prenumerationsnivå, licensnyckel och prenumerationsstatus.
  • API-nycklar per användare för AI-inferensleverantörer (specifikt OpenRouter). Dessa är inloggningsuppgifter för inferensleverantörer — skilda från dina Workspace OAuth-tokens. De finns för flödet med hanterade krediter och för användare som vill ta med sin egen OpenRouter-nyckel för att använda i caiioos AI-funktioner.
  • Lista över enhetsaktiveringar för licenshantering.
  • Granskningsloggar, som sparas för SOC 2-beviskrav.
  • En routingtabell för valfria inkommande webhooks (WhatsApp, Telegram, etc.) — används endast om du har konfigurerat dessa meddelandeintegrationer.

Databasen lagrar inte:

  • Dina Workspace OAuth-tokens (Gmail, Kalender, Drive, Microsoft 365). Dessa finns endast på din enhet.
  • Ditt konversationsinnehåll. Den agentiska koordinatorn körs i din sidopanel; konversationer lever i din lokala lagring.
  • Din Workspace-data — e-postmeddelanden, kalenderhändelser, Drive-filer. Dessa läses direkt från Google/Microsoft till din enhet och passerar aldrig genom vår infrastruktur.
  • Innehållet i meddelanden som strömmar genom WebSocket-reläet. Reläet ser endast krypterad text.

Ett intrång i vår centrala databas skulle exponera konto-/faktureringsidentitet, granskningsloggar och kolumnen för OpenRouter-inferensnycklar. Det skulle inte ge några Workspace-tokens, konversationsinnehåll eller Workspace-data, eftersom dessa inte finns där att ta.

De ärliga förbehållen

Detta är en annorlunda hotmodell, inte en magisk sköld. Här är några förtydliganden som vi hellre vill att du hör från oss än upptäcker senare.

OAuth-kodutbytet passerar kortvarigt vårt relay. Google (och Microsoft, GitHub, Slack) kräver att OAuth client_secret presenteras vid steget för token-utbyte, och den hemligheten kan inte skickas med i klientkoden. Därför bifogar vårt tillståndslösa relay client_secret och vidarebefordrar din auktoriseringskod till Google i utbyte mot de faktiska tokens. Dessa tokens kommer tillbaka via vårt relay och returneras omedelbart till din enhet för lagring. De sparas inte i vår infrastruktur. Detta är samma anledning till att varje infödd Google-integrerad app du någonsin använt har någon form av serverkomponent — det är en begränsning från Google, inte ett designval av caiioo.

Anpassade slutpunkter låter dig kringgå vår OAuth-klient helt och hållet. Caiioo stöder konfiguration av anpassade OAuth-slutpunkter, vilket innebär att en användare som är villig att tillhandahålla sin egen OAuth-klient i Google Cloud Console (eller motsvarande i Microsoft Entra) helt kan undvika Caiioo:s OAuth-omfång och vårt relays utbytessteg. När detta väl är konfigurerat sker autentiseringsflödet mellan din enhet och Google utan att Caiioo finns med i loopen. Vi exponerar inte detta som en inställning för vanliga konsumenter eftersom de flesta användare inte behöver den och standardarkitekturen redan håller din Workspace-data borta från våra servrar. Men möjligheten finns, och implementeringen kommer att kännas bekant för alla som har konfigurerat en OAuth-klient i Google Cloud Console tidigare.

Kompromittering av enheten spelar fortfarande roll. Om din bärbara dator blir hackad, blir även dina tokens hackade. Local-first flyttar attackytan från "leverantörens valv" till "din slutpunkt". Det är en mindre och mer försvarbar yta, men den är inte noll.

Inloggningsnivån "Logga in med Google" är separat från Workspace-åtkomst. Om du loggar in i själva Caiioo med Google eller Apple, är det flödet endast för identitet och skapar en Basic-anslutning kopplad till ditt konto. Det är inte samma väg som flödet för Workspace-åtkomst som beskrivs ovan och ger inte AI:n åtkomst till din inkorg eller kalender.

Supply-chain-attacker mot själva Caiioo är fortfarande tänkbara. En kompromitterad uppdateringskanal skulle i princip kunna skicka kod som exfiltrerar tokens från din enhet. Vi motverkar detta med kodsignering och notarization på varje plattform vi levererar till, men motåtgärden skiljer sig från modellen med leverantörsvalv — och det gör även angriparnas ekonomi.

Hur du verifierar det själv

Det ärliga svaret är att en leverantörs integritetspåståenden på en marknadsföringssida inte kan bevisas för en skeptiker. Så här kan du bekräfta det vi har hävdat med hjälp av dina egna verktyg.

Kör en nätverksövervakare medan du använder caiioo. Little Snitch på macOS, GlassWire på Windows eller Wireshark på valfritt system. Använd Caiioo som vanligt under en timme. Trafiken du kommer att se, och vad varje anslutning innebär:

Destination När Vad det innebär
oauth2.googleapis.com, gmail.googleapis.com, calendar.googleapis.com, www.googleapis.com När agenten läser din Workspace-data Din enhet kommunicerar direkt med Google med din lokala token. Vi finns inte med i denna kedja.
login.microsoftonline.com, graph.microsoft.com Om du har anslutit Microsoft 365 Samma struktur, din enhet till Microsoft.
api.anthropic.com, openrouter.ai, api.openai.com, generativelanguage.googleapis.com, localhost:11434 (Ollama) När du skickar en chatt eller kör ett verktyg som använder en LLM Din enhet kommunicerar med den AI-leverantör du har konfigurerat. Vi finns inte med i denna kedja.
relay.pebbleflow.ai (HTTPS) Kortvarigt, under initial Workspace OAuth-konfiguration och vid periodisk token-uppdatering Det tillståndslösa OAuth-kodutbytet. Tokens passerar igenom, men sparas inte på serversidan.
relay.pebbleflow.ai (HTTPS) Periodiskt Licensvalidering, hämtning av versionsanteckningar / användarguider, model-intelligence-data, kontroll av prenumerationsstatus.
relay.pebbleflow.ai (HTTPS) När du laddar webbplatsen eller visar status för anslutna konton Standard API-trafik.
relay.pebbleflow.ai (WebSocket) Kontinuerligt, om du har flera caiioo-komponenter installerade (tillägg + skrivbordsapp, eller mobil + skrivbord) Kapabilitetsbryggan som låter dina enheter prata med varandra. End-to-end-krypterad. Vi ser endast chiffertext.
relay.pebbleflow.ai/api/messaging/... Endast om du har konfigurerat meddelandeintegrationer (WhatsApp, Telegram, Slack inkommande) Webhook-dirigering för inkommande meddelanden.

Vad du aldrig kommer att se:

  • Din Workspace-data (e-post, kalenderhändelser, Drive-filer) som flödar till relay.pebbleflow.ai. Dessa anrop går från din enhet direkt till *.googleapis.com.
  • Ditt konversationsinnehåll som flödar till relay.pebbleflow.ai. Orkrastreraren körs i din sidopanel; chatthistoriken finns i din lokala lagring.
  • Dina API-nycklar för AI-leverantörer som flödar till relay.pebbleflow.ai. De stannar på din enhet. (Undantaget: om du använder flödet för hanterade krediter använder du ett serverallokerat OpenRouter-underkonto, och inferensanropet görs fortfarande från din enhet.)

Om du någonsin ser en förfrågan från din enhet till vår infrastruktur som inte passar in i tabellen ovan, är det en upptäckt. Berätta det för oss, så förklarar vi det eller åtgärdar det.

Vad du ska göra om du är kund hos Vercel eller Context AI

Den publicerade vägledningen från Vercel, Context AI och säkerhetsforskare har enats om en konsekvent checklista:

  1. Rotera varje hemlighet som lagras som en okrypterad Vercel-miljövariabel. Krypterade/känsliga variabler rapporterades vara opåverkade, men rotation är billigt.
  2. Granska ditt teams OAuth-medgivanden från tredje part i Google Workspace (och Microsoft 365, om tillämpligt). Återkalla allt du inte känner igen, och behandla alla verktyg som du gett breda "Tillåt alla"-omfång som en inloggningsuppgift du behöver byta ut.
  3. Strama åt framtida samtycke. Föredra verktyg som begär minsta möjliga behörighet, och föredra arbetsytor vars arkitektur inte kräver att du lämnar över långlivade tokens överhuvudtaget.

Det tredje är det strukturella draget, och det som denna incident tyst fortsätter att rekommendera.

Prova Caiioo

Om lärdomen från Vercel/Context AI-incidenten är att platsen för dina OAuth-tokens avgör din skadeyta när leverantören drabbas av ett intrång, är svaret att välja en arbetsyta som inte lagrar dem.

Caiioo är en kraftfull, integritetsfokuserad arbetsyta med en agentisk koordinator och chattgränssnitt som körs i en sidopanel. Tillgänglig som webbläsartillägg, infödd macOS-app, infödd iOS-app, infödd Android-app och skrivbordsapp för Windows och Linux. Kom igång gratis.

Källor: