סוכני בינה ב Microsoft 365 כמערכת שליטה דינמית ומתפתחת
סאטיה הציג את אחת האמירות שמסמלות יותר מכל את הצעדים שאליהם ארגונים הולכים. לפי החזון שלו, מספר הסוכנים יעלה על מספר המשתמשים האנושיים, והתופעה הזו כבר מתחילה לבצבץ במציאות המבצעית של ארגונים. סוכני בינה הופכים ליחידות עבודה דיגיטליות שמסוגלות לקבל הנחיות, לבצע פעולות, לצרוך מידע פנימי ולפעול מול מערכות חיצוניות, מה שממקם אותם בשכבה חדשה לגמרי של אחריות ניהולית ותפעולית.
המשמעות האמיתית של האמירה הזו אינה רק הנפח הכמותי של סוכנים, אלא השינוי המנטלי שנדרש ממנהלי IT ואבטחה. אם בעבר נדרשה שליטה על משתמשים, תהליכים, מכונות וקונפיגורציות, הרי שהיום נכנסת קטגוריה חדשה שמחייבת חשיבה ארגונית של ניהול בינה עצמאית עם סוכנים ומערכות בינה אקולוגיות אחרות. סוכן שאוחז בזהות ארגונית, נגישות למידע, ויכולת לבצע פעולות מגוונות הוא למעשה עובד דיגיטלי לכל דבר, אך כזה שפועל בקצב, בהיקף ובהרשאות שעובד אנושי לא מסוגל להתקרב אליהם.
בנקודה הזו יש צורך ברור והוא לנהל בינה כמו שמנהלים את הגורם האנושי. להעניק לכל סוכן זהות ייעודית, לייצר עבורו מסגרת הרשאות, לוודא שקיימת מדיניות גישה סגורה ומנוהלת, ולפקח בזמן אמת על ההתנהגות שלו ועל הכלים שאליהם הוא מחובר. המודל המסתמן בארגונים מובילים מעביר את הבינה משלב של כלי עזר אוטומטי אל שלב של כוח עבודה חצי אוטונומי, וכאן מתחיל להיאסף הצורך בתשתיות כמו Agent 365.
המעבר הזה אינו רק טכנולוגי אלא מבני והוא מנגיש לעולם הארגוני מציאות שלא ניתן לברוח ממנה. ברגע שבינה הופכת לשחקן פעיל בשרשרת הייצור הדיגיטלית, האחריות על השליטה בה הופכת להיות זהה לזו של עובד אנושי, וכמו שעובד יכול לטעות, לסטות, או להביא סיכון, כך גם סוכן יכול לבצע פעולות בלתי צפויות, לקבל הנחיות זדוניות, או להתרסק על קלט שאינו מהימן. עדיין, ההבדל היחיד הוא שהסוכן מבצע זאת בקנה מידה של מערכת, ולא של גורם אנושי בודד.
המאמר מתמקד ביכולות של Agent 365 עם הארכיטקטורה, מיפוי, קטלוג ועוד. המאמר מעלה מספר נקודות כלליות של אבטחה אל אינו בא להתמקד באטחה אלא ביכולות של Agent 365. מאמרי אבטחה (ניצול משטחי תקיפה, הקשחות, ניטור ועוד) על Agent 365 יעלו בקרוב בהמשך למאמר הנוכחי.
הקדמה
היכולת להבין מהו Agent 365 מתחילה מהעיקרון שהארגון כבר לא נשען רק על אובייקטים מוכרים ורגילים כמו משתמשים, קבוצות, מכונות ויישומים קלאסיים.
הארגון חי היום בתוך מרחב מרובה סוכנים שבו בינה מלאכותית מייצרת פעולות, מפעילה משימות, מתקשרת עם מערכות אחרות ומבצעת עבודת עומק שבעבר הייתה שמורה לצוותי אבטחה, IT, וכן הלאה. וזה לא רק מודלים, אלא על סוכנים, וארגון שלא מנהל סוכנים, יישאר מאחור.
Agent 365 נולד בדיוק בנקודה הזו. זוהי שכבת זהות, אבטחה וניהול שממסגרת את היכולת של סוכני בינה לפעול בצורה בטוחה ומבוקרת בתוך Microsoft 365, בתוך Entra, וברמת ה tooling שמאפשרת לאותם סוכנים לבצע פעולות אמיתיות בארגון. במקום מודל שמדבר טקסט, מתקבלת ישות אמיתית עם Agent ID, מחזור חיים, גישה למשאבים, הרשאות, טוקנים, פעילות לוגית ותבניות פעולה שניתן למדוד, לאכוף, לאמת, לחסום ולתעד.
הגישה הזאת מכניסה את הסוכן של הבינה אל אותו עולם שאנחנו מנהלים עבור משתמשים אנושיים. בדיוק כפי שמשתמש מקבל זהות ב Entra ID, גם סוכן מקבל Agent ID.
הטוויט שהעליתי לאחרונה על Agent ב Entra ID והשאלות הגיעו נותנות נקודת מבט על השינוי שמגיע.
בדיוק כפי שמשתמש כפוף ל Conditional Access, כך גם הסוכן, ולכן כל פעולה שלו עוברת רישום, ניטור, אנליזה, וחקירה במידת הצורך, וכל גישה למשאב נבדקת. היכולת לבצע enforce או revoke מתבצעת בדיוק באותה צורה והמשמעות היא שלא רק מוסיפים סוכן לארגון, אלא מוסיפים אותו לתוך אותו מודל Zero Trust שהפך לסטנדרט של הארגון המודרני.
היופי הוא שהמודל הזה אינו נשאר רק בתחום הזהויות. Agent 365 מחבר קצוות בין Identity, Productivity, Data Security, Compliance, Threat Protection ו Observability. , ולכן סוכן אינו רק ישות שמבצעת פעולות הוא ישות שמייצרת אירועים, מייצרת סיגנלים, מייצרת התנהגות. במקרה כזה סוכן צריך להיות חלק מהמערכת החשיבתית של SOC, חלק ממערך ה IR, חלק ממנגנון הגנת הנתונים, חלק מדפוסי ה Threat Modeling ובוודאי חלק מה Governance. תשתית שמציבה סוכני בינה ללא Agent 365 היא תשתית ללא בקרה.
כאשר בונים סוכנים בארגון או מאמצים סוכנים חיצוניים, מתברר מהר מאוד שהאתגר אינו איך לבנות יכולת, אלא האתגר הוא איך להפעיל יכולת, איך להנגיש הקשר, איך להגביל הרשאות, איך להבטיח שהסוכן יבצע רק את מה שהוגדר לו, איך להגן מפני זליגת מידע, להבין פעולה חריגה, ניצול לרעה, או מתקפה שמנצלת שרשרת אספקה של סוכן. כי כמו שראינו, גם בעולם הסוכנים הניצול קורה דרך החוליה החלשה.
בנוסף, הנקודה החשובה ביותר בעולם הסוכנים היא שהסוכן פועל דרך כלים, אפליקציות וסרוויסים קיימים ב Microsoft 365, וכל כלי כזה הופך לשכבת כוח של סוכן, ולכן הוא חייב להיות ממוסגר במודל הרשאות ברור, מדיד, מנוטר. Agent 365 מספק ל tooling הזה עטיפה שמאפשרת לארגון ליהנות מסוכנים מבלי לשלם מחירי סיכון מיותרים.
בסופו של דבר, Agent 365 מייצר את מה שהיה חסר לעולם הבינה המלאכותית הארגונית, שליטה, נראות, וניהול מבוקר. ממש מערכת שמאפשרת לסוכן לעבוד, אבל לא לאבד שליטה על מה שהסוכן עושה, וזה הבסיס של המציאות החדשה שבה בינה איננה משתלב בארגון אלא הוא הופכת להיות חלק ממנה.
המשך טבעי הוא להבין איך Agent 365 מתפרק ליכולות, מה נמצא בתפריט, אילו כלים קיימים, וכן הלאה.
מבט מלמעלה
הבקרה הראשית של Agent 365 מציגה שכבת תצפית שמאפשרת להבין בצורה רציפה ואינטגרטיבית את כלל הסוכנים האוטונומיים שפועלים בתוכו. זוהי שכבה שנבנתה מתוך תפיסה ארגונית חדשה שבה סוכנים אינם ישויות צדדיות, אלא מרכיבים פעילים בתהליכים העסקיים, בפעולות המידע ובאינטגרציות הטכנולוגיות שמרכיבות את סביבת microsoft 365. הבקרה הופכת מערך של ישויות מבוזרות ומוסתרות למערכת שקופה ומאורגנת שבה כל סוכן מקבל תיעוד מלא, סיווג מדויק, ומקום ברור בארכיטקטורת התפעול.
המערכת נשענת על agent registry שהוא מאגר מרכזי אשר מתעד את כלל פרטי המידע התפעוליים של כל סוכן. המאגר הינו מבנה דינמי שמרכז זהות טכנולוגית מלאה עבור כל סוכן, כולל סוג הסוכן, הפלטפורמה שמריצה אותו, מודל היצירה שלו, הקשרים עם שירותי microsoft 365, ואופן הצריכה של נתונים ושירותים אחרים. מאגר זה מאפשר לארגון לבנות מבנה עקבי של ניהול סוכנים ולראות את מחזור חייהם מתחילתם ועד התנהלותם השוטפת.
רכיב agent publishers בחלק הבקרה משמש כמערכת שמציגה את מקורות היצירה וההפצה של הסוכנים. הוא מראה כמה סוכנים נוצרו בתוך הארגון, כמה הגיעו באמצעות שיתוף, כמה הוטמעו מספקים חיצוניים וכמה פותחו על ידי microsoft. חלוקה זו מאפשרת לזהות מגמות של אימוץ פיתוחים פנימיים לעומת שימוש ביכולות חיצוניות, להבין את הפיזור הטכנולוגי, ולבחון אילו אזורים בארגון מעדיפים לפתח סוכנים בעצמם ואילו אזורים נשענים על פתרונות קיימים.
רובד agent platforms מציג תמונה טכנולוגית עמוקה של סוגי הפלטפורמות שעליהן מבוססים הסוכנים. המערכת מסווגת סוכנים לפי שימוש ב copilot studio, פלטפורמות אינטגרציה, מודלים פנימיים או יכולות המופעלות על ידי ממשקי graph. נתון זה מאפשר להבין את פיזור התשתיות שעליהן נשענים הסוכנים, להבחין בהיקף האוטומציה שיוצרת כל פלטפורמה, ולהעריך את כמות התלויות הטכנולוגיות שמתפתחות במהלך פעילות הסוכנים.
רכיב ownerless agents בחלק הבקרה מאפשר לזהות סוכנים ללא בעלים תפעולי מוגדר. תצפית זו חשובה לניהול אופטימלי משום שהיא מאפשרת לארגון לשמור על משמעת תפעולית ברורה, להבטיח שכל סוכן מנוהל ומקבל תחזוקה מתאימה, ולמנוע מצב שבו סוכן ממשיך לפעול ללא כיוון ארגוני ברור. זהו מנגנון שמבטיח סדר, קוהרנטיות ויעילות לאורך זמן.
הבקרה יוצרת מסגרת אחודה שבה ניתן להבין את תזרים הסוכנים הארגוני, לבחון את החיבורים הטכנולוגיים, לעקוב אחר המגמות התפעוליות ולהתאים את המבנה הארגוני לצמיחה המואצת בעולם של סוכנים אוטונומיים. ככל שיותר סוכנים נכנסים לפעילות ארגונית ומבצעים משימות שבעבר היו תלויים באדם, הבקרה הופכת לכלי מרכזי שמסייע לארגון לראות, למדוד ולכוון את האוטומציה המתרחבת שלו.
ניהול סוכנים
ניהול סוכנים ב Agent 365 הופך מאמצעי תמיכה למנגנון שליטה קריטי כי הארגון כבר לא נשען רק על משתמשים אנושיים או אובייקטים דוממים אלא גם על סוכני בינה שפועלים מול נתונים, שירותים וממשקי API. כל סוכן מחזיק יכולות, הרשאות ולפעמים גם לוגיקה אוטונומית, ולכן ניהול נכון קובע מי פועל בתוך המערכת, מה היקף הגישה שלו, ואיך מונעים הפעלה לא רצויה. בסביבה שבה מספר הסוכנים בארגון מתחיל להתקרב ובשנים הקרובות יעבור בוודאות את מספר המשתמשים, ניהול סוכנים הוא שכבת אבטחה ותפעול חובה, ולא תוספת נוחה.
Agent 365 מכיל ארבע שכבות שמרכיבות יחד את התפעול והאבחון של כלל הסוכנים הארגוניים וכל שכבה מספקת תצפית אחרת ומבוססת על טלמטריה שונה. הבנה עמוקה של הרכיבים מאפשרת להעריך את הדינמיקה הארגונית סביב סוכנים אוטונומיים ולנתח התנהגות, פיזור מערכתי ותהליכי חיים מלאים של סוכנים, ואלה שכבות שמחברות בין יכולות של ai systems לבין מודלים תפעוליים מסורתיים של microsoft 365.
שכבת המיפוי הטופולוגי של סוכנים ארגוניים
ה Map היא שכבה טופולוגית שמכילה מבנה גרפי של כלל הסוכנים, יחסי השיתוף שלהם, הפעילות הארגונית שהם מריצים, והפלטפורמות שעליהן הם בנויים. ה map מבוסס על מנוע גרפי שמזכיר מבנים של knowledge graphs ומייצר התמרה בין טלמטריה של microsoft graph לבין מבני יחסים שניתן לראות בצורה ברורה כמערכות מחוברות.
ברמה הטכנית map מציג מידע שמתורגם ממספר שכבות מידע
- טלמטריה של graph api
- סיגנלים מבוססי פעילות של m365 services
- ניהול אובייקטים במערכת entra
- נתונים על publisher מקור יצירה וערוצי הפצה
- נתוני usage המשויכים ל users
המיפוי מייצר יכולת להבחין בין סוכנים מרכזיים לבין סוכנים שוליים, להבין את עומס העבודה שמופעל על סוכנים מסוימים, ולנתח אילו חלקים בארגון מפתחים תלות גבוהה יותר באוטומציה. זהו כלי שאפשר להשתמש בו כדי לזהות התפשטות סוכנים בין מחלקות, יכולת לבצע segmentation של סוכנים בעלי תפקידים דומים, וכן לבצע הערכה מהירה של מוקדי צפיפות.
חשוב להדגיש כי סוכנים עם חיבוריות גבוהה מדי עשויים לייצר משטח תקיפה עם סיכונים. למשל, אם סוכן אחד מקושר למספר רב של שירותים, הוא הופך לנקודת ריכוז של הרשאות ופעולות. שכבת map מאפשרת לזהות מקרים כאלה ולסמן אותם לבדיקה. דוגמה מוכרת היא סוכן copilot studio שמחובר גם ל outlook גם ל sharepoint גם ל teams וגם ל graph מייצר משטח פעולה רחב במיוחד.
הבסיס הנתוני של הסוכנים
אפשר לומר ש Registry הוא הליבה. זהו מאגר שבו כל סוכן מוגדר כאובייקט מלא המכיל identity פנימי, פרטי יצירה, פרטי פלטפורמה, הרשאות, binding של משתמשים, list של endpoints שהוא צורך, ו stack טכנולוגי מלא. אפשר לומר ש registry מקביל במובנים רבים ל app registrations של entra אך הוא מותאם לסוכנים ולמודל עבודה מבוססי בינה.
ה registry משמש נקודת עוגן לביצוע פעולות כגון, מעקב אחרי גרסאות הסוכן, היסטוריית עדכונים, מודל יכולות functions actions tasks, הרשאות קריאה וכתיבה לשירותים, רמת שקיפות על דגמים ומקורות ידע, התנהגות ברמת עומס תפעולי ועוד.
חשוב להדגיש כי registry משמש כמנגנון שניתן לזהות בו היבטים בעייתיים כמו, סוכן ללא תיעוד מספיק סוכן שצורך הרשאות גדולות מדי, סוכן שהוגדר ללא owner פעיל, סט הרשאות שאינו תואם ל tradeoff התפעולי וכן הלאה. במספר ארגונים נמצאו סוכנים שנוצרו עבור פיילוט פנימי ב copilot studio אך נשארו עם הרשאות graph רחבות כמו files read write all או mail read. במקרים כאלה ה registry מאפשר לזהות זאת מיידית.
מנגנון בקרת הכניסה של סוכנים חדשים
ה requests הוא השער. כל ניסיון להכניס סוכן חדש לארגון או להעניק יכולת חדשה לסוכן קיים עובר דרך שכבת requests ובמקום לאפשר לכל משתמש להכניס סוכנים נוספים ללא בקרה, המערכת מייצרת תור של בקשות שהארגון צריך לאשר.
במובן התפעולי requests מאפשר לבדוק כמה סוכנים ממתינים, לבדוק מי ביקש את ההוספה, לנתח על מה הסוכן נשען, לזהות מה רמת ההשפעה על הארגון, לבחון אינטגרציות שהסוכן יפעיל. ארגונים גדולים משתמשים במנגנון הזה כדי למנוע הצפת סוכנים ולשמור על סדר תפעולי, בקשות שמגיעות ממחלקות לא טכנולוגיות עשויות להכיל סוכנים שמבצעים פעולות אוטומציה שאינן מאושרות, ולצד זה, בקשות שמגיעות מספקים חיצוניים חייבות להיבדק כדי לוודא שהסוכן אינו משתמש ב tokens או endpoints שאינם תואמים מדיניות.
בקשות לשינוי הרשאות של סוכן קיים חייבות לעבור בקרה כדי למנוע privilege escalation אוטומטי.
בארגונים שבהם מחלקת שיווק או hr פרסמו סוכנים פנימיים לניתוח קבצי sharepoint נמצאו מקרים שבהם הבקשה כללה הרשאות של sites full control שאינן נדרשות. requests מאפשר לזהות את זה לפני שהסוכן נכנס לפעילות.
רשימת היכולות והסוכנים המאושרים בארגון
catalog הוא שכבת המיון הפנימית שמציגה את כלל הסוכנים הזמינים לשימוש בארגון. זוהי מערכת שמאפשרת לעיין בסוכנים קיימים, להבין מה כל סוכן עושה, אילו יכולות קיימות בו, ומהם המודלים התפעוליים שהוא תומך בהם. catalog מאפשר לארגון לנהל מערכת מסודרת ולאפשר למשתמשים לאתר סוכנים בצורה מסודרת ומבוקרת.
catalog מכיל פרטים כגון, תיאור סוכן, יכולות תפעוליות, מודולריות, הרשאות שהוא צורך, קישוריות לשירותים, תלות טכנולוגית, רמת זמינות, פלטפורמה טכנית ועוד.
כמו גם, catalog משמש גם ככלי audit פנימי המאפשר לזהות סוכנים שאינם בשימוש, סוכנים שאינם חלק מארכיטקטורה מאושרת, סוכנים שחורגים מהרשאות או מתכונות מאושרות, סוכנים שצריכים לעבור ביקורת מחדש ועוד.
כאשר מחברים את map registry requests catalog מתקבלת ארכיטקטורה שלמה לניהול סוכנים אוטונומיים שמאומצת כעת בארגוני enterprise גדולים. היא מייצרת יכולות ראייה, בקרה, תפעול וניתוח שעד כה היו מפוזרות בין מספר מערכות.
אולי הדבר הכי חשוב כאן והא להבין שבקרוב מספר הסוכנים האוטונומיים בארגון יחצה את מספר המשתמשים האנושיים, וכל אינטראקציה עם מערכת הופכת לפעולה שמבוצעת דרך agent קטן שחי ברקע, המסקנה האבטחתית צריכה להיות מובנת. ניהול סוכנים הוא היום אחד ממשטחי התקיפה הקריטיים ביותר בארכיטקטורת Microsoft 365 והארגון שלא ישלוט בהם ברמת עומק ימצא את עצמו חשוף בלי להבין אפילו מי הפעיל מה.
נותנת הצצה לאופן שבו המערכת הפכה להיות אקוסיסטם שלם של אוטומציות, חיבורים, אפליקציות זעירות, מחוללי בקשות, ופרוקסי אינטראקציות שמייצרים פעולות בשם המשתמשים. נשמע תמים, אבל בפועל מדובר בגורם שמקבל הרשאות, מבצע קריאות Graph, מזריק פעולות לערוצים שונים, ונוגע במידע חי של הארגון. כל חולשה בסוכן כזה הופכת מיידית לרכישת גישה.
הטעות הארגונית הגדולה ביותר היא להסתכל על agents כמו על תוספים כי בפועל הם רכיבי ריצה שמקבלים זהות משל עצמם, טוקן משל עצמם, יכולות פעולה משל עצמם, ודורשים רמת Governance שלא קיימת עדיין ברוב הארגונים. במספר ארגוני enterprise נמצאו סוכנים שנוצרו בפיילוטים שונים של copilot אך מעולם לא הוסרו. חלקם המשיכו להופיע ב catalog למרות שלא היה בהם שימוש ולא הייתה עליהם בקרה. catalog מהווה שכבת תיעוד המאפשרת למנוע הצטברות כזו.
כלים וכאלה
ה tools הוא בעצם המקום שבו הארגון מגדיר מאחורי הקלעים את הדבר הכי חזק בועל סיכון גבוה בעולם של agentic ai בתוך Microsoft 365 והוא איך המודל נוגע בנתונים אמיתיים ובמערכות אמיתיות. אם ב agents אנחנו מדברים על מי הם הסוכנים, אז ב tools אנחנו מדברים על מה הם יכולים לעשות בפועל, מול אילו שירותים, דרך אילו פרוטוקולים, ובאילו גבולות משחק. זו שכבת הדבק בין ai לבין ה data plane הארגוני.
ברמה התפיסתית tools הם לא תוסף נחמד אלא שכבת אינטגרציה מבוססת model context protocol שמגדירה באיזה אופן מודל בינה מוגבל או מורשה לקרוא נתונים, להריץ פעולות, לבצע שאילתות ולעדכן מערכות. במקום לאפשר למודל לעבוד על טקסט בלבד, אנחנו מחברים אותו לאפליקציות וסרוויסים ב Microsoft 365 דרך mcp servers שכל אחד מהם הוא שירות ייעודי שמייצג יכולות ספציפיות. כיום ישנם מספר mcp שרשומים.
כל אחד מה mcp האלה ממפה בין שפה טבעית לבין פעולות קונקרטיות על שירות ספציפי. לדוגמה outlook mail mcp server יודע להפוך בקשות כמו מצא את כל המיילים מהלקוח הזה בשבוע האחרון לבין קריאות מסודרות ל api של exchange online כולל סינון תאריכים שדות header ותוכן. sharepoint lists mcp server יודע לבצע פעולות כמו קריאה עדכון חיפוש וסינון על רשימות sharepoint בלי שהמודל נדרש להכיר את פרטי ה rest api בעצמו.
מאחורי הקלעים כל mcp server מגדיר סט של כלים tools שכל אחד מהם הוא action מוגדר עם פרמטרים סוגי קלט ופלט ומודל הרשאות. המודל משלב בין כמה שכבות, כמו, הגדרת ה api הפונקציונלית למשל get messages list items query user profile, הגדרת הפרמטרים והטיפוסים לדוגמה mailbox id query filters time range, הגדרת התנהגות שגיאה למשל מה קורה כשיש כשל הרשאות או חריגה מגבולות, הגדרת חיבור הקשרית לקונטקסט של השיחה שה סוכן מנהל עם המשתמש והרבה אחרים.
ה tools הם השכבה שמחליטה מה המודל יכול לעשות ומה הוא לעולם לא יבצע גם אם קיבל prompt תוקפני. בעולם של prompt injection אין אפשרות לסמוך על הטקסט בלבד ולכן חייבים שה tool יהיה השומר האחרון שמוודא שלא מבוצעת פעולה החוצה מהמסגרת המותרת.
לדוגמה ברגע שאתה מפעיל microsoft 365 admin center mcp server אתה בעצם נותן למודל אפשרות לפעול מול שכבת הניהול של הענן הארגוני. זה אומר ש tool תמים כמו get license assignment או list users יכול להפוך לכלי מודיעיני עמוק אם המודל מקבל בקשה ל enumerate כל המשתמשים בעלי רשיונות מסוימים. לכן חייבים לוודא ש
ה tools עובדים תמיד עם scoping ברור למשל רק על המשתמש הנוכחי או רק על קבוצות מוגדרות
ה tools אינם מאפשרים פעולות מסוכנות כמו מחיקה שינוי הרשאות או שינוי הגדרות קריטיות אלא אם הוגדר לכך מודל ממשל ברור. ה tools מתועדים ברמת registry כך שכל tool וכל mcp server ניתנים לבקרה ול audit.
אם נסתכל על tools עבור outlook אפשר לדמיין קצת עומק תפעולי. נניח שקיים tool בשם search mail עם פרמטרים mailbox query time range ו fields. ברמת ai המודל מתרגם שאלה בשפה טבעית לתבנית חיפוש אבל ברמת אבטחת מידע מעניין יותר מה הטווח המקסימלי המותר לחיפוש, האם מותר לחפש רק ב mailbox של המשתמש הקורא או גם בתיבות ששותפו איתו, האם מותר למשוך גוף הודעות מלא או רק metadata, והאם יש מגבלות על מספר התוצאות לכל קריאה. כל אלה הם שאלות אבטחה לא פחות מאשר שאלות ux.
ב sharepoint and onedrive mcp server המצב עוד יותר רגיש משום שהידע הארגוני מרוכז שם. tool כמו list documents או query list item מאפשר למודל למשוך תוכן מדויק לרמת מסמך כולל גרסאות והקשרים. כאן אבטחת המידע צריכה להתעסק בשאלות כמו' האם ה tool מכבד security trimming מלא כפי שמוגדר ב sharepoint
האם המודל יכול לבצע חיפושים רוחביים בלי שאילתת משתמש מוגדרת, האם אפשר למנוע מצב שבו סוכן מריץ שאילתות דמויות crawl ומייצר העתק סמוי של ידע ארגוני ועוד
בהקשר של microsoft 365 user profile mcp server אפשר לחשוב על כלי שמאפשר להוציא מידע על משתמשים כגון מחלקה תפקיד מנהל ישיר פרטי קשר ועוד. כלי כזה הוא נכס זהב לתוקף שמנסה לבנות מפה של הארגון ולכן בניהול tools צריך להתייחס אליו כמו אל api רגיש בדיוק כמו graph users.
כיוון נוסף מאתגר הוא ש tools הם הממשק שבו אפשר לשלב מערכות צד שלישי דרך mcp. אם מחר תוסיף mcp server שמדבר עם jira או עם מערכת crm חיצונית אז בפועל אתה מוסיף שכבת תקשורת חדשה בין מודל ai לבין תשתית עסקית קריטית. כאן נכנסות שאלות אבטחת מידע כמו ניהול סודות tokens keys ו client secrets של החיבור, ניהול תפקידים של הסוכן מול המערכת החיצונית, והתנהגות במקרה של עיכוב תקשורת או שגיאה שתגרום למודל לנסות שוב ולייצר עומס או לולאה.
נקודה טכנית שמעט מדברים עליה היא logging של tools. כל קריאה ל tool צריכה להיות מתועדת ברזולוציה גבוהה כולל מי המשתמש שביקש את הפעולה באיזה הקשר שיחה באיזה סוכן באיזה mcp server באיזה זמן ומה הייתה התשובה. הלוג הזה הוא לא רק forensics אלא גם שכבת פיקוח שיכולה להפעיל מנגנוני rate limiting או חסימת דפוסים חריגים כמו flood של בקשות חיפוש מ agent אחד.
מבחינת מבנה המערכת חלק ה tools שאתה רואה כעת עם רשימת תשעת ה mcp servers של microsoft מייצג את המצב היציב אבל מהר מאוד יתווספו אליו mcp servers נוספים מצד microsoft ומצד גורמים חיצוניים. המשמעות היא שבנוסף לניהול agents אתה חייב שיהיה לך מודל ניהול tools שבו אתה מחליט איזה mcp servers בכלל מותר לשימוש בארגון, אפשר לקבוע אילו סוכנים מורשים להשתמש באילו tools ולא רק להפך, או אפשר לבצע סקירה תקופתית של tools בדומה לסקירת הרשאות אפליקציות oauth, או לנתח אם יש tools שאינם בשימוש וצריך להסירם כדי לצמצם משטח תקיפה.
לסיכום
Agent 365 מוצג על ידי מיקרוסופט כתשתית שליטה וניהול אחודה לסוכני בינה ארגוניים. המערכת מיועדת להחליף את הגישה האנלוגית שבה ארגונים מתייחסים כיום לסוכני AI כאובייקטים זמניים, ולהפוך אותם ליחידות עבודה דיגיטליות הדורשות ניהול זהויות, בקרות גישה, נראות תפעולית, רישוי, וגופי ניטור בדומה לעובדים אנושיים. מבחינה ארכיטקטונית Agent 365 ממוקם מעל Entra בקטגוריית ניהול זהויות לסוכנים, מעל Defender בקטגוריית הגנה, ומעל Purview בקטגוריית ממשל מידע. שילוב זה אמור לייצר Control Plane אחיד שמרכז את כלל הסוכנים, ללא תלות בפלטפורמת הפיתוח שלהם או בזירת ההפעלה שלהם.
במבט תפעולי Agent 365 מספק שכבת רישום שבה כל סוכן מקבל Agent ID ייחודי, מנגנון הממפה את היכולות והכלים שמותקנים עליו, ממשק ניטור שמקל על מעקב אחר ביצועי הסוכן, ומידע המיועד להפעלה תחת Windows 365 כאשר מדובר בסוכנים מבצעיים. במבט עסקי זהו המנגנון שמאפשר למיקרוסופט לבצע מעבר אל מודל מסחרי חדש המשלב רישוי פר משתמש ורישוי פר סוכן. המשמעות הארגונית היא כי תקציבי IT עתידיים יתבססו על Digital Headcount המכיל גם עובדים אנושיים וגם סוכני בינה שמפעילים תהליכים.
אולם לצד המודל החדש מתרחשת התנגשות הנדסית עם המציאות. Agent 365 אינו מערכת אבטחה, ולמעשה גם אינו מבטיח סביבת הפעלה בטוחה לסוכנים. הדוגמאות שהוצגו במהלך Ignite ומחקרים קודמים מציגות בבירור כי הבעיה העיקרית אינה השליטה על הסוכן אלא בעיית המודל הבסיסית. LLM אינו יודע להבחין בין נתונים להוראות, ולכן כל סוכן הנחשף לקלט לא מהימן, לתוכן בלתי צפוי או ל־DOM של דפדפן עלול לבצע פעולות שלא הוגדרו מראש. השילוב של גישה לנתונים ארגוניים, יכולת לבצע תקשורת חיצונית, וחשיפה לקלט בלתי נשלט מייצר את שלושת תנאי הכשל שמהווים בסיס להשתלטות על סוכן.
סוכנים המבוססים על Copilot Studio או על פלטפורמות Agent Framework משתמשים בכלים חיצוניים כדי לבצע פעולות ולכן הסיכון מוכפל. תרחיש שבו סוכן פותח Windows 365 Cloud PC ומתפעל דפדפן או רכיבי Office מגדיר בפועל יכולת RPA לא דטרמיניסטית. בניגוד לבוטי אוטומציה סטנדרטיים, כאן התנהגות הסוכן מוכתבת על ידי מודלים שאינם יציבים ואינם מחויבים לרצף לוגי או ציות לפרוטוקולים קבועים. במצבים כאלה כל תוכן שנמצא בממשק יכול להפוך לפקודה בסמכות מלאה.
הזהרה של פרויקט Opal ממחישה את זה בצורה ברורה. מיקרוסופט מבהירה כי כל שימוש ביכולת Computer Use חשוף לסיכוני אבטחה חמורים. הסוכן עלול לבצע פעולות בלתי מכוונות, כולל ביצוע פקודות הפועלות על נכסי הארגון, חשבונות משתמשים, וסביבות ייצור. מנגנוני ניטור ומדיניות לא משנים את העובדה שמדובר בהפעלה של מודל לא דטרמיניסטי בתוך סביבת הפעלה רגישה.
במישור הסיכונים סוכני AI מייצרים משטח תקיפה חדש לחלוטין. היכולת של גורם זדוני לבצע Prompt Injection ישיר או עקיף דרך אתר אינטרנט, קובץ אופיס, או פרטי אימייל משאירה סוכנים חשופים כמעט ללא יכולת הגנה אמיתית. מאחר שהמודל אינו מבדיל בין הוראה אמיתית להוראה שמסתתרת בתוך נתון תמים, כל תשתית שליטה כמו Agent 365 יכולה רק לתעד, לגדר, ולנתב את אירועי הסיכון. היא אינה מסוגלת למנוע אותם מהותית.
מבחינה עסקית ומבנית מיקרוסופט עשתה צעד נכון. היא בנתה תשתית המאפשרת לארגונים לנהל סוכנים בינה בתצורת Enterprise, לתת להם זהות, מחשב, הרשאות, התראות, ולהתאים את המרחב הארגוני לשילוב של סוכנים מבצעיים.
אולם מבחינה אבטחתית הבעיה אינה נפתרת באמצעות רישוי, ממשקי ניהול או סקירות לוגים. הבעיה טמונה בטבע של המודלים עצמם ובאופי הלא יציב של הסקות והנחות. לכן Agent 365 יהפוך לפלטפורמת בקרה חשובה, אך לא יפתור את הסיכונים של סוכני בינה.
