OWASP LLM Top 10 בפרודקשן: הקשחת RAG, סוכנים, והווקטורים שרוב הצוותים מפספסים

ה-OWASP LLM Top 10 (מהדורת 2025) הוא רשימה שימושית. אבל עצם זה שמדובר ברשימה הוא חלק מהבעיה: זו לא הצורה הנכונה לעבודה שבאמת צריך לעשות. רשימות יוצרות checkboxes. הקשחת אפליקציית GenAI בפרודקשן היא לא תרגיל checkbox. היא תרגיל threat-modeling וארכיטקטורה שמשתמש ברשימה כפרומפט פתיחה במקום כיעד.

זו הקריאה התפעולית של LLM Top 10 שאנחנו משתמשים בה עם לקוחות שבונים מערכות GenAI לפרודקשן. היא ממפה כל קטגוריה לאן שהסיכון באמת מופיע בארכיטקטורות אמיתיות (RAG pipelines, סוכני AI, workflowים של fine-tuning) ואיך נראית בקרת ההנדסה המתאימה. אנחנו נוקטים עמדה ברורה לגבי אילו קטגוריות הכי חשובות ב-2026 ואילו מודגשות יתר על המידה ביחס לסיכון הממומש שלהן.

הסיכונים שבאופן עקבי נוחתים באירועי פרודקשן

בעבודת התגובה לאירועים שלנו על אפליקציות GenAI ב-18 החודשים האחרונים, שלוש מקטגוריות OWASP מהוות את הרוב המכריע של הנזק הממומש:

LLM01 Prompt Injection. זה נשאר וקטור התקיפה הדומיננטי במרווח גדול. ההתפתחות המעניינת היא ש-prompt injection ישיר (משתמש שמקליד "ignore previous instructions") מוגן היטב היום ברוב מערכות הפרודקשן. ההתקפות הממומשות הן כמעט כולן indirect prompt injection, שבהן תוכן בשליטת תוקף מגיע דרך retrieval, web fetches, העלאות קבצים, או פלטי tools. דפוס ההגנה שבאמת עובד הוא הפרדת privileges בין ה-context שהמודל קורא לבין הסמכות שלו לכתוב, לא system prompts טובים יותר.

LLM02 חשיפת מידע רגיש. בדרך כלל מופיע או כדליפת training data (נדיר ב-RAG ברמת פרודקשן) או כדליפת context בין משתמשים (הרבה יותר נפוץ). הדפוס: system prompt או context retrieved מכיל נתונים ממשתמש A, אז בקשה ממשתמש B מקבלת בטעות חלק מה-context הזה בגלל caching, שימוש חוזר ב-session, או טעויות בידוד tenants. הבקרה היא בנייה קפדנית של context לכל בקשה, וללא state משותף של מודל בין משתמשים.

LLM05 טיפול לא ראוי בפלט. המודל מייצר פלט שאז נצרך באופן לא בטוח על-ידי קוד downstream (מבוצע כ-query, מנותח כ-JSON ללא ולידציה, מוצג כ-HTML). בארכיטקטורות של agents זה הופך חמור כי tools מבצעים פלט מודל כהוראות. הבקרה היא להתייחס לפלט מודל כקלט לא מהימן, באותה דרך שתתייחסו לקלט משתמש.

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

Indirect prompt injection ב-RAG: התיקון הארכיטקטוני

למערכת RAG יש שלושה מקומות שבהם תוכן בשליטת תוקף יכול להיכנס ל-context של המודל: corpus המסמכים (אם כל משתמש יכול לתרום), web retrieval (אם המערכת מושכת תוכן חיצוני), ופלטי tools (אם tools נוגעים בנתונים בהשפעת תוקף). כל אחד מאלה הוא וקטור פוטנציאלי ל-prompt injection ללא קשר לכמה ה-system prompt זהיר.

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

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

Tools עם הפרדת privileges. המודל יכול לקרוא מכל מקום, אבל הוא לא יכול להפעיל פעולות בעלות privilege גבוה (כתיבות לבסיס נתונים, קריאות API חיצוניות, עסקאות פיננסיות, שינויי נתוני משתמש) ישירות מ-turn שכלל retrieval לא מהימן. פעולות privileged דורשות הפעלת מודל נפרדת, קטנה יותר, נעולת-הוראות שמקבלת פרמטרים מובנים שחולצו מהזרימה הראשית. תוכן תוקף עדיין יכול להשפיע על מה שהמודל אומר, הוא לא יכול להשפיע על מה שהמערכת עושה.

Schema-ים מובנים לפלט. איפה שפלט המודל מניע התנהגות downstream (בחירת tool, ארגומנטים לפעולה, יצירת query), דרשו JSON schema קפדני ודחו כל דבר שלא מנותח. ה-injection עדיין קורה, האפקט המתוכנן של ה-injection מוכל כי ערוץ הפלט המובנה לא מכבד הוראות free-form.

Context עם מעקב provenance. כל chunk של context שמגיע למודל נושא tag של provenance (system מהימן, משתמש מהימן, retrieved לא מהימן). Tools וצרכנים downstream יכולים לבדוק provenance ולסרב לפעולות בעלות trust גבוה על תוכן trust נמוך. זו האקוויוולנטית של LLM ל-taint analysis.

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

משטח הסיכון של מערכות agentic

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

נגד-מידות שאנחנו ממליצים עליהן למערכות agent בפרודקשן:

• תקציב פעולה ל-session. תקרה קשיחה למספר קריאות tool בעלות privilege גבוה ל-session של agent. Agent שפוגע בתקרה משהה את עצמו לסקירה אנושית. רוב הנזק הממומש במערכות agent הוא נפחי קריאות tool גבוהים, הגבלת הנפח היא בדיקה גסה אבל אפקטיבית.
• זיכרון session מוגבל ועם tag של provenance. ככל שזיכרון agent ארוך יותר, יותר הזרקות מבוססות-זמן הוא יכול לשאת. הגבילו זיכרון למשימה ותייגו כל ערך זיכרון עם המקור שלו.
• Schema-ים לתוצאות tools ו-trust scopes. אותו דפוס כמו RAG: tools מחזירים פלטים מובנים ונושאים tags של trust. המודל יכול לחשוב על פלט tool אבל לא יכול לבלוע פלט tool לא מהימן כהוראות.
• Rate limits פר-agent בשכבת הפעולה. לא רק בשכבת ה-API. Agent שלפתע יורה 50 קריאות tool ב-60 שניות מציג או באג או התקפה, בכל מקרה, שכבת הפעולה צריכה להשהות אותו.

מערכות agent הן המקום שבו עבודת האבטחה הכי חדשנית מתרחשת ב-2026. הקטגוריות ב-LLM Top 10 עדיין חלות, אבל האיומים הממומשים מורכבים אחרת כשהמודל פועל.

מה מודגש יתר על המידה ברשימה

שלוש קטגוריות מופיעות באופן בולט ב-LLM Top 10 אבל מייצרות נזק ממומש פחות ממה שמיקומן מציע:

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

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

LLM10 צריכה בלתי-מוגבלת. בעיה אמיתית (סחרורי עלות, denial of wallet) אבל פתורה על-ידי rate-limiting סטנדרטי והתראות תקציב בשכבת האפליקציה והתשתית. הסיכון הממומש אמיתי אבל העבודה לא חדשנית.

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

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

תחום פתרונות ה-AI של פליקן-טק בונה מערכות GenAI לפרודקשן עם הארכיטקטורות האלה מההתחלה: tools עם הפרדת privileges, פלטים עם ולידציית schema, context עם מעקב provenance, תקציבי פעולה למערכות agentic. אנחנו עובדים יחד עם צוות ניהול הסיכונים שלנו כש-threat model צריך להשתלב בתוכנית הסייבר הרחבה, ועם צוות הזהויות שלנו כשדפוס בניית ה-context לכל בקשה דורש גישת נתונים מודעת-זהות.

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