ארבעת השטחים המתים של ה-AI: מה שה-CISO לא רואה
מאת: דודו עקיבא, מהנדס פתרונות בכיר בנטסקופ ישראל
תשאלו כל CISO איפה נמצאת ה-AI בארגון שלו, והוא יענה בביטחון: "יש לנו את הצ'טבוט הארגוני, חילקנו רישיונות Copilot, ויש עוד פיילוט אחד מבוקר במעבדה". עכשיו לכו ותשאלו את צוות הפיתוח את אותה שאלה – ותקבלו חיוך מבויש ורשימה ארוכה פי שלושה.
הפער הזה לא נובע מרשלנות. הוא קורה כי התרגלנו למפות כלי AI דרך רשומות רכש ואישורי אפליקציות, בזמן שהסיכון האמיתי לדליפת מידע מגיע דווקא ממה שמעולם לא עבר תהליך אישור.
מערכות האבטחה הקיימות שלנו נבנו סביב שתי הנחות יסוד: או שהן מנטרות תעבורה שחוצה את הרשת, או שהן מנטרות פעולות שמבצע בן אדם. עולם ה-AI החדש יושב בדיוק ברווח שבין שניהם – הטכנולוגיה פועלת מקומית על המחשב, מפעילה סוכנים אוטונומיים שלא מתנהגים כמו משתמש אנושי, ומשתלבת עמוק בתוך תהליכי דאטה פנימיים. בצבא קוראים לזה "שטח מת": אזור שנמצא ממש בטווח הראייה שלנו, אבל מבנה השטח מסתיר אותו מהתצפית.
ארבעה אירועי אבטחה אמיתיים מהשנה החולפת ממחישים בדיוק איפה "השטחים המתים" האלה נמצאים ולמה כלי האבטחה המסורתיים מפספסים אותם.
שטח מת 1: הלפטופ של המפתח (כשה-AI לא יוצאת לרשת)
רוב בקרות האבטחה הארגוניות יושבות בשער היציאה לאינטרנט ומחכות לראות תעבורה חשודה. אבל מה קורה כשה-AI חיה ופועלת בתוך תחנת הקצה עצמה?
באוגוסט 2025 תוקפים העלו ל-npm גרסאות זדוניות של Nx – כלי פיתוח (Build) פופולרי מאוד בסביבות JavaScript (מתקפה שכונתה s1ngularity). התחכום במתקפה הזו היה שהנוזקה לא הכילה כלי סריקה או גניבת מידע משלה, כאלה שמערכות הגנה על תחנות קצה (EDR) יודעות לזהות ולחסום. במקום זאת, התוקפים השתמשו בטכניקה חדשה: הם חיפשו על המחשב של המפתח כלי AI בשורת הפקודה (CLI) שהמפתח כבר התקין בעצמו כמו Claude Code, Gemini CLI ו-Amazon Q.
הנוזקה הפעילה את כלי ה-AI האלו עם דגלים (Flags) מיוחדים, שמדלגים על בקשת אישור מהמשתמש, ופשוט ביקשה מהם באנגלית פשוטה: "תחפשו במחשב קבצי הגדרות, סיסמאות, מפתחות ענן וטוקנים". התוצאה: 2,349 סודות דלפו ופורסמו במאגרים ציבוריים ב-גיטהאב (GitHub), תחת החשבונות של הקורבנות עצמם.
מבחינת כלי האבטחה הרשתיים, הכול נראה שגרתי לחלוטין: מחשב של מפתח מתקשר עם ספק AI מוכר ועם גיטהב. איסוף המידע הרגיש עצמו נעשה מקומית על הלפטופ, באמצעות כלי לגיטימי שהמפתח הוריד לבד.
הבעיה מחריפה כשמפתחים מריצים מודלים מקומיים (כמו Ollama) ישירות על המחשב שלהם. מודלים כאלה מתקשרים בתוך המחשב בלבד (דרך תעבורת Loopback פנימית) ולא יוצאים כלל לרשת הארגונית או לענן – מה שהופך אותם לשקופים ב-100% עבור בקרות רשת.
ניסיון לפתור את זה באמצעות חסימה גורפת של כלי AI רק יחמיר את הבעיה: לפי Cloud and Threat Report של נטסקופ (Netskope), כ-47% מהעובדים כבר משתמשים בחשבונות AI פרטיים, שעוקפים את בקרות הארגון, וחסימה רק דוחפת יותר עובדים לעבוד "מתחת לרדאר".
הפתרון הנכון הוא שילוב של הכוונת משתמשים בזמן אמת (Real-time Coaching) לכלי AI מאושרים, יחד עם ירידה לרמת ה-Endpoint: מיפוי תהליכים רצים, פורטים פתוחים ותעבורה פנימית על המכשירים המנוהלים עצמם. אחרת, אתם ממפים רק את ה-AI ש"בחרה" להיראות.
שטח מת 2: מה שמאחורי הצ'אט (לאבטח את הבוט ולשכוח את המסד)
ארגונים רבים משקיעים מאמצים אדירים בבדיקות אבטחה למודל ה-AI עצמו (כמו הגנה מפני Prompt Injection) או ל-API Gateway שמולו. אבל אם סקירת האבטחה שלכם נעצרת במודל, אתם בודקים רק את קצה הקרחון. צ'טבוט לא חי בחלל ריק – הוא מחובר למסדי נתונים, לממשקי ניהול ולתהליכי סנכרון מידע.
מערכת הגיוס McHire ששימשה את מקדונלד'ס (McDonald's) היא הדוגמה הטובה ביותר לכך. מועמדים לעבודה באתר ניהלו שיחה עם Olivia, צ'טבוט גיוס מבוסס AI שפותח על ידי חברת פרדוקס (Paradox.ai). ביוני 2025, חוקרי אבטחה לא היו צריכים להנדס שום פרומפט מתוחכם כדי להוציא מידע מהבוט. הם פשוט מצאו דף כניסה לצוות הניהול, והצליחו להתחבר אליו באמצעות חשבון בדיקה נשכח משנת 2019, ששם המשתמש והסיסמה שלו היו 123456.
מאחורי החשבון הזה ישב ממשק API פגיע ללא בקרת הרשאות תקינה, שאפשר לחוקרים לשנות מספרי מועמדים בבקשה ולעבור על רשומות אחת אחרי השנייה. לפי הדיווחים, הפרצה חשפה נתונים אישיים מתוך כ-64 מיליון מועמדויות לעבודה. החולשה תוקנה במהירות, והחברה ציינה כי החוקרים ניגשו בפועל למספר מצומצם של רשומות, אך הודתה שבדיקות החדירה השוטפות שלה פספסו את הנקודה הזו.
חשוב להבין: Olivia לא הייתה Shadow AI. היא הגיעה כחלק מפלטפורמת גיוס רשמית שמקדונלד'ס רכשה ואישרה, והצ'טבוט עצמו תפקד ללא דופי. הכשל היה בכל המעטפת שמאחוריו.
כשאתם מאשרים מערכת AI של ספק חיצוני או בונים אחת בעצמכם, אל תשאלו רק "איך אתם מאבטחים את המודל?", אלא בדקו את כל ה-Pipeline: אילו מסדי נתונים מזינים אותו, אילו תהליכים טוענים אליהם מידע, ולמי יש גישה לדאטה הזה מאחורי הקלעים.
שטח מת 3: הסוכן שעושה בדיוק מה שביקשו ממנו
בשנה האחרונה עברנו מצ'טבוטים שרק "עונים תשובות" לסוכני AI שמבצעים פעולות אקטיביות: שולחים מיילים, פותחים קריאות שירות, כותבים לקובצי מערכת ומריצים קוד. כדי לאפשר לסוכנים להתחבר לכל המערכות האלו בקלות, אומץ במהירות תקן פתוח בשם MCP (ר"ת Model Context Protocol).
על מנת להבין מהו MCP בצורה פשוטה, חשבו עליו כמו על כבל ה-USB של עולם ה-AI. בעולם הפיזי שלנו, במקום שנדרש לכבל ייחודי ומתאם נפרד לכל מקלדת, עכבר, מצלמה או כונן חיצוני, תקן ה-USB מאפשר לחבר כל מכשיר לכל מחשב מיד ובאותה צורה.
MCP עושה בדיוק את אותו הדבר עבור סוכני בינה מלאכותית: במקום שמפתחים יצטרכו לכתוב מאפס קוד התחברות ייעודי בין מודל ה-AI לכל מערכת ארגונית, הם פשוט מורידים ומחברים "שרת MCP" מוכן מראש – והסוכן מקבל מיד ערוץ פתוח לקרוא נתונים ולבצע פעולות במערכות כמו GitHub, Slack, מסדי נתונים או שרתי אימייל.
אבל בדיוק כמו בעולם הפיזי, הנוחות הזו יוצרת פרצה מסוכנת: מה קורה כשמחברים לארגון "כבל USB" שנראה תמים לחלוטין, אבל מישהו שתל בתוכו שבב ריגול?
זה בדיוק מה שקרה בספטמבר 2025, כשחברת קוי סקיוריטי (Koi Security) זיהתה את שרת ה-MCP הזדוני הראשון בטבע: חבילה בשם postmark-mcp, שהתחזתה לספרייה לגיטימית ומוכרת לשליחת אימיילים. במשך 15 גרסאות החבילה פעלה כשורה וצברה אמון. אלא שבגרסה 1.0.16, המפתח הוסיף שורת קוד אחת שקטה: כל אימייל שהסוכן שלח דרך השרת נשלח במקביל כעותק סמוי (BCC) לכתובת אימייל של התוקף. לפני שהחבילה הוסרה, היא הורדה 1,643 פעמים.
למה כלי האבטחה הקיימים עיוורים למתקפה כזו? כי מבחינת הרשת, אין כאן שום חריגה. הסוכן אומת בהצלחה, קיבל הרשאה לשלוח מייל, ושלח מייל דרך שרת לגיטימי – זה בדיוק התפקיד שלו.
כשהאיום מגיע מתוך סוכן מורשה שפועל "לפי הכללים", אימות חד-פעמי בתחילת הסשן כבר לא מספיק – סוכני AI צריכים לקבל את אותה רמת בקרה וחשדנות שאנחנו מפעילים כלפי עובדים (Zero Trust לזהויות לא-אנושיות): פיקוח רציף ברמת ה-Session ומדיניות גישה מפורטת שיודעת לנתח את ההקשר בזמן אמת, למשל לזהות שנוסף נמען חיצוני לא מוכר לכל מייל שיוצא מהמערכת. וגם אז, מערכות סיווג אוטומטיות יגידו לכם מה הסוכן עשה, אבל הן לא תמיד ידעו להחליט אם פעולה שנמצאת בתוך גבולות הגזרה שלו הייתה טעות עסקית. בשביל זה עדיין צריך שיקול דעת אנושי בתהליך.
שטח מת 4: הדאטה, עוד לפני שהוא הופך לפרומפט
מרבית כלי האבטחה ל-AI מתמקדים בשלב השיחה: לסרוק את הפרומפט שהמשתמש הקליד ואת התשובה שהמודל החזיר. אבל בהרבה מקרים, דליפת המידע מתרחשת הרבה לפני שהמשתמש הראשון הקליד מילה אחת – כבר בשלב הכנת הדאטה והאימון.
ניקח לדוגמה את DataComp CommonPool – אחד ממאגרי המידע הפתוחים הגדולים בעולם לאימון מודלים, שהורד יותר משני מיליון פעמים. מפעילי המאגר הסתמכו על כלים אוטומטיים לטשטוש פנים וסינון מידע אישי. ביוני 2025, חוקרים מ-המכון הטכנולוגי של מסצ'וסטס (MIT) בדקו דגימה זעירה של 0.1% בלבד מהמאגר, ונדהמו לגלות אלפי מסמכים אמיתיים ורגישים להחריד: צילומי דרכונים, כרטיסי אשראי, תעודות לידה וקורות חיים מלאים. ההערכה היא שמנגנון הטשטוש האוטומטי פספס כ-102 מיליון פנים.
בארגון שלכם זה אולי לא מאגר תמונות ציבורי, אבל המנגנון זהה לחלוטין: צוותי פיתוח ודאטה מייצאים מאגרי מידע פנימיים, תיקיות שיתוף או תכתובות שירות לקוחות, ומזינים אותם ישירות לתוך תהליכי AI ארגוניים (כמו מערכות RAG או Fine-tuning), בלי שאף אחד סיווג ובדק מה באמת מסתתר בתוך הקבצים האלה. לפי נתוני נטסקופ, הארגון הממוצע חווה 223 הפרות של מדיניות נתוני AI בכל חודש.
את סינון וסיווג המידע (Data Classification & DLP) חייבים לבצע לפני הייצוא וההזנה למערכת ה-AI. ברגע שמידע רגיש כבר נבלע בתוך אימון של מודל, או אונדקס ללא בקרת הרשאות, אי אפשר פשוט "למחוק שורה מטבלה" – הדרך היחידה להוציא אותו היא בדרך כלל לאמן או לבנות את המודל מחדש מאפס. וזו כבר שיחה שאף CISO לא רוצה לנהל עם הדירקטוריון.
מה משותף לכל האירועים האלה?
אף אחד מארבעת המקרים האלו לא התחיל במתקפת סייבר קולנועית ודרמטית. כולם התחילו בדברים יומיומיים ושקטים: כלי עזר שמפתח התקין על הלפטופ, חשבון בדיקה ישן במערכת SaaS, עדכון גרסה לחבילת קוד, או ייצוא שגרתי של מאגר נתונים.
הנזק התאפשר כי תפישת האבטחה עדיין רודפת אחרי ה-AI בדיעבד: לפי מחקר של נטסקופ, כ-68% מהארגונים עדיין מנהלים את סיכוני ה-AI שלהם בצורה תגובתית (Reactive) – כלומר, מחכים שהבעיה תצוף ורק אז מטפלים בה.
ב-נטסקופ בנינו את הפלטפורמה שלנו בדיוק כדי לסגור את הפערים האלו כמערכת אחת מחוברת: גילוי ואכיפת מדיניות אחידה על פני הרשת, תחנות הקצה (Endpoint), מודלים באירוח עצמי, תעבורת סוכנים (MCP) וצינורות הדאטה. פלטפורמת Netskope Skylight AI Command Center, למשל, מאפשרת לחשוף הן כלי AI מנוהלים והן Shadow AI, מזהה יישומי AI המוטמעים בתוך אפליקציות SaaS קיימות, ומחברת את פעילות שרתי ה-MCP ישירות ליכולות DLP ו-Guardrails מתקדמות – כך שה-CISO מקבל תמונת שליטה אחת מלאה, במקום ארבעה שטחים מתים.
רוצים לראות איך סוגרים את השטחים המתים האלו בפועל?
ביום ה' הקרוב (22.10) נערוך בתל אביב את כנס AI in the Fast Lane Tel Aviv 2026, שבו נצלול לעומק האתגרים של אבטחת AI ארגונית, נציג תרחישי אמת ונראה איך בונים אסטרגיית הגנה שמאפשרת לארגון לרוץ קדימה בביטחון.
לקראת כנס AI in the Fast Lane Tel Aviv 2026, ה-22.10, יום ה'










