בקצרה
הגנה מהזרקת הוראות דורשת יותר מהנחיה למודל. מפרידים מקורות והוראות, מצמצמים כלים, אוכפים הרשאות מחוץ למודל ובודקים ראיות לביצוע. גם מודל משופר אינו מבטל את הצורך בגבולות האלה.
סוכן AI מקבל משימה לגיטימית: לקרוא מסמך ולסכם את התנאים החשובים. המסמך הוא מקור מידע. הוא אינו המנהל של הסוכן, אינו המשתמש שביקש את העבודה ואינו רשאי לשנות את ההרשאות.
ההפרדה הזאת ברורה לבני אדם על הנייר. במערכות שפה היא עלולה להיטשטש, משום שהמשימה, ההסברים והמסמך מגיעים כולם אל מודל שמפרש שפה. Prompt Injection מתחיל כשהמערכת נותנת לתוכן שהיא אמורה לנתח מעמד של הוראה שהיא אמורה לבצע.
זאת אינה רק בעיה של תשובה מוזרה בצ׳אט. ברגע שהמודל מחובר לקבצים, למערכות עסקיות ולכלי פעולה, בלבול בין מידע לסמכות עלול להשפיע על העולם שמחוץ לשיחה.
הבעיה אינה מילה מסוימת, אלא גבול שנחצה
OWASP מגדיר Prompt Injection כסיכון שבו קלט משנה את התנהגות המודל בדרך שלא התכוון אליה יוצר המערכת. ההבחנה החשובה היא בין קלט ישיר של משתמש לבין תוכן שמגיע בעקיפין, למשל מאתר, מקובץ או מתוצאת כלי.
במקרה העקיף, האדם שביקש את העבודה יכול להיות משתמש מורשה לחלוטין. הבעיה נמצאת בחומר שהמערכת קוראת בדרכה לבצע את המשימה. לכן אימות זהות המשתמש לבדו אינו מספיק.
גם מאגר פנים־ארגוני אינו מקור סמכות אחיד. מסמך מדיניות שאושר, טיוטה של עובד והערה שהגיעה מלקוח יכולים להישמר באותה מערכת. מיקום האחסון אינו הופך כל משפט בכל אחד מהם להוראה תקפה.
מקור יכול להיות אמין לתיאור עובדה מסוימת בלי להיות מוסמך להורות על פעולה. חשבונית יכולה להעיד על סכום שנדרש לתשלום. היא אינה מעניקה לסוכן הרשאה לשלם אותו.
למה סוכנים מגדילים את משמעות הטעות
במערכת שעונה בלבד, השפעה על המודל עלולה לעוות את התשובה. במערכת שפועלת, אותה השפעה עשויה להפנות פעולה לכלי או לרשומה הלא נכונים. לכן הסיכון תלוי גם במה שהמערכת יכולה לעשות.
השאלה אינה רק ״האם המודל זיהה טקסט חשוד?״ אלא ״מה יקרה אם לא זיהה?״. אם כל כלי בודק בנפרד את זהות המשתמש, את תחום הפעולה ואת הרשומה המותרת, טעות הפרשנות נתקלת בגבול נוסף. אם הכלים מקבלים כל בקשה שהמודל מייצר, אותו גבול חסר.
זהו ההבדל בין הגנה שמבקשת מהמודל להתנהג נכון לבין הגנה שמצמצמת את ההשלכות גם כשהוא טועה. במאמר על אבטחת סוכני AI הגבול הזה נבחן דרך זהויות, הרשאות ואישור פעולות.
חשוב גם להבחין בין הצעה לפעולה, ניסיון לבצע אותה ופעולה שהושלמה. בדיקה שמסתיימת בכך שהמודל כתב תשובה לא רצויה אינה זהה לבדיקה שבה שירות חיצוני קיבל שינוי. דוח אבטחה צריך לציין באיזו שכבה אירע הכשל.
למה ״תתעלם מהוראות במסמכים״ אינו פתרון מלא
הוראת מערכת ברורה היא שכבה מועילה. היא מגדירה את תפקיד הסוכן ומסבירה כיצד להתייחס למקורות. אבל היא עדיין ניתנת למודל שמבצע פרשנות, ולא למנגנון הרשאות חיצוני שמחליט אילו פעולות אפשריות.
סינון תוכן יכול להוסיף הגנה, אך גם לו יש מגבלות. הוא עלול לפספס תוכן בעייתי או לחסום מסמך לגיטימי שעוסק בעצמו בהוראות. המטרה אינה לאסור כל מסמך שכולל ציווי; מדריך הפעלה תקין מלא במשפטים כאלה.
Anthropic תיארה במחקר על סוכני דפדפן שילוב של אימון המודל, מסווגים ובדיקות אנושיות. לצד שיפור במדידות שלה, החברה הדגישה שהבעיה לא נפתרה. מדובר בראיה לצורך בהגנות שכבתיות, לא באישור שמוצר מסוים חסין.
גם RAG ו־Fine-tuning אינם מבטלים את הסיכון מעצם השימוש בהם. מאגר שליפה יכול להחזיר תוכן לא מתאים, ומודל מאומן עדיין עשוי לפרש אותו באופן שגוי. ההבדל בין שליפת ידע לאימון מודל חשוב לבחירת הארכיטקטורה, אבל אינו מחליף גבולות סמכות.
ארבע שכבות שכדאי להפריד
מקור ותפקיד
כל פריט מידע צריך להגיע עם הקשר: מאין הגיע, מתי נאסף ולמה הוא משמש. תוצאת חיפוש היא חומר לבחינה. תשובת מערכת עסקית יכולה להעיד על מצב רשומה. אף אחת מהן לא צריכה להחליף בשקט את בקשת המשתמש.
סימון מקור אינו קסם, אבל הוא מאפשר למערכת ולבודק להבין אם מסקנה נשענת על מסמך רשמי, על פרשנות או על טקסט שלא אומת.
תכנון
המודל יכול להציע כיצד להמשיך, אך התוכנית אינה הרשאה. בשלב הזה כדאי לצמצם את המידע והכלים הזמינים למה שנחוץ למשימה. סוכן שמסכם תנאי שירות אינו זקוק בהכרח לכלי שמעדכן פרטי תשלום.
אכיפה
לפני פעולה, שירות נפרד בודק את התנאים: האם המשתמש מוסמך, האם יעד הפעולה מותר, האם הפרמטרים עומדים בכללים והאם נדרש אישור. אלה בדיקות שמתבססות על מצב ומדיניות, לא על מידת הביטחון שבה המודל ניסח את הבקשה.
ראיות והתאוששות
לאחר הפעולה שומרים תוצאה שימושית: מה התבקש, מה אושר, מה בוצע ומה הוחזר. אין צורך לשמור כל מידע רגיש בכל לוג. נדרש מספיק תיעוד מוגן כדי להבין שינוי ולתקן אותו.
אישור אנושי מועיל רק אם האדם רואה את ההחלטה
מסך אישור עמום יכול להפוך לחותמת אוטומטית. אם הוא מציג רק את הסיכום של המודל, האדם עלול לאשר על בסיס אותה פרשנות שגויה שהובילה לבקשה.
אישור טוב מציג את הפעולה המדויקת, היעד, הנתונים שישתנו ומקור הבקשה. בשינוי רגיש הוא צריך להבדיל בין מה שהמשתמש ביקש לבין מה שהסוכן הסיק.
יש חשיבות גם לזמן. אישור שניתן למצב מסוים אינו בהכרח תקף אחרי שהרשומה השתנתה. אם הפרמטרים או היעד השתנו, המערכת צריכה לבדוק מחדש את תוקף האישור בהתאם למדיניות.
במערכות אוטומציה אפשר לחבר אישור לכלי מסוים ולא לכל השיחה. זו אחת ההבחנות המעשיות במאמר על n8n בעידן הסוכנים.
איך בודקים את ההגנה בלי להתבלבל מתשובה יפה
בדיקת הגנה צריכה להתחיל בהגדרת תנאים שאסור שיישברו. למשל: מסמך חיצוני אינו רשאי להרחיב הרשאות; מידע של לקוח אחד לא יוצג ללקוח אחר; פעולה שלא קיבלה אישור מתאים לא תושלם.
את הבדיקות מבצעים בסביבה מורשית ומבודדת, עם מידע סינתטי וכלי דמה. כך אפשר לבדוק אם בקשות נחסמו במקום הנכון בלי לסכן רשומות, הודעות או כספים אמיתיים.
| מה בודקים | מה נחשב ראיה טובה | מה אינו מספיק |
|---|---|---|
| הפרדת לקוחות | כללי גישה נאכפים בשירות הנתונים | הבטחה של המודל שלא לחשוף מידע |
| גבול פעולה | כלי דוחה בקשה שחורגת מהמדיניות | ניסוח זהיר בתשובת הצ׳אט |
| אישור | ביצוע קשור לפרמטרים שאושרו | לחיצה כללית על ״המשך״ |
| תיעוד | ניתן לשחזר איזו פעולה התבצעה | סיכום חופשי של הסוכן בלבד |
הטבלה אינה תוכנית תקיפה. היא דרך להגדיר מה המערכת חייבת להוכיח. מטרת הבדיקה היא לבדוק את ההגנות ואת תוצאותיהן, לא לדרג את היצירתיות של ניסוח חריג.
מדידה רצינית צריכה לכלול גם חסימות שגויות. מערכת שעוצרת כל משימה אולי נמנעת מפעולה לא רצויה, אבל אינה שימושית. השאלה היא אם אפשר להשלים עבודה תקינה תוך שמירה על הגבולות.
בדיקה חד־פעמית אינה הבטחה לשנה שלמה
החלפת מודל, שינוי תיאור כלי או הוספת מקור ידע יכולים לשנות את ההתנהגות. לכן תוצאות בדיקה מתייחסות לגרסה ולתצורה מסוימות.
כדאי לשמור אוסף בדיקות יציב ולצרף אליו מקרים שהתגלו במהלך העבודה. כאשר משנים רכיב, מריצים שוב את המקרים הרלוונטיים ובודקים גם שהעבודה התקינה עדיין מצליחה. ציון כולל אינו צריך להסתיר כשל נדיר בפעולה בעלת נזק גבוה.
גם מספר הצלחות קטן אינו מוכיח חסינות. שיעור שגיאות שנמדד בתנאים מסוימים אינו בהכרח השיעור במערכת אחרת, עם כלים אחרים ומידע אחר.
העיקרון הזה משתלב בהטמעת AI מדורגת בעסק: להגדיל את היקף הפעולה רק לאחר שיש ראיות מתאימות, ולא מפני שההדגמה הראשונה עברה.
כשמתגלה חריגה, צריך לעצור את הנתיב הנכון
תגובה לאירוע אינה מסתכמת בהוספת משפט ל־Prompt. קודם מבררים אם היה רק תוכן שגוי, ניסיון פעולה שנחסם או שינוי שהושלם. ההבדל קובע את היקף הטיפול.
במידת הצורך משביתים את הכלי או החיבור הרלוונטי, שומרים תיעוד מוגן ובודקים אילו רשומות הושפעו. אם נחשפו פרטי גישה, מטפלים בהם בהתאם. תיקון המודל או ההנחיה מגיע לצד תיקון הגבול שאפשר את ההשפעה, לא במקומו.
חשוב לא פחות לתקן דיווחים שגויים למשתמשים. אם המערכת אמרה שהשלימה פעולה שלא בוצעה, זו בעיית אמינות גם בלי אירוע אבטחה. המאמר על תשובות משכנעות מול ראיות מסביר למה סיכום של סוכן אינו תחליף לתוצאת כלי.
השורה התחתונה
Prompt Injection מחייב לחשוב מחדש על היחס בין שפה לבין סמכות. המודל צריך לקרוא מידע כדי לעזור, אבל הקריאה אינה יכולה להעניק למידע זכות לפקד.
מערכת עמידה אינה נשענת על התקווה שהמודל תמיד יזהה כוונה בעייתית. היא מגדירה מה מותר לבצע, אוכפת זאת מחוץ לפרשנות שלו ושומרת ראיות למה שקרה.
זהו שינוי בתכנון מערכת, לא רק תוספת לרשימת מילים אסורות.
שאלות נפוצות
האם מסמך פנימי נחשב בטוח אוטומטית?
לא. צריך להבחין בין מקור המידע, מי רשאי לערוך אותו והאם הוא מוסמך לקבוע הוראות. אחסון בתוך הארגון אינו מעניק סמכות לכל משפט.
האם מודל חזק יותר פותר את הבעיה?
הוא עשוי להפחית טעויות מסוימות. הוא אינו מחליף הרשאות, בדיקת כלים ותיעוד, ואין להסיק חסינות מציון במבחן יחיד.
האם חייבים לאשר כל פעולה ידנית?
לא. אפשר לאפשר פעולות מוגבלות והפיכות אוטומטית. האישור נדרש לפי ההשלכות והמדיניות, והוא צריך להיות ממוקד במקום שבו הוא מוסיף בקרה אמיתית.
מה ההבדל בין מידע שגוי להזרקת הוראות?
מידע שגוי עלול להוביל למסקנה שגויה. הזרקת הוראות מנסה לשנות את דרך הפעולה של המערכת. שני הסיכונים יכולים להופיע יחד, אך הם דורשים גם בדיקות שונות.