Prompt Injection היא בעיה של אבטחת מוצר, לא מגבלה של מודל

המסגור הנפוץ ביותר של prompt injection ב-2026 עדיין מתייחס אליו כאל בעיה של המודל: המודל נאיבי מדי, ה-system prompt לא חזק מספיק, ל-alignment training יש פערים. המסגור הזה מייצר את ההגנות הלא נכונות. הוא מייצר system prompts ארוכים יותר, פילטרים מורכבים יותר ל-"ignore previous instructions", classifiers של תוכן שאומנו על דוגמאות יריביות. אף אחת מההגנות האלה לא מפחיתה משמעותית את מספר המתקפות שמצליחות בפועל בפרודקשן.

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

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

למה תיקונים ברמת איכות מודל לא סוגרים את המחלקה

האינטואיציה ש"מודל חכם יותר יתנגד טוב יותר ל-prompt injection" נכונה חלקית, אבל רחוקה מלהספיק. מודלי frontier ב-2026 הרבה יותר טובים בלסרב ל-prompts יריביים ישירים מאשר מודלי 2023. שיעור ההתקפות הממומש בפרודקשן לא ירד באופן פרופורציונלי. הסיבה היא שווקטור ההתקפה התפתח.

Prompt injection ישיר (משתמש שמקליד הוראות יריביות) מוגן היטב היום ברוב מערכות הפרודקשן. ההתקפות הממומשות הן indirect: תוכן יריבי מגיע דרך מסמכים שאוחזרו, דפי web שה-agent משך, קבצים שהמשתמש העלה, פלטי tool משירותים חיצוניים, או ערכי זיכרון מ-turns קודמים. עד שהמודל רואה את ה-injection, הוא משולב עם תוכן לגיטימי ממקור שנראה מהימן.

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

זו בדיוק הסיבה המבנית ש-SQL injection קלאסי לא נפתר על-ידי "parsers חכמים יותר". הוא נפתר על-ידי parameterised queries, שמפרידים את נתיב הנתונים מנתיב הבקרה ברמת האפליקציה. אותה הפרדה היא מה שסוגר prompt injection.

הדפוס: להפריד את ה-read context מסמכות הכתיבה

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

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

1. שכבת השיחה. איפה שהמודל קורא מכל מקור — המשתמש, מסמכים שאוחזרו, פלטי tool, זיכרון — ומייצר טקסט או פלט מובנה. לשכבה הזו אין privileges ישירים. היא לא יכולה לכתוב לבסיס הנתונים, לקרוא ל-APIs חיצוניים שמשנים state, או להפעיל פעולות הנראות למשתמש.

2. ה-Schema של פלט מובנה. איפה שהמודל מבטא מה הוא רוצה שייעשה, אבל בצורה מוגבלת: JSON שתואם ל-schema מוגדר מראש, ארגומנטי function-call שתואמים לחתימה, שמות commands ממערכת ידועה. טקסט free-form בשכבה הזו נדחה, לא מנותח בסלחנות.

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

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

כשבונים עם ארבע השכבות האלה, prompt injection נהיה ממוקד. ההוראה שהוזרקה יכולה לשנות מה שהמודל אומר (מעצבן, לפעמים מביך) אבל היא לא יכולה לשנות מה שהמערכת עושה, כי פעולות המערכת עוברות דרך שכבות 2–4 שלא מכבדות הוראות free-form בשפה טבעית.

איפה צוותים שוברים את הדפוס הזה בטעות

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

הגדרות tool שמקבלות טקסט free-form. Tool שלוקח פרמטר query יחיד של טקסט בלתי-מוגבל הוא פשוט back-door מהמודל לבסיס הנתונים. Tools צריכים לקבל ארגומנטים מובנים שמתאימים ל-schema, לא bag-of-text.

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

ערכי זיכרון מטופלים כמהימנים. מאגר זיכרון שלוכד תוכן שרירותי מ-turns קודמים ומזריק אותו מחדש ב-turns מאוחרים יותר הוא שכבת התמדה מושלמת ל-injection. ערכי זיכרון צריכים להיות מתויגים עם provenance וערכים לא מהימנים לא צריכים להיות זכאים להשפיע על פעולות privileged.

Caching בין משתמשים. מפתח cache שלא כולל זהות משתמש, או session שדולף context, מאפשר ל-injection של משתמש אחד לנחות ב-session של משתמש אחר. זה אותו נושא "blast radius" כמו בארכיטקטורת ענן: דפוס הכישלון הוא גורל משותף.

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

שכבת הזיהוי שגם צריכה להתקיים

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

• Anomaly detection על הפלטים המובנים של המודל. בקשות פתאומיות לפעולות privileged, צורות ארגומנטים יוצאות דופן, כשלים חוזרים בשער הוולידציה מ-session יחיד, הם סיגנלי זיהוי.
• מדדי קצב פעולה ל-session ולמקור נתונים. Session שלפתע מתחיל להפעיל 30 פעולות בדקה כש-session בסיסי מפעיל 2, מציג או באג או הצלחת injection.
• לוגינג מודע-provenance. כל פעולה מתועדת עם תגיות trust של הקלטים שהובילו אליה. שחזור post-incident תלוי בטלמטריה הזו, הדפוס הישן של "תיעדנו את ה-prompt ואת התשובה" גס מדי לחקור.

הזיהויים האלה מזינים את פרקטיקת ה-SIEM/SOAR שכיסינו קודם. מערכות GenAI הן עכשיו חלק ממשטח הזיהוי.

איפה אנחנו נכנסים

תחום פתרונות ה-AI של פליקן-טק בונה מערכות GenAI לפרודקשן עם הארכיטקטורה הארבע-שכבתית למעלה כברירת מחדל, לא כמחשבה מאוחרת. אנחנו עובדים יחד עם צוות ניהול הסיכונים שלנו כש-threat model של GenAI צריך להשתלב בתוכנית הסייבר הרחבה, ועם המומחים שלנו ל-SIEM/SOAR להביא את שכבת הזיהוי ל-SOC הקיים.

אם אפליקציית ה-GenAI שלכם בפרודקשן והארכיטקטורה עוד לא כוללת את הפרדת ה-privilege של read/write, זה ה-engagement שצריך להתחיל איתו לפני שתיתקלו בגרסה הממומשת של מחלקת ההתקפה הזו.