אבטחת LLM — OWASP Top 10
עשרת הסיכונים הקריטיים באפליקציות AI ואיך מתגוננים

למה אבטחת LLM שונה מאבטחה רגילה

אפליקציות מבוססות LLM מציבות משטח תקיפה חדש שאבטחת אפליקציות מסורתית לא מכסה. שלוש סיבות עיקריות: המודל לא-דטרמיניסטי (אותו קלט יכול להניב פלטים שונים), הוראות ונתונים חולקים ערוץ אחד (הכול טקסט באותו context window — ולכן קשה להפריד בין "פקודה" ל"מידע"), וסוכנים יכולים לבצע פעולות בעולם האמיתי (לקרוא מיילים, להריץ קוד, לגשת ל-API).

כדי לתת שפה משותפת לסיכונים האלה, פרויקט OWASP Gen AI Security מתחזק את OWASP Top 10 for LLM Applications — רשימת עשרת הסיכונים הקריטיים ביותר. המהדורה של 2025 היא הבסיס למדריך הזה. לכל סיכון נסביר מה הוא, דוגמה קצרה, ואיך מתגוננים.

עשרת הסיכונים במבט-על

לצד OWASP: טקסונומיית NIST למתקפות ML יריב

רשימת OWASP שלמעלה היא רשימת סיכונים מתועדפת לבוני אפליקציות — מה לתקן קודם. לצידה כדאי להכיר מסמך משלים ובעל אופי אחר: NIST AI 100-2e2025 — Adversarial Machine Learning: A Taxonomy and Terminology. זו לא רשימת עשרת המובילים אלא טקסונומיה ומילון מונחים של מתקפות על מערכות ML ושל אמצעי ההגנה מולן, שנועד לתת שפה משותפת לכל מי שעוסק בתחום.

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

איך להשתמש בשניהם יחד: OWASP עונה על "מה הכי דחוף לתקן באפליקציה שלי", ו-NIST AI 100-2 נותן את המונחים המדויקים לתאר את המתקפה וההגנה — שימושי בעיקר בתיעוד, בהערכת סיכונים ובתקשורת מול צוותי אבטחה. את המספור הפנימי המלא של המסמך לא אימתנו בסריקה זו ולכן הוא לא מובא כאן.

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 מלא →

עדכון אבטחה — אוקטובר 2026: שרתי MCP

Model Context Protocol (MCP) הפך לדרך המקובלת לחבר סוכן לכלים: שרת MCP מצהיר אילו כלים יש לו, והמודל בוחר מתי להפעיל אותם. זה ההמשך הטבעי של LLM06 — כל שרת שמחברים הוא עוד סט הרשאות שהסוכן מחזיק. התיעוד הרשמי של MCP פרסם מדריך אבטחה ייעודי לשרתים שרצים על המחשב שלכם (Local Server Security), ושלושה רעיונות ממנו שווים כאן הסבר.

1. תיאור של כלי הוא הוראה

כשהלקוח מתחבר לשרת, השרת שולח לו את שמות הכלים ואת התיאורים שלהם, והמודל קורא את התיאורים האלה כהוראות. לכן שרת יכול להסתיר בתיאור הנחיות שמכוונות את הסוכן — כולל לגבי השימוש בכלים של שרתים אחרים — בלי שהכלי עצמו יופעל אפילו פעם אחת. התיעוד קורא לזה tool poisoning, ו-tool shadowing כשההנחיה מכוונת לכלים של שרת אחר. ויש עוד שלב: ההגדרות לא קבועות ברגע ההתקנה. שרת יכול לשנות אותן בשקט אחרי שאישרתם אותו (מה שמכונה rug pull), ולכן אישור חד-פעמי ונעילת גרסת חבילה לא מכסים את המשטח הזה.

הגנה:

• קראו את רשימת הכלים לפני שאתם סומכים על שרת. MCP Inspector מציג כל כלי שהשרת חושף, בלי מודל בדרך. תיאור שמכיל הוראות שלא קשורות לתפקיד הכלי — סיבה להסיר את השרת.
• העדיפו לקוח שרושם את הגדרות הכלים כשאישרתם שרת, ושואל שוב כשהן משתנות. הפרוטוקול לא מחייב את זה, ולכן זו תכונה שכדאי לבחור לקוח לפיה.
• החזיקו מעט שרתים. כל השרתים חולקים את אותו הקשר של המודל, כך שכל שרת שמוסיפים מרחיב את המשטח שהאחרים חשופים אליו.

2. הרשאות לכל שרת בנפרד

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

• העבירו סודות דרך ההגדרות של כל שרת בנפרד, לא דרך הסביבה הגלובלית — כך כל שרת רואה רק את שלו.
• לכל שרת טוקן משלו, בהיקף הקטן ביותר שעובד: למשל טוקן שמוגבל לריפו אחד ולא טוקן לכל החשבון. דליפה נשארת מוגבלת וניתנת לביטול.
• גישה לקבצים: התיקייה הצרה ביותר שעובדת, ולקריאה בלבד כשזה מספיק — לעולם לא תיקיית הבית. שימו לב שתיקיות כמו ~/.ssh ו-~/.aws הן סודות על הדיסק.
• allowlist בקובץ ההגדרות הוא גבול שיתופי: שרת הגון מכבד אותו, שרת זדוני לא. האכיפה האמיתית מגיעה מבידוד — container או sandbox שבו התיקייה המותרת היא היחידה שקיימת.
• רשת: שרת שעובד רק על קבצים מקומיים לא צריך רשת בכלל. לשאר — allowlist של יעדים, כי תעבורה ליעד לא צפוי היא לרוב הסימן הראשון שמשהו השתבש. והאזנה ל-127.0.0.1 אינה אימות: אתרים בדפדפן יכולים להגיע לשירות מקומי, ולכן הוא צריך אימות אמיתי ובדיקת origin.

3. בצד השרת: לא להעביר טוקנים הלאה

למי שבונה שרת MCP שמתחבר ל-API חיצוני, מסמך Security Best Practices קובע כלל חד: שרת MCP אסור שיקבל טוקן שלא הונפק במפורש עבורו. הדפוס שנאסר נקרא token passthrough — לקבל טוקן מהלקוח ולהעביר אותו כמו שהוא ל-API שמאחור. כשהשרת לא בודק שהטוקן נועד לו (למשל דרך ה-audience claim), הוא עלול לקבל טוקן שהונפק לשירות אחר; וכשהוא גם מעביר אותו הלאה, ה-API שמאחור מניח שהבקשה נבדקה — זה ה-confused deputy מ-LLM06, ברמת הפרוטוקול. המחיר: עקיפה של בקרות שתלויות בזהות (כמו rate limiting), לוגים שמראים זהות שגויה, ושרת שהופך לפרוקסי להוצאת מידע בידי מי שגנב טוקן.

הגנה: אמתו שכל טוקן הונפק לשרת שלכם, ודחו כל טוקן אחר.

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 ומכסות, ניטור עלויות, הגבלת גודל קלט/פלט, וזיהוי דפוסי שימוש חריגים.

עדכון אבטחה — נובמבר 2026: שרשרת האספקה של ה-AI כיעד

במהלך 2026 מעבדות ה-AI הגדולות התחילו לפרסם דוחות מודיעין על ניצול לרעה של מערכותיהן. קריאה שלהם זו לצד זו מגלה דפוס עקבי: התוקפים כבר לא מכוונים רק לפלט של המודל, אלא לשרשרת האספקה של ה-AI עצמה — מפתחות API, אסימוני סשן, שירותי-עטיפה (wrappers) והמודלים עצמם.

שתי מסקנות חוזרות על פני הדוחות, ושתיהן מעשיות להגנה:

• AI הוא מגבר, לא קסם. OpenAI מדווחת שהתוקפים משלבים מודלים עם כלים רגילים (אתרים, חשבונות רשתות חברתיות) ומחליפים בין מודלים באמצע מבצע. כלומר ההגנות הקיימות עדיין רלוונטיות — ה-AI מזרז תקיפה, לא ממציא אותה מחדש.
• שרשרת האספקה מותקפת ישירות. דוח Anthropic מספטמבר 2026 מתעד פושעים שאוספים מפתחות API ואסימוני סשן גנובים ומוכרים גישה; אתרי "שירות AI" מזויפים שמפיצים גונבי-פרטים ולעיתים מתחזים לכלים אמיתיים; והזרקת פרומפט נגד שירות-עטיפה כדי לגנוב מפתחות production. ה-GTIG של Google מדווח על עלייה בתקיפות נגד נכסי AI (מודלים קנייניים ופרטי-גישה) ועל מסעות זיקוק (distillation) בקנה מידה גדול לחילוץ יכולות מודל.

הגנה:

• התייחס למפתחות ה-API ולאסימוני הסשן של ה-AI כאל סודות production: שמור בצד-שרת, סובב (rotate) באופן קבוע, הענק הרשאה מינימלית, ולעולם אל תטמין אותם בקוד צד-לקוח.
• ודא מקור: הורד CLI או תוספים של כלי AI רק מהמקור הרשמי. אתרי-התחזות לכלי AI הם וקטור הפצת תוכנה זדונית מתועד.
• הקשח שירותי-עטיפה ו-proxy (כמו LiteLLM וכדומה): התייחס לקלט שלהם כלא-מהימן (הזרקת פרומפט יכולה להגיע לסודות שמאוחסנים בהם), בודד את הסודות והחל הרשאה מינימלית.
• נטר דפוסי חילוץ: נפח שאילתות חריג נגד המודל או ה-API שלך (rate limiting, מכסות וזיהוי אנומליות — כמו ב-LLM10) הוא סימן אפשרי למסע זיקוק.
• צרוך את דוחות המודיעין האלה כ-feed: הם מתארים TTPs עדכניים שאפשר למפות לבקרות שלך (למשל ל-MITRE ATT&CK).

ארכיטקטורה מאובטחת ל-LLM

הגנה טובה היא הגנה לעומק — אף שכבה בודדת לא מספיקה. כך נראית זרימת בקשה מאובטחת, עם בקרות בכל גבול-אמון:

שכבות נוספות: canary tokens לזיהוי דליפות, ניהול סודות (secrets management), ומודל-שומר שני (dual-LLM) לבדיקת קלט/פלט.

Red Teaming ו-Evaluation

אבטחת LLM היא תהליך מתמשך, לא בדיקה חד-פעמית. בנו סוללת בדיקות שמכסה את כל עשרת הסיכונים, מדדו Attack Success Rate (ASR), והריצו regression אחרי כל שינוי מודל או prompt. שלבו בדיקות אוטומטיות עם סקירה אנושית, ונטרו בפרודקשן.

צ'קליסט אבטחת LLM