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

אבטחת מודלי שפה: החולשה שמקשה על בינה מלאכותית להבחין בין מידע להוראה

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

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

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

הבעיה אינה רק מה כתוב, אלא מי מוסמך לומר זאת

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

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

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

מה גילו החוקרים על זיוף שרשרת חשיבה

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

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

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

הדיווח מזכיר ניסויים במודלים של OpenAI, ובהם gpt-oss-20b ו־GPT-5. החוקרים מסרו כי קיבלו תוצאות דומות גם במודלים של Anthropic, Alibaba ו־DeepSeek. יש להבחין בין הניסויים המתוארים במאמר לבין התוצאות הנוספות שעליהן דיווחו החוקרים; החומר שסופק אינו כולל פירוט מלא המאפשר להשוות ביניהן.

אבטחת מודלי שפה תלויה גם בזיהוי מקור הטקסט

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

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

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

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

פריצת הגנות והזרקת הנחיות: שתי תופעות קרובות, לא זהות

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

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

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

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

למה עוד אימון אינו בהכרח פתרון מלא

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

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

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

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

כשהעוזר יכול לפעול, חולשת טקסט הופכת לסיכון עסקי

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

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

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

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

מה ארגונים יכולים לעשות כבר עכשיו

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

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

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

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

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

איך לקרוא הבטחות אבטחה של ספקי בינה מלאכותית

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

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

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

טבלת סיכום: החולשה והמשמעות המעשית

חמש שאלות שכדאי לשאול לפני שמרחיבים את השימוש

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

המטרה: מערכת בטוחה גם כשהמודל טועה

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

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