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

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

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

למאמרי Shadow AI נוספים

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

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

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

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

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

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

Shadow AI כמשטח סיכון שקט ומתמשך

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

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

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

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

כדאי להכיר: המדריך Govern data sent to AI apps מסביר כיצד לנהל נתונים שנשלחים לכלי בינה מלאכותית באמצעות Purview החל מביקורת, שמירה, חקירה וזיהוי התנהגויות מסוכנות כדי למנוע דליפות מבוססות Shadow AI.

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

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

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

בשטח מתגלה דפוס חוזר ומסוכן. כדי לאפשר לסוכנים לפעול בצורה חלקה, ניתנות להם הרשאות רחבות מראש לרוב באמצעות service principals, managed identities, API keys או application permissions ברמת tenant או resource group. לאחר ההקצאה כמעט אין תהליך שיטתי של סקירה תקופתית, צמצום הרשאות או תיחום בזמן. התוצאה היא יצירה מואצת של זהויות לא אנושיות (Non-Human Identities) בעלות הרשאות גבוהות שממשיכות להתקיים גם אחרי סיום הפרויקט או הניסוי שבמסגרתו נוצרו. זהויות אלה הופכות לזהויות זומביות: הן נשארות פעילות ברקע, מחזיקות בטוקנים תקפים, ויכולות לגשת למשאבים רגישים חודשים ארוכים בלי שאיש עוקב אחריהן באופן רציף.

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

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

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

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

מגבלות הבקרה הקיימת במציאות התפעולית

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

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

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

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

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

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

בניית נראות ושליטה כתהליך מתמשך

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

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

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

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

כלים שמסייעים בנראות 

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

מיקרוסופט בנתה בשנים האחרונות שכבת נראות רחבה יחסית סביב שימוש בבינה מלאכותית וסוכנים והכלים העיקריים שעובדים טוב בשטח הם שילוב של Microsoft 365 Admin Center, Entra, Defender, Purview ו Agent 365. הם לא פותרים הכול לבד וחייבים להיות בהלימה אחד עם השני בכדי שיוכלו לתת בסיס חזק לנראות בלי צורך להתחיל מאפס.

הכלים הפוטנציאלים

Microsoft 365 Admin Center מכיל פורטל ייעודי בשם Shadow AI (תחת Agents). הדף מציג סוכנים לא מנוהלים שזוהו בארגון כמו OpenClaw, גרסאות Desktop של ChatGPT או Claude ועוד. הוא מאפשר לראות היכן הם רצים ולנקוט פעולות בסיסיות של חסימה דרך Intune.

Microsoft Entra Global Secure Access מספק גילוי מבוסס רשת של יישומי AI, שרתי MCP וספקי מודלים. הוא מנתח תעבורה ומשייך את היישומים לקטלוג של Defender for Cloud Apps עם ציון סיכון.

Microsoft Agent 365 משמש כשכבת רישום מרכזית. הוא מרכז סוכנים מנוהלים וגם כאלה שזוהו כ-Shadow, כולל סוכנים מקומיים שרצים על תחנות קצה. הוא מתחבר ל-Defender, Purview ו-Entra ומציג תמונה מאוחדת של זהויות, הרשאות ופעילות.

Microsoft Defender (בעיקר Defender for Endpoint ו-XDR) מזהה סוכנים מקומיים על מכשירי Windows ו-macOS מנוהלים, מציג פרופיל שלהם כולל שרתי MCP משויכים ומחשב חשיפה אפשרית. האותות זורמים לטבלאות כמו CloudAppEvents עם סוגי פעולות ייעודיים לסוכנים.

Microsoft Purview, ובמיוחד DSPM for AI ו-AI Observability, נותן נראות לפעילות של סוכנים, אינטראקציות עם נתונים רגישים וסיכונים פנימיים. הוא מאפשר לראות אילו סוכנים פעילים, אילו פעילויות מסוכנות בוצעו ולבנות מדיניות סביבם. Insider Risk Management הורחב גם לסוכנים.

כלים נוספים שמשלימים הם Defender for Cloud Apps לגילוי יישומי AI, Entra לניהול זהויות של סוכנים (Agent ID) ו-Intune לאכיפה על תחנות קצה.

איך עובדים עם הכלים בפועל

הגישה שעובדת בשטח מתחילה תמיד מגילוי רחב ואז עוברת למיקוד.

ראשית עובדים עם האפשרויות של Microsoft 365 Admin Center ובודקים את מצב ה Shadow AI. מסווגים את הסוכנים שזוהו, את מספר המכשירים שעליהם הם רצים ואת הסטטוס שלהם. במקביל פותחים את Entra Global Secure Access ומסננים לפי Generative AI apps and tools. כך מתקבלת רשימה של יישומים חיצוניים שהעובדים מתחברים אליהם יחד עם נתוני שימוש וציוני סיכון.

בשלב הבא עוברים ל Agent 365 ועובדים ישירות על ה Registry ושם אפשר לראות גם סוכנים מקומיים וגם כאלה שנבנו ב Copilot Studio או Foundry ולכל סוכן בודקים בעלים, זהות ברמת Entra ID, הרשאות ופעילות אחרונה.

לאחר מכן עובדים מול Purview DSPM for AI / AI Observability, שם כדאי לבחון את הסוכנים הפעילים ב 30 הימים האחרונים, ממיינים לפי רמת סיכון ובודקים פעילויות כמו oversharing או גישה לנתונים רגישים, ובמידה ויש אירועים חשודים מעבירים אותם ל Insider Risk Management לבדיקה מעמיקה יותר.

ברמת Defender XDR מחפשים ב CloudAppEvents או באירועי Endpoint אחר פעולות של סוכנים (InvokeAgent, ExecuteTool וכו'), וניתן לבנות שאילתות של קורלציה בין זהות הסוכן, הכלי שנקרא והנתונים שניגשו אליהם, ואת הממצאים אפשר להזרים ל Sentinel לתחקור מרכזי.

לאכיפה הראשונית משתמשים ב Intune כדי לחסום הרצה של סוכנים לא מאושרים על מכשירים מנוהלים, וב Defender for Cloud Apps או במדיניות Conditional Access ב Entra ID כדי להגביל גישה ליישומי AI מסוימים.

שגרות ניהול