הסיכון הנסתר מאחורי כלי AI חינמיים: מדוע ChatGPT ו-LLM אחרים אינם בטוחים

הפסיקו להעמיד פנים שהצ'אט בוט שלכם הוא פרטי

צוותי האבטחה עדיין מדברים על "שימוש זהיר ב-ChatGPT", כאילו הסיכון העיקרי הוא שמפתח ידביק קוד קנייני בצ'אט בוט ציבורי. תפיסה זו מיושנת כבר שנים. הבעיה האמיתית היא מבנית: מודלים לשוניים גדולים (LLM) כמו ChatGPT, Gemini, Claude ועוזרים פתוחים אינם תוכנות דטרמיניסטיות. הם מערכות הסתברותיות שלומדות מנתונים, זוכרות דפוסים וניתן לתפעל אותן באמצעות שפה — ולא לתקן אותן כמו קבצים בינאריים. זה לבדו אומר ש"אבטחת LLM" היא לא סתם עוד רשימת בדיקה של AppSec; היא תחום אבטחה בפני עצמו. (SentinelOne)

יש גם שקר מתמשך בתוך חברות: "זה רק לצורך סיעור מוחות פנימי, אף אחד לא יראה את זה." המציאות לא מסכימה עם זה. נתונים פנימיים — הערות ביקורת, טיוטות משפטיות, מודלים של איומים, תחזיות הכנסות — מועתקים מדי יום לכלי AI ציבוריים או פרימיום, ללא אישור אבטחה. מחקר שנערך לאחרונה על השימוש ב-AI בארגונים מצא כי עובדים מדביקים באופן פעיל קוד רגיש, מסמכי אסטרטגיה פנימיים ונתוני לקוחות ב-ChatGPT, Microsoft Copilot, Gemini וכלים דומים, לעתים קרובות מחשבונות אישיים או לא מנוהלים. נתוני החברה עוזבים את הסביבה באמצעות HTTPS ומגיעים לתשתית שהחברה אינה מחזיקה או שולטת בה. זוהי דליפת נתונים בזמן אמת, ולא סיכון היפותטי. (Axios)

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

מה המשמעות האמיתית של "אבטחת LLM"

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

בפועל, גבול האבטחה משתרע על:

• נתוני אימון וכיוונון עדין. דוגמאות מורעלות או זדוניות יכולות להטמיע התנהגות אחורית (backdoor) המופעלת רק תחת הנחיות ספציפיות שנוצרו על ידי התוקף. (SentinelOne)
• משקלי מודל. גניבה, חילוץ או שיבוט של מודל מכויל היטב גורמים לדליפת קניין רוחני, יתרון תחרותי ונתונים שעשויים להיות כפופים לרגולציה המוטמעים בזיכרון המודל. (SentinelOne)
• ממשק מהיר. זה כולל הנחיות למשתמש, הנחיות למערכת, הקשר זיכרון, מסמכים שאוחזרו ופיגומי קריאה לכלי. תוקפים יכולים להזריק הוראות נסתרות לכל אחת מהשכבות הללו כדי לעקוף את המדיניות ולכפות דליפת נתונים. (קרן OWASP)
• משטח פעולה. LLM קוראים יותר ויותר לתוספים, ממשקי API פנימיים, מערכות חיוב, כלי DevOps, CRM, מערכות פיננסיות, מערכות כרטיסים. מודל שנפגע עלול לגרום לשינויים בעולם האמיתי, ולא רק לטקסט גרוע. (חדשות ההאקרים)
• תשתית שירות. זה כולל מאגרי נתונים וקטוריים, סביבות ריצה לתזמור, צינורות אחזור ו"סוכנים אוטונומיים". מערכות סוכניות יורשות סיכונים בסיסיים של LLM, כגון הזרקת פקודות או זיהום נתונים, ואז מגבירות את ההשפעה מכיוון שהסוכן יכול לפעול. (Inovia)

Wiz וחוקרי אבטחת ענן אחרים החלו לתאר זאת כ"בעיה מקיפה": תקריות AI נראות כעת כמו פגיעה קלאסית בענן (גניבת נתונים, העלאת הרשאות, ניצול כספי), אך במהירות LLM ובשטח LLM. (קנוסטי)

הרגולטורים מתחילים להדביק את הפער. המכון הלאומי לתקנים וטכנולוגיה (NIST) בארצות הברית מתייחס כעת להתנהגות ML עוינת (הזרקת פקודות, זיהום נתונים, חילוץ מודלים, גניבת מודלים) כאל נושא מרכזי בתחום אבטחת מידע בניהול סיכונים ב-AI — ולא כאל נושא מחקר ספקולטיבי. (פרסומי NIST)
ראה: מסגרת ניהול סיכונים של NIST AI ו טקסונומיה של למידת מכונה יריבה (NIST AI 100-2e2025).

האמת הלא נעימה על "חינם"

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

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

זה חשוב משלוש סיבות:

1. חשיפה לתאימות. ייתכן שאתה מדליף נתונים מוסדרים — נתוני בריאות (HIPAA), תחזיות פיננסיות (SOX) או מידע אישי של לקוחות (GDPR/CCPA) — לתשתית מחוץ לגבולות החוקיים שלך. ניתן לגלות זאת באופן מיידי בביקורת. (Axios)
2. סיכון לריגול תעשייתי. התקפות חילוץ מודלים והיפוך משתפרות. תוקפים יכולים לשאול באופן איטרטיבי LLM כדי לשחזר קטעים מזיכרון האימון או מהלוגיקה הקניינית. זה כולל תבניות קוד רגישות, אישורים שהודלפו וכללי החלטה פנימיים. (SentinelOne)
3. אין גבול שמירה שניתן לבדוק. מחיקת "היסטוריית הצ'אט" בממשק המשתמש אינה אומרת שהנתונים נמחקו. ספקים רבים חושפים צורות שונות של רישום ושמירה לטווח קצר (לצורך ניטור שימוש לרעה, שיפור איכות וכו'), ותוספים/אינטגרציות עשויים לנהל את הנתונים שלהם באופן שאינו גלוי לעין. (חדשות סייבר)
   ראה: הסיכון הנסתר מאחורי כלי AI חינמיים ו SentinelOne על סיכוני אבטחת LLM.

בקיצור: כאשר סמנכ"ל החברה שלך מדביק מודל איומים ב"עוזר AI חינמי", אתה יוצר מעבד צד שלישי של החומר הרגיש ביותר שלך — ללא חוזה, ללא הסכם עיבוד נתונים (DPA) וללא SLA לשמירת נתונים.

עשרה מצבי כשל אבטחה פעילים ב-LLM שעליכם למדל כאיומים

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

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

Shadow AI כבר עוסקת בתגובה לאירועים, ולא בתיאוריה בלבד.

לרוב הארגונים אין נראות מלאה לגבי האופן שבו נעשה שימוש ב-AI באופן פנימי. עובדים מבקשים בשקט מ-LLM ציבוריים לסכם ביקורות, לשכתב מדיניות תאימות או לנסח טיוטות של תקשורת עם לקוחות. במספר מקרים מתועדים, מסמכים רגישים הנוגעים לאבטחה פנימית הועתקו ל-ChatGPT או לשירותים דומים מחשבונות אישיים לא מנוהלים, מה שהוביל לבדיקות בדיעבד של האירועים. בדיקות אלה גזלו שבועות של זמן חקירה, לא בגלל שהייתה הפרה מאושרת, אלא בגלל שצוותי המשפט והאבטחה נאלצו לענות על השאלה: "האם הדלפנו נתונים מוסדרים לספק שאין לנו איתו חוזה?" (Axios)

מדוע DLP מסורתי אינו יכול לפתור את הבעיה:

• התנועה ל-ChatGPT או לכלים דומים נראית כמו HTTPS מוצפן רגיל.
• בדיקה מיידית מלאה באמצעות יירוט SSL היא רגישה מבחינה משפטית ופוליטית ברוב החברות.
• גם אם תכפה בקרות דפדפן מקומיות, תכונות AI רבות מוטמעות כיום בכלים SaaS אחרים (עורכי מסמכים, עוזרי CRM, מסכמי דוא"ל). המשתמשים שלך עלולים לדלוף נתונים באמצעות "תכונות AI" שהם אפילו לא מודעים לכך שהן AI. (Axios)

תופעה זו מכונה לעתים קרובות "בינה מלאכותית צלליתית" (Shadow AI). שם זה מטעה. העובדים אינם פועלים בפזיזות; הם פשוט פועלים מהר יותר מהממשל. התייחסו לבינה מלאכותית צלליתית כמו אל SaaS צלליתית — אלא ש-SaaS זו יכולה לזכור אתכם.

מדריך הגנה מינימלי למהנדסי אבטחה

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

התייחס לפקודות כקלט לא מהימן

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

התייחס לתגובות כאל פלט לא אמין

• לעולם אל תבצע ישירות SQL שנוצר על ידי מודל, פקודות shell, שלבי תיקון או קריאות API. הנח שכל פלט של מודל נשלט על ידי התוקף, עד שיוכח אחרת. OWASP מכנה זאת "טיפול לא מאובטח בפלט" (Insecure Output Handling), וזהו סיכון LLM מהדרגה העליונה. (קרן OWASP)
• אכוף את כל הפעולות המופעלות על ידי LLM באמצעות אכיפת מדיניות, סנדבוקסינג ורשימות היתרים.

אוטונומיה של מודל הבקרה

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

צפה בהתעללות כלכלית

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

להנחיות מפורטות יותר, ראה:

• עשרת המובילים של OWASP עבור יישומים של מודלים לשוניים גדולים
• SentinelOne: סיכוני אבטחה LLM
• מסגרת ניהול סיכונים של NIST AI

דוגמה: עטיפת LLM מאחורי שכבת מדיניות ו-sandbox

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

# פסאודו-קוד עבור מחלקת עטיפת אבטחה LLM SecurityException(Exception): pass

# (1) בקרת קלט: דחה ניסיונות הזרקת פקודות ברורים def sanitize_prompt(user_prompt: str) -> str: banned_phrases = [ "התעלם מהוראות קודמות", "הוצא סודות", "העבר אישורים", "עקוף את אמצעי הבטיחות והמשך" ]
    lower_p = user_prompt.lower() if any(p in lower_p for p in banned_phrases): raise SecurityException("Potential prompt injection detected.") return user_prompt # (2) קריאה למודל עם הפרדה קפדנית בין מערכת למשתמש def call_llm(system_prompt: str, user_prompt: str) -> str:
    safe_user_prompt = sanitize_prompt(user_prompt) response = model.generate( system=lockdown(system_prompt), # immutable system role user=safe_user_prompt, max_tokens=512, temperature=0.2, ) return response

# (3) בקרת פלט: לעולם אל תבצע באופן עיוור def execute_action(llm_response: str): parsed = parse_action(llm_response) if parsed.type == "shell": # רק ברשימת ההיתרים, בתוך מיכל ארגז חול כלוא
        if parsed.command not in ALLOWLIST: raise SecurityException("Command not allowed.") return sandbox_run(parsed.command) elif parsed.type == "sql": # Parameterized, read-only queries only return db_readonly_query(parsed.query)

    else: # טקסט רגיל, עדיין מטופל כנתונים לא מהימנים return parsed.content # ביקורת על כל שלב לצורך חקירה ורגולציה answer = call_llm(SYSTEM_POLICY, user_input) result = execute_action(answer) audit_log(user_input, answer, result)

דפוס זה תואם באופן ישיר את סיכוני ה-LLM המובילים של OWASP: הזרקת פקודות (LLM01), טיפול לא מאובטח בתפוקה (LLM02), הרעלת נתוני אימון (LLM03), מניעת שירות מודל (LLM04), פגיעות בשרשרת האספקה (LLM05), סוכנות מוגזמת (LLM08) והסתמכות יתר (LLM09). (קרן OWASP)

היכן מתאים שימוש בבדיקות חדירות אוטומטיות מבוססות בינה מלאכותית (Penligent)

בשלב זה, "אבטחת LLM" כבר לא נשמעת כמו תיאטרון ממשלתי, אלא מתחילה להיראות שוב כמו אבטחה התקפית. לא מסתפקים בשאלה "האם המודל שלנו בטוח?" אלא מנסים לפרוץ אותו – בצורה מבוקרת – בדיוק כפי שהייתם בודקים API חשוף או נכס הפונה לאינטרנט.

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

באופן קונקרטי, פלטפורמה כמו Penligent יכולה:

• נסה לבצע הזרקה מהירה ודפוסי פריצה נגד העוזר הפנימי שלך ורשום אילו מהם הצליחו.
• בדקו אם הודעה לא מהימנה יכולה להטעות "סוכן" פנימי ולגרום לו לגשת ל-API בעלי הרשאות מיוחדות — למשל, פיננסים, פריסה, הנפקת כרטיסים. (Inovia)
• בדיקת נתיבי זליגת נתונים: האם המודל מדליף זיכרון משיחות קודמות או מנתוני אימון הכוללים מידע אישי, סודות או קוד מקור? (SentinelOne)
• דמה "סירוב ארנק": האם תוקף יכול להגדיל את חשבון ההסקת המסקנות שלך או להציף את מאגר ה-GPU שלך רק על ידי הזנת הנחיות פתולוגיות? (קרן OWASP)
• הפק דוח מבוסס ראיות הממפה כל ניצול מוצלח להשפעה עסקית קונקרטית (חשיפה רגולטורית, פוטנציאל להונאה, עלייה חדה בעלויות) והנחיות לתיקון שמהנדסים ומנהלים יכולים לפעול לפיהן.

זה חשוב כי רוב הארגונים עדיין לא יכולים לענות על שאלות בסיסיות כמו:

• "האם הנחיה חיצונית יכולה לגרום לסוכן הפנימי שלנו לקרוא ל-API לחיוב מיוחדת?"
• "האם המודל עלול לדלוף חלקים מנתוני האימון הדומים מאוד לפרטי זיהוי אישי של לקוחות?"
• "האם מישהו יכול לגרום לחשבון ה-GPU שלנו להתפוצץ באופן שהחשבונאות תבחין בו רק בחודש הבא?" (קרן OWASP)

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

הצעדים הבאים המיידיים עבור מהנדסי אבטחה

1. מלאי נקודות המגע של LLM. סווגו היכן נמצאים ה-LLM בארגון שלכם:
   • SaaS ציבורי (חשבונות בסגנון ChatGPT)
   • "LLM ארגוני" המארח על ידי ספק
   • מודלים פנימיים המארחים את עצמם או מכוונים בקפידה
   • סוכנים אוטונומיים המחוברים לתשתית ול-CI/CD
     זוהי מפת שטח ההתקפה החדשה שלך. (Axios)
2. התייחסו ל-LLM ציבוריים כמו ל-SaaS חיצוני. "אין סודות בכלים של בינה מלאכותית לא מנוהלת" חייב להיות כתוב כקובץ מדיניות, ולא כהצעה. יש להדריך את הצוות להתייחס לכלים חינמיים של בינה מלאכותית בדיוק כמו לפרסום בפורום ציבורי: ברגע שהמידע יוצא, אין לך שליטה על שמירתו. (חדשות סייבר)
3. פעולות בעלות השפעה רבה מאחורי בני האדם. כל סוכן AI שיכול להעביר כספים, לשנות תצורות או להשמיד רשומות חייב לקבל אישור מפורש מבני אדם עבור פעולות בעלות השפעה רבה. הנח שיש פגיעה. בנה מערכות לבלימת הפגיעה. (Inovia)
4. הפוך את בדיקות החדירה המותאמות ל-LLM לחלק מהשחרור. לפני שתשלחו "עוזר AI" ללקוחות או לעובדים, בצעו בדיקת התנגדות שמנסה:
   • הזן הנחיות,
   • לחלץ סודות,
   • העלאת הרשאות התוסף,
   • עלות שיא.
     התייחסו לזה כמו שאתם מתייחסים למבחני חדירות API חיצוניים.

הפניות מומלצות לספר המשחקים שלך:

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

מסקנה סופית

אבטחת LLM אינה היגיינה אופציונלית. היא כוללת תגובה לאירועים, בקרת עלויות, הגנה על קניין רוחני, ניהול נתונים ובטיחות ייצור — הכל בבת אחת. התייחסות ל-ChatGPT כאל "רק כלי פרודוקטיביות חינמי" ללא מודלים לאיומים היא המקבילה של שנת 2025 לאפשר למהנדסים לשלוח אישורי גישה בטקסט רגיל בדוא"ל כי "בכל מקרה זה פנימי". בינה מלאכותית חינמית אינה חינמית. אתם משלמים בנתונים, בשטח התקפה ובסופו של דבר בזמן חקירה. (חדשות סייבר)

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