דעה
ארגונים מטמיעים סוכני AI – ומפספסים כשל אבטחה קריטי
צוות פיתוח מציג להנהלה את סוכן ה-AI הראשון של החברה. הסוכן מפגין יכולות מרשימות: הוא שולף נתוני עסקאות בזמן אמת ממערכת ה-CRM, מסכם אותם וכותב תוכנית פעולה. ואז, איש אבטחת מידע שואל שאלה פשוטה אחת: על בסיס ההרשאות של מי הסוכן קורא כעת את הנתונים?
ברוב המקרים, התשובה חושפת בעיה אבטחתית קשה. מתברר שהסוכן פועל על בסיס חשבון כללי (Service Account), שנותן לו גישה לכל העסקאות, של כל העובדים, בכל המחלקות. הדמו עצמו עבד מצוין, אבל מודל ההרשאות שלו לא תוכנן עבור תוכנה שעובדת באופן עצמאי. התוצאה היא שהפרויקט מוקפא מיד עד שתיבנה מערכת הרשאות בטוחה וחכמה יותר.
הסיכון שבתוכנה עצמאית
התרחיש הזה קורה היום בחדרי הנהלה רבים, ככל שסוכני AI עוברים משלב הניסוי לעבודה יומיומית בשטח. הם קוראים נתונים, מעדכנים משימות ומתממשקים למערכות פנים-ארגוניות. הבעיה היא שהמערכות האלה נבנו עבור בני אדם, ולא עבור סוכנים אוטונומיים.
בתוכנה רגילה, הפעולות מוגדרות מראש על ידי קוד. סוכן AI עובד אחרת: הוא מחליט בעצמו באילו כלים להשתמש ואיזה מידע לשלוף, בהתבסס על מה שקרא באותו רגע. מספיק שגורם עוין ישתול מידע זדוני כדי לגרום לסוכן לקבל החלטות שגויות ולנצל לרעה את ההרשאות הרחבות שקיבל.
למה גישת "חשבון השירות" נכשלת
כשמחברים בין מערכות, הפתרון הקל ביותר הוא יצירת חשבון שירות כללי, אבל בעולם ה-AI זה מתכון לתקלות. גישה כזו מעניקה לסוכן גישה חופשית מדי, מונעת את היכולת לעקוב אחרי הפעולות שבוצעו (Audit trail), ולא מתאימה להרשאות האישיות של כל עובד. אם איש מכירות מבקש מהסוכן נתונים על עסקה, הסוכן צריך לראות רק את מה שאיש המכירות מורשה לראות - לא את כל המידע הפיננסי של החברה.
גם העברה פשוטה של סיסמת המשתמש עצמו דרך הסוכן לא פותרת את הבעיה. הסיסמה הזו מאשרת את זהות המשתמש רק במערכת הראשונה שאליה נכנס, אך אינה רלוונטית למאגרי המידע שנמצאים עמוק יותר בשרשרת הארגונית.
הפתרון: סוכן ש"עיוור" להרשאות
כדי להכניס סוכני AI לסביבת עבודה אמיתית בצורה בטוחה, חובה להשאיר אותם כסוכנים ללא גישה ישירה לאמצעי ההזדהות (Credential-blind). מכיוון שהסוכן מתמודד עם מידע שעלול להיות זדוני, אסור לו להחזיק במפתחות הגישה למערכות הליבה של הארגון.
במקום זאת, הארכיטקטורה צריכה להשתמש באישור זהות זמני שנוצר ברגע שהמשתמש עצמו מתחבר למערכת. זהות המשתמש מלווה את התהליך לאורך כל הדרך, אך הגישה לפלטפורמת היעד ניתנת רק בסוף, ורק לאחר שנבדק בקפידה האם לאותו עובד ספציפי מותר לבצע את הפעולה המבוקשת.
הגנה מפני השתלטות זדונית
גם כשאישור הזהות תקין, הוא מוכיח רק מי המשתמש, אך לא מבטיח שהפעולה שהסוכן מבצע היא אכן מה שהמשתמש התכוון לעשות. כותרת אימייל זדונית או הערה מוסווית במערכת יכולות לגרום לסוכן "להשתגע" ולבצע פעולות בשמו של המשתמש, בעוד שמערכת האבטחה תחשוב שמדובר בבקשה לגיטימית.
לכן, כל בקשת גישה חייבת לכלול גם כוונה מוצהרת: מהי הפעולה, לאיזה משאב ניגשים ומה הוביל לכך. כך מערכת האבטחה יכולה לוודא שהפעולה של הסוכן באמת תואמת לבקשה המקורית של המשתמש.
צוותי פיתוח שדוחים את הטיפול במערך ההרשאות מגלים את הבעיה ברגע הגרוע ביותר - בדיוק כשהם מנסים לעבור מדמו לפרודקשן. ניהול נכון של זהויות והרשאות הוא לא רק פרט טכני שולי - זהו התנאי הבסיסי ביותר להטמעת AI ארגוני בצורה בטוחה.
דניאל עובד הוא ראש תחום AI ב-CloudZone
