אבטחת LLM — OWASP Top 10 לאפליקציות AI (2025)

מדריך הגנה למפתחים

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

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

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

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

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

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

איך להשתמש במדריך: זהו מדריך-מטריה. שני הנושאים החמים ביותר — Prompt Injection ו-Jailbreak — מקבלים מדריכים מלאים ונפרדים. כאן תקבל את התמונה השלמה של כל 10 הסיכונים.

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

#	הסיכון	בקצרה
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), והפרדת מקורות לא-מהימנים.

מהשטח · בדיקות אבטחה

טעות נפוצה בהגנה על LLM: להסתמך על regex/blocklist לחסימת prompt injection. זה נותן תחושת ביטחון כוזבת — עוקפים אותו עם קידוד, ניסוח מחדש או many-shot. כשאנחנו בודקים אפליקציית LLM, אנחנו מריצים אוסף סקריפטים ב-Python (harness) שיורה עשרות וריאציות הזרקה מול ה-endpoint, בתוך סביבת ארגז-חול מבודדת — כדי לא לגעת בפרודקשן ולא לדלוף מפתחות. הממצא החוזר: הבעיה האמיתית היא כמעט תמיד ב-Output Handling — הפלט של המודל נכנס ל-eval/SQL/HTML בלי סניטציה, וזה ה-RCE/XSS.

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

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

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

① קלט משתמש → מסווג-קלט (prompt guard) + סניטציה

② הנחיה → היררכיית הוראות (system > developer > user > tool)

③ תוכן חיצוני / RAG → סימון כלא-מהימן + גבולות תוכן + בידוד דיירים

④ כלים / סוכן → הרשאות מינימום + sandbox + allowlist ל-egress

⑤ פלט המודל → מסווג-פלט/מודרציה + קידוד לפי הקשר

⑥ פעולה רגישה → אישור אנושי (HITL) + לוגים + ניטור

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

Red Teaming ו-Evaluation

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

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

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

התייחס לכל תוכן חיצוני כלא-מהימן

RAG, web, PDF, מייל, תיאורי כלים ו-MCP — כולם קלט עוין פוטנציאלי.

קדד ואמת כל פלט (LLM05)

פלט המודל = קלט לא-מהימן למערכת הבאה.

הרשאות מינימום לסוכנים (LLM06)

כלים מצומצמים + HITL לפעולות הרסניות.

בידוד דיירים ב-RAG (LLM08)

בקרת גישה בשלב ה-retrieval, לא רק בתצוגה.

אל תשים סודות ב-system prompt (LLM07)

הנח שהוא ידלוף; אכוף הרשאות בצד השרת.

Rate limits, מכסות וניטור עלות (LLM10)

מנע Denial-of-Wallet ומיצוי משאבים.

בדוק שרשרת אספקה (LLM03)

אמת מקור של מודלים, דאטהסטים ותוספים.

בדיקות אבטחה בכל שחרור

Regression על כל 10 הסיכונים + ניטור בפרודקשן.

העמק את ההגנה

כעת שיש לך את מפת הסיכונים המלאה — צלול לשני הנושאים הקריטיים ביותר, ובנה הגנה שלמה לאפליקציות ולסוכנים שלך.

↑ מרכז אבטחת AI מדריך Prompt Injection מדריך Jailbreak מדריך AI Agents

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