Cloudflare: מידע של לקוחות אחרים נכלל ב־155 תשובות ב־Workers AI

Cloudflare חשפה ב־26 באוקטובר 2026 כי 155 תשובות של המודל GLM-5.3 בשירות Workers AI כללו מידע מבקשות של לקוחות אחרים, בעקבות דיווח של גדי עברון מ־Knostic. התקלה התרחשה בין 27 באוגוסט ל־9 בספטמבר וכבר תוקנה, כך שהחדשות הן פרסום התחקיר ולא גילוי של פרצה פעילה. עבור ארגונים ישראליים שמשלבים AI במוצרים ובתהליכים פנימיים, זהו מקרה שממחיש מדוע צריך לבדוק לא רק מה המודל עושה עם המידע, אלא גם כיצד תשתית ההרצה מפרידה בין לקוחות.

01מה נחשף, ומה הנתונים אינם אומרים

לפי Cloudflare, האירוע נגע ל־GLM-5.3 ב־Workers AI, ולא נמצאה פגיעה במודלים אחרים בשירות. החברה מסרה גם שלא נמצאו ראיות לניצול מכוון. אלה הבחנות חשובות: אין בסיס לתאר את האירוע כמתקפה רחבה על כלל שירותי החברה, וגם לא להסיק שכל לקוח שהשתמש במודל קיבל מידע זר או שמידע שלו נחשף.

המספר שפורסם, 155, מתייחס לתשובות שבהן נכלל מידע מבקשות של לקוחות אחרים. הוא אינו מספר הלקוחות שנפגעו, מספר האנשים שפרטיהם נחשפו או מדד לחומרת המידע שהופיע. בלי פירוט נוסף, אי אפשר להסיק ממנו אם מדובר בקטעי טקסט שוליים או בתוכן בעל רגישות עסקית גבוהה. גם מספר מוגבל של תשובות אינו מאפשר, בפני עצמו, לקבוע שהנזק היה קטן.

02לא שאלה מניפולטיבית, אלא כשל בהפרדת לקוחות

המאפיין המרכזי של המקרה הוא מקור הדליפה: כשל בהפרדה בין משתמשים בתשתית ההרצה, ולא שאלה מניפולטיבית שנועדה לשכנע צ׳טבוט לחשוף סודות. ההבחנה משנה את מוקד הבדיקה. במקום לבחון רק את ההנחיות שניתנו למודל ואת יכולתו לסרב לבקשה בעייתית, צריך לבחון גם את המערכת שמקבלת בקשות, מעבדת אותן ומחזירה תשובות ללקוחות שונים.

בשירות AI משותף, משתמש מצפה שהתגובה תתבסס על המידע וההרשאות של הבקשה שלו, ולא על תוכן של לקוח אחר. כאשר הגבול הזה נכשל, ניסוח זהיר של prompt אינו פתרון מספק. גם הוראה מפורשת בנוסח 'אל תחשוף מידע סודי' אינה תחליף להפרדה תקינה בשכבת התשתית. זו מסקנה אבטחתית כללית מהאירוע, ולא טענה שמנגנון הגנה מסוים נבדק ונכשל בו.

אותה הבחנה חשובה גם בדיון על שימוש בנתונים לאימון. מדיניות של ספק לגבי אימון המודל עוסקת בשאלה אחת; מניעת מעבר מידע בין בקשות בזמן הפעלת השירות עוסקת בשאלה אחרת. ארגון יכול לקבל תשובה מספקת על הראשונה ועדיין להזדקק לבירור נפרד על השנייה. אין להסיק מהאירוע שהמידע שדלף שימש לאימון.

03הזווית הישראלית: מהדיווח של עברון לבדיקת ספקים

הקשר המקומי הישיר הוא הדיווח של גדי עברון מ־Knostic, שבעקבותיו נחשף האירוע בתחקיר החברה. מעבר לכך, המשמעות לעסקים בישראל מעשית מאוד: מערכת שירות לקוחות בעברית, כלי לסיכום מסמכים או מוצר תוכנה שמפעיל מודל דרך API עשויים להעביר לספק חיצוני תוכן שהמשתמש כלל אינו רואה את מסלולו. אלה דוגמאות לשימושים שמצריכים בדיקה, לא רשימה של מערכות שנפגעו באירוע.

לעסק ישראלי אין די בשאלה 'באיזה מודל אנחנו משתמשים?'. עליו לדעת גם מי מפעיל את המודל, דרך איזה שירות נשלחת הבקשה, ואילו סוגי מידע יוצאים מהארגון. אם צוות הפיתוח משלב שירות חיצוני בתוך מוצר קיים, האחריות הפנימית צריכה להיות ברורה גם לאנשי האבטחה, הפרטיות והרכש. שם המודל לבדו אינו מתאר את סביבת העיבוד.

בתהליך בחירת ספק כדאי לכן לבקש הסבר על הפרדת לקוחות, על בדיקות שמטרתן לזהות מעבר מידע ביניהם ועל הדרך שבה הספק מודיע על אירועים. רצוי לברר גם איזה מידע ניתן לקבל בדיעבד כדי לזהות בקשות רלוונטיות. אין בכך הבטחה למניעת תקלות, אבל תשובות קונקרטיות מאפשרות הערכת סיכון טובה יותר מהצהרה כללית שהשירות מאובטח.

04מה כדאי לבדוק עכשיו אם השתמשתם ב־Workers AI

הבדיקה הראשונה צריכה להיות ממוקדת: האם הארגון השתמש ב־GLM-5.3 דרך Workers AI בתקופה שצוינה. אין בסיס להרחיב אוטומטית את החשד לכל שימוש ב־Cloudflare או לכל מודל AI. מנגד, היעדר תלונות ממשתמשים אינו מספיק כדי לשלול חשיפה, משום שהארגון לא בהכרח יכול לראות תוכן שהגיע לתשובה של לקוח אחר.

1. בדקו ברישומי המערכת ובתצורת השירות איזה מודל הופעל ובאילו מועדים. שימוש בתקופה הרלוונטית הוא עילה לבירור, לא הוכחה לפגיעה.
2. מפו אילו סוגי מידע נשלחו: טקסט ציבורי, מסמכים פנימיים, פרטים אישיים או תוכן עסקי חסוי. רגישות המידע צריכה להנחות את המשך הבדיקה.
3. פנו לספק לבירור פרטני עם מזהי בקשות ונתונים תפעוליים זמינים, ככל שישנם. הימנעו מצירוף מיותר של תוכן רגיש לפניות תמיכה.
4. אם עולה חשד לחשיפת מידע אישי או חסוי, ערבו את גורמי האבטחה, הפרטיות והייעוץ המשפטי לפני קביעה על היקף האירוע או חובות הדיווח.

בטווח הארוך, צמצום המידע שנשלח למודל הוא אמצעי להפחתת הנזק האפשרי: להסיר מזהים שאינם נחוצים למשימה ולהימנע משליחת מסמך מלא כאשר די בקטע רלוונטי. זו אינה דרך לתקן כשל תשתיתי אצל ספק, אלא שכבת זהירות נוספת שבשליטת הארגון. היא מועילה גם כשהשירות פועל כמתוכנן.

05מה הלאה: לבחון את התיקון בלי להרחיב את הטענות

הפרסום של Cloudflare מאפשר לדון בכשל מתועד במקום בתרחיש היפותטי. עם זאת, האמירה שלא נמצאו ראיות לניצול מכוון אינה מבטלת את עצם החשיפה, והעובדה שהתקלה תוקנה אינה עונה לבדה על שאלות של לקוח לגבי מידע שכבר נשלח. מנגד, אין הצדקה להציג את השירות כפרוץ כעת בניגוד לדיווח החברה.

השאלה המעשית להמשך היא אילו ראיות ומנגנוני בקרה יכולים ספקי AI להציג ללקוחותיהם לגבי הפרדת מידע בזמן ההרצה. עבור מפתחים ועסקים בישראל, הלקח אינו להפסיק כל שימוש בשירות משותף, אלא להתייחס לתשתית ההפעלה כחלק מהחלטת האבטחה. בחירת מודל, ניסוח הנחיות ומדיניות אימון הם רק חלק מהבדיקה; גם הגבול בין בקשה של לקוח אחד לתשובה שמקבל אחר צריך להיכלל בה.