
Huu ni utafsiri wa mashine wa hati asili ya Kiingereza. Ikitokea mgongano wowote kati ya tafsiri hii na toleo asili la Kiingereza, toleo la Kiingereza ndilo litakalozingatiwa. Soma toleo asili la Kiingereza
Si katikati: kwa nini ukiukaji wa mtindo wa Context AI dhidi ya Caiioo hautazalisha chochote muhimu
2026-04-22 · Caiioo Team
Mnamo Aprili 19, 2026, Vercel ilifichua kuwa zana ya AI ya upande wa tatu ya mfanyakazi mmoja ilikuwa imeingiliwa, na kwamba tokeni ya OAuth iliyoingiliwa ilikuwa imetumika kuingia katika mazingira ya ndani ya Vercel. Kikundi kidogo cha wateja kilikuwa na vigezo vya mazingira visivyo nyeti vilivyofichuliwa. Vigezo vya mazingira vilivyosimbwa/nyeti havi kuathiriwa.
Zana hiyo ilikuwa Context AI. Mfanyakazi alikuwa ameipa ufikiaji mpana wa "Allow All" kwa Google Workspace yao ya kampuni. Ruzuku hiyo moja ya OAuth, iliyoshikiliwa katika seva za Context AI, ilikuwa hatua ya kujiinua kwa kila kitu kilichofuata.
Mhusika wa tishio kwenye BreachForums ameweka kando orodha ya kile anachodai ni rekodi 580 za wafanyakazi wa Vercel zinazouzwa kwa $2M. Vercel haijathibitisha orodha hiyo.
Tukio hilo halijaisha. Lakini somo la usanifu tayari liko wazi, na ni muhimu kwa yeyote anayetathmini nafasi ya kazi ya AI.
Sura ya shambulio
Mtindo wa SaaS-AI humweka muuzaji katikati ya kila ruzuku ya OAuth unayoitoa.
Unapoweka zana ya tija ya AI ya upande wa tatu na kubofya skrini ya idhini ya OAuth, tokeni ya ufikiaji na tokeni ya kuonyesha upya iliyotolewa na Google (au Microsoft, au mtoa huduma yeyote wa utambulisho) hazibaki kwenye kifaa chako. Zinawasilishwa kwa seva za muuzaji, kwa sababu AI inayozihitaji inafanya kazi katika wingu la muuzaji. Miundombinu ya muuzaji inashikilia seti ya tokeni zinazohuishwa kila mara kwa kila mmoja wa watumiaji wao, zikiwa na ruhusa za "Allow All" ambazo watumiaji wengi walibofya bila kusoma.
Hifadhi hiyo kuu ya tokeni ndiyo hasa washambuliaji hulenga. Kuingilia muuzaji mara moja hukupa ufikiaji wa Workspace kwa maelfu ya wateja. Taarifa ya Vercel yenyewe inaonya kuwa athari za mkondo wa chini zinaweza kugusa "mamia ya watumiaji katika mashirika mengi."
Ripoti zinafuatilia mnyororo wa asili hadi kwa mfanyakazi wa Context AI ambaye kifaa chake cha kibinafsi kiliingiliwa mnamo Februari 2026, inasemekana kupitia upakuaji wa mchezo wa Roblox uliobeba programu hasidi ya Lumma Stealer. Programu hiyo hasidi ilichukua sifa za Google Workspace na AWS za mfanyakazi huyo, ambazo nazo zilifungua chumba cha tokeni za OAuth. Kifaa kimoja cha kibinafsi kilichoambukizwa, chumba kimoja cha SaaS cha kampuni, mamia ya Workspaces za mkondo wa chini.
Sababu tatu za kusanifu kwanini uvunjaji wa usalama wa mtindo wa Context AI dhidi ya Caiioo hautatoa chochote chenye manufaa
Caiioo ni eneo la kazi lenye nguvu na linalozingatia faragha kwanza likiwa na kioratibu cha kiwakala (agentic orchestrator) na kiolesura cha soga kinachoendeshwa kwenye paneli ya pembeni. "Faragha kwanza" inaelezea msimamo mahususi wa kisanifu, si mstari wa masoko. Kuna sifa tatu madhubuti zinazofanya kazi.
1. Tokeni zako za OAuth za Workspace zimehifadhiwa zikiwa zimesimbwa kwenye kifaa chako, si kwenye seva zetu
Unapounganisha akaunti ya Google au Microsoft katika Caiioo, utaona skrini ya kawaida ya idhini ya OAuth ya Google ikiwa na upeo (scopes) unaotoa. Hadi hapa hii inaonekana sawa na kutoa idhini kwa Context AI.
Tofauti ya kimuundo ni kile kinachotokea kwa tokeni zinazotokana na mchakato huo wa idhini. Tokeni ya ufikiaji (access token) na tokeni ya kuhuisha (refresh token) ambazo Google hutoa zimehifadhiwa zikiwa zimesimbwa kwenye kifaa chako — katika Keychain kwenye macOS na iOS, katika Keystore ya Android kwenye Android, katika hifadhi salama ya kivinjari kwenye kiongezi (extension). Hazihifadhiwi katika hifadhidata kuu ya Caiioo. Hatuna chumba cha kuhifadhia tokeni (token vault) kinachozishikilia kwa niaba yako.
Wakati kioratibu cha kiwakala kinapohitaji kusoma kalenda yako au kutafuta kikasha chako cha barua pepe, wito wa API hutoka kwenye kifaa chako moja kwa moja kwenda Google, ukiwa na tokeni kutoka kwenye hifadhi salama ya kifaa chako ikiwa imeambatishwa. Miundombinu yetu haipo kwenye njia ya data kwa maudhui yoyote ya Workspace yako.
Unaweza kuthibitisha hili mwenyewe kwenye chanzo: src/shared/auth/connections-manager.ts ndipo miunganisho ya OAuth ya Google/Microsoft inapohifadhiwa. Rekodi za OAuthConnection, ikijumuisha sehemu za accessToken na refreshToken, huandikwa kupitia adapta ya hifadhi ya ndani — hazitumwi kwenye hifadhi kuu ya tokeni.
2. Basi la ujumbe la relay limesimbwa mwisho-hadi-mwisho (end-to-end encrypted)
Wakati vipengele vya Caiioo kwenye vifaa tofauti vinapohitaji kuratibu — kiongezi chako cha kivinjari kikizungumza na programu yako ya desktop, simu yako ikizungumza na seva yako ya nyumbani, UI ya paneli ya pembeni ikiita zana inayofanya kazi asilia kwenye macOS — hufanya hivyo kupitia relay tunayohifadhi kwenye relay.pebbleflow.ai. Relay ndio kituo cha kukutania kinachoruhusu vifaa vyako kupatana kwenye mitandao tofauti.
Relay hiyo imesimbwa mwisho-hadi-mwisho. Vifaa vya kila mtumiaji hufanya ubadilishanaji wa funguo kupitia bahasha ya relay, na tangu hapo, ujumbe kati ya vifaa vyako ni maandishi yaliyosimbwa (ciphertext) kwa mtazamo wa relay. Relay inaweza kuzielekeza lakini haiwezi kuzisoma.
Hii siyo nadharia tu. Durable Object inayoshughulikia miunganisho ya WebSocket, cloud/relay/src/user-relay.ts, imerekodiwa kama: "Inasimamia miunganisho ya WebSocket kwa mtumiaji mmoja. Inashughulikia ujumbe uliosimbwa wa E2E (opaque kwa relay) na ubadilishanaji wa funguo." Njia za kodi zinazoshughulikia aina ya ujumbe wa ENCRYPTED zimewekewa maelezo waziwazi: "Ujumbe uliosimbwa kwa mteja mahususi (hatuwezi kuusoma)." Relay haina uwezo wa kisanifu kukagua maudhui ya ujumbe inaofikisha.
3. Relay ni ya mpangaji mmoja kwa kila mtumiaji, kwa ujenzi wake
Relay ya Caiioo imejengwa juu ya Cloudflare Durable Objects. Kila mtumiaji anapata instansi yake ya UserRelay — kipande tofauti cha ukokotoaji na hifadhi kilichotengwa wakati wa utendaji (runtime-isolated). Hakuna hifadhidata ya pamoja ya wapangaji wengi inayoshikilia hali ya kikao cha moja kwa moja cha kila mtumiaji, kwa sababu hakuna hifadhidata ya wapangaji wengi kabisa kwa jukumu hilo. Relay ya kila mtumiaji ni kitu (object) tofauti.
Hii ni muhimu kwa sababu inaondoa hali ya kufeli kwa lengo-moja-la-pamoja (single-shared-target). Hata kama mshambuliaji angepata njia ya kuingilia Durable Object ya mtumiaji mmoja, hangeweza kupata ufikiaji wa pembeni kwa data ya mtumiaji mwingine yeyote — hakuna hifadhi ya pamoja ya kugeukia. Kila mtumiaji, kimuundo, ni mpangaji wake mwenyewe.
Kile kilicho na kisichopo kwenye hifadhidata yetu kuu
Tunatumia hifadhidata kuu (Cloudflare D1) kwa mambo yanayohitaji kuwa makuu. Uaminifu ni muhimu hapa. Hifadhidata huhifadhi:
- Utambulisho wa akaunti: barua pepe yako, nywila yako iliyosimbwa ikiwa unatumia kuingia kwa barua pepe/nywila, kitambulisho cha mtoa huduma kilichorejeshwa na Google/Apple/Microsoft ikiwa unatumia kitufe cha kuingia kwa mitandao ya kijamii.
- Hali ya malipo: kitambulisho chako cha mteja wa Stripe, daraja la usajili, ufunguo wa leseni, na hali ya usajili.
- Funguo za API za kila mtumiaji kwa watoa huduma wa AI (OpenRouter, haswa). Hizi ni sifa za mtoa huduma wa AI — tofauti na tokeni zako za OAuth za Workspace. Zipo kwa ajili ya mtiririko wa mikopo inayodhibitiwa na kwa watumiaji wanaotaka kuleta ufunguo wao wa OpenRouter ili kuutumia kwenye vipengele vya AI vya caiioo.
- Orodha ya uanzishaji wa kifaa kwa ajili ya utekelezaji wa leseni.
- Kumbukumbu za ukaguzi, zinazowekwa kwa mahitaji ya ushahidi wa SOC 2.
- Jedwali la uelekezaji kwa webhooks zinazoingia za hiari (WhatsApp, Telegram, n.k.) — hutumiwa tu ikiwa umesanidi miunganisho hiyo ya ujumbe.
Hifadhidata haishiki:
- Tokeni zako za OAuth za Workspace (Gmail, Kalenda, Drive, Microsoft 365). Hizo zipo kwenye kifaa chako pekee.
- Maudhui ya mazungumzo yako. Kiratibu cha kikala kinafanya kazi kwenye paneli yako ya kando; mazungumzo yanaishi kwenye hifadhi yako ya ndani.
- Data yako ya Workspace — barua pepe, matukio ya kalenda, faili za Drive. Hizo hufikiwa moja kwa moja kutoka Google/Microsoft hadi kwenye kifaa chako, bila kupita kwenye miundombinu yetu.
- Maudhui ya ujumbe wowote unaopita kwenye relay ya WebSocket. Relay huona maandishi yaliyosimbwa pekee.
Ukiukaji wa hifadhidata yetu kuu ungefichua utambulisho wa akaunti/malipo, kumbukumbu za ukaguzi, na safu ya ufunguo wa AI wa OpenRouter. Hautatoa tokeni za Workspace, maudhui ya mazungumzo, au data ya Workspace, kwa sababu hizo hazimo humo ili kuchukuliwa.
Tahadhari za kweli
Huu ni mfumo tofauti wa tishio, si ngao ya kichawi. Hapa kuna mambo machache ambayo tungependa uyasikie kutoka kwetu badala ya kuyagundua baadaye.
Mchakato wa OAuth code-exchange unagusana kwa muda mfupi na relay yetu. Google (na Microsoft, GitHub, Slack) zinahitaji client_secret ya OAuth iwasilishwe wakati wa hatua ya token-exchange, na siri hiyo haiwezi kusafirishwa ndani ya kodi ya mteja (client code). Hivyo, relay yetu isiyo na hifadhi (stateless relay) huunganisha client_secret na kusambaza authorization code yako kwenda Google ili kubadilishana na token halisi. Token hizo hurudi kupitia relay na kurejeshwa mara moja kwenye kifaa chako kwa ajili ya kuhifadhiwa. Hazihifadhiwi kwenye miundombinu yetu. Hii ndiyo sababu ile ile inayofanya kila app asilia iliyounganishwa na Google uliyowahi kutumia kuwa na sehemu fulani ya server — ni sharti la Google, si chaguo la muundo wa caiioo.
Endpoint maalum zinakuruhusu kuruka OAuth client yetu kabisa. Caiioo inaruhusu kusanidi OAuth endpoints maalum, kumaanisha mtumiaji aliye tayari kuandaa OAuth client yake mwenyewe kwenye Google Cloud Console (au mbadala wake wa Microsoft Entra) anaweza kuepuka OAuth scopes za Caiioo na hatua ya exchange ya relay yetu kabisa. Mara baada ya kusanidiwa, mtiririko wa auth unakuwa kati ya kifaa chako na Google huku Caiioo ikiwa haipo kabisa kwenye mzunguko huo. Hatuiweki hii kama mpangilio wa kawaida kwa watumiaji kwa sababu watumiaji wengi hawaihitaji na muundo wa asili tayari unaweka data zako za Workspace nje ya server zetu. Lakini ipo, na utekelezaji wake utakuwa wa kawaida kwa yeyote aliyewahi kusanidi OAuth client kwenye Google Cloud Console hapo awali.
Uvamizi wa kifaa bado ni muhimu. Ikiwa laptop yako itavamiwa, token zako pia zimevamiwa. Mfumo wa Local-first unahamisha eneo la hatari (attack surface) kutoka kwenye "vault ya muuzaji" hadi kwenye "endpoint yako." Hilo ni eneo dogo zaidi na linaloweza kulindwa kwa urahisi, lakini si sifuri.
Ngazi ya kuingia ya "Sign in with Google" ni tofauti na ufikiaji wa Workspace. Ikiwa utaingia kwenye Caiioo yenyewe kwa kutumia Google au Apple, mtiririko huo ni wa utambulisho pekee na unatengeneza muunganisho wa Basic uliolenga akaunti yako. Sio njia sawa na mtiririko wa ufikiaji wa Workspace ulioelezwa hapo juu na haupi AI ufikiaji wa inbox au kalenda yako.
Mashambulizi ya supply-chain dhidi ya Caiioo yenyewe bado yanawezekana. Njia ya sasisho (update channel) iliyovamiwa inaweza, kimsingi, kusafirisha kodi inayoweza kuiba token kutoka kwenye kifaa chako. Tunapunguza hatari hii kwa kutumia code signing na notarization kwenye kila platform tunayotoa, lakini upunguzaji huu ni tofauti na ule wa mfumo wa vendor-vault — na vivyo hivyo kwa uchumi wa washambuliaji.
Jinsi ya kuhakiki mwenyewe
Jibu la kweli ni kwamba madai ya faragha ya muuzaji kutoka kwenye ukurasa wa masoko hayawezi kuthibitishwa kwa mtu mwenye shaka. Hivyo basi, hivi ndivyo unavyoweza kuthibitisha kile tulichodai kwa kutumia zana zako mwenyewe.
Washa kichunguzi cha mtandao (network monitor) unapotumia caiioo. Little Snitch kwenye macOS, GlassWire kwenye Windows, au Wireshark kwenye mfumo wowote. Tumia Caiioo kama kawaida kwa saa moja. Trafiki utakayoiona, pamoja na maana ya kila muunganisho:
| Marudio | Lini | Inamaanisha nini |
|---|---|---|
oauth2.googleapis.com, gmail.googleapis.com, calendar.googleapis.com, www.googleapis.com |
Wakati wowote agent anaposoma data yako ya Workspace | Kifaa chako kinawasiliana moja kwa moja na Google kwa kutumia token yako iliyo kwenye kifaa. Hatupo kwenye njia hii. |
login.microsoftonline.com, graph.microsoft.com |
Ikiwa umeunganisha Microsoft 365 | Muundo ule ule, kifaa chako kwenda kwa Microsoft. |
api.anthropic.com, openrouter.ai, api.openai.com, generativelanguage.googleapis.com, localhost:11434 (Ollama) |
Unapotuma soga au kuendesha chombo kinachotumia LLM | Kifaa chako kinawasiliana na mtoa huduma yeyote wa AI uliyemusanidi. Hatupo kwenye njia hii. |
relay.pebbleflow.ai (HTTPS) |
Kwa muda mfupi, wakati wa usanidi wa awali wa Workspace OAuth na wakati wa kuhuisha token mara kwa mara | Mabadilishano ya stateless OAuth code. Token hupita, hazihifadhiwi upande wa server. |
relay.pebbleflow.ai (HTTPS) |
Mara kwa mara | Uhakiki wa leseni, upatikanaji wa maudhui ya release-notes / user-guide, data ya model-intelligence, ukaguzi wa hali ya usajili. |
relay.pebbleflow.ai (HTTPS) |
Unapopakia tovuti au kuangalia hali ya akaunti iliyounganishwa | Trafiki ya kawaida ya API. |
relay.pebbleflow.ai (WebSocket) |
Muda wote, ikiwa una vipengele vingi vya Caiioo vilivyosakinishwa (extension + desktop app, au mobile + desktop) | Daraja la uwezo linaloruhusu vifaa vyako kuzungumza vyenyewe. Imesimbwa kwa njia ya end-to-end encrypted. Sisi tunaona ciphertext pekee. |
relay.pebbleflow.ai/api/messaging/... |
Ikiwa tu umesanidi muunganisho wa ujumbe (WhatsApp, Telegram, Slack inbound) | Njia ya Webhook kwa ajili ya ujumbe unaoingia. |
Kile ambacho hutaona, kamwe:
- Data yako ya Workspace (barua pepe, matukio ya kalenda, faili za Drive) ikitiririka kwenda
relay.pebbleflow.ai. Simu hizo huenda kutoka kwenye kifaa chako moja kwa moja kwenda*.googleapis.com. - Maudhui ya mazungumzo yako yakitiririka kwenda
relay.pebbleflow.ai. Orchestrator huendeshwa kwenye side panel yako; historia ya soga iko kwenye hifadhi yako ya ndani (local storage). - API keys za mtoa huduma wako wa AI zikitiririka kwenda
relay.pebbleflow.ai. Zinaishi kwenye kifaa chako. (Ubaguzi: ikiwa unatumia mfumo wa managed-credits, unatumia sub-account ya OpenRouter iliyotengwa na server, na ombi la inference bado linafanywa kutoka kwenye kifaa chako.)
Ikiwa utawahi kuona ombi kutoka kwenye kifaa chako kwenda kwenye miundombinu yetu ambalo haliendani na jedwali hapo juu, huo ni ugunduzi. Tuambie, nasi tutalielezea au kulirekebisha.
Nini cha kufanya ikiwa wewe ni mteja wa Vercel au Context AI
Mwongozo uliochapishwa kutoka Vercel, Context AI, na jumuiya ya utafiti wa usalama umeungana kwenye orodha thabiti:
- Badilisha kila siri iliyohifadhiwa kama kigezo cha mazingira cha Vercel kisichosimbwa. Vigezo vilivyosimbwa/nyeti viliripotiwa kutoathiriwa, lakini mabadiliko ni rahisi.
- Kagua ruzuku za OAuth za upande wa tatu za timu yako kwenye Google Workspace (na Microsoft 365, ikiwa inatumika). Batilisha chochote usichokitambua, na uchukulie zana yoyote uliyopa ufikiaji mpana wa "Allow All" kama sifa unayohitaji kubadilisha.
- Kaza idhini ya baadaye. Pendelea zana zinazoomba ufikiaji wa kiwango cha chini kabisa, na pendelea nafasi za kazi ambazo usanifu wake hauhitaji ukabidhi tokeni za muda mrefu kabisa.
Ya tatu ndiyo hatua ya kimuundo, na ndiyo ambayo tukio hili linaendelea kupendekeza kimyakimya.
Jaribu Caiioo
Ikiwa somo la tukio la Vercel/Context AI ni kwamba eneo la tokeni zako za OAuth huamua kiwango cha athari wakati muuzaji anapovamiwa, jibu ni kuchagua nafasi ya kazi ambayo haizishiki.
Caiioo ni nafasi ya kazi yenye nguvu, inayozingatia faragha kwanza ikiwa na kiratibu cha kikala na kiolesura cha gumzo kinachofanya kazi kwenye paneli ya kando. Inapatikana kama kiongezi cha kivinjari, programu asilia ya macOS, programu asilia ya iOS, programu asilia ya Android, na programu ya kompyuta ya Windows na Linux. Anza bila malipo.
Vyanzo:
- Vercel Knowledge Base: Taarifa ya tukio la usalama ya Aprili 2026
- Context AI: Sasisho la usalama
- TechCrunch: Mwenyeji wa programu Vercel asema alivamiwa na data ya wateja kuibwa
- The Hacker News: Ukiukaji wa Vercel Unahusishwa na Uvamizi wa Context AI
- BleepingComputer: Vercel yathibitisha ukiukaji huku wadukuzi wakidai kuuza data iliyoibwa
- Trend Micro: Ukiukaji wa Vercel — Shambulio la Mnyororo wa Ugavi wa OAuth Lafichua Tishio Lililofichwa