9.9.2026 | מאת אייל מרקוס
מיקרוסופט פרסמה ב-1 בספטמבר את דוח השקיפות השנתי שלה על AI, ויחד איתו הודיעה שהיא משנה את התקן הפנימי שלפיו היא מאשרת מערכות AI. עד עכשיו המודל היה בדיקה אחת, לפני שהמערכת יוצאת החוצה. מעכשיו הבדיקה נמשכת לאורך כל חיי המוצר.
ההסבר שלהם קצר ואני חושב שהוא נכון: המערכות האלה כבר לא מודל שעונה על שאלה. הן זוכרות, הן משתמשות בכלים, הן ניגשות לנתונים והן מבצעות פעולות בשם המשתמש. ולכן, במילים שלהם, הסיכון משתנה תוך כדי, כשהמערכת מתחככת במשתמשים, בסביבה ובמערכות אחרות.
מה שהשתנה בפועל בתקן: במקום להעריך מודל בודד, מיקרוסופט מנטרת עכשיו את מה שקורה בין המודלים, הסוכנים, הכלים, הנתונים והאנשים. שלושת הדברים הקונקרטיים שהיא הוסיפה הם זהות לכל סוכן, הרשאות ברמת הכלי, וניטור של הפעולות עצמן.
היא גם הכשירה אלפי מהנדסים שלה בשני נושאים ספציפיים: מידול איומים על סוכנים (threat modeling, כלומר לשבת ולשאול מראש איך מישהו ינצל את המערכת הזאת לרעה) והגנה מפני prompt injection (הזרקת הוראות נסתרות לתוך תוכן שהסוכן קורא, בדיוק הנושא שכתבתי עליו כאן כשה-Defender התחיל לחסום מיילים כאלה).
ובצד הכלים היא שחררה AI Red Teaming Agent שמנסה לשבור מערכות AI, כלי הערכה לסוכנים, ומשהו בשם RAMPART שלוקח ממצא של צוות תקיפה והופך אותו לבדיקה חוזרת. יש גם ASSERT ו-Agent Control Specification, שמאפשרים להטמיע בקרה בתוך זרימת העבודה של הסוכן ולא רק סביבה.
ולמי שמתעניין בתקינה: מיקרוסופט קיבלה הסמכת ISO 42001 (תקן לניהול מערכות AI בארגון) על מוצרים כולל קופיילוט ו-GitHub Copilot, והקימה ברית של צוותי תקיפה חיצוניים עם 18 אוניברסיטאות בשש יבשות.
ומה בפועל עושים עם זה?
קודם כל, תכינו רשימה של הסוכנים שכבר פעילים אצלכם. לרוב הארגונים אין כזאת, ואי אפשר לנטר משהו שאתם לא יודעים שהוא קיים. אם אתם על קופיילוט, יש היום ייצוא נתונים שמראה מי בנה כל סוכן ומי ממשיך להשתמש בו, וזאת נקודת ההתחלה.
אחר כך, על כל סוכן ברשימה, שתי שאלות ולא שאלה אחת: לאן הוא מגיע, ומה הוא יכול לעשות. הרשאות ופעולות, לא איזה מודל רץ מתחת. זה בדיוק ההבדל בין מה שבודקים בסקר אבטחה לבין מה שקובע מה יקרה בפועל.
ותחליטו מי מקבל את ההתראה ומי מוסמך לעצור סוכן באמצע. ניטור בלי מישהו שמותר לו ללחוץ על הכפתור האדום הוא לוג, לא בקרה.
ועוד דבר קטן שקל לפספס: סוכן שקיבל חיבור חדש לפני חודש הוא כבר לא אותו סוכן שאישרתם. שווה לקבוע נקודת בדיקה חוזרת אחרי כל שינוי, ולא רק בהתקנה.
למי זה רלוונטי אצלכם
להנהלה, וזה הפעם הראשונה שאני כותב את זה על דוח ולא על פיצ'ר. הדוח הזה משנה את השאלה שנשאלת בישיבת ההיגוי. היא כבר לא "אישרנו את זה?" אלא "מי מסתכל על זה עכשיו?". לאבטחת מידע ול-IT, כי זהות לסוכן והרשאות ברמת הכלי הן עבודה שצריך לתכנן ולא סעיף בטופס. ולמי שאחראי על ההטמעה, כי זה בדיוק הרגע שבו כדאי לספור כמה סוכנים באמת רצים אצלכם.
ומה שתפס לי את העין הוא מי אומר את זה. מיקרוסופט היא שמוכרת לכם את הסוכנים, והיא זו שמודיעה שאישור חד פעמי לפני ההדלקה לא מגן על כלום. שני הדברים נכונים באותו זמן, וזה לא סותר. אבל אם החברה שבונה את הכלים החליטה שהמודל הזה לא מספיק לה, קשה להסביר למה הוא מספיק לארגון שרק מפעיל אותם. תבדקו מתי בפעם האחרונה מישהו הסתכל על הסוכנים שלכם אחרי שהם כבר עבדו.
מקורות: ההודעה הרשמית של מיקרוסופט, דוח השקיפות עצמו והסיקור של SecurityBrief.
רוצים את החדשות האלה פעם בשבוע במייל, עם ההקשר המלא? הניוזלטר השבועי Don't Panic.
