
यह मूल अंग्रेजी दस्तावेज़ का मशीन अनुवाद है। इस अनुवाद और मूल अंग्रेजी संस्करण के बीच किसी भी विवाद की स्थिति में, अंग्रेजी संस्करण ही मान्य होगा। मूल अंग्रेजी संस्करण पढ़ें
बीच में नहीं: Caiioo के खिलाफ Context AI-शैली का उल्लंघन कुछ भी उपयोगी क्यों नहीं देगा
2026-04-22 · Caiioo Team
19 अप्रैल, 2026 को, Vercel ने खुलासा किया कि एक कर्मचारी के तीसरे पक्ष के AI टूल के साथ समझौता किया गया था, और उस OAuth टोकन का उपयोग Vercel के आंतरिक वातावरण में जाने के लिए किया गया था। ग्राहकों के एक सीमित उपसमूह के गैर-संवेदनशील वातावरण चर (environment variables) उजागर हो गए थे। एन्क्रिप्टेड/संवेदनशील वातावरण चर अप्रभावित रहे।
वह टूल Context AI था। कर्मचारी ने इसे अपने कॉर्पोरेट Google Workspace तक व्यापक "Allow All" एक्सेस दिया था। Context AI के सर्वर में रखा गया वह एकल OAuth अनुदान, उसके बाद होने वाली हर चीज़ के लिए लाभ उठाने का बिंदु था।
BreachForums पर एक हमलावर ने अलग से उन रिकॉर्ड्स को सूचीबद्ध किया है जिन्हें वे $2M में बिक्री के लिए 580 Vercel कर्मचारी रिकॉर्ड होने का दावा करते हैं। Vercel ने उस लिस्टिंग को सत्यापित नहीं किया है।
घटना अभी खत्म नहीं हुई है। लेकिन आर्किटेक्चरल सबक पहले से ही स्पष्ट है, और यह AI वर्कस्पेस का मूल्यांकन करने वाले किसी भी व्यक्ति के लिए उपयोगी है।
हमले का स्वरूप
SaaS-AI मॉडल आपके द्वारा दिए गए प्रत्येक OAuth अनुदान के बीच में एक वेंडर को रखता है।
जब आप एक तीसरे पक्ष का AI उत्पादकता टूल इंस्टॉल करते हैं और OAuth सहमति स्क्रीन पर क्लिक करते हैं, तो Google (या Microsoft, या किसी भी पहचान प्रदाता) द्वारा जारी एक्सेस टोकन और रिफ्रेश टोकन आपके डिवाइस पर नहीं रहते हैं। वे वेंडर के सर्वर पर डिलीवर किए जाते हैं, क्योंकि जिस AI को उनकी आवश्यकता होती है वह वेंडर के क्लाउड में चलता है। वेंडर का इंफ्रास्ट्रक्चर उनके प्रत्येक उपयोगकर्ता के लिए टोकन का एक निरंतर रिफ्रेश सेट रखता है, जो उन "Allow All" अनुमतियों तक सीमित होता है जिन्हें अधिकांश उपयोगकर्ताओं ने बिना पढ़े क्लिक कर दिया था।
वह केंद्रीकृत टोकन स्टोर ठीक वही है जिसे हमलावर निशाना बनाते हैं। वेंडर के साथ एक बार समझौता करने से आपको हजारों ग्राहकों के Workspace तक पहुंच मिल जाती है। Vercel का अपना बुलेटिन चेतावनी देता है कि इसके प्रभाव "कई संगठनों के सैकड़ों उपयोगकर्ताओं" को छू सकते हैं।
रिपोर्टिंग मूल श्रृंखला को Context AI के एक कर्मचारी तक ले जाती है जिसका व्यक्तिगत डिवाइस फरवरी 2026 में संक्रमित हुआ था, कथित तौर पर एक डाउनलोड किए गए Roblox गेम एक्सप्लोइट के माध्यम से जिसमें Lumma Stealer इन्फोस्टेलर मैलवेयर था। उस मैलवेयर ने कर्मचारी के Google Workspace और AWS क्रेडेंशियल्स को चुरा लिया, जिसने बदले में OAuth टोकन वॉल्ट को अनलॉक कर दिया। एक संक्रमित व्यक्तिगत डिवाइस, एक कॉर्पोरेट SaaS वॉल्ट, सैकड़ों डाउनस्ट्रीम Workspaces।
तीन संरचनात्मक कारण कि Caiioo के खिलाफ Context AI-शैली का उल्लंघन कुछ भी उपयोगी क्यों नहीं देगा
Caiioo एक शक्तिशाली, गोपनीयता-प्रथम (privacy-first) वर्कस्पेस है जिसमें एक एजेंटिक ऑर्केस्ट्रेटर और चैट इंटरफ़ेस है जो साइड पैनल में चलता है। "गोपनीयता-प्रथम" एक विशिष्ट संरचनात्मक स्थिति का वर्णन करता है, न कि केवल एक मार्केटिंग लाइन का। यहाँ तीन ठोस गुण कार्य कर रहे हैं।
1. आपके वर्कस्पेस OAuth टोकन आपके डिवाइस पर एन्क्रिप्टेड रूप में स्टोर होते हैं, हमारे सर्वर पर नहीं
जब आप Caiioo में Google या Microsoft अकाउंट कनेक्ट करते हैं, तो आपको उन स्कोप्स के साथ Google की मानक OAuth सहमति स्क्रीन दिखाई देगी जिन्हें आप अनुमति दे रहे हैं। अब तक यह Context AI को अधिकृत करने के समान ही दिखता है।
संरचनात्मक अंतर यह है कि उस सहमति प्रवाह (consent flow) से निकलने वाले टोकन का क्या होता है। Google द्वारा जारी किए गए एक्सेस टोकन और रिफ्रेश टोकन आपके डिवाइस पर एन्क्रिप्टेड रूप में स्टोर किए जाते हैं — macOS और iOS पर Keychain में, Android पर Android के Keystore में, और एक्सटेंशन में ब्राउज़र के सुरक्षित स्टोरेज में। वे Caiioo के केंद्रीय डेटाबेस में स्टोर नहीं किए जाते हैं। हमारे पास आपकी ओर से उन्हें रखने वाला कोई टोकन वॉल्ट नहीं है।
जब एजेंटिक ऑर्केस्ट्रेटर को आपका कैलेंडर पढ़ने या आपके इनबॉक्स को खोजने की आवश्यकता होती है, तो API कॉल आपके डिवाइस से सीधे Google पर जाती है, जिसमें आपके डिवाइस के सुरक्षित स्टोरेज से टोकन जुड़ा होता है। हमारा इंफ्रास्ट्रक्चर आपकी किसी भी वर्कस्पेस सामग्री के डेटा पथ (data path) में नहीं है।
आप स्वयं सोर्स में इसकी पुष्टि कर सकते हैं: src/shared/auth/connections-manager.ts वह स्थान है जहाँ Google/Microsoft OAuth कनेक्शन सुरक्षित रखे जाते हैं। OAuthConnection रिकॉर्ड, जिसमें accessToken और refreshToken फ़ील्ड शामिल हैं, स्थानीय स्टोरेज एडॉप्टर के माध्यम से लिखे जाते हैं — किसी केंद्रीय टोकन स्टोर में प्रसारित नहीं किए जाते।
2. रिले का मैसेज बस एंड-टू-एंड एन्क्रिप्टेड है
जब विभिन्न डिवाइसों पर Caiioo घटकों को समन्वय करने की आवश्यकता होती है — आपका ब्राउज़र एक्सटेंशन आपके डेस्कटॉप ऐप से बात कर रहा है, आपका फोन आपके होम सर्वर से बात कर रहा है, साइड-पैनल UI किसी ऐसे टूल को कॉल कर रहा है जो macOS पर नेटिव रूप से चलता है — तो वे हमारे द्वारा relay.pebbleflow.ai पर होस्ट किए गए एक रिले के माध्यम से ऐसा करते हैं। रिले वह मिलन बिंदु (rendezvous point) है जो आपके डिवाइसों को नेटवर्क के पार एक-दूसरे को खोजने की अनुमति देता है।
वह रिले एंड-टू-एंड एन्क्रिप्टेड है। प्रत्येक उपयोगकर्ता के डिवाइस रिले लिफाफे के माध्यम से एक की-एक्सचेंज (key exchange) करते हैं, और उसके बाद से, आपके डिवाइसों के बीच के संदेश रिले के दृष्टिकोण से सिफरटेक्स्ट (ciphertext) होते हैं। रिले उन्हें रूट कर सकता है लेकिन उन्हें पढ़ नहीं सकता।
यह केवल एक आकांक्षा नहीं है। Durable Object जो WebSocket कनेक्शन को संभालता है, cloud/relay/src/user-relay.ts, इस प्रकार प्रलेखित है: "एकल उपयोगकर्ता के लिए WebSocket कनेक्शन प्रबंधित करता है। E2E एन्क्रिप्टेड संदेशों (रिले के लिए अपारदर्शी) और की-एक्सचेंज को संभालता है।" ENCRYPTED संदेश प्रकार को संभालने वाले कोड पथ स्पष्ट रूप से कमेंट किए गए हैं: "विशिष्ट क्लाइंट को एन्क्रिप्टेड संदेश (हम इसे नहीं पढ़ सकते)।" रिले संरचनात्मक रूप से उन संदेशों की सामग्री का निरीक्षण करने में सक्षम नहीं है जिन्हें वह फॉरवर्ड करता है।
3. रिले निर्माण के अनुसार प्रति उपयोगकर्ता सिंगल-टेनेंट है
Caiioo का रिले Cloudflare Durable Objects पर बनाया गया है। प्रत्येक उपयोगकर्ता को अपना स्वयं का UserRelay इंस्टेंस मिलता है — जो कंप्यूट और स्टोरेज का एक अलग, रनटाइम-आइसोलेटेड हिस्सा है। प्रत्येक उपयोगकर्ता के लाइव सेशन स्टेट को रखने वाला कोई साझा मल्टी-टेनेंट डेटाबेस नहीं है, क्योंकि उस भूमिका के लिए कोई मल्टी-टेनेंट डेटाबेस है ही नहीं। प्रत्येक उपयोगकर्ता का रिले एक अलग ऑब्जेक्ट है।
यह महत्वपूर्ण है क्योंकि यह सिंगल-शेयर्ड-टारगेट विफलता मोड को समाप्त करता है। यदि कोई हमलावर एक उपयोगकर्ता के Durable Object से समझौता करने का तरीका ढूंढ भी लेता है, तो वे किसी अन्य उपयोगकर्ता के डेटा तक लैटरल एक्सेस प्राप्त नहीं कर पाएंगे — क्योंकि वहां से आगे बढ़ने के लिए कोई साझा बैकिंग स्टोर नहीं है। प्रत्येक उपयोगकर्ता, संरचनात्मक रूप से, अपना स्वयं का टेनेंट है।
हमारे केंद्रीय डेटाबेस में क्या है और क्या नहीं है
हम उन चीज़ों के लिए एक केंद्रीय डेटाबेस (Cloudflare D1) संचालित करते हैं जिन्हें केंद्रीय होने की आवश्यकता है। यहाँ ईमानदारी मायने रखती है। डेटाबेस स्टोर करता है:
- खाता पहचान: आपका ईमेल, यदि आप ईमेल/पासवर्ड लॉगिन का उपयोग करते हैं तो आपका हैश किया हुआ पासवर्ड, यदि आप सोशल-लॉगिन बटन का उपयोग करते हैं तो Google/Apple/Microsoft द्वारा लौटाया गया प्रदाता ID।
- बिलिंग स्थिति: आपकी Stripe ग्राहक ID, सदस्यता स्तर, लाइसेंस कुंजी और सदस्यता स्थिति।
- AI अनुमान प्रदाताओं के लिए प्रति-उपयोगकर्ता API कुंजियाँ (विशेष रूप से OpenRouter)। ये अनुमान-प्रदाता क्रेडेंशियल हैं — आपके Workspace OAuth टोकन से अलग। ये प्रबंधित-क्रेडिट प्रवाह के लिए और उन उपयोगकर्ताओं के लिए मौजूद हैं जो Caiioo की AI सुविधाओं में उपयोग करने के लिए अपनी स्वयं की OpenRouter कुंजी लाना चाहते हैं।
- लाइसेंस प्रवर्तन के लिए डिवाइस सक्रियण सूची।
- ऑडिट लॉग, SOC 2 साक्ष्य आवश्यकताओं के लिए रखे गए।
- ऑप्ट-इन इनबाउंड वेबहुक के लिए एक रूटिंग टेबल (WhatsApp, Telegram, आदि) — केवल तभी उपयोग किया जाता है जब आपने उन मैसेजिंग इंटीग्रेशन को कॉन्फ़िगर किया हो।
डेटाबेस स्टोर नहीं करता है:
- आपके Workspace OAuth टोकन (Gmail, Calendar, Drive, Microsoft 365)। वे केवल आपके डिवाइस पर हैं।
- आपकी बातचीत की सामग्री। एजेंटिक ऑर्केस्ट्रेटर आपके साइड पैनल में चलता है; बातचीत आपके स्थानीय स्टोरेज में रहती है।
- आपका Workspace डेटा — ईमेल, कैलेंडर इवेंट, Drive फ़ाइलें। वे सीधे Google/Microsoft से आपके डिवाइस पर पढ़े जाते हैं, हमारे इंफ्रास्ट्रक्चर से कभी नहीं गुजरते।
- WebSocket रिले के माध्यम से बहने वाले किसी भी संदेश की सामग्री। रिले केवल सिफरटेक्स्ट (ciphertext) देखता है।
हमारे केंद्रीय डेटाबेस के उल्लंघन से खाता/बिलिंग पहचान, ऑडिट लॉग और OpenRouter अनुमान-कुंजी कॉलम उजागर होंगे। यह Workspace टोकन, बातचीत की सामग्री या Workspace डेटा नहीं देगा, क्योंकि वे वहां लेने के लिए मौजूद ही नहीं हैं।
ईमानदार चेतावनियाँ (The honest caveats)
यह एक अलग थ्रेट मॉडल है, कोई जादुई ढाल नहीं। कुछ ऐसी बातें जो हम चाहेंगे कि आप बाद में खुद पता लगाने के बजाय हमसे सुनें।
OAuth कोड-एक्सचेंज संक्षेप में हमारे रिले को छूता है। Google (और Microsoft, GitHub, Slack) को टोकन-एक्सचेंज चरण में OAuth client_secret प्रस्तुत करने की आवश्यकता होती है, और उस सीक्रेट को क्लाइंट कोड में नहीं भेजा जा सकता है। इसलिए हमारा स्टेटलेस रिले client_secret को जोड़ता है और वास्तविक टोकन के बदले में आपके ऑथराइजेशन कोड को Google को फॉरवर्ड करता है। टोकन रिले के माध्यम से वापस आते हैं और स्टोरेज के लिए तुरंत आपके डिवाइस पर भेज दिए जाते हैं। वे हमारे इंफ्रास्ट्रक्चर में सेव (persist) नहीं किए जाते हैं। यही कारण है कि आपके द्वारा उपयोग किए गए हर नेटिव Google-इंटिग्रेटेड ऐप में कुछ सर्वर घटक होते हैं — यह Google की एक बाध्यता है, Caiioo का डिज़ाइन विकल्प नहीं।
कस्टम एंडपॉइंट्स आपको हमारे OAuth क्लाइंट को पूरी तरह से बायपास करने की अनुमति देते हैं। Caiioo कस्टम OAuth एंडपॉइंट्स को कॉन्फ़िगर करने का समर्थन करता है, जिसका अर्थ है कि Google Cloud Console (या Microsoft Entra समकक्ष) में अपना स्वयं का OAuth क्लाइंट प्रोविज़न करने के इच्छुक उपयोगकर्ता Caiioo के OAuth स्कोप और हमारे रिले के एक्सचेंज चरण से पूरी तरह बच सकते हैं। एक बार कॉन्फ़िगर होने के बाद, ऑथराइजेशन फ्लो आपके डिवाइस और Google के बीच होता है और Caiioo कहीं भी लूप में नहीं होता है। हम इसे उपभोक्ता-सामना करने वाली सेटिंग (consumer-facing setting) के रूप में नहीं दिखाते हैं क्योंकि अधिकांश उपयोगकर्ताओं को इसकी आवश्यकता नहीं होती है और डिफ़ॉल्ट आर्किटेक्चर पहले से ही आपके Workspace डेटा को हमारे सर्वर से दूर रखता है। लेकिन यह मौजूद है, और इसका कार्यान्वयन उन सभी के लिए परिचित होगा जिन्होंने पहले Google Cloud Console में OAuth क्लाइंट सेटअप किया है।
डिवाइस का समझौता (Compromise) अभी भी मायने रखता है। यदि आपका लैपटॉप हैक हो जाता है, तो आपके टोकन भी हैक हो जाते हैं। लोकल-फर्स्ट अटैक सरफेस को "वेंडर के वॉल्ट" से हटाकर "आपके एंडपॉइंट" पर ले आता है। यह एक छोटा और अधिक बचाव योग्य सरफेस है, लेकिन यह शून्य नहीं है।
लॉगिन-टियर "Sign in with Google" Workspace-एक्सेस से अलग है। यदि आप Google या Apple के साथ स्वयं Caiioo में साइन इन करते हैं, तो वह फ्लो केवल पहचान (identity-only) के लिए है और आपके अकाउंट तक सीमित एक बेसिक कनेक्शन बनाता है। यह ऊपर वर्णित Workspace-एक्सेस फ्लो के समान पथ नहीं है और AI को आपके इनबॉक्स या कैलेंडर तक पहुंच प्रदान नहीं करता है।
स्वयं Caiioo पर सप्लाई-चेन हमले अभी भी कल्पनीय हैं। एक समझौता किया गया अपडेट चैनल सैद्धांतिक रूप से ऐसा कोड भेज सकता है जो आपके डिवाइस से टोकन निकाल (exfiltrate) ले। हम इसे हर उस प्लेटफॉर्म पर कोड साइनिंग और नोटराइजेशन के साथ कम करते हैं जिस पर हम शिप करते हैं, लेकिन यह बचाव वेंडर-वॉल्ट मॉडल से अलग है — और हमलावरों का अर्थशास्त्र भी।
इसे स्वयं कैसे सत्यापित करें
ईमानदार जवाब यह है कि किसी मार्केटिंग पेज से वेंडर के प्राइवेसी के दावे को किसी संशयवादी (skeptic) के सामने साबित नहीं किया जा सकता। इसलिए, यहाँ बताया गया है कि आप अपने स्वयं के टूल्स का उपयोग करके हमारे दावों की पुष्टि कैसे कर सकते हैं।
Caiioo का उपयोग करते समय एक नेटवर्क मॉनिटर चलाएँ। macOS पर Little Snitch, Windows पर GlassWire, या किसी भी सिस्टम पर Wireshark। एक घंटे के लिए सामान्य रूप से Caiioo का उपयोग करें। आपको जो ट्रैफिक दिखाई देगा, और प्रत्येक कनेक्शन का क्या अर्थ है, वह यहाँ है:
| गंतव्य (Destination) | कब | इसका क्या अर्थ है |
|---|---|---|
oauth2.googleapis.com, gmail.googleapis.com, calendar.googleapis.com, www.googleapis.com |
जब भी एजेंट आपका Workspace डेटा पढ़ता है | आपका डिवाइस आपके ऑन-डिवाइस टोकन के साथ सीधे Google से बात कर रहा है। हम इस पथ (path) में नहीं हैं। |
login.microsoftonline.com, graph.microsoft.com |
यदि आपने Microsoft 365 कनेक्ट किया है | वही प्रक्रिया, आपका डिवाइस Microsoft से कनेक्ट हो रहा है। |
api.anthropic.com, openrouter.ai, api.openai.com, generativelanguage.googleapis.com, localhost:11434 (Ollama) |
जब आप चैट भेजते हैं या कोई ऐसा टूल चलाते हैं जो LLM का उपयोग करता है | आपका डिवाइस आपके द्वारा कॉन्फ़िगर किए गए AI प्रदाता से बात कर रहा है। हम इस पथ में नहीं हैं। |
relay.pebbleflow.ai (HTTPS) |
संक्षिप्त रूप में, शुरुआती Workspace OAuth सेटअप और समय-समय पर टोकन रिफ्रेश के दौरान | स्टेटलेस (stateless) OAuth कोड-एक्सचेंज। टोकन यहाँ से गुजरते हैं, सर्वर-साइड पर सेव नहीं किए जाते हैं। |
relay.pebbleflow.ai (HTTPS) |
समय-समय पर | लाइसेंस सत्यापन, रिलीज-नोट्स / यूजर-गाइड कंटेंट फेच, मॉडल-इंटेलिजेंस डेटा, सब्सक्रिप्शन स्टेटस चेक। |
relay.pebbleflow.ai (HTTPS) |
जब आप वेबसाइट लोड करते हैं या कनेक्टेड-अकाउंट स्टेटस देखते हैं | स्टैंडर्ड API ट्रैफिक। |
relay.pebbleflow.ai (WebSocket) |
लगातार, यदि आपके पास कई Caiioo कंपोनेंट्स इंस्टॉल हैं (extension + desktop app, या mobile + desktop) | कैपेबिलिटी ब्रिज जो आपके डिवाइसेस को एक-दूसरे से बात करने देता है। एंड-टू-एंड एन्क्रिप्टेड। हम केवल सिफरटेक्स्ट (ciphertext) देखते हैं। |
relay.pebbleflow.ai/api/messaging/... |
केवल तभी जब आपने मैसेजिंग इंटीग्रेशन कॉन्फ़िगर किया हो (WhatsApp, Telegram, Slack इनबाउंड) | इनकमिंग मैसेज के लिए वेबहुक रूटिंग। |
आप कभी भी क्या नहीं देखेंगे:
- आपका Workspace डेटा (ईमेल, कैलेंडर इवेंट, Drive फाइलें)
relay.pebbleflow.aiपर जाते हुए। वे कॉल आपके डिवाइस से सीधे*.googleapis.comपर जाते हैं। - आपकी बातचीत का कंटेंट
relay.pebbleflow.aiपर जाते हुए। ऑर्केस्ट्रेटर आपके साइड पैनल में चलता है; चैट हिस्ट्री आपके लोकल स्टोरेज में होती है। - आपके AI प्रदाता की API कीज़
relay.pebbleflow.aiपर जाते हुए। वे आपके डिवाइस पर रहती हैं। (अपवाद: यदि आप मैनेज्ड-क्रेडिट फ्लो का उपयोग करते हैं, तो आप सर्वर-एलोकेटेड OpenRouter सब-अकाउंट का उपयोग कर रहे होते हैं, और इन्फरेंस कॉल अभी भी आपके डिवाइस से ही की जाती है।)
यदि आप कभी भी अपने डिवाइस से हमारे इंफ्रास्ट्रक्चर पर कोई ऐसा अनुरोध देखते हैं जो ऊपर दी गई तालिका में फिट नहीं बैठता है, तो वह एक महत्वपूर्ण खोज है। हमें बताएं, और हम इसे स्पष्ट करेंगे या इसे ठीक करेंगे।
यदि आप Vercel या Context AI के ग्राहक हैं तो क्या करें
Vercel, Context AI और सुरक्षा अनुसंधान समुदाय द्वारा प्रकाशित मार्गदर्शन एक सुसंगत चेकलिस्ट पर सहमत हुआ है:
- प्रत्येक सीक्रेट को रोटेट करें जो गैर-एन्क्रिप्टेड Vercel वातावरण चर के रूप में संग्रहीत है। एन्क्रिप्टेड/संवेदनशील चर अप्रभावित बताए गए थे, लेकिन रोटेशन सस्ता है।
- Google Workspace पर अपनी टीम के तीसरे पक्ष के OAuth अनुदानों का ऑडिट करें (और यदि लागू हो तो Microsoft 365)। ऐसी किसी भी चीज़ को रद्द करें जिसे आप नहीं पहचानते हैं, और किसी भी टूल को जिसे आपने व्यापक "Allow All" स्कोप दिया है, उसे एक क्रेडेंशियल के रूप में मानें जिसे आपको बदलने की आवश्यकता है।
- भविष्य की सहमति को कड़ा करें। उन उपकरणों को प्राथमिकता दें जो न्यूनतम-विशेषाधिकार (least-privilege) स्कोप का अनुरोध करते हैं, और उन वर्कस्पेस को प्राथमिकता दें जिनका आर्केस्ट्रक्चर आपको लंबे समय तक चलने वाले टोकन सौंपने की आवश्यकता नहीं रखता है।
तीसरा वाला संरचनात्मक कदम है, और वह जिसकी यह घटना चुपचाप सिफारिश करती रहती है।
Caiioo आज़माएँ
यदि Vercel/Context AI घटना का सबक यह है कि आपके OAuth टोकन का स्थान वेंडर के उल्लंघन होने पर आपके प्रभाव क्षेत्र को निर्धारित करता है, तो उत्तर एक ऐसा कार्यक्षेत्र चुनना है जो उन्हें अपने पास नहीं रखता है।
Caiioo एक शक्तिशाली, गोपनीयता-प्रथम कार्यक्षेत्र है जिसमें एक एजेंटिक ऑर्केस्ट्रेटर और चैट इंटरफ़ेस है जो साइड पैनल में चलता है। ब्राउज़र एक्सटेंशन, नेटिव macOS ऐप, नेटिव iOS ऐप, नेटिव Android ऐप और Windows और Linux के लिए डेस्कटॉप ऐप के रूप में उपलब्ध है। मुफ़्त में शुरू करें।
स्रोत:
- Vercel Knowledge Base: April 2026 security incident bulletin
- Context AI: Security update
- TechCrunch: App host Vercel says it was hacked and customer data stolen
- The Hacker News: Vercel Breach Tied to Context AI Hack
- BleepingComputer: Vercel confirms breach as hackers claim to be selling stolen data
- Trend Micro: The Vercel Breach — OAuth Supply Chain Attack Exposes the Hidden Threat