אבטחת LLM — OWASP Top 10
עשרת הסיכונים הקריטיים באפליקציות AI ואיך מתגוננים
ככל שאפליקציות מבוססות LLM נכנסות לפרודקשן, משטח התקיפה גדל. המדריך הזה עובר על OWASP Top 10 for LLM Applications (2025) — עשרת הסיכונים הקריטיים — עם הסבר, דוגמה והגנה לכל אחד.
למה אבטחת LLM שונה מאבטחה רגילה
אפליקציות מבוססות LLM מציבות משטח תקיפה חדש שאבטחת אפליקציות מסורתית לא מכסה. שלוש סיבות עיקריות: המודל לא-דטרמיניסטי (אותו קלט יכול להניב פלטים שונים), הוראות ונתונים חולקים ערוץ אחד (הכול טקסט באותו context window — ולכן קשה להפריד בין "פקודה" ל"מידע"), וסוכנים יכולים לבצע פעולות בעולם האמיתי (לקרוא מיילים, להריץ קוד, לגשת ל-API).
כדי לתת שפה משותפת לסיכונים האלה, פרויקט OWASP Gen AI Security מתחזק את OWASP Top 10 for LLM Applications — רשימת עשרת הסיכונים הקריטיים ביותר. המהדורה של 2025 היא הבסיס למדריך הזה. לכל סיכון נסביר מה הוא, דוגמה קצרה, ואיך מתגוננים.
עשרת הסיכונים במבט-על
| # | הסיכון | בקצרה |
|---|---|---|
| LLM01 | Prompt Injection | קלט עוין שמשנה את התנהגות המודל |
| LLM02 | חשיפת מידע רגיש | דליפת PII/סודות דרך הפלט |
| LLM03 | שרשרת אספקה | מודלים, דאטהסטים ותוספים מזיקים |
| LLM04 | הרעלת נתונים ומודל | זיהום נתוני אימון/RAG |
| LLM05 | טיפול לקוי בפלט | אמון עיוור בפלט → XSS/SQLi/RCE |
| LLM06 | סוכנות עודפת | יותר מדי הרשאות/אוטונומיה לסוכן |
| LLM07 | דליפת System Prompt | הסתמכות על סודיות ההנחיה |
| LLM08 | חולשות Vector/Embedding | דליפה בין-דיירים ב-RAG |
| LLM09 | מידע מוטעה | הזיות והסתמכות-יתר |
| LLM10 | צריכה בלתי-מוגבלת | Denial-of-Wallet, מיצוי משאבים |
LLM01 · Prompt Injection
הפגיעות מספר 1. תוקף מזריק הוראות — ישירות בקלט המשתמש, או בעקיפין דרך תוכן חיצוני שהמודל קורא (דף אינטרנט, PDF, מייל, תיאור כלי/MCP) — וגורם למודל לעקוף את הוראות המפתח. בסוכני AI עם גישה לכלים זו מובילה לביצוע פעולות זדוניות.
הגנה: היררכיית הנחיות, הפרדת הוראות מנתונים, הרשאות מינימום לכלים, human-in-the-loop לפעולות מסוכנות. מדריך Prompt Injection מלא ומעמיק → · קשור: Jailbreak.
LLM02 · חשיפת מידע רגיש
המודל חושף PII, סודות, מפתחות או מידע קנייני — דרך הפלט, דרך נתוני אימון שנשמרו, או דרך הקשר שדלף בין משתמשים. דוגמה: chatbot שמחזיר פרטי לקוח אחר כי המידע הגיע להקשר.
הגנה: מזעור נתונים (data minimization), סינון וסניטציה של פלט, בקרת גישה מבוססת-הקשר, ואל תכניס סודות ל-prompt.
LLM03 · שרשרת אספקה (Supply Chain)
מודלים, דאטהסטים, תוספים, adapters ו-LoRA-ים מגורמי צד-שלישי עלולים להיות מורעלים או פגיעים. מודל שהורד מריפו לא-מהימן יכול להכיל backdoor.
הגנה: אימות מקור (provenance), חתימות, "SBOM למודלים", בדיקת רכיבים לפני שילוב, ונעילת גרסאות.
LLM04 · הרעלת נתונים ומודל
תוקף מזהם נתוני אימון, fine-tuning או מקורות RAG כדי להטות את התנהגות המודל או לשתול טריגרים נסתרים. במערכות RAG, מסמך מורעל שנכנס לאינדקס יכול להשפיע על תשובות עתידיות.
הגנה: בדיקת מקורות, ניטור אנומליות, שמירה על שלמות נתונים (data integrity), והפרדת מקורות לא-מהימנים.
LLM05 · טיפול לקוי בפלט (Improper Output Handling)
אחת הטעויות הנפוצות: להתייחס לפלט המודל כמהימן. אם מזריקים פלט ישירות ל-HTML, לשאילתת SQL או ל-shell — נוצרות פרצות XSS, SQL Injection או אפילו RCE. הפלט הוא קלט לא-מהימן למערכת הבאה בשרשרת.
הגנה: קידוד/escaping לפי הקשר, ולידציה של הפלט, ואל תריץ פלט מודל ישירות ללא sandbox.
LLM06 · סוכנות עודפת (Excessive Agency)
סוכן שקיבל יותר מדי הרשאות, כלים או אוטונומיה. כשמשלבים זאת עם הזרקה עקיפה, מתקבל "confused deputy" — הסוכן משתמש בהרשאות שלו לטובת התוקף. זה הווקטור מאחורי מקרי ה-RCE של 2026 בכלי קוד אגנטיים.
הגנה: עקרון ההרשאה המינימלית, כלים מצומצמים ומוגדרים, allowlist לפעולות, ואישור אנושי לפעולות הרסניות. מדריך אבטחת סוכני AI מלא →
LLM07 · דליפת System Prompt
ה-system prompt כמעט תמיד ניתן לחילוץ (prompt leaking). הטעות היא להסתמך על סודיותו או לאחסן בו סודות/מפתחות/לוגיקת הרשאות.
הגנה: הנח שה-prompt ידלוף. אל תשים בו סודות, ואכוף הרשאות בצד השרת — לא בהנחיה.
LLM08 · חולשות Vector ו-Embedding (RAG)
במערכות RAG: היפוך embeddings לשחזור טקסט מקורי, דליפה בין-דיירים (cross-tenant) כשאין בידוד, ווקטורים מורעלים באינדקס. שאילתה של דייר אחד עלולה לשלוף מסמכים של דייר אחר.
הגנה: בידוד דיירים (tenant isolation), בקרת גישה בשלב ה-retrieval, וולידציה של תוכן שנכנס לאינדקס. קשור: מדריך RAG.
LLM09 · מידע מוטעה (Misinformation)
המודל מייצר תוכן בטוח-בעצמו אך שגוי (הזיות), ומשתמשים מסתמכים עליו בלי בדיקה. בהקשרים רגישים (רפואי, משפטי, פיננסי) זה סיכון ממשי.
הגנה: עיגון (grounding/RAG) עם ציטוט מקורות, אימות אנושי, והצגת אי-ודאות במקום המצאה.
LLM10 · צריכה בלתי-מוגבלת (Unbounded Consumption)
מתקפות שמנצלות את עלות ההרצה: "Denial-of-Wallet" (הצפת בקשות יקרות), מיצוי משאבים, וחילוץ מודל (model extraction) דרך כמות גדולה של שאילתות.
הגנה: rate limiting ומכסות, ניטור עלויות, הגבלת גודל קלט/פלט, וזיהוי דפוסי שימוש חריגים.
ארכיטקטורה מאובטחת ל-LLM
הגנה טובה היא הגנה לעומק — אף שכבה בודדת לא מספיקה. כך נראית זרימת בקשה מאובטחת, עם בקרות בכל גבול-אמון:
שכבות נוספות: canary tokens לזיהוי דליפות, ניהול סודות (secrets management), ומודל-שומר שני (dual-LLM) לבדיקת קלט/פלט.
Red Teaming ו-Evaluation
אבטחת LLM היא תהליך מתמשך, לא בדיקה חד-פעמית. בנו סוללת בדיקות שמכסה את כל עשרת הסיכונים, מדדו Attack Success Rate (ASR), והריצו regression אחרי כל שינוי מודל או prompt. שלבו בדיקות אוטומטיות עם סקירה אנושית, ונטרו בפרודקשן.
צ'קליסט אבטחת LLM
העמק את ההגנה
כעת שיש לך את מפת הסיכונים המלאה — צלול לשני הנושאים הקריטיים ביותר, ובנה הגנה שלמה לאפליקציות ולסוכנים שלך.