68% מאנשי אבטחת המידע לא מזהים סוכן AI מתחזה

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

הנתון המדאיג שכולם מפספסים

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

אז מה בעצם קורה מאחורי הקלעים?

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

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

לאן האחריות נעלמת?

הסיפור הזה חושף בעיה עמוקה של אחריות (Accountability) בעולם סוכני ה-AI. האחריות על פעולה שבוצעה על ידי סוכן יכולה להתפזר בין גורמים רבים:

1. העובד שאישר פעולה בשלב האחרון – לכאורה, הוא החותם האחרון.
2. המנהל או המחלקה שקבעו את ההרשאות – הם אלה שהגדירו מה הסוכן יכול לעשות.
3. צוות ה-IT או הפיתוח שהטמיע את הסוכן – הם אחראים לתצורה הטכנית.
4. ספק הסוכן (Vendor) – שמספק את הפלטפורמה.

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

הפתרון? לתת לסוכן זהות משלו

כאן נכנס רעיון מרתק, שמזכיר אתגר מוכר מעולם הסייבר: הדואר האלקטרוני. לפני שנות ה-2000, כל אחד יכול היה לשלוח אימייל שהתחזה לבנק, לחברת האשראי או למנכ״ל. לא הייתה דרך אמינה לאמת את זהות השולח. הפתרון הגיע בדמות פרוטוקולים כמו DMARC, שמאפשרים לאמת את זהות השולח באמצעות רשומות DNS. חברות כמו Valimail, שאחד ממייסדיה ישראלי, הפכו את הטכנולוגיה הזו למיינסטרים.

ההצעה היא ליצור מנגנון דומה לסוכני AI. במקום שסוכן יפעל ״בשם״ העובד, הוא יקבל זהות ייחודית משלו (Agent Identity). זהות כזו תכלול:

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

שלב האישור הופך לשלב הבקרה

הפילוסופיה הזו משנה את התהליך כולו. נחזור לחשבונית. אם לסוכן יש זהות משלו, התהליך נראה כך:

1. הסוכן מזהה פער – ומעביר הצעה לתיקון עם כל הראיות.
2. העובד מקבל את ההצעה – וכאן מתרחש שלב האישור הקריטי. העובד בוחר לאשר או לפסול.
3. הפעולה מבוצעת – אבל הלוג מראה בבירור: ״סוכן X הציע, העובד Y אישר״.

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

הסיכום: לא עוד תקווה עיוורת

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

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