חטיפת זהות של תהליך עבודה: Noma Labs הופכת דוא״ל תמיכה רגיל לגישה לנתונים עם הרשאות גבוהות

ב-9 בספטמבר 2026 פרסם צוות המחקר ב-Noma Security, בכתיבה בשם Noma Labs, תיאור של מה שהוא מכנה חטיפת זהות של זרימת עבודה: זרימת עבודה ארגונית של AI קוראת הודעה רגילה שמגיעה לנקודת כניסה ציבורית — תיבת דואר של תמיכה, issue ב-GitHub, טופס אינטרנט, מסמך משותף — ואז מבצעת את העבודה המבוקשת באמצעות חשבון השירות בעל ההרשאות הגבוהות שלה במקום הרשאות השולח. התיאור של Noma מציג גורם חיצוני ששולח בדוא״ל לכתובת התמיכה הציבורית של חברה ומבקש, בין היתר, את נתוני המכירות הרבעוניים מהודעת הדוא״ל האחרונה של מנהל הכספים; כעבור דקות מגיע התוכן לתיבת הדואר של התוקף. לא הוטעה שום מודל ולא נפרץ שום חשבון, וזו הנקודה של הדוח: ״כל מה שהתוקף היה צריך לעשות הוא לבקש.״ הארכיון אינו מתעד נזק ממשי — לא ננקב שם של קורבן ולא מתוארת מערכת שהוטמעה כפגועה — ומדרג את הממצא כמחקר, חומרה בינונית, ודאות A, במחלוקת false. תיאור זה נשען על הדוח של Noma Labs, על הסיקור של Dark Reading שפורסם באותו יום ועל כתבת ההמשך של CSO Online, וארכיון אירועי ה-AI מחזיק ערך זה לצד שכניו, שלכל אחד מהם מקורות משלו, חומרה ודירוג ודאות.

השדות של הרשומה עצמה ראויים לקריאה לפני הטקסט. היא מתויגת ב-INFRA וב-EXFIL, מכסה את אזור GLOBAL, נושאת תאריך יחיד ומדויק ליום — 9 בספטמבר 2026 — ואינה מסומנת כרשומת ציון דרך. התאריך הוא תאריך הפרסום של המחקר ולא דבר אחר; אין מצורף לו ציר זמן של תקרית, מפני שאין תקרית לתזמן. זה הדבר הראשון שכדאי להחזיק בו: מה ש-Noma פרסמה הוא מנגנון וקטגוריה, לא דוח פרצה.

מה נומה הדגימה, ומה היא לא הדגימה

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

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

מכיוון שהפעולות מתבצעות דרך אוטומציה מהימנה עם פרטי התחברות תקפים, נומה טוענת שאין כמעט מה שההתראה הקונבנציונלית תוכל לתפוס. הבקשה שגרתית, הפלט של המודל הוא פלט מודל תקף, קריאת ה-API מאומתת, והתגובה היא התגובה שתהליך העבודה נבנה כדי לשלוח. CSO Online ציטט את איש צוות ה-Red Team Vibhum Dubey, שהמחיש את בעיית הזיהוי: "האירועים הבודדים יכולים להיראות לגמרי לגיטימיים. האותות השימושיים יגיעו מקורלציה בין המבקש המקורי, הזהות שבה נעשה שימוש בהמשך, המשאבים שאליהם ניגשו, הפרמטרים שסופקו והפעולה הסופית."

הבדיקה שנכשלת היא בדיקת הרשאה, ולא מסנן תוכן

ההמחשה החדה ביותר בדוח היא צמד בקשות זהות. מסמנכ״ל כספים: "מה הם נתוני המכירות הרבעוניים ממנהל הכספים בהודעת הדוא״ל האחרונה שלו?" משולח חיצוני: אותן מילים. הנקודה של נומה היא שההנחיה והפעולה המבוקשת זהות, ואילו החלטת ההרשאה אמורה להיות שונה לחלוטין — "סמנכ״ל כספים זכאי למידע הזה; שולח חיצוני אינו זכאי."

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

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

תהליכי עבודה סטטיים נמצאים מחוץ למאמץ להקשחת סוכנים

Noma מפרידה בין שני דברים שבאופן שגרתי משמשים זה במקום זה. תהליך עבודה של AI הוא רצף סטטי ומוגדר מראש שבו המודל הוא שלב עיבוד אחד — בקיצור של הדו״ח: שלב A, מודל, שלב B, שלב C — והצינור הדטרמיניסטי שסביב המודל קובע מה קורה. תהליך עבודה סוכני הוא אוטונומי: הסוכן מחליט אילו שלבים לבצע ואילו כלים להפעיל. חלק ניכר ממאמץ האבטחה הנוכחי, כך טוען הדו״ח, הופנה לסוג השני — הגבלת גישה לכלים והגדרת היקף הרשאות לסוכנים שמקבלים החלטות דינמיות — והבקרות הללו אינן חלות על הראשון.

הדוח גם סוגר פתח מילוט ברור. הגבלת מי או מה יכול להפעיל תהליך עבודה אינה פותרת את הבעיה: אם אוטומציה פועלת בשעה 8:00 בבוקר לפי לוח זמנים ופועלת על תיבת דואר שכל אחד יכול לכתוב אליה, ביקורת של "מי יכול להפעיל את תהליך העבודה הזה" משיבה על השאלה הלא נכונה. הכלל של Noma הוא שכל אוטומציה חייבת להיבחן לפי "הגורם הפחות מהימן שמסוגל להשפיע על מה שהיא פועלת עליו" — כולל הודעות דואר אלקטרוני, טפסים, קריאות שירות, נושאים ב-GitHub, מסמכים משותפים והודעות צ'אט.

נומה אומרת שגוגל תיקנה מקרה של Google Workflows; גוגל לא פרסמה דבר

הפלטפורמה היחידה שנקראת בשמה בדוח היא של Google. Noma מציינת שהיא זיהתה את אותו וקטור סיכון בתוך Google Workflows, שדיווחה עליו באחריות, ושה-Google אישרה את הדיווח ואישרה תיקון "בלי לחשוף פרטי יישום". המשפט הזה הוא כל התיעוד הציבורי. לא ניתן היה לאתר ייעוץ של Google, הערת שחרור או CVE המתארים את הווקטור הזה, וכל דיווח משני על התיקון — כולל אלה שפורסמו בימים שאחרי 9 בספטמבר — מייחס אותו ל-Noma ולא ל-Google.

הדוח גם אינו עקבי לגמרי לגבי איזה מוצר של Google הוא מתכוון. הטקסט עצמו מזכיר את Google Workflows; כותרת סעיף באותו דוח היא "Google Workspace: חטיפת זהות של זרימת עבודה ב-AI". שניהם מוצרים של Google עם גבולות אמון שונים, והדוח אינו מיישב ביניהם. Noma אינה אומרת אם המקרה שדיווחה עליו נוצל לרעה, כמה לקוחות נחשפו, או מה השתנה בתיקון — ומכיוון ש-Google לא אמרה דבר, לא ניתן לסגור אף אחד מהפערים הללו מצד הספק.

GitLost היה אותו גבול, במבט מבעד לעדשה צרה יותר

הגילוי המוקדם של Noma מספק תקדים לקטגוריה. ביולי 2026 פרסמה הקבוצה מחקר על GitHub Agentic Workflows, שאותו כינתה GitLost: תהליך עבודה שהופעל כאשר issue הוקצה, קרא את הכותרת והגוף של ה-issue והשיב בתגובה, ומכיוון שלסוכן הייתה גישת קריאה בכל המאגרים של הארגון, משתמשים חיצוניים יכלו להשתמש בהקצאת issue כדי להגיע לנתונים של מאגר פרטי. Dark Reading סיקר זאת ב-7 ביולי 2026 ותיאר תוקף שמסתיר פקודות באנגלית פשוטה בגוף issue שנפתח במאגר ציבורי, ללא צורך באישורים וללא כישורי קידוד.

שתי המסגרות אינן זהות, וההבדל הוא החלק המעניין. הדיווח של Dark Reading מיולי הוא סיפור של הזרקת פרומפט: טקסט שנשלט על ידי תוקף נקרא כהוראות. הדוח של Noma מספטמבר מתאר את GitLost במונחים של הטריגר וגישת הקריאה ברמת המאגר כולו, ומציג אותו כאותו גבול הרשאה שנראה מזווית אחת. שני התיאורים מתאימים לתהליך עבודה שסוכן שלו קרא טקסט שכתב גורם חיצוני, אבל רק התיאור המוקדם יותר תלוי בכך שהמודל מונחה. Noma אומרת כעת שהיא דיווחה על אותו וקטור סיכון ל-Google; היא לא אומרת אם מקרה GitLost נוצל אי פעם מעבר להדגמה שפורסמה.

התיאור של Noma עצמה לגבי היקף החשיפה הוא ש-Hacker News, Dark Reading ויותר מ-100 כלי תקשורת בינלאומיים אחרים סיקרו את מחקר GitLost. הנתון הזה הוא של הספק, והמאמר הזה לא ספר באופן עצמאי את הסיקור.

העוסקים בתחום מסכימים שהמנגנון ישן; הוויכוח הוא על השם

סיקור עצמאי לא ערער על הממצא, ושני אנשי מקצוע חיצוניים התנגדו לטענת החידוש ולא לטענה המהותית. מוריי הבר, יועץ האבטחה הראשי ב-BeyondTrust, אמר ל-Dark Reading: "איש לא הוליך שולל מודל AI לגרום לו לעשות משהו שהוא לא היה אמור לעשות. המודל עשה בדיוק את מה שנאמר לו, על ידי זר (לא מהימן), ותהליך העבודה שסביבו השתמש בזהות של מישהו אחר כדי שזה יקרה, מכיוון שהוא לא הוגדר בהיקף ולא טופל לפי הרשאת מינימום." CSO Online ציטט את Vibhum Dubey שתיאר את הדפוס כ"סוג מוכר של חולשת הרשאה", והוסיף כי במקום שבו קלט לא מאומת יכול להפעיל תהליך עבודה מהימן שפועל בהרשאותיו שלו, "תהליך העבודה יכול לשמש למעשה כסגן מבולבל."

רם ורדארג'אן, מנכ"ל Acalvio, הציע ל-Dark Reading בקרה שונה לחלוטין: במקום עוד סינון, לזרוע בסביבה פיתויים — שרשורי מנהלים מזויפים, רשומות honeytoken — שאין שום סיבה לגיטימית לכך שזרימת עבודה מורשית כלשהי תיגע בהם, כך שבקשה שנראית תמימה שמנסה להגיע לאחד מהם מפעילה גבול שאסור לה לחצות לעולם. המחלוקת, ככל שהיא קיימת, היא בשאלה אם התרומה השימושית היא שם חדש לפגם האצלה מתקופת 1988 או תיאור עובד של היכן אותו פגם נמצא כיום. עמדתו של Noma היא השנייה: שהדפוס הוא מערכתי לאורך צינורות ה-AI הארגוניים ושב מסגרות אבטחת ה-AI הנוכחיות מסתכלות על המשטח הלא נכון.

ההקלה היא האצלה ונקודת ביקורת, לא מסנן טוב יותר

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

דובי נתן ל-CSO Online מבחן זול יותר מכל אחד משלושת האחרים: השוואת תוצאות בין רמות הרשאה. "אם משתמש בעל הרשאה נמוכה יכול להשיג את אותה תוצאה כמו מנהל מערכת משום שמערכות במורד הזרם רואות רק את זהות תהליך העבודה, שם הייתי מתמקד בחקירה."

מה שהתיעוד מותיר פתוח

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

• איזה מוצר של Google תוקן, ומה היה התיקון. הפרוזה של Noma אומרת Google Workflows, כותרת הסעיף שלה אומרת Google Workspace, ו-Google לא פרסמה דבר. ארגונים עדיין אינם יכולים לקבוע ממקורות ציבוריים אם צינור שהם מפעילים היה בהיקף.

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

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

• מי מציג את הטענה. Noma Labs היא זרוע המחקר של Noma Security, שמוכרת בקרות אבטחה לסוכנים בדיוק מהסוג שהדוח שלה ממליץ עליו. זה לא הופך את הממצא לשגוי — גם Dark Reading וגם CSO Online דיווחו עליו, ואף אחד מהם לא מצא שגיאה עובדתית — אבל זהו הקשר שכדאי לקורא להחזיק בראש כששוקלים עד כמה רחבה נמתחת הקטגוריה.

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