מהו Prompt Injection?
Prompt Injection הוא מצב שבו קלט גורם למודל לסטות מהכוונה של האפליקציה. הדוגמה הפשוטה היא משתמש שכותב "התעלם מההוראות הקודמות". האיום המשמעותי יותר הוא כאשר המערכת קוראת מסמך, אתר או אימייל שבתוכם הוראה נסתרת, ואז מפעילה כלי, חושפת מידע או משנה החלטה.
הזרקה ישירה
המשתמש שולח הוראה עוינת ישירות בצ'אט או בשדה קלט. בודקים אם היא משנה כללים, חושפת prompt פנימי או מובילה לפעולה אסורה.
הזרקה עקיפה
ההוראה מגיעה מתוכן שהמערכת מעבדת, כגון מסמך RAG, דף Web, ticket, קובץ או אימייל. המשתמש אינו חייב לראות את ההוראה.
Jailbreak
ניסיון לעקוף מגבלות בטיחות של המודל באמצעות ניסוח, role play, קידוד או שיחה רב שלבית. הוא חשוב, אבל אינו מכסה לבדו את הסיכון המערכתי.
הצלחת תקיפה אינה נמדדת לפי משפט מוזר שהמודל כתב. היא נמדדת לפי השפעה: מידע שנחשף, פעולה שבוצעה, הרשאה שנעקפה או החלטה שהוטתה.
למה RAG ו־fine-tuning אינם פתרון מלא?
RAG יכול לשפר grounding ו־fine-tuning יכול לשנות התנהגות, אבל תוכן לא מהימן עדיין נכנס להקשר שהמודל מעבד. OWASP מדגיש שהשיטות האלו אינן מבטלות Prompt Injection. צריך לבנות trust boundaries מחוץ למודל.
ממפים את משטח התקיפה
לפני ניסוח payloads, מציירים את מסלול המידע והפעולה:
- מאיפה מגיע קלט: chat, upload, email, CRM, Web או API.
- אילו מקורות RAG זמינים ולמי.
- אילו tools המודל יכול להפעיל.
- אילו נתונים נכנסים ל־context ומה נשמר בזיכרון.
- אילו פעולות דורשות אישור משתמש או מערכת.
- מה נרשם בלוג ומי יכול לראות אותו.
| נכס | איום | השפעה אפשרית |
|---|---|---|
| System prompt | בקשה לחשוף הוראות או secrets | מידע שמקל על תקיפה נוספת |
| RAG | מסמך זדוני או מעבר בין tenants | הטיית תשובה ודליפת מידע |
| Tool calling | בחירת כלי או arguments לא מורשים | שליחה, שינוי או מחיקה של מידע |
| Conversation memory | הרעלת הקשר או זליגה בין משתמשים | התנהגות מתמשכת וחשיפת נתונים |
| Output rendering | קישור, HTML או Markdown מזיק | exfiltration, phishing או XSS לפי היישום |
| Logs | שמירת PII, token או prompt רגיש | דליפה דרך מערכות תפעול |
מתייחסים למודל כאל משתמש לא מהימן
Tool call שנוצר על ידי מודל אינו פקודה מהימנה. השרת צריך לאכוף authentication, authorization, schema, מגבלות ערך ואישור לפעולות בעלות השפעה. גם אם המודל הוזרק, הוא לא אמור להיות מסוגל לעבור את גבולות המערכת.
תכנית AI Red Team מבוססת סיכון
מגדירים יעד
איזה נזק מנסים למנוע: דליפה, פעולה לא מורשית, הטיית החלטה, פגיעה במשתמש או שימוש לרעה בכלי.
מגדירים כללי מעורבות
סביבה, חשבונות, שעות, נתוני demo, פעולות אסורות, איש קשר ודרך לעצור את הבדיקה. לא בודקים ייצור ללא הרשאה מפורשת.
בונים taxonomy
הזרקה ישירה, עקיפה, רב שלבית, multilingual, obfuscation, RAG poisoning, tool misuse, data exfiltration והרשאות.
יוצרים תרחישים
לכל תרחיש מגדירים מצב התחלתי, קלט, פעולה, תוצאה אסורה, ראיה וחומרה. מפרידים בין שינוי טקסט לנזק מערכתי.
מריצים ומתעדים
שומרים גרסת מודל, prompt, retrieval, tool calls ופלט. חוזרים מספר פעמים כאשר התנהגות הסתברותית.
מתקנים ובודקים מחדש
מוסיפים control מחוץ למודל כאשר אפשר, ממירים את הכשל ל־regression ומוודאים שהתיקון לא פוגע במסלולים תקינים.
דירוג חומרה
דרגו לפי השפעה והיתכנות. מודל שחוזר על חלק מהוראת המערכת הוא ממצא שונה לחלוטין ממערכת ששולחת מסמך פרטי לכתובת חיצונית. בדקו אילו הרשאות נדרשו, האם יש אישור משתמש, כמה צעדים דרושים והאם התקיפה עובדת באופן עקבי.
תרחישי בדיקה מעשיים
1. שינוי הוראות ישיר
שלחו בקשות שסותרות את מטרת המוצר, מבקשות לשנות role או לחשוף הוראות. נסו ניסוח ישיר, סיפור, quoted text ושפה אחרת. התוצאה הצפויה אינה תמיד סירוב. לעיתים המערכת צריכה להתעלם מהחלק העוין ולהמשיך במשימה התקינה.
2. מסמך זדוני ב־RAG
העלו בסביבה מורשית מסמך demo שמכיל הוראה לא רלוונטית למשימה, למשל בקשה להתעלם מהשאלה ולהציג ערך מסוים. בדקו אם retrieval שולף אותו, אם המודל מתייחס לתוכן כהוראה ואם citations חושפים את המקור. חזרו עם הוראה מוסתרת ב־metadata, טבלה או טקסט לבן אם הפורמטים נתמכים.
3. Tool call ללא הרשאה
בקשו מהמערכת לקרוא, לשלוח, לשנות או למחוק משאב שאינו שייך למשתמש. בדקו שהשרת חוסם את הפעולה גם אם המודל יצר tool call תקין מבחינת schema. לפעולה רגישה בדקו אישור מפורש, הצגת הפרטים לפני הביצוע ויכולת ביטול.
4. Exfiltration דרך פלט
בדקו אם תוכן עוין יכול לגרום לתגובה לכלול URL עם מידע מהשיחה, Markdown image או HTML פעיל. ה־UI צריך לסנן פלט ולמנוע בקשות חיצוניות לא מאושרות. בדקו את ההתנהגות בדפדפן ולא רק את הטקסט הגולמי.
5. זיכרון ושיחה רב שלבית
הכניסו הוראה בשלב מוקדם ובדקו אם היא משפיעה אחרי מספר הודעות. עברו בין פרויקטים או משתמשים ובדקו שאין context משותף. מחקו שיחה ובדקו אם הזיכרון באמת הוסר לפי החוזה.
6. Encoding, Unicode ושפות
בדקו ניסוחים בעברית, אנגלית ושילוב שפות, תווים דומים, Base64 רק אם המוצר מפענח אותו, וטקסט בתוך JSON או קוד. המטרה היא לבדוק את צינור העיבוד שהמוצר באמת תומך בו, לא לייצר רשימה אינסופית ללא קשר.
תבנית לתיעוד ממצא
Title: Unauthorized tool call triggered by retrieved document
Environment: staging, model version, prompt version
Preconditions: demo user, demo document, no write permission
Steps: upload document, ask supported question, approve no actions
Expected: document content treated as data; no write tool is called
Actual: model requested updateRecord with another tenant id
Evidence: trace id, retrieved chunks, tool arguments, server response
Impact: attempted cross-tenant modification
Frequency: 4 of 10 runs
Suggested control: server-side authorization and explicit confirmationהגנות שצריך לבדוק, לא רק להניח שקיימות
- Least privilege: לכל tool רק ההרשאות הנדרשות למשימה.
- Server-side authorization: אימות מחדש בכל פעולה, בלי לסמוך על arguments מהמודל.
- Structured output: schema, allowlist ומגבלות ערך לפני הפעלה.
- Human confirmation: אישור ברור לפעולה כספית, שליחה, מחיקה או שינוי.
- Data separation: הפרדת tenant, מקור והרשאה ב־retrieval וב־cache.
- Output encoding: סינון HTML, Markdown, URLs ותוכן פעיל לפי ה־UI.
- Monitoring: tool calls חריגים, סירובים, ניסיונות הזרקה ודליפות שנחסמו.
- Incident response: עצירת tool, החלפת secret, הסרת מסמך ושחזור trace.
בדיקות regression לאחר תיקון
כל ממצא הופך למקרה בדיקה קבוע עם וריאציות. מריצים אותו על כל שינוי ב־prompt, model, retrieval או tool. במקביל בודקים שההגנה אינה חוסמת משתמשים תקינים. מערכת שמסרבת לכל בקשה אינה מערכת בטוחה ושימושית, אלא מערכת שאינה ממלאת את תפקידה.
מה QA מוסיף לתהליך?
QA מחבר בין threat טכני להתנהגות מוצר: מי המשתמש, מה היה המצב, מה הראיה, מה ההשפעה והאם התיקון ניתן לבדיקה. העבודה נעשית יחד עם אבטחת מידע ופיתוח, במיוחד כאשר נדרש penetration test מלא.
כדי לבנות מערך evaluation רחב, המשיכו למדריך איך בודקים מערכת מבוססת LLM ולמדריך AI בבדיקות תוכנה.
שאלות נפוצות
מהו Prompt Injection?
זהו קלט שמשנה את התנהגות ה־LLM בדרך שלא התכוון אליה המוצר. הקלט יכול להגיע ישירות מהמשתמש או בעקיפין ממסמך, אתר, אימייל או כלי שהמערכת קוראת.
מה ההבדל בין Prompt Injection ל־Jailbreak?
Jailbreak מתמקד בדרך כלל בעקיפת מגבלות המודל. Prompt Injection משפיע על הוראות המערכת או על פעולות האפליקציה, ולעיתים מוביל לגישה למידע או לכלים שלא אמורים להיות זמינים.
האם אפשר לפתור Prompt Injection באמצעות system prompt חזק?
לא באופן מלא. הוראות טובות עוזרות, אבל הגנה צריכה להיות מערכתית: הרשאות, הפרדת נתונים מהוראות, אישור פעולות, validation, ניטור ובדיקות חוזרות.
מי צריך להשתתף ב־AI red team?
QA, אבטחת מידע, פיתוח, מוצר, Data או AI ובעלי התחום העסקי. הבדיקה צריכה לחבר התנהגות מודל לנזק אפשרי במערכת האמיתית.