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

Ito ay isang machine translation ng orihinal na dokumentong Ingles. Sa kaganapan ng anumang salungatan sa pagitan ng pagsasaling ito at ng orihinal na bersyong Ingles, ang bersyong Ingles ang mangingibabaw. Basahin ang orihinal na bersyong Ingles

Hindi sa gitna: kung bakit ang isang Context AI–style na breach laban sa Caiioo ay walang makukuhang kapaki-pakinabang

2026-04-22 · Caiioo Team

Noong Abril 19, 2026, isiniwalat ng Vercel na ang third-party AI tool ng isang empleyado ay nakompromiso, at ang nakompromisong OAuth token ay ginamit upang makapasok sa mga internal environment ng Vercel. Isang limitadong subset ng mga customer ang nagkaroon ng mga non-sensitive environment variables na nalantad. Ang mga encrypted/sensitive environment variables ay hindi naapektuhan.

Ang tool ay Context AI. Binigyan ito ng empleyado ng malawak na "Allow All" na access sa kanilang corporate Google Workspace. Ang nag-iisang OAuth grant na iyon, na hawak sa mga server ng Context AI, ang naging leverage point para sa lahat ng sumunod.

Isang threat actor sa BreachForums ang hiwalay na naglista ng inaangkin nilang 580 record ng empleyado ng Vercel na ibinebenta sa halagang $2M. Hindi pa na-verify ng Vercel ang listahang iyon.

Hindi pa tapos ang insidente. Ngunit ang aral sa arkitektura ay malinaw na, at ito ay isang kapaki-pakinabang para sa sinumang sumusuri ng isang AI workspace.

Ang anyo ng pag-atake

Ang SaaS-AI model ay naglalagay ng vendor sa gitna ng bawat OAuth grant na ibinibigay mo rito.

Kapag nag-install ka ng isang third-party AI productivity tool at nag-click sa OAuth consent screen, ang access token at refresh token na ibinigay ng Google (o Microsoft, o anumang identity provider) ay hindi nananatili sa iyong device. Ang mga ito ay ipinapadala sa mga server ng vendor, dahil ang AI na nangangailangan sa mga ito ay tumatakbo sa cloud ng vendor. Ang imprastraktura ng vendor ay humahawak ng patuloy na nire-refresh na set ng mga token para sa bawat isa sa kanilang mga user, na naka-scope sa "Allow All" na mga pahintulot na karamihan ng mga user ay nag-click nang hindi nagbabasa.

Ang sentralisadong token store na iyon ang mismong tina-target ng mga attacker. Ang pagkompromiso sa vendor nang isang beses ay nagbibigay sa iyo ng Workspace access para sa libu-libong customer. Ang sariling bulletin ng Vercel ay nagbabala na ang mga downstream effect ay maaaring tumama sa "daan-daang user sa maraming organisasyon."

Ang mga ulat ay nagtuturo sa orihinal na chain pabalik sa isang empleyado ng Context AI na ang personal na device ay nakompromiso noong Pebrero 2026, ayon sa ulat ay sa pamamagitan ng isang na-download na Roblox game exploit na may dalang Lumma Stealer infostealer malware. Ang malware na iyon ay nag-exfiltrate ng Google Workspace at AWS credentials ng empleyado, na siya namang nagbukas sa OAuth token vault. Isang nahawaang personal na device, isang corporate SaaS vault, daan-daang downstream Workspaces.

Tatlong arkitektural na dahilan kung bakit ang isang Context AI–style na breach laban sa Caiioo ay walang mapapala

Ang Caiioo ay isang makapangyarihan at privacy-first na workspace na may agentic orchestrator at chat interface na tumatakbo sa isang side panel. Ang "Privacy-first" ay naglalarawan ng isang partikular na arkitektural na posisyon, hindi lamang isang linya sa marketing. Mayroong tatlong konkretong katangian na gumagana rito.

1. Ang iyong Workspace OAuth tokens ay nakaimbak nang encrypted sa iyong device, hindi sa aming mga server

Kapag ikinonekta mo ang isang Google o Microsoft account sa Caiioo, makikita mo ang standard na OAuth consent screen ng Google kasama ang mga scope na iyong ibinibigay. Sa puntong ito, mukhang katulad lang ito ng pag-authorize sa Context AI.

Ang pagkakaiba sa istruktura ay kung ano ang nangyayari sa mga token na lumalabas sa consent flow na iyon. Ang access token at refresh token na ibinibigay ng Google ay nakaimbak nang encrypted sa iyong device — sa Keychain sa macOS at iOS, sa Keystore ng Android sa Android, at sa secure storage ng browser sa extension. Ang mga ito ay hindi nakaimbak sa sentral na database ng caiioo. Wala kaming token vault na humahawak sa mga ito para sa iyo.

Kapag kailangan ng agentic orchestrator na basahin ang iyong calendar o i-search ang iyong inbox, ang API call ay direktang nanggagaling sa iyong device patungo sa Google, kalakip ang token mula sa secure storage ng iyong device. Ang aming infrastructure ay wala sa data path para sa alinman sa iyong nilalaman sa Workspace.

Maaari mo itong i-verify mismo sa source: sa src/shared/auth/connections-manager.ts iniimbak ang mga Google/Microsoft OAuth connection. Ang mga OAuthConnection record, kabilang ang mga field na accessToken at refreshToken, ay isinusulat sa pamamagitan ng local storage adapter — hindi ipinapadala sa isang sentral na token store.

2. Ang message bus ng relay ay end-to-end encrypted

Kapag ang mga component ng Caiioo sa iba't ibang device ay kailangang mag-coordinate — ang iyong browser extension na nakikipag-usap sa iyong desktop app, ang iyong telepono na nakikipag-usap sa iyong home server, ang side-panel UI na tumatawag sa isang tool na tumatakbo nang native sa macOS — ginagawa nila ito sa pamamagitan ng isang relay na aming hino-host sa relay.pebbleflow.ai. Ang relay ang nagsisilbing rendezvous point na nagpapahintulot sa iyong mga device na mahanap ang isa't isa sa iba't ibang network.

Ang relay na iyon ay end-to-end encrypted. Ang mga device ng bawat user ay nagsasagawa ng key exchange sa pamamagitan ng relay envelope, at mula noon, ang mga mensahe sa pagitan ng iyong mga device ay ciphertext na sa pananaw ng relay. Maaaring i-route ng relay ang mga ito ngunit hindi nito mababasa ang mga ito.

Hindi ito isang mithiin lamang. Ang Durable Object na humahawak sa mga WebSocket connection, cloud/relay/src/user-relay.ts, ay dokumentado bilang: "Manages WebSocket connections for a single user. Handles E2E encrypted messages (opaque to relay) and key exchange." Ang mga code path na humahawak sa ENCRYPTED na uri ng mensahe ay tahasang may komento na: "Encrypted message to specific client (we can't read it)." Ang relay ay walang kakayahan sa arkitektura nito na siyasatin ang mga nilalaman ng mga mensaheng ipinapasa nito.

3. Ang relay ay single-tenant bawat user, ayon sa pagkaka-disenyo

Ang relay ng Caiioo ay binuo sa Cloudflare Durable Objects. Ang bawat user ay nakakakuha ng sarili nilang UserRelay instance — isang hiwalay at runtime-isolated na bahagi ng compute at storage. Walang shared multi-tenant database na humahawak sa live session state ng bawat user, dahil wala talagang multi-tenant database para sa tungkuling iyon. Ang relay ng bawat user ay isang hiwalay na object.

Mahalaga ito dahil inaalis nito ang single-shared-target failure mode. Kahit na makahanap ang isang attacker ng paraan upang makompromiso ang Durable Object ng isang user, hindi sila makakakuha ng lateral access sa data ng sinumang ibang user — walang shared backing store na magagamit upang makalipat sa iba. Ang bawat user, sa istruktura, ay sarili nilang tenant.

Ano ang nasa loob at wala sa aming sentral na database

Nagpapatakbo kami ng isang sentral na database (Cloudflare D1) para sa mga bagay na kailangang maging sentral. Mahalaga ang katapatan dito. Ang database ay nag-iimbak ng:

  • Pagkakakilanlan ng Account: iyong email, iyong hashed password kung gumagamit ka ng email/password login, ang provider ID na ibinalik ng Google/Apple/Microsoft kung gumagamit ka ng social-login button.
  • Katayuan ng Billing: iyong Stripe customer ID, subscription tier, license key, at status ng subscription.
  • Per-user API keys para sa AI inference providers (OpenRouter, partikular). Ang mga ito ay credentials ng inference-provider — iba sa iyong mga Workspace OAuth token. Umiiral ang mga ito para sa managed-credits flow at para sa mga gumagamit na gustong dalhin ang sarili nilang OpenRouter key para gamitin sa mga AI feature ng Caiioo.
  • Listahan ng device activation para sa pagpapatupad ng lisensya.
  • Audit logs, na itinatago para sa mga kinakailangan sa ebidensya ng SOC 2.
  • Isang routing table para sa mga opt-in inbound webhooks (WhatsApp, Telegram, atbp.) — ginagamit lamang kung na-configure mo ang mga integration sa pagmemensahe na iyon.

Ang database ay hindi nag-iimbak ng:

  • Iyong mga Workspace OAuth token (Gmail, Calendar, Drive, Microsoft 365). Ang mga iyon ay nasa iyong device lamang.
  • Ang nilalaman ng iyong pag-uusap. Ang agentic orchestrator ay tumatakbo sa iyong side panel; ang mga pag-uusap ay nasa iyong lokal na storage.
  • Iyong data sa Workspace — mga email, calendar event, Drive files. Ang mga iyon ay direktang binabasa mula sa Google/Microsoft papunta sa iyong device, at hindi dumadaan sa aming imprastraktura.
  • Ang mga nilalaman ng anumang mensahe na dumadaloy sa WebSocket relay. Ciphertext lamang ang nakikita ng relay.

Ang isang breach sa aming sentral na database ay maglalantad ng account/billing identity, audit logs, at ang OpenRouter inference-key column. Hindi ito magbibigay ng mga Workspace token, nilalaman ng pag-uusap, o data sa Workspace, dahil wala ang mga iyon doon para makuha.

Ang mga tapat na babala

Ito ay isang kakaibang threat model, hindi isang mahiwagang kalasag. Narito ang ilang mga paglilinaw na mas gusto naming marinig mo mula sa amin kaysa matuklasan mo na lang sa huli.

Ang OAuth code-exchange ay panandaliang dumadaan sa aming relay. Kinakailangan ng Google (at Microsoft, GitHub, Slack) na ipakita ang OAuth client_secret sa hakbang ng token-exchange, at ang secret na iyon ay hindi maaaring isama sa client code. Kaya ikinakabit ng aming stateless relay ang client_secret at ipinapasa ang iyong authorization code sa Google kapalit ng mga aktwal na token. Ang mga token ay babalik sa pamamagitan ng relay at agad na ibabalik sa iyong device para i-store. Hindi sila pinananatili sa aming infrastructure. Ito rin ang dahilan kung bakit ang bawat native Google-integrated app na nagamit mo na ay mayroong server component — ito ay isang Google constraint, hindi isang desisyon sa disenyo ng caiioo.

Pinapayagan ka ng mga custom endpoint na lampasan nang buo ang aming OAuth client. Sinusuportahan ng Caiioo ang pag-configure ng mga custom OAuth endpoint, na nangangahulugang ang isang user na handang mag-provision ng sarili nilang OAuth client sa Google Cloud Console (o ang katumbas sa Microsoft Entra) ay maaaring iwasan ang mga OAuth scope ng Caiioo at ang exchange step ng aming relay nang buo. Kapag na-configure na, ang auth flow ay sa pagitan na lamang ng iyong device at Google nang wala ang Caiioo sa loop. Hindi namin ito inilalabas bilang isang consumer-facing setting dahil hindi ito kailangan ng karamihan sa mga user at ang default na architecture ay pinapanatili na ang iyong Workspace data sa labas ng aming mga server. Ngunit umiiral ito, at ang implementation ay magiging pamilyar sa sinumang nakapag-set up na ng OAuth client sa Google Cloud Console noon.

Mahalaga pa rin ang device compromise. Kung ang iyong laptop ay nakompromiso, ang iyong mga token ay nakompromiso rin. Inililipat ng local-first ang attack surface mula sa "vendor's vault" patungo sa iyong "endpoint." Iyon ay isang mas maliit at mas madaling ipagtanggol na surface, ngunit hindi ito zero.

Ang login-tier na "Sign in with Google" ay hiwalay sa Workspace-access. Kung magsa-sign in ka sa Caiioo mismo gamit ang Google o Apple, ang flow na iyon ay para sa identity-only at gumagawa ng isang Basic connection na naka-scope sa iyong account. Hindi ito ang parehong landas gaya ng Workspace-access flow na inilarawan sa itaas at hindi nagbibigay sa AI ng access sa iyong inbox o calendar.

Ang mga supply-chain attack sa Caiioo mismo ay posible pa rin. Ang isang nakompromisong update channel ay maaaring magpadala ng code na mag-e-exfiltrate ng mga token mula sa iyong device. Pinapagaan namin ito sa pamamagitan ng code signing at notarization sa bawat platform na aming sineserbisyuhan, ngunit ang mitigation na ito ay naiiba sa vendor-vault model — at gayundin ang ekonomiya ng mga attacker.

Paano ito i-verify nang mag-isa

Ang tapat na sagot ay ang mga pahayag tungkol sa privacy ng isang vendor mula sa isang marketing page ay hindi mapapatunayan sa isang nagdududa. Kaya narito kung paano makukumpirma ang aming mga sinasabi gamit ang sarili mong mga tool.

Magpatakbo ng isang network monitor habang gumagamit ng caiioo. Little Snitch sa macOS, GlassWire sa Windows, o Wireshark sa kahit ano. Gamitin ang Caiioo nang normal sa loob ng isang oras. Ang trapiko na iyong makikita, kasama ang kahulugan ng bawat koneksyon:

Destinasyon Kailan Ano ang ibig sabihin nito
oauth2.googleapis.com, gmail.googleapis.com, calendar.googleapis.com, www.googleapis.com Sa tuwing binabasa ng agent ang iyong Workspace data Ang iyong device ay direktang nakikipag-usap sa Google gamit ang iyong on-device token. Wala kami sa path na ito.
login.microsoftonline.com, graph.microsoft.com Kung ikinonekta mo ang Microsoft 365 Parehong anyo, ang iyong device patungo sa Microsoft.
api.anthropic.com, openrouter.ai, api.openai.com, generativelanguage.googleapis.com, localhost:11434 (Ollama) Kapag nagpadala ka ng chat o nagpatakbo ng tool na gumagamit ng LLM Ang iyong device ay nakikipag-usap sa kung sinumang AI provider ang iyong na-configure. Wala kami sa path na ito.
relay.pebbleflow.ai (HTTPS) Sandali, sa panahon ng initial Workspace OAuth setup at sa pana-panahong token refresh Ang stateless OAuth code-exchange. Ang mga token ay dumadaan lamang, hindi pinapanatili (not persisted) sa server-side.
relay.pebbleflow.ai (HTTPS) Pana-panahon License validation, pagkuha ng release-notes / user-guide content, model-intelligence data, subscription status checks.
relay.pebbleflow.ai (HTTPS) Kapag ni-load mo ang website o tiningnan ang connected-account status Standard API traffic.
relay.pebbleflow.ai (WebSocket) Patuloy, kung mayroon kang maraming Caiioo components na naka-install (extension + desktop app, o mobile + desktop) Ang capability bridge na nagpapahintulot sa iyong mga device na mag-usap sa isa’t isa. End-to-end encrypted. Ciphertext lamang ang nakikita namin.
relay.pebbleflow.ai/api/messaging/... Kung nag-configure ka lamang ng mga messaging integration (WhatsApp, Telegram, Slack inbound) Webhook routing para sa mga papasok na mensahe.

Ang hindi mo makikita, kailanman:

  • Ang iyong Workspace data (mga email, calendar events, Drive files) na dumadaloy sa relay.pebbleflow.ai. Ang mga call na iyon ay mula sa iyong device nang direkta sa *.googleapis.com.
  • Ang nilalaman ng iyong pag-uusap (conversation content) na dumadaloy sa relay.pebbleflow.ai. Ang orchestrator ay tumatakbo sa iyong side panel; ang chat history ay nasa iyong local storage.
  • Ang iyong AI provider API keys na dumadaloy sa relay.pebbleflow.ai. Ang mga ito ay nananatili sa iyong device. (Ang exception: kung gumagamit ka ng managed-credits flow, gumagamit ka ng server-allocated OpenRouter sub-account, at ang inference call ay ginagawa pa rin mula sa iyong device.)

Kung makakita ka man ng request mula sa iyong device patungo sa aming infrastructure na hindi tumutugma sa talahanayan sa itaas, isa itong finding. Sabihin sa amin, at ipapaliwanag namin ito o aayusin.

Ano ang gagawin kung ikaw ay isang customer ng Vercel o Context AI

Ang inilathalang gabay mula sa Vercel, Context AI, at sa security research community ay nagkasundo sa isang pare-parehong checklist:

  1. I-rotate ang bawat secret na nakaimbak bilang isang non-encrypted Vercel environment variable. Ang mga encrypted/sensitive variables ay iniulat na hindi naapektuhan, ngunit ang rotation ay mura lang.
  2. I-audit ang mga third-party OAuth grants ng iyong team sa Google Workspace (at Microsoft 365, kung naaangkop). I-revoke ang anumang hindi mo kinikilala, at ituring ang anumang tool na binigyan mo ng malawak na "Allow All" scopes bilang isang credential na kailangan mong palitan.
  3. Higpitan ang pahintulot sa hinaharap. Mas piliin ang mga tool na humihiling ng least-privilege scopes, at mas piliin ang mga workspace na ang arkitektura ay hindi nangangailangan sa iyo na magbigay ng long-lived tokens sa lahat.

Ang pangatlo ay ang structural move, at ang isa na tahimik na inirerekomenda ng insidenteng ito.

Subukan ang Caiioo

Kung ang aral ng insidente sa Vercel/Context AI ay ang lokasyon ng iyong mga OAuth token ang nagtatakda ng lawak ng pinsala kapag ang vendor ay na-breach, ang sagot ay pumili ng isang workspace na hindi humahawak sa mga ito.

Ang Caiioo ay isang malakas at privacy-first na workspace na may agentic orchestrator at chat interface na tumatakbo sa isang side panel. Available bilang extension sa browser, native na macOS app, native na iOS app, native na Android app, at desktop app para sa Windows at Linux. Magsimula nang FREE.

Mga Sanggunian: