
זוהי תרגום מכונה של המסמך המקורי באנגלית. במקרה של סתירה בין תרגום זה לבין הגרסה המקורית באנגלית, הגרסה באנגלית היא הקובעת. קרא את הגרסה המקורית באנגלית
לא באמצע: מדוע פריצה בסגנון Context AI נגד Caiioo לא תניב שום דבר שימושי
2026-04-22 · Caiioo Team
ב-19 באפריל 2026, Vercel חשפה כי כלי AI מצד שלישי של עובד בודד נפרץ, וכי אסימון ה-OAuth שנפרץ שימש לחדירה לסביבות הפנימיות של Vercel. תת-קבוצה מוגבלת של לקוחות חוותה חשיפה של משתני סביבה שאינם רגישים. משתני סביבה מוצפנים/רגישים לא הושפעו.
הכלי היה Context AI. העובד העניק לו גישת "אפשר הכל" רחבה ל-Google Workspace הארגוני שלו. אותו אישור OAuth בודד, שהוחזק בשרתים של Context AI, היה נקודת המינוף לכל מה שקרה לאחר מכן.
תוקף ב-BreachForums פרסם בנפרד רשימה של מה שלטענתו הם 580 רשומות של עובדי Vercel למכירה ב-2 מיליון דולר. Vercel לא אימתה את הרישום הזה.
האירוע טרם הסתיים. אך הלקח הארכיטקטוני כבר ברור, והוא שימושי לכל מי שבוחן סביבת עבודה מבוססת AI.
צורת המתקפה
מודל ה-SaaS-AI מציב ספק באמצע כל אישור OAuth שאתם מעניקים לו.
כשאתם מתקינים כלי פרודוקטיביות AI מצד שלישי ומאשרים את מסך ה-OAuth, אסימון הגישה (access token) ואסימון הרענון (refresh token) שהונפקו על ידי Google (או Microsoft, או כל ספק זהות אחר) אינם נשארים במכשיר שלכם. הם מועברים לשרתי הספק, מכיוון שה-AI שזקוק להם פועל בענן של הספק. התשתית של הספק מחזיקה סט אסימונים שמתרעננים ללא הרף עבור כל אחד מהמשתמשים שלהם, בהיקף הרשאות של "אפשר הכל" שרוב המשתמשים אישרו מבלי לקרוא.
מאגר האסימונים המרכזי הזה הוא בדיוק היעד של התוקפים. פריצה אחת לספק מעניקה גישה ל-Workspace של אלפי לקוחות. העדכון של Vercel עצמה מזהיר כי השפעות השרשרת עלולות לגעת ב-"מאות משתמשים בארגונים רבים".
דיווחים עוקבים אחר השרשרת המקורית עד לעובד Context AI שמכשירו האישי נפרץ בפברואר 2026, לפי הדיווחים באמצעות ניצול פרצה (exploit) במשחק Roblox שהורד והכיל את הנוזקה Lumma Stealer. נוזקה זו גנבה את פרטי הגישה של העובד ל-Google Workspace ול-AWS, אשר בתורם פתחו את כספת אסימוני ה-OAuth. מכשיר אישי נגוע אחד, כספת SaaS ארגונית אחת, מאות סביבות Workspace שנפגעו בשרשרת.
שלוש סיבות ארכיטקטוניות לכך שפריצה בסגנון Context AI נגד Caiioo לא תניב שום דבר מועיל
Caiioo היא סביבת עבודה עוצמתית המתמקדת בפרטיות (privacy-first), הכוללת מנצח (orchestrator) סוכני וממשק צ'אט הפועל בפאנל צדי. "Privacy-first" מתאר עמדה ארכיטקטונית ספציפית, ולא שורת שיווק. ישנם שלושה מאפיינים קונקרטיים הפועלים כאן.
1. טוקני ה-OAuth של ה-Workspace שלך מאוחסנים מוצפנים במכשיר שלך, לא בשרתים שלנו
כאשר אתה מחבר חשבון Google או Microsoft ב-caiioo, תראה את מסך הסכמת ה-OAuth הסטנדרטי של Google עם ה-scopes שאתה מעניק. עד כה זה נראה זהה לאישור של Context AI.
ההבדל המבני הוא מה שקורה לטוקנים שיוצאים מתהליך ההסכמה הזה. ה-access token וה-refresh token ש-Google מנפיקה מאוחסנים מוצפנים במכשיר שלך — ב-Keychain ב-macOS ו-iOS, ב-Keystore של Android ב-Android, ובאחסון המאובטח של הדפדפן בתוסף. הם אינם מאוחסנים במסד הנתונים המרכזי של caiioo. אין לנו כספת טוקנים המחזיקה אותם עבורך.
כאשר המנצח הסוכני צריך לקרוא את לוח השנה שלך או לחפש בתיבת הדואר הנכנס שלך, קריאת ה-API עוברת מהמכשיר שלך ישירות ל-Google, כשהטוקן מהאחסון המאובטח של המכשיר שלך מצורף אליה. התשתית שלנו אינה נמצאת בנתיב הנתונים עבור אף תוכן מה-Workspace שלך.
אתה יכול לאמת זאת בעצמך במקור: src/shared/auth/connections-manager.ts הוא המקום שבו חיבורי ה-OAuth של Google/Microsoft נשמרים. רשומות ה-OAuthConnection, כולל שדות ה-accessToken וה-refreshToken, נכתבות דרך מתאם האחסון המקומי — ולא מועברות למאגר טוקנים מרכזי.
2. אפיק ההודעות (message bus) של ה-relay מוצפן מקצה לקצה
כאשר רכיבי Caiioo במכשירים שונים צריכים לתאם ביניהם — תוסף הדפדפן שלך מדבר עם אפליקציית שולחן העבודה שלך, הטלפון שלך מדבר עם השרת הביתי שלך, ממשק הפאנל הצדי מפעיל כלי שרץ באופן טבעי ב-macOS — הם עושים זאת דרך relay שאנו מארחים בכתובת relay.pebbleflow.ai. ה-relay הוא נקודת המפגש המאפשרת למכשירים שלך למצוא זה את זה על פני רשתות שונות.
ה-relay הזה מוצפן מקצה לקצה. המכשירים של כל משתמש מבצעים החלפת מפתחות דרך מעטפת ה-relay, ומאותו רגע, הודעות בין המכשירים שלך הן טקסט מוצפן מנקודת המבט של ה-relay. ה-relay יכול לנתב אותן אך אינו יכול לקרוא אותן.
זה לא חזון תיאורטי. ה-Durable Object שמנהל חיבורי WebSocket, cloud/relay/src/user-relay.ts, מתועד כך: "מנהל חיבורי WebSocket עבור משתמש יחיד. מטפל בהודעות מוצפנות E2E (אטומות ל-relay) ובהחלפת מפתחות." נתיבי הקוד המטפלים בסוג ההודעה ENCRYPTED מסומנים במפורש בהערה: "הודעה מוצפנת ללקוח ספציפי (איננו יכולים לקרוא אותה)." ה-relay אינו מסוגל ארכיטקטונית לבחון את תוכן ההודעות שהוא מעביר.
3. ה-relay הוא single-tenant לכל משתמש, מעצם בנייתו
ה-relay של Caiioo בנוי על Cloudflare Durable Objects. כל משתמש מקבל מופע UserRelay משלו — יחידת מחשוב ואחסון נפרדת ומבודדת בזמן ריצה. אין מסד נתונים משותף מרובה דיירים (multi-tenant) המחזיק את מצב הסשן החי של כל המשתמשים, כי אין בכלל מסד נתונים מרובה דיירים לתפקיד הזה. ה-relay של כל משתמש הוא אובייקט נפרד.
זה חשוב כי זה מבטל את מצב הכשל של "יעד משותף יחיד". גם אם תוקף ימצא דרך לפרוץ ל-Durable Object של משתמש אחד, הוא לא יקבל גישה רוחבית לנתונים של אף משתמש אחר — אין מאגר אחסון משותף שניתן לעבור דרכו. כל משתמש הוא, מבנית, דייר בפני עצמו.
מה נמצא ומה לא נמצא במסד הנתונים המרכזי שלנו
אנחנו מפעילים מסד נתונים מרכזי (Cloudflare D1) עבור דברים שחייבים להיות מרכזיים. יושרה חשובה כאן. מסד הנתונים שומר:
- זהות חשבון: הדוא"ל שלכם, הסיסמה המגובבת שלכם אם אתם משתמשים בהתחברות דוא"ל/סיסמה, מזהה הספק שמוחזר על ידי Google/Apple/Microsoft אם אתם משתמשים בכפתור התחברות חברתית.
- מצב חיוב: מזהה לקוח Stripe שלכם, רמת המנוי, מפתח הרישיון וסטטוס המנוי.
- מפתחות API לכל משתמש עבור ספקי בינה מלאכותית (OpenRouter, ספציפית). אלו הם אישורי ספק — נפרדים מאסימוני ה-OAuth של ה-Workspace שלכם. הם קיימים עבור זרימת קרדיטים מנוהלת ועבור משתמשים שרוצים להביא מפתח OpenRouter משלהם לשימוש בתכונות הבינה המלאכותית של caiioo.
- רשימת הפעלת מכשירים לאכיפת רישיונות.
- יומני ביקורת (Audit logs), הנשמרים עבור דרישות ראיות של SOC 2.
- טבלת ניתוב עבור Webhooks נכנסים (opt-in) (WhatsApp, Telegram וכו') — בשימוש רק אם הגדרתם את אינטגרציות ההודעות הללו.
מסד הנתונים אינו שומר:
- את אסימוני ה-OAuth של ה-Workspace שלכם (Gmail, Calendar, Drive, Microsoft 365). אלו נמצאים במכשיר שלכם בלבד.
- את תוכן השיחות שלכם. המנצח (orchestrator) הסוכני פועל בפאנל הצדדי שלכם; השיחות חיות באחסון המקומי שלכם.
- את נתוני ה-Workspace שלכם — הודעות דוא"ל, אירועי לוח שנה, קבצי Drive. אלו נקראים ישירות מ-Google/Microsoft למכשיר שלכם, ומעולם לא עוברים דרך התשתית שלנו.
- את התוכן של כל הודעה שזורמת דרך ממסר ה-WebSocket. הממסר רואה טקסט מוצפן בלבד.
פריצה למסד הנתונים המרכזי שלנו תחשוף את זהות החשבון/חיוב, יומני ביקורת ועמודת מפתחות ה-OpenRouter. היא לא תניב אסימוני Workspace, תוכן שיחות או נתוני Workspace, כי אלו פשוט לא נמצאים שם.
הסתייגויות כנות
זהו מודל איומים שונה, לא מגן קסמים. הנה כמה הבהרות שהיינו מעדיפים שתשמעו מאיתנו מאשר שתגלו מאוחר יותר.
החלפת קוד ה-OAuth עוברת לזמן קצר דרך ה-relay שלנו. Google (וכמוה גם Microsoft, GitHub, Slack) דורשת את ה-client_secret של ה-OAuth בשלב החלפת ה-token, ולא ניתן לשלוח את הסוד הזה בתוך קוד לקוח (client code). לכן, ה-relay חסר-המדינה (stateless) שלנו מצרף את ה-client_secret ומעביר את קוד ההרשאה שלכם ל-Google בתמורה ל-tokens הממשיים. ה-tokens חוזרים דרך ה-relay ומועברים מיד למכשיר שלכם לאחסון. הם אינם נשמרים בתשתית שלנו. זוהי אותה סיבה שבגללה לכל אפליקציה מקומית עם אינטגרציית Google שהשתמשתם בה אי פעם יש רכיב שרת כלשהו — זוהי מגבלה של Google, לא בחירה עיצובית של caiioo.
נקודות קצה מותאמות אישית (Custom endpoints) מאפשרות לכם לעקוף את לקוח ה-OAuth שלנו לחלוטין. Caiioo תומכת בהגדרת נקודות קצה OAuth מותאמות אישית, מה שאומר שמשתמש המוכן להגדיר לקוח OAuth משלו ב-Google Cloud Console (או במקביל של Microsoft Entra) יכול להימנע לחלוטין מה-OAuth scopes של Caiioo ומשלב ההחלפה ב-relay שלנו. לאחר ההגדרה, תהליך האימות מתבצע בין המכשיר שלכם לבין Google מבלי ש-caiioo נמצאת בשום שלב בלולאה. אנחנו לא מציגים זאת כהגדרה הפונה לצרכן הרחב מכיוון שרוב המשתמשים אינם זקוקים לכך והארכיטקטורה המוגדרת כברירת מחדל כבר שומרת את נתוני ה-Workspace שלכם מחוץ לשרתים שלנו. אך האפשרות קיימת, וההטמעה תהיה מוכרת לכל מי שהגדיר לקוח OAuth ב-Google Cloud Console בעבר.
פריצה למכשיר עדיין משמעותית. אם הלפטופ שלכם נפרץ, ה-tokens שלכם נפרצו. גישת ה-Local-first מעבירה את שטח הפנים של התקיפה מ"כספת הספק" אל "נקודת הקצה שלכם". זהו שטח פנים קטן יותר וקל יותר להגנה, אך הוא אינו אפסי.
שכבת ההתחברות "Sign in with Google" נפרדת מהגישה ל-Workspace. אם אתם מתחברים ל-caiioo עצמה באמצעות Google או Apple, תהליך זה נועד לזיהוי בלבד ויוצר חיבור בסיסי המוגבל לחשבון שלכם. זהו אינו אותו נתיב כמו תהליך הגישה ל-Workspace שתואר לעיל, והוא אינו מעניק ל-AI גישה לתיבת הדואר הנכנס או ללוח השנה שלכם.
מתקפות שרשרת אספקה על Caiioo עצמה הן עדיין אפשריות. ערוץ עדכונים שנפרץ יכול, באופן עקרוני, לשלוח קוד שמוציא tokens מהמכשיר שלכם. אנחנו מצמצמים סיכון זה באמצעות חתימת קוד (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 ובמהלך רענון token תקופתי | החלפת קוד ה-OAuth (stateless). ה-tokens עוברים דרך השרת, אך אינם נשמרים בצד השרת. |
relay.pebbleflow.ai (HTTPS) |
מעת לעת | אימות רישיון, שליפת תוכן של הערות שחרור / מדריכי משתמש, נתוני model-intelligence, בדיקות סטטוס מנוי. |
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 וקהילת מחקר האבטחה התכנסו לרשימת בדיקה עקבית:
- החליפו (Rotate) כל סוד שנשמר כמשתנה סביבה לא מוצפן ב-Vercel. דווח כי משתנים מוצפנים/רגישים לא הושפעו, אך החלפה היא פעולה זולה.
- בצעו ביקורת על אישורי OAuth של צד שלישי בצוות שלכם ב-Google Workspace (וב-Microsoft 365, אם רלוונטי). בטלו כל דבר שאינכם מזהים, והתייחסו לכל כלי שהענקתם לו הרשאות "אפשר הכל" רחבות כאל פרטי גישה שיש להחליף.
- הדקו את ההסכמה בעתיד. העדיפו כלים המבקשים הרשאות בגישת "ההרשאה המינימלית" (least-privilege), והעדיפו סביבות עבודה שהארכיטקטורה שלהן אינה דורשת מכם למסור אסימונים ארוכי טווח כלל.
הסעיף השלישי הוא המהלך המבני, וזה שהאירוע הזה ממליץ עליו בשקט.
נסו את Caiioo
אם הלקח מאירוע Vercel/Context AI הוא שמיקום אסימוני ה-OAuth שלכם קובע את טווח הפגיעה כשהספק נפרץ, התשובה היא לבחור בסביבת עבודה שאינה מחזיקה אותם.
Caiioo היא סביבת עבודה עוצמתית ששמה את הפרטיות במרכז, עם מנצח סוכני וממשק צ'אט שפועל בפאנל צדדי. זמין כתוסף לדפדפן, אפליקציית macOS טבעית, אפליקציית iOS טבעית, אפליקציית Android טבעית, ואפליקציית שולחן עבודה ל-Windows ו-Linux. התחילו בחינם.
מקורות:
- Vercel Knowledge Base: עדכון אירוע אבטחה אפריל 2026
- Context AI: עדכון אבטחה
- TechCrunch: מארחת האפליקציות Vercel אומרת שנפרצה ונתוני לקוחות נגנבו
- The Hacker News: הפריצה ל-Vercel קשורה לפריצה ל-Context AI
- BleepingComputer: Vercel מאשרת פריצה בזמן שהאקרים טוענים שהם מוכרים נתונים גנובים
- Trend Micro: הפריצה ל-Vercel — מתקפת שרשרת אספקה של OAuth חושפת את האיום הנסתר