מהי אבטחת LLM? כך תצמצמו את 10 סיכוני הבטיחות המובילים של OWASP

מתקפה שגורמת לבינה מלאכותית להתייחס להוראות של תוקף כאל פקודות – הזרקת פרומפטים (prompt injection) – נמצאת במקום הראשון ברשימת OWASP Top 10 ליישומי LLM בכל מהדורה מאז 2023.

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

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

גם מהדורת 2026 נפתחת באותה נימה. מוביל הפרויקט קורא לנו “להפסיק לנסות לבנות מודל שאי אפשר להטעות”, ולתכנן את המערכת שסביבו כך שמודל שהוטעה לא יוכל לפגוע בשום דבר חשוב.

אנחנו מאמצים את הגישה הזו לאורך כל 10 הסיכונים ברשימת 2026 של OWASP.

מה פירוש אבטחת LLM?

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

בתוכנה מאובטחת כראוי יש גבול ברור בין ההוראות שהתוכנה מבצעת לבין המידע שהיא מעבדת. אבל למודלי LLM אין גבול כזה.

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

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

נתקלנו באותה בעיה גם עם סוכני ה-AI שלנו. ה-CISO שלנו, קייל פולי, אמר ל-ISMG שסוכנים “עלולים לא לציית למדיניות גם אם מוסיפים אותה לפרומפט המערכת”. בגלל זה בנינו את Numbat, כלי קוד פתוח שבודק מה סוכן עומד לעשות, ויכול לחסום את הפעולה אם היא מפרה כלל אבטחה מוגדר.

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

מהן השיטות המומלצות לאבטחת LLM?

נעבור על רשימת OWASP Top 10 ליישומי LLM לשנת 2026 לפי הסדר, ממקום 1 ועד מקום 10.

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

1. בלימת הזרקת פרומפטים

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

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

PCMag משווה את אבטחת הפרומפטים לסתימת חורים באבן נקבובית. אוטמים פתח אחד, והמים מוצאים פתח אחר. “מתקפה מוצאת את דרכה פנימה; היא מתוקנת, אבל אינספור נתיבי תקיפה אחרים עדיין ממתינים לגילוי, פשוט בגלל עד כמה מערכות כמו LLM הן דינמיות.”

דוגמה: ביוני 2025 גילו חוקרים מ-Aim Security את EchoLeak, פגם שגרם ל-Microsoft 365 Copilot להדליף מידע פרטי של החברה. כשעובד שאל שאלת עבודה שגרתית, Copilot יכול היה לשלוף את הודעת הדוא״ל של התוקף, לבצע את ההוראות שהוסתרו בה ולשלוח לתוקף מידע רגיש. המתקפה עקפה את הבדיקות שנועדו לזהות הוראות זדוניות ולהסיר קישורים חשודים.

מה אפשר לעשות:

• פעלו לפי “כלל השניים” של Meta: EchoLeak נזקק ל-AI שיכול לקרוא נתוני חברה, לקרוא דוא״ל חיצוני ולשלוח מידע החוצה – והיו לו כל שלוש היכולות. הגבלה לשתיים מהיכולות האלה מונעת מהזרקת פרומפטים להשיג שליטה רבה מדי. אם המשימה דורשת את שלושתן, דרשו אישור אנושי לפני כל פעולה.
• בדקו מול תוקפים שמכירים את ההגנות שלכם: מסרו לבודקי האבטחה שלכם את הכללים והמסננים שהטמעתם, ותנו להם למצוא דרכים לעקוף אותם. במחקר אחד, תוקפים שהתאימו את עצמם להגנות הצליחו ביותר מ-90% מהמקרים מול רוב 12 ההגנות שנבדקו.

2. מניעת דליפה של מידע רגיש

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

דליפות רבות מתחילות ב“שיתוף יתר”. נניח שחברה מחברת את ה-AI שלה לכוננים ולמאגרי ידע עם הרשאות רופפות. ה-AI שולף כל מה שהוא יכול להגיע אליו, בדיוק כפי שתוכנן. אף אחד לא צריך לפרוץ פנימה, אבל אפשר להתייחס ל-LLM כאילו כבר נפרץ.

דוגמה: בינואר 2025 מצאו חוקרי Wiz מסד נתונים של DeepSeek שהיה פתוח לאינטרנט, עם יותר ממיליון רשומות יומן, כולל היסטוריית צ׳אטים ומפתחות API – שבהם תוכנות משתמשות כדי לגשת לשירותים אחרים. החוקרים לא נזקקו לשכנע את המודל לחשוף דבר.

מה אפשר לעשות:

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

3. ריסון יכולת פעולה מופרזת

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

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

דוגמה: ביולי 2025 דיווח ג׳ייסון למקין, מייסד SaaStr, שסוכן הקוד של Replit מחק את מסד הנתונים שלו, שהכיל 1,206 רשומות של מנהלים, למרות הוראות שלא לבצע שינויים. בתחילה טען הסוכן שאי אפשר לשחזר את הנתונים, אבל מאוחר יותר התברר שהשחזור אפשרי. ג׳ייסון גילה שההוראה להשאיר את מסד הנתונים בשקט לא שללה מהסוכן את היכולת למחוק אותו.

הגדלה

מקור: X

מה אפשר לעשות:

• הסירו יכולות שהמשימה לא צריכה: הגבילו גם את הכלים שסוכן מקבל וגם את מה שהכלים האלה יכולים לעשות. עוזר שמסכם הודעות דוא״ל צריך הרשאה לקרוא אותן, לא לשלוח או למחוק אותן.
• מקמו את בדיקות ההרשאות מחוץ ל-AI: בכל פעם שמתבקשת פעולה, בדקו אותה מול כללי האבטחה שלכם ודרשו שאדם יאשר אותה.

4. בדיקת מה שנכנס לשרשרת האספקה של ה-AI

מעט חברות מפתחות AI מאפס, ומספרן הולך וקטן משנה לשנה. לפי סקר The State of Generative AI in the Enterprise לשנת 2025 של Menlo Ventures, 53% מהחברות רכשו מודלי AI ב-2024, ושיעור זה עלה ל-76% ב-2025.

ברוב המקרים, חברות מורידות מודלים ממאגרים כמו Hugging Face, ממשיכות לאמן אותם על מערכי נתונים שאנשים אחרים אספו, ומחברות אליהם תוספים וחבילות קוד שנכתבו בידי זרים.

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

דוגמה: מספר מאגרי המודלים הציבוריים ב-Hugging Face גדל מ-2.43 מיליון ל-2.96 מיליון בין ינואר 2026 לאוגוסט 2026. אבל ביולי 2026, המודלים של OpenAI עקפו בקרות שנועדו למנוע מהם גישה לאינטרנט במהלך בדיקות אבטחה פנימיות, ופרצו לחלקים ממערכות Hugging Face. למעשה, אחד הסוכנים השיג 14 פרטי גישה שנחשפו בפומבי, וידא שהם עובדים ושיתף אותם עם סוכנים אחרים. בהמשך ניצלו הסוכנים פגמים שאפשרו להם להריץ קוד בשרתים של Hugging Face.

“אנחנו מציבים דרישות מחמירות יותר בנוגע ליישור (alignment) לאורך כל מחזור החיים של המודל, ויוצרים ארגזי חול מבודדים יותר, מגבילים את הגישה לאינטרנט ומהדקים עוד יותר את הבקרה על הגישה למשקולות המודלים”, נכתב בדוח של OpenAI.

מה אפשר לעשות:

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

5. הגנה מפני הרעלת נתונים ומודלים

AI מורעל לומד מנתונים פגומים. אלה יכולים להיות הדוגמאות שעליהן עבר כוונון עדין (fine-tuning), או מאגר ידע שבו הוא מחפש תשובות. המודל עדיין נראה תקין; הוא פשוט לומד את הלקחים הלא נכונים, ולפעמים הוא לומד להתנהג בצורה חריגה רק כשהוא נתקל בביטוי מפעיל מסוים.

הביטוי יחמוק מכל בדיקה שתריצו, עד שמישהו ישתמש בו.

הגדלה

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

דוגמה: באוקטובר 2025 הראו חוקרים מ-Anthropic, ממכון אבטחת ה-AI של בריטניה (UK AI Security Institute) וממכון אלן טיורינג ש250 מסמכים מורעלים יכולים ללמד מודל לייצר ג׳יבריש בכל פעם שהוא נתקל בטריגר מסוים. אותו מספר הספיק בכל ארבעת גדלי המודלים שנבדקו, אף שהגדול שבהם אומן על כמות נתונים נקיים גדולה פי יותר מ-20.

מה אפשר לעשות:

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

6. הצבת תקרה לצריכה בלתי מוגבלת

כשאין למערכות AI שום מגבלה על כמות העבודה שהן יכולות לבצע או על העלות שהן יכולות לצבור, הצריכה שלהן נחשבת “בלתי מוגבלת”. רוב שירותי ה-AI גובים תשלום לפי שימוש, כך שתוקף יכול לנפח לכם את החשבון או לבנות עותק של המודל שלכם.

OWASP מכנה את הבעיה המרכזית “אסימטריית עלויות”. בקשה קצרה וזולה יכולה להפעיל חישוב יקר בצד שלכם.

דוגמה: במאי 2024 גילה צוות חקר האיומים של Sysdig מתקפה חדשה בשם “LLMjacking”. קבוצת תוקפים כיוונה את המתקפה ל-10 שירותי LLM המתארחים בענן באמצעות פרטי גישה גנובים. הם חדרו דרך גרסה פגיעה של Laravel, ולאחר מכן בדקו מה אפשר לעשות עם פרטי הגישה ומהן המכסות, במטרה הברורה למכור את הגישה. הם גם בדקו הגדרות רישום רבות, כנראה כדי להימנע מגילוי. לפי Sysdig, בתרחיש הגרוע ביותר העלות לקורבן עלולה לעלות על 46,000 דולר ביום.

מה אפשר לעשות:

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

7. זיהוי מידע שגוי לפני נקיטת פעולה

כש-AI מייצר משהו שגוי שנשמע נכון, ומישהו – או משהו – פועל על פיו, התופעה נקראת מידע שגוי. הסיכון המרכזי הוא לא כל כך התשובה השגויה עצמה, אלא העובדה שסומכים עליה ומשתמשים בה.

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

דוגמה: ב-2025 הגישה Deloitte Australia סקירה של מערכות IT בתחום הרווחה במסגרת חוזה ממשלתי בהיקף של 440,000 דולר אוסטרלי. החוקר כריס ראדג׳ מאוניברסיטת סידני מצא הפניות למחקרים שאינם קיימים וציטוט מפוברק מפסק דין של בית משפט פדרלי. הדוח המתוקן חשף ש-Deloitte השתמשה ב-Azure OpenAI GPT-4o במתודולוגיה שלה, והחברה הסכימה להחזיר את התשלום האחרון. למרבה הצער, מדובר היה בסקירת הבטחה (assurance review).

מה אפשר לעשות:

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

8. צמצום הנזק מחשיפת הקשר נסתר

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

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

דוגמה: בפברואר 2023 הצליחו משתמשים לגרום ל-Bing Chat של Microsoft לחשוף את ההוראות הפנימיות שלו. אחד הניסיונות המוצלחים היה של מרווין פון האגן, שטען שהוא מפתח ב-OpenAI וביקש את ההוראות כדי להגדיר את המודל. Bing חשף את הכללים שמנחים את החיפושים, התשובות והתנהגות הבטיחות שלו, וגם את שמו הפנימי, Sydney. בין ההוראות שנחשפו הייתה גם הוראה לשמור את ההוראות האלה בסוד.

מה אפשר לעשות:

• הרחיקו סודות מההקשר של המודל: הניחו שכל מה שהמודל יכול לקרוא עלול להיחשף למשתמשים — אחסנו סיסמאות, מפתחות API ואסימוני גישה במערכת נפרדת לניהול סודות.
• ודאו שההרשאות נאכפות גם כשהכללים דולפים: אכפו בדיקות גישה בקוד של האפליקציה. אם כלי מסוים מוגבל למנהלי מערכת, בדקו את הרשאות החשבון של המשתמש לפני שאתם מריצים אותו.

9. אבטחו היטב את הווקטורים וההטמעות שלכם

כשבינה מלאכותית משתמשת בחיפוש וקטורי כדי למצוא תשובות במסמכי החברה שלכם, היא לא מחפשת ישירות בטקסט. המסמכים מומרים ל“הטמעות” (embeddings) — רשימות ארוכות של מספרים שמבטאות את המשמעות של כל קטע — ונשמרים במסד נתונים וקטורי. גם השאלה מומרת באותו אופן, והמערכת שולפת את הקטעים שהמספרים שלהם קרובים אליה ביותר.

OWASP מסכמת את ארבעת אופני הכשל: הרעלה גורמת למערכת לטעות, היפוך (inversion) גורם לה לדלוף, שיבוש (jamming) גורם לה לשתוק, ובקרת גישה פגומה גורמת לה למסור כל דבר לכל אחד.

המספרים אינם הפשטה בטוחה כפי שהם נראים. אפשר להמיר את ההטמעות השמורות בחזרה לטקסט, ושיטה אחת הצליחה לשחזר במדויק 92% מהקטעים הקצרים, באורך 32 טוקנים, בבדיקות שנערכו לה. לכן גם גיבוי שדלף ומכיל “הטמעות בלבד” עלול לחשוף את תוכן המסמכים.

דוגמה: במחקר שהוצג בכנס USENIX Security 2025, חוקרים הראו שמסמך אחד שנוסח בקפידה יכול למנוע מבינה מלאכותית לענות על שאלה מסוימת. הם הוסיפו אותו לאוסף המסמכים שהבינה המלאכותית חיפשה בו. כשהיא מצאה אותו, היא יכלה לומר שאין לה מספיק מידע או שמתן תשובה לא יהיה בטוח. המסמך לא היה צריך להורות לבינה המלאכותית להתעלם מהכללים שלה. תופעה זו נקראת “שיבוש אחזור” (retrieval jamming).

מה אפשר לעשות:

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

10. בדקו את הפלט של הבינה המלאכותית לפני שאתם מעבירים אותו הלאה

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

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

דוגמה: ב-2025 החוקר Johann Rehberger הראה כיצד עוזר הקוד Amp של Sourcegraph יכול להדליף תוכן של צ׳אט פשוט באמצעות הצגת תמונה. הוא השתמש בהזרקת הנחיות (prompt injection) כדי לגרום ל-Amp לכלול מידע פרטי בכתובת האינטרנט של תמונה. לאחר מכן האפליקציה טענה את התמונה באופן אוטומטי ושלחה את המידע לשרת שלו. הכשל בטיפול בפלט היה אותה בקשה אוטומטית — הטקסט שהמודל יצר הפך לחיבור לשרת חיצוני, שנשא איתו נתונים פרטיים.

מה אפשר לעשות:

• ודאו שהפלט בטוח עבור היעד שלו: בדקו את התגובות וטפלו בהן בהתאם למקום שאליו הן מגיעות. בדף אינטרנט, מנעו מהטקסט שנוצר להפוך לקוד בר-הרצה. במסד נתונים, השתמשו בשאילתות מוכנות מראש (prepared queries) ששומרות על הפרדה בין הערכים שסופקו לבין הפקודות.
• מנעו מתשובות ליצור חיבורים חיצוניים באופן אוטומטי: השביתו כברירת מחדל טעינה אוטומטית של תמונות, תצוגות מקדימות של קישורים ודפים מוטמעים בתגובות המודל. הגבילו חיבורים הכרחיים ליעדים שאושרו במפורש.

איך Perplexity מאבטחת מודלי LLM?

אנחנו מניחים שכל אחד מהסיכונים שלמעלה יתממש בסופו של דבר, ומתכננים את המערכות כך שגם כשזה יקרה, הנזק יהיה מוגבל. מנהל אבטחת המידע הראשי (CISO) שלנו, Kyle Polley, הסביר איך אנחנו עושים זאת בסדנה שנערכה לאחרונה.

• הסוכן מקבל מחשב משלו, והמחשב הזה מתחיל ריק: כלי סוכנים שמותקנים במחשב הנייד שלכם יכולים לקבל גישה לקבצים, לאפליקציות ולפרטי ההתחברות השמורים בו. Perplexity Computer פועל בדרך ההפוכה. כל משימה רצה בארגז חול מבודד משלה, וכפי ש-Polley מנסח זאת, “כברירת מחדל אין לו גישה לשום דבר.”
• הסוכן אף פעם לא רואה את הסיסמאות: פרטי ההתחברות לשירותים המחוברים מאוחסנים מחוץ לארגז החול. כשהסוכן צריך לגשת לשירות כמו GitHub, הוא שולח בקשה בלי פרטי התחברות מצורפים. שער (gateway) בודק שהיעד והבקשה תואמים את מה שהוא מצפה לו, ורק אז מוסיף את פרטי ההתחברות בדרך החוצה. הסוכן יכול להשתמש בחיבור בלי לקבל את המפתחות.
• ההרשאות שלכם נשמרות, ואפשר להדק אותן: חיבורים שנוצרים באמצעות OAuth שומרים על הרשאות הגישה שלכם בשירות המחובר. אם אתם לא יכולים לראות משהו, גם הסוכן שלכם לא יכול.
• כל דף אינטרנט נחשב לזר: בנינו את BrowseSafe עבור Comet, הדפדפן מבוסס הסוכנים שלנו, כי הכלים שבדקנו לא ענו על הצרכים שלנו בשימוש בעולם האמיתי. הדפדפן סורק דפי אינטרנט ותוכן חיצוני אחר, כולל הודעות אימייל, כדי לאתר הזרקת הנחיות. פרסמנו בקוד פתוח גם את המודל וגם את מערך הנתונים.
• אנחנו מפקחים על הסוכן ועל המכונות שהוא רץ עליהן: Numbat ממוקם בין ההחלטה של הסוכן לפעול לבין ההרצה בפועל של הכלי. Numbat מתעד פעילות של סוכני קוד נתמכים ויכול לחסום פעולות שמפרות מדיניות שהוגדרה, עוד לפני שהן מתבצעות. Bumblebee ממפה את חבילות התוכנה במחשבים ניידים, בשרתים ובצינורות בנייה (build pipelines), ומסמן חבילות זדוניות ידועות. שני הכלים זמינים בקוד פתוח.
• ספקי המודלים לא שומרים את הנתונים שלכם: יש לנו הסדרים של אפס שמירת נתונים (zero data retention) עם ספקי ה-LLM החיצוניים שלנו. מנהלי מערכת ב-Enterprise יכולים גם לקצר את תקופת שמירת הנתונים של Perplexity עצמה עד ל-24 שעות בלבד.

בנינו את Numbat באופן יזום, מסיבה ש-Polley מסכם במשפט אחד: “ככל שנותנים לסוכן יותר אוטונומיה, כך הסיכון גדול יותר.”

שאלות נפוצות על אבטחת LLM

מהו מודל ה-LLM המאובטח ביותר?

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

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

מהן פגיעויות LLM?

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

עשרת הסיכונים העיקריים הם הזרקת הנחיות, חשיפת מידע רגיש, סוכנות מופרזת (excessive agency), שרשרת האספקה, הרעלת נתונים ומודלים, צריכה בלתי מוגבלת, מידע שגוי, חשיפת הקשר נסתר, חולשות בווקטורים ובהטמעות, וטיפול לא תקין בפלט.

האם LLM פרטי בטוח?

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

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