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

هذه ترجمة آلية للمستند الأصلي باللغة الإنجليزية. في حال وجود أي تعارض بين هذه الترجمة والنسخة الإنجليزية الأصلية، تُعتمد النسخة الإنجليزية. اقرأ النسخة الإنجليزية الأصلية

ليس في المنتصف: لماذا لن يؤدي اختراق بأسلوب Context AI ضد Caiioo إلى نتائج مفيدة

2026-04-22 · Caiioo Team

في 19 أبريل 2026، كشفت Vercel أن أداة ذكاء اصطناعي تابعة لجهة خارجية لموظف واحد قد تم اختراقها، وأن رمز OAuth المخترق قد استُخدم للانتقال إلى بيئات Vercel الداخلية. تعرضت مجموعة محدودة من العملاء لكشف متغيرات بيئة غير حساسة. لم تتأثر متغيرات البيئة المشفرة/الحساسة.

كانت الأداة هي Context AI. منحها الموظف وصولاً واسعاً "Allow All" إلى Google Workspace الخاص بالشركة. كان منح OAuth الوحيد هذا، والمخزن في خوادم Context AI، هو نقطة الارتكاز لكل ما تبع ذلك.

قام جهة تهديد على BreachForums بإدراج ما يزعم أنها 580 سجلاً لموظفي Vercel للبيع مقابل 2 مليون دولار. لم تتحقق Vercel من تلك القائمة.

الحادث لم ينتهِ بعد. لكن الدرس المعماري واضح بالفعل، وهو درس مفيد لأي شخص يقيم مساحة عمل للذكاء الاصطناعي.

شكل الهجوم

يضع نموذج SaaS-AI البائع في منتصف كل منح OAuth تعطيه له.

عندما تقوم بتثبيت أداة إنتاجية ذكاء اصطناعي تابعة لجهة خارجية وتنقر عبر شاشة موافقة OAuth، فإن رمز الوصول ورمز التحديث الصادرين من Google (أو Microsoft، أو أي مزود هوية) لا يبقيان على جهازك. يتم تسليمهما إلى خوادم البائع، لأن الذكاء الاصطناعي الذي يحتاجهما يعمل في سحابة البائع. تحتفظ بنية البائع التحتية بمجموعة من الرموز المحدثة باستمرار لكل مستخدم من مستخدميهم، بنطاق أذونات "Allow All" التي نقر عليها معظم المستخدمين دون قراءة.

مخزن الرموز المركزي هذا هو بالضبط ما يستهدفه المهاجمون. اختراق البائع مرة واحدة يمنحك وصولاً إلى Workspace لآلاف العملاء. تحذر نشرة Vercel الخاصة من أن الآثار اللاحقة قد تطال "مئات المستخدمين عبر العديد من المؤسسات".

تتبع التقارير السلسلة الأصلية وصولاً إلى موظف في Context AI تعرض جهازه الشخصي للاختراق في فبراير 2026، ويقال إن ذلك تم عبر ثغرة في لعبة Roblox محملة كانت تحمل برمجية Lumma Stealer الخبيثة لسرقة المعلومات. قامت تلك البرمجية باستخراج بيانات اعتماد Google Workspace وAWS الخاصة بالموظف، والتي بدورها فتحت خزنة رموز OAuth. جهاز شخصي واحد مصاب، خزنة SaaS واحدة للشركة، مئات من مساحات العمل المتضررة.

ثلاثة أسباب معمارية تجعل أي اختراق لـ Caiioo بأسلوب Context AI لا يسفر عن أي شيء مفيد

تُعد Caiioo مساحة عمل قوية تعطي الأولوية للخصوصية، مع منسق وكيل (agentic orchestrator) وواجهة دردشة تعمل في لوحة جانبية. "الخصوصية أولاً" تصف وضعاً معمارياً محدداً، وليست مجرد شعار تسويقي. هناك ثلاث خصائص ملموسة قيد التنفيذ.

1. يتم تخزين رموز OAuth الخاصة بمساحة عملك مشفرة على جهازك، وليس على خوادمنا

عندما تقوم بربط حساب Google أو Microsoft في Caiioo، ستظهر لك شاشة موافقة OAuth القياسية من Google مع النطاقات (scopes) التي تمنحها. حتى الآن، يبدو هذا مطابقاً تماماً لتفويض Context AI.

الاختلاف الهيكلي يكمن في ما يحدث للرموز (tokens) الناتجة عن تدفق الموافقة هذا. يتم تخزين رمز الوصول (access token) ورمز التحديث (refresh token) اللذين تصدرهما Google مشفرين على جهازك — في Keychain على macOS و iOS، وفي Keystore على Android، وفي التخزين الآمن للمتصفح في الإضافة. لا يتم تخزينها في قاعدة بيانات Caiioo المركزية. نحن لا نملك خزنة رموز تحتفظ بها نيابة عنك.

عندما يحتاج المنسق الوكيل إلى قراءة تقويمك أو البحث في بريدك الوارد، ينتقل استدعاء API من جهازك مباشرة إلى Google، مع إرفاق الرمز من التخزين الآمن لجهازك. بنيتنا التحتية ليست في مسار البيانات لأي من محتويات مساحة عملك.

يمكنك التحقق من ذلك بنفسك في المصدر: src/shared/auth/connections-manager.ts هو المكان الذي يتم فيه حفظ اتصالات Google/Microsoft OAuth. يتم كتابة سجلات OAuthConnection ، بما في ذلك حقول accessToken و refreshToken ، عبر محول التخزين المحلي — ولا يتم إرسالها إلى مخزن رموز مركزي.

2. ناقل الرسائل الخاص بالمرحل (relay) مشفر من طرف إلى طرف

عندما تحتاج مكونات Caiioo على أجهزة مختلفة إلى التنسيق — مثل تواصل إضافة المتصفح مع تطبيق سطح المكتب، أو هاتفك مع خادمك المنزلي، أو استدعاء واجهة اللوحة الجانبية لأداة تعمل بشكل أصلي على macOS — فإنها تفعل ذلك من خلال مرحل (relay) نستضيفه في relay.pebbleflow.ai. المرحل هو نقطة الالتقاء التي تتيح لأجهزتك العثور على بعضها البعض عبر الشبكات.

هذا المرحل مشفر من طرف إلى طرف. تقوم أجهزة كل مستخدم بتبادل المفاتيح عبر غلاف المرحل، ومنذ ذلك الحين، تصبح الرسائل بين أجهزتك نصاً مشفراً من منظور المرحل. يمكن للمرحل توجيهها ولكنه لا يستطيع قراءتها.

هذا ليس مجرد طموح. إن Durable Object الذي يتعامل مع اتصالات WebSocket، وهو cloud/relay/src/user-relay.ts ، موثق كالتالي: "يدير اتصالات WebSocket لمستخدم واحد. يتعامل مع الرسائل المشفرة E2E (غير شفافة للمرحل) وتبادل المفاتيح." مسارات الكود التي تتعامل مع نوع الرسالة ENCRYPTED معلق عليها صراحة: "رسالة مشفرة لعميل معين (لا يمكننا قراءتها)." المرحل غير قادر معمارياً على فحص محتويات الرسائل التي يمررها.

3. المرحل أحادي المستأجر لكل مستخدم، حسب التصميم

تم بناء مرحل Caiioo على Cloudflare Durable Objects. يحصل كل مستخدم على مثيل UserRelay خاص به — وهو جزء منفصل ومعزول برمجياً من الحوسبة والتخزين. لا توجد قاعدة بيانات مشتركة متعددة المستأجرين تحتفظ بحالة الجلسة المباشرة لكل مستخدم، لأنه لا توجد قاعدة بيانات متعددة المستأجرين لهذا الدور أصلاً. مرحل كل مستخدم هو كائن منفصل.

هذا الأمر مهم لأنه يلغي نمط الفشل القائم على "الهدف المشترك الواحد". حتى لو وجد مهاجم طريقة لاختراق Durable Object الخاص بمستخدم واحد، فلن يتمكن من الوصول الجانبي إلى بيانات أي مستخدم آخر — حيث لا يوجد مخزن دعم مشترك للانتقال من خلاله. كل مستخدم، من الناحية الهيكلية، هو مستأجر مستقل بذاته.

ما هو موجود وما هو غير موجود في قاعدتنا المركزية

نحن ندير قاعدة بيانات مركزية (Cloudflare D1) للأشياء التي يجب أن تكون مركزية. الصدق مهم هنا. تخزن قاعدة البيانات:

  • هوية الحساب: بريدك الإلكتروني، وكلمة المرور المجزأة (hashed) إذا كنت تستخدم تسجيل الدخول بالبريد/كلمة المرور، ومعرف المزود الذي ترجعه Google/Apple/Microsoft إذا كنت تستخدم زر تسجيل الدخول الاجتماعي.
  • حالة الفوترة: معرف عميل Stripe الخاص بك، وفئة الاشتراك، ومفتاح الترخيص، وحالة الاشتراك.
  • مفاتيح API لكل مستخدم لمزودي استنتاج الذكاء الاصطناعي (OpenRouter تحديداً). هذه هي أوراق اعتماد مزود الاستنتاج — وهي متميزة عن رموز OAuth الخاصة بـ Workspace. وهي موجودة لتدفق الائتمانات المدارة وللمستخدمين الذين يرغبون في إحضار مفتاح OpenRouter الخاص بهم لاستخدامه عبر ميزات الذكاء الاصطناعي في caiioo.
  • قائمة تنشيط الأجهزة لإنفاذ التراخيص.
  • سجلات التدقيق، المحفوظة لمتطلبات أدلة SOC 2.
  • جدول توجيه لخطافات الويب (webhooks) الواردة الاختيارية (WhatsApp و Telegram وما إلى ذلك) — تُستخدم فقط إذا قمت بتكوين عمليات دمج المراسلة تلك.

قاعدة البيانات لا تخزن:

  • رموز OAuth الخاصة بـ Workspace (Gmail و Calendar و Drive و Microsoft 365). هذه موجودة على جهازك فقط.
  • محتوى محادثاتك. يعمل المنسق الوكيل في لوحتك الجانبية؛ وتعيش المحادثات في تخزينك المحلي.
  • بيانات Workspace الخاصة بك — رسائل البريد الإلكتروني، وأحداث التقويم، وملفات Drive. يتم قراءتها مباشرة من Google/Microsoft إلى جهازك، ولا تمر أبداً عبر بنيتنا التحتية.
  • محتويات أي رسالة تتدفق عبر وسيط WebSocket. يرى الوسيط النص المشفر فقط.

إن اختراق قاعدتنا المركزية سيكشف عن هوية الحساب/الفوترة، وسجلات التدقيق، وعمود مفاتيح استنتاج OpenRouter. لن ينتج عنه رموز Workspace، أو محتوى المحادثات، أو بيانات Workspace، لأنها ليست موجودة هناك ليتم أخذها.

التحذيرات الصادقة

هذا نموذج تهديد مختلف، وليس درعاً سحرياً. إليك بعض التوضيحات التي نفضل أن تسمعها منا بدلاً من اكتشافها لاحقاً.

عملية تبادل كود OAuth تلمس وسيطنا (relay) لفترة وجيزة. تتطلب Google (وكذلك Microsoft و GitHub و Slack) تقديم client_secret الخاص بـ OAuth في خطوة تبادل الرموز (token-exchange)، ولا يمكن شحن هذا السر ضمن كود العميل (client code). لذا، يقوم وسيطنا عديم الحالة (stateless relay) بإرفاق client_secret وتوجيه كود التفويض الخاص بك إلى Google مقابل الحصول على الرموز الفعلية. تعود الرموز عبر الوسيط ويتم إرجاعها فوراً إلى جهازك لتخزينها. لا يتم استبقاء هذه الرموز في بنيتنا التحتية. هذا هو نفس السبب الذي يجعل كل تطبيق أصلي متكامل مع Google استخدمته من قبل يحتوي على مكون خادم — إنه قيد من Google، وليس خياراً تصميمياً من caiioo.

تسمح لك نقاط النهاية المخصصة (Custom endpoints) بتجاوز عميل OAuth الخاص بنا تماماً. يدعم Caiioo تكوين نقاط نهاية OAuth مخصصة، مما يعني أن المستخدم المستعد لإعداد عميل OAuth الخاص به في Google Cloud Console (أو ما يعادله في Microsoft Entra) يمكنه تجنب نطاقات OAuth الخاصة بـ Caiioo وخطوة التبادل في وسيطنا تماماً. بمجرد التكوين، يكون تدفق المصادقة بين جهازك و Google دون وجود Caiioo في الحلقة نهائياً. نحن لا نظهر هذا كإعداد موجه للمستهلك العادي لأن معظم المستخدمين لا يحتاجون إليه، ولأن البنية الافتراضية تحافظ بالفعل على بيانات Workspace الخاصة بك بعيداً عن خوادمنا. لكنه موجود، وسيكون التنفيذ مألوفاً لأي شخص قام بإعداد عميل OAuth في Google Cloud Console من قبل.

لا يزال اختراق الجهاز أمراً مهماً. إذا تم اختراق جهاز الكمبيوتر المحمول الخاص بك، فقد تم اختراق رموزك. ينقل نهج "المحلي أولاً" (Local-first) سطح الهجوم من "خزنة المورد" إلى "نقطة النهاية الخاصة بك". هذا السطح أصغر وأكثر قابلية للدفاع عنه، لكنه ليس صفراً.

عملية "تسجيل الدخول باستخدام Google" على مستوى الحساب منفصلة عن الوصول إلى Workspace. إذا قمت بتسجيل الدخول إلى Caiioo نفسه باستخدام Google أو Apple، فإن هذا التدفق مخصص للهوية فقط وينشئ اتصالاً أساسياً (Basic connection) مقتصرًا على حسابك. إنه ليس نفس مسار تدفق الوصول إلى Workspace الموضح أعلاه، ولا يمنح الـ AI حق الوصول إلى بريدك الوارد أو تقويمك.

لا تزال هجمات سلاسل التوريد على Caiioo نفسه متصورة. يمكن لقناة تحديث مخترقة، من الناحية النظرية، شحن كود يقوم بتسريب الرموز من جهازك. نحن نخفف من ذلك من خلال توقيع الكود (code signing) والتوثيق (notarization) على كل منصة نشحن إليها، لكن التخفيف يختلف عن نموذج "خزنة المورد" — وكذلك تختلف اقتصاديات المهاجمين.

كيفية التحقق من ذلك بنفسك

الإجابة الصادقة هي أن ادعاءات الخصوصية التي يقدمها أي مزود في صفحات التسويق لا يمكن إثباتها للمشككين. لذا، إليك كيفية التأكد مما ادعيناه باستخدام أدواتك الخاصة.

قم بتشغيل مراقب للشبكة أثناء استخدام caiioo. استخدم Little Snitch على نظام macOS، أو GlassWire على نظام Windows، أو Wireshark على أي نظام آخر. استخدم Caiioo بشكل طبيعي لمدة ساعة. حركة المرور التي ستراها، ومعنى كل اتصال:

الوجهة متى ماذا يعني ذلك
oauth2.googleapis.com, gmail.googleapis.com, calendar.googleapis.com, www.googleapis.com عندما يقرأ الوكيل بيانات Workspace الخاصة بك جهازك يتحدث مباشرة مع Google باستخدام رمز (token) موجود على جهازك. نحن لسنا طرفاً في هذا المسار.
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) لفترة وجيزة، أثناء إعداد OAuth الأولي لـ Workspace وأثناء التحديث الدوري للرموز تبادل أكواد OAuth عديم الحالة (stateless). تمر الرموز عبره، ولا يتم حفظها في جانب الخادم.
relay.pebbleflow.ai (HTTPS) بشكل دوري التحقق من ترخيص البرنامج، جلب محتوى ملاحظات الإصدار / دليل المستخدم، بيانات ذكاء النماذج، وفحص حالة الاشتراك.
relay.pebbleflow.ai (HTTPS) عندما تقوم بتحميل الموقع الإلكتروني أو عرض حالة الحساب المتصل حركة مرور API قياسية.
relay.pebbleflow.ai (WebSocket) بشكل مستمر، إذا كان لديك عدة مكونات من Caiioo مثبتة (الإضافة + تطبيق سطح المكتب، أو الهاتف + سطح المكتب) جسر الإمكانيات الذي يسمح لأجهزتك بالتحدث مع بعضها البعض. مشفر من طرف إلى طرف (End-to-end encrypted). نحن نرى النص المشفر فقط.
relay.pebbleflow.ai/api/messaging/... فقط إذا قمت بتكوين تكاملات المراسلة (WhatsApp، Telegram، Slack الواردة) توجيه Webhook للرسائل الواردة.

ما لن تراه أبداً:

  • بيانات Workspace الخاصة بك (رسائل البريد الإلكتروني، أحداث التقويم، ملفات Drive) تتدفق إلى relay.pebbleflow.ai. تلك الطلبات تذهب من جهازك مباشرة إلى *.googleapis.com.
  • محتوى محادثاتك يتدفق إلى relay.pebbleflow.ai. يعمل المنسق (orchestrator) في اللوحة الجانبية الخاصة بك؛ وسجل الدردشة موجود في وحدة التخزين المحلية لديك.
  • مفاتيح API الخاصة بمزود AI تتدفق إلى relay.pebbleflow.ai. فهي تبقى على جهازك. (الاستثناء: إذا كنت تستخدم تدفق الرصيد المدار (managed-credits)، فأنت تستخدم حساباً فرعياً في OpenRouter مخصصاً من الخادم، ومع ذلك يتم طلب الاستدلال (inference) من جهازك).

إذا رأيت في أي وقت طلباً من جهازك إلى بنيتنا التحتية لا يتوافق مع الجدول أعلاه، فهذا يعتبر اكتشافاً. أخبرنا بذلك، وسنقوم بتوضيحه أو إصلاحه.

ماذا تفعل إذا كنت عميلاً لـ Vercel أو Context AI

تقاربت الإرشادات المنشورة من Vercel وContext AI ومجتمع أبحاث الأمن حول قائمة مرجعية متسقة:

  1. قم بتدوير كل سر (secret) مخزن كمتغير بيئة Vercel غير مشفر. تم الإبلاغ عن عدم تأثر المتغيرات المشفرة/الحساسة، لكن التدوير إجراء غير مكلف.
  2. دقق في منح OAuth التابعة لجهات خارجية لفريقك على Google Workspace (وMicrosoft 365، إذا كان ذلك ينطبق). قم بإلغاء أي شيء لا تتعرف عليه، وعامل أي أداة منحتها نطاقات "Allow All" واسعة كبيانات اعتماد تحتاج إلى استبدال.
  3. شدد الموافقة المستقبلية. فضل الأدوات التي تطلب نطاقات بأقل الامتيازات، وفضل مساحات العمل التي لا تتطلب بنيتها تسليم رموز طويلة الأمد على الإطلاق.

الخيار الثالث هو التحرك الهيكلي، وهو الخيار الذي يوصي به هذا الحادث بهدوء.

جرب Caiioo

إذا كان الدرس المستفاد من حادثة Vercel/Context AI هو أن موقع رموز OAuth الخاصة بك يحدد نطاق الضرر عند اختراق البائع، فإن الحل هو اختيار مساحة عمل لا تحتفظ بها.

Caiioo هي مساحة عمل قوية تعطي الأولوية للخصوصية مع منسق وكيل وواجهة دردشة تعمل في لوحة جانبية. متوفر كامتداد للمتصفح، وتطبيق macOS أصلي، وتطبيق iOS أصلي، وتطبيق Android أصلي، وتطبيق سطح مكتب لأنظمة Windows و Linux. ابدأ مجاناً.

المصادر: