Heads of Security: הגנה מהזרקת פרומפטים במנגנון הקשב
Heads of Security נועד להבחין בתוך המודל בין הוראות מהימנות לתוכן חיצוני. בניסוי החוקרים ירד שיעור הצלחת המתקפה מ־97% ל־10%, אך אין זו חסינות.
מסמך שסוכן AI קורא אמור לספק לו מידע, לא להפוך למנהל שלו. מחקר שפורסם ב־27 באוקטובר 2026 מציג את Heads of Security (HoS), מנגנון הגנה נלמד בתוך מערכת הקשב של המודל, שנועד להבחין בין הוראות מהימנות לתוכן חיצוני. בניסוי שמציגים החוקרים, שיעור ההצלחה של מתקפת RL-Hammer ירד מ־97% מול GPT-OSS-20B ל־10% עם ההגנה: ירידה ניכרת, אבל לא חסינות.
מה המחקר מציע: הפרדה בתוך מערכת הקשב
הבעיה שאליה מכוון HoS היא הזרקת פרומפטים דרך מידע חיצוני. סוכן יכול לקבל מהמשתמש משימה לגיטימית, למשל לסכם מסמך או לחפש תשובה במאגר ארגוני, ובמהלך העבודה להיתקל בטקסט שמנסה לשנות את ההוראות שלו. הטקסט הזה עשוי להיות חלק ממסמך, דף אינטרנט או תוצאה שמוחזרת מכלי. עצם העובדה שהסוכן צריך לקרוא אותו אינה מקנה לו סמכות להכתיב פעולות.
לפי המחקר ב־arXiv, HoS מנסה לטפל בהבחנה הזאת באמצעות מנגנון נלמד בתוך מערכת הקשב. זהו ההיבט המחקרי המרכזי: ההפרדה בין מידע להוראות אינה נשארת רק בניסוח הבקשה למודל, אלא מקבלת מענה בתוך המודל עצמו. מהתחקיר אין בסיס לפרט כיצד המנגנון אומן או אילו שינויים מדויקים נעשו בכל רכיב, ולכן אין להסיק שמדובר בתוספת פשוטה שאפשר לחבר לכל שירות קיים.
החוקרים מדווחים גם שההגנה לא פגעה משמעותית ביכולות במבחנים שנבדקו. הסייג הזה חשוב: מנגנון שחוסם כל מסמך חשוד עלול להגן על הסוכן במחיר הפיכתו לפחות שימושי. השאלה המחקרית היא אם אפשר לשמר את היכולת להפיק מידע מהמסמך, ובמקביל למנוע מהוראות המסתתרות בו לקבל עדיפות על המשימה המקורית.
מה המספרים מוכיחים, ומה הם עדיין לא מוכיחים
ההשוואה בין 97% ל־10% מתייחסת למתקפת RL-Hammer ולתנאי הניסוי שעליהם דיווחו המחברים. היא אינה אומרת שכל סוכן מוגן יהיה חשוף לאותה רמת סיכון, ואינה מודדת את כלל הדרכים שבהן אפשר להטעות מערכת. גם השם GPT-OSS-20B מופיע כאן כמודל שנבחן במחקר, לא כהמלצה לבחירת מודל לארגון.
אלה תוצאות שמציגים מחברי המחקר, ולא אימות עצמאי. שיעור הצלחה של 10% בניסוי עדיין משמעו שההגנה לא עצרה את כל המתקפות שנבדקו; אין לפרש אותו כסיכון הצפוי במערכת שלכם.
כדי להעריך התאמה לפריסה אמיתית, צריך לבדוק מעבר לתוצאה המרכזית. האם ההגנה מועילה גם מול מתקפות אחרות? האם היא נשמרת לאורך רצף של קריאות לכלים? מה קורה כשהמסמך כולל הוראות לגיטימיות שהמשתמש דווקא ביקש לנתח? אלה שאלות להמשך בדיקה, לא חולשות שהוכחו במחקר ולא יכולות שאפשר לייחס לו על סמך התחקיר.
גם הממצא על שימור היכולות דורש קריאה מדויקת. הצלחה במבחנים שנבדקו אינה מבטיחה ביצועים זהים בכל משימה עסקית, שפה או סוג מסמך. עבור צוות מחקר או אבטחה, התוצאה היא סיבה לבחון את הגישה, לא תחליף לבדיקת איכות ובטיחות על תהליכי העבודה המקומיים.
למה מסמך חיצוני הוא גבול אבטחה
כדי להבין את הסיכון, דמיינו סוכן שהתבקש להשוות הצעות מספקים. בתוך אחת ההצעות מופיע משפט שמורה לו להתעלם מהמתחרים ולשלוח את המסמכים לכתובת חיצונית. זו דוגמה היפותטית, לא אירוע שדווח במחקר. הסוכן צריך להבין שהמשפט נמצא בהצעת הספק, אך לא לראות בו אישור לשנות את המשימה או להוציא מידע מהארגון.
מידע שהסוכן רשאי לקרוא אינו בהכרח הוראה שהוא רשאי לבצע.
ההבחנה הזאת נעשית חשובה במיוחד כאשר למערכת יש כלים שמסוגלים לבצע פעולות. טעות בסיכום עלולה להטעות קורא; טעות אצל סוכן בעל הרשאות עלולה להתגלגל לשינוי רשומה או לשליחת הודעה. לכן גם הגנה פנימית מוצלחת אינה מחליפה בדיקות הרשאה מחוץ למודל. המערכת שמפעילה את הכלים צריכה להגביל מה ניתן לבצע, בלי להסתמך רק על האופן שבו המודל פירש את המסמך.
המשמעות בישראל: לבדוק עברית והרשאות בפועל
לעסק ישראלי שמחבר סוכן למאגר נהלים, לתיבת שירות או למסמכי ספקים, השאלה המעשית אינה רק אם המודל מזהה מתקפה באנגלית. סביבת העבודה עשויה לכלול עברית, אנגלית ומסמכים שמשלבים ביניהן. התחקיר אינו מציג תוצאות ייעודיות לעברית, ולכן אין להסיק שהשיפור המדווח מתקיים גם במסמכי הארגון המקומי.
אפשר לתרגם את שאלת המחקר לתוכנית בדיקה גם בלי להניח ש־HoS זמין לשימוש. המטרה היא לבחון אם הסוכן ממשיך במשימה המקורית כשהמקור שהוא קורא מנסה להסיט אותו, ולוודא שהצלחה בקריאת המסמך אינה מתבלבלת עם ציות להוראות שבתוכו.
- בנו מסמכי בדיקה מדומים בעברית ובאנגלית, ובהם ניסיון להחליף את המשימה או לבקש העברת מידע החוצה.
- בדקו בנפרד את איכות התשובה ואת הפעולות שהסוכן ניסה להפעיל דרך הכלים.
- הגבילו את הרשאות הכלים לצורך העסקי, ודרשו אישור אנושי לפעולות רגישות כגון שליחת מידע לנמען חדש.
- השתמשו בנתוני דמה בזמן הבדיקה, כדי שניסוי אבטחה לא יהפוך בעצמו לחשיפה של מידע עסקי.
- כללו גם מסמכים תקינים שמצטטים הוראות, כדי לבדוק שההגנה אינה חוסמת ניתוח לגיטימי.
מה הלאה: לבדוק את ההגנה מעבר לניסוי
התרומה המעניינת של Heads of Security היא הניסיון ללמד את המודל לשמור על גבול סמכות בתוך עיבוד המידע. התוצאה המדווחת מצדיקה תשומת לב מחקרית, במיוחד משום שהיא משלבת צמצום בהצלחת מתקפה עם שימור יכולות במבחנים שנבדקו. אבל השלב הבא בהערכת הגישה צריך לכלול בדיקות בלתי תלויות, מגוון תרחישי תקיפה ומשימות הקרובות לשימוש ארגוני.
למפתחים ולצוותי אבטחה בארץ, המסקנה כרגע אינה שאפשר להסיר מגבלות מסוכנים. היא שכדאי לבחון הגנות בתוך המודל לצד הרשאות, אישורים ותיעוד פעולות מחוצה לו. עד שתצטבר תמונה רחבה יותר, HoS הוא כיוון מחקרי מבטיח לצמצום הזרקת פרומפטים, לא אישור לתת למסמך חיצוני את המפתחות למערכת.
שאלות נפוצות
מהו Heads of Security ואיך הוא קשור להזרקת פרומפטים?
Heads of Security, או HoS, הוא מנגנון נלמד בתוך מערכת הקשב של מודל, שנועד להפריד בין הוראות מהימנות לבין תוכן חיצוני שעלול להכיל הוראות זדוניות. המחקר פורסם ב־27 באוקטובר 2026, והוא מציג כיוון להגנה פנימית במודל ולא חסינות מוכחת.
האם Heads of Security מונע לחלוטין מתקפות על סוכני AI?
לא. בניסוי שעליו דיווחו מחברי המחקר, שיעור ההצלחה של RL-Hammer ירד מ־97% מול GPT-OSS-20B ל־10% עם ההגנה. אלה תוצאות בתנאי הניסוי, ללא אימות עצמאי בתחקיר המצורף, ולא מדד לכל סוגי המתקפות.
איך מגינים על סוכן AI שקורא מסמכים ארגוניים?
כדאי לשלב הפרדה בין הוראות לתוכן חיצוני עם הרשאות מצומצמות לכלים ואישור אנושי לפעולות רגישות. יש לבדוק גם מסמכים המכילים הוראות זדוניות, ובמערכת ישראלית לכלול תרחישים בעברית ובשילוב עברית ואנגלית.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות