פרצה שאי אפשר לסתום: חוקרים קובעים שמודלי שפה לעולם לא יהיו חסינים לגמרי מפני האקרים

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

הבעיה נקראת 'הזרקת פרומפטים' (prompt injection), והיא נחשבת כבר שנתיים ברציפות לחולשת האבטחה המסוכנת ביותר במערכות מבוססות LLM לפי דירוג ארגון ה-OWASP. במקום לפרוץ למערכת באמצעות קוד זדוני קלאסי, תוקף פשוט 'משכנע' את המודל, למשל דרך טקסט שמוטמע בדף אינטרנט, במסמך או במייל שהצ'אטבוט קורא, לסטות מההוראות שקיבל מהמפעיל ולבצע פעולה אחרת: לחשוף מידע רגיש, לשלוח תשלום, או לייצר תוכן אסור. הסיבה לכך שההתקפה כל כך קשה לעצירה היא שמודלי השפה מעבדים כל קלט, הוראת מערכת, שאלת משתמש ותוכן שנשלף מהרשת, כזרם אחיד של טוקנים, בלי מנגנון מובנה שמבחין בין 'פקודה שיש לציית לה' לבין 'מידע שיש לקרוא בלבד'.

לפי דיווחים על המחקר, אחד השותפים לכתיבתו, החוקר העצמאי צ'רלס יי, העריך שקיימת סבירות ממשית שמדובר בבעיה שלא ניתנת לפתרון מוחלט במסגרת הארכיטקטורה הנוכחית של מודלי השפה. גם ב-OpenAI הודו בעבר שהזרקת פרומפטים 'ככל הנראה לא תיפתר באופן מלא לעולם', בדיוק מהסיבה הזו: אין הפרדה קשיחה בין 'הוראות אמינות' לבין 'תוכן לא אמין' בתוך אותו חלון הקשר. חוקרי אבטחה מרבים להשוות את התופעה להזרקת SQL הקלאסית מעולם פיתוח האתרים, כשההבדל המרכזי הוא ש-SQL injection נפתר בסופו של דבר באמצעות שינוי ארכיטקטוני (שאילתות מוכנות מראש), בעוד שעבור LLM-ים עדיין לא נמצא מקבילה כזו.

המשמעות המעשית חשובה במיוחד ככל שחברות ממהרות לפרוס 'סוכני AI' (AI agents) שמקבלים הרשאות פעולה בעולם האמיתי, כמו גישה לדוא"ל, ליומן, לחשבונות בנק או ליכולת לבצע רכישות מטעם המשתמש. ככל שסוכן AI מקבל יותר כוח פעולה עצמאי, כך גם ההשלכות של הזרקת פרומפטים מוצלחת הופכות חמורות יותר, ממחיקת קבצים ועד העברת כספים לגורם לא מורשה. מנגנוני הגנה קיימים, כמו סינון קלט, הרשאות מינימליות ('least privilege') ומסווגים ייעודיים שמזהים ניסיונות תקיפה, מצמצמים את הסיכון אך אינם מבטלים אותו, שכן הם מטפלים בסימפטומים ולא בשורש הבעיה הארכיטקטוני.

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

מעבר להצהרה העקרונית, בשטח כבר מצטברות דוגמאות לכך שהחולשה אינה תיאורטית. במהלך 2026 תועדו מקרים שבהם עוזרי AI ארגוניים כמו Copilot של מיקרוסופט, Slack AI וכלי קידוד מבוססי סוכנים נוצלו באמצעות תוכן חיצוני שהוטמע במסמכים, בקריאות API או בקוד עצמו, ולא רק בהודעת צ'אט ישירה מהמשתמש. המשותף לרוב המקרים הללו הוא שהתוקף כלל לא פנה למערכת ישירות, אלא 'הזין' לה תוכן שהיא הייתה אמורה לקרוא בלבד, וזה מספיק כדי לגרום לה לפעול נגד המפעיל שלה. זו בדיוק הסיבה שארגון OWASP ממשיך למקם את ההזרקה בראש רשימת הסיכונים למערכות מבוססות LLM כבר שנה שלישית ברציפות.

בצד ההגנה, קהילת המחקר לא נשארה אדישה: בשנתיים האחרונות פורסמו כמה שיטות שמנסות לצמצם את הבעיה ברמה הארכיטקטונית ולא רק ברמת הסינון החיצוני. שיטות כמו StruQ ו-SecAlign מנסות ל'אמן' את המודל להבחין בין ערוץ הוראות לערוץ נתונים כבר בשלב האימון, ושיטת DefensiveTokens מוסיפה טוקנים ייעודיים שמסמנים למודל אילו קטעים אסור לו לציית להם. אף אחת מהשיטות הללו, כולל אלה שהוצגו בכנסים מובילים כמו ICML ו-USENIX Security, לא טוענת להגנה של מאה אחוז — כולן מדווחות על צמצום משמעותי בשיעור ההצלחה של התקפות, לא על חיסול מוחלט שלהן. זה בדיוק התירוץ המחקרי לטענה המרכזית של המאמר החדש: כל עוד הפתרון הוא שיפור סטטיסטי ולא הפרדה מבנית מוחלטת, תמיד יישאר פתח.

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

בפועל, הגישה שמתגבשת בתעשייה נקראת לעיתים 'הנחת פגיעה' (assume breach), מונח שמקורו בעולם אבטחת הרשתות הקלאסי ומיובא עכשיו לעולם ה-AI: במקום לנסות למנוע כל הזרקה, מתכננים את הרשאות הסוכן, את הגישה שלו לכספים ולנתונים רגישים ואת נקודות האישור האנושי (human-in-the-loop) כך שגם תרחיש הכישלון הגרוע ביותר יישאר נסבל. עבור ארגון שמפעיל סוכן AI עם גישה לחשבון בנק או ליומן רגיש, השאלה הרלוונטית כבר אינה 'האם ננעל לגמרי את הפרצה', אלא 'כמה נזק סוכן שנפרץ יכול לגרום לפני שמישהו שם לב'. זו למעשה הנקודה שבה המחקר האקדמי והצורך העסקי הדחוף נפגשים.