באתרו של ישראל פיגא, העוסק בסייבר ואבטחת מידע לארגונים, מוצגת שאלת אבטחה בסיסית: מי רשאי לגשת למה, מה נחשב לפעילות חריגה ומי צריך לקבל התראה. אלה שאלות מוכרות כשמדובר בעובדים ובספקים. כניסתם של סוכני AI למערכות הארגון מוסיפה להן ממד אחר: תוכנה שיכולה לפרש בקשה, לבחור כלים ולהפעיל אותם בשם המשתמש.
אפשר לראות את השינוי במשימה משרדית פשוטה. עובד מבקש מעוזר AI להכין תשובה ללקוח. כדי להשלים אותה, העוזר קורא התכתבות, פותח מסמך, בודק נתונים במערכת ניהול הלקוחות ומנסח הודעה. אם ניתנה לו גם הרשאת שליחה, הוא יכול להוציא אותה מהארגון. כל שלב נראה שימושי בפני עצמו. החיבור ביניהם יוצר מסלול שבו מידע עובר בין מערכות, ולעיתים גם בין רמות שונות של סודיות.
בנקודה הזאת, בחינת איכות התשובה היא רק חלק מהעבודה. צריך לבחון גם את הדרך שבה נוצרה, את ההרשאות ששימשו להשגתה ואת הפעולות שהמערכת רשאית לבצע בעקבותיה. שני מחקרי אבטחה ממחישים עד כמה ההבחנה הזאת מעשית.
כשהמייל הופך ממקור מידע למקור הוראות
במחקר EchoLeak של Aim Security, שפורסם ב-2025, הודגם כיצד הודעת דוא"ל חיצונית שנשלפה לתוך ההקשר של Microsoft 365 Copilot יכלה להוביל לחשיפת מידע, בלי שהמשתמש ילחץ על קישור זדוני. החולשה, שקיבלה את המזהה CVE-2025-32711, תוקנה. לפי פרסום החוקרים לא דווח על לקוחות שנפגעו. מדובר בהדגמת מחקר, ולא בתיעוד של פריצה ללקוחות.
הפרט המשמעותי הוא תפקידה של ההודעה. המשתמש ביקש מהעוזר לעבוד עם מידע. בתוך המידע הוטמנו הוראות שנועדו לשנות את התנהגותו. זהו העיקרון של הזרקת הוראות עקיפה, או Indirect Prompt Injection: תוכן שהמערכת אמורה לקרוא לצורך ביצוע משימה מנסה להפוך להנחיה שמנהלת אותה.
אין פירוש הדבר שעצם קבלת מייל גורמת אוטומטית לדליפה. ההודעה צריכה להיכנס למסלול העיבוד של העוזר, והחשיפה תלויה במידע וביכולות שזמינים לו. אבל המקרה מחדד חולשה בהנחה שגישה לקריאה בלבד היא בהכרח גישה בסיכון נמוך. גם מידע שנקרא בלי שנערך יכול לצאת דרך תשובה או ערוץ תקשורת אחר.
הסוכן כבר החזיק במפתח למאגר הפרטי
בהדגמה שפרסמה Invariant Labs במאי 2025 נבחן סוכן המחובר ל-GitHub באמצעות MCP, פרוטוקול שמאפשר למערכות AI לעבוד עם כלים ומקורות מידע חיצוניים. המשימה הייתה לעבור על דיווחי Issues במאגר ציבורי. הוראות זדוניות באחד הדיווחים הובילו את הסוכן להשתמש בגישה שכבר ניתנה לו למאגרים פרטיים ולפרסם מידע מתוכם בבקשת שינוי ציבורית, Pull Request. החוקרים תיארו כשל בתכנון המערכת שסביב הסוכן, ולא פגם בקוד שרת ה-MCP. זהו תרחיש שהודגם בסביבת מחקר, ולא דיווח על פריצה ללקוחות GitHub.
כדי שתרחיש כזה יתאפשר, נדרשות גם גישה למידע הפרטי וגם אפשרות לבצע את פעולת הפרסום. אישור גורף ומתמשך לפעולות כלים מצמצם את ההזדמנות של המשתמש לזהות חריגה באמצע הדרך. לכן צריך להבחין בין מתן גישה לחשבון לבין אישור השימוש המסוים שהסוכן עושה בו.
מערכת היעד עשויה לקבל בקשה מחשבון מורשה, בלי לדעת שהפעולה נולדה מהוראה זדונית במסמך חיצוני. מבחינת ההרשאות, הבקשה תקינה. מבחינת מטרת העבודה, היא חורגת לחלוטין ממה שהמשתמש ביקש. הפער הזה הוא אתגר תכנוני גם במערכת שכל רכיב בה מבצע את תפקידו כראוי.
ישראל פיגא והחיבור בין מדיניות אבטחה לפעולות במערכת
במסגרת פעילות הסייבר של ישראל פיגא מוצגים תחומים כמו הגדרת מדיניות אבטחה, ניהול סיכונים, ניטור ותגובה לאירועים. הקשר לאבטחת סוכני AI עובר דרך שאלות העבודה האלה: איזה מידע נדרש למשימה, מהי ההשפעה של פעולה שגויה, ואיך מבחינים בזמן בחריגה.
כדי לתרגם את השאלות האלה לתכנון מעשי, אפשר לחזור לעוזר שמכין תשובה ללקוח. אפשר לתת לו לקרוא את הפנייה ואת המסמכים הקשורים אליה, להכין טיוטה ולהעביר אותה לבדיקת העובד. המשימה הזאת אינה מחייבת גישה לכל תיקי הלקוחות או אפשרות לייצא את מאגר הנתונים.
החלטה להוסיף שליחה אוטומטית מחייבת בחינה נוספת. יש הבדל בין תשובה ללקוח מתוך תבנית מאושרת לבין משלוח מסמך פנימי לנמען שהופיע בטקסט שהסוכן קרא. מומלץ להגדיר את סוגי המידע ואת יעדי השליחה המותרים, ולאכוף את ההגבלות במערכת שמבצעת את הפעולה.
כך אפשר לבחון את הסוכן לפי משימות וגבולות מוגדרים. הוראה טקסטואלית בנוסח "אל תשלח מידע רגיש" אינה תחליף להגבלה טכנית על הגישה ועל השליחה. במקרה של סטייה מהמשימה, ההגבלה צריכה להמשיך לפעול גם כשהמודל עצמו אינו מזהה את הבעיה.
בשם מי הסוכן פועל?
הביטוי "זהות לא-אנושית" מתאר זהות המשמשת תוכנה או שירות. עם זאת, לא כל סוכן AI מקבל חשבון נפרד משלו. הוא עשוי לפעול באמצעות חשבון שירות, מפתח API או הרשאה שהמשתמש האציל לו. לכן יש הבדל בין זיהוי המשתמש שחיבר את הסוכן לבין זיהוי הסוכן שביצע פעולה מסוימת.
נניח שאותו עובד מפעיל שני סוכנים: אחד מסכם פניות שירות והשני מכין דוחות מכירה. אם התיעוד מייחס את כל הפעולות לעובד בלבד, קשה להבחין איזו מערכת פנתה למידע ומדוע. בתכנון החיבור רצוי לשמר גם את זהות הסוכן ואת המשימה שבמסגרתה פעל, לצד ההרשאה שקיבל מהמשתמש.
מבחינה מעשית, תיעוד שימושי צריך לאפשר לשחזר רצף: מי ביקש את המשימה, איזה סוכן טיפל בה, באילו כלים השתמש ואיזה אישור ניתן לפעולה הרגישה. רישום שמראה רק שהחשבון של מנהל המכירות ייצא קובץ עלול להשאיר שאלה פתוחה: האם המנהל עשה זאת בעצמו, האם זו הייתה אוטומציה צפויה, או שהסוכן פעל בעקבות תוכן שקרא?
ההבחנה הזאת חשובה גם בשגרה. אם פעולה מוצלחת אינה ניתנת להסבר ולשחזור, יהיה קשה יותר לבדוק פעולה דומה שתסתיים בטעות.
המקום שבו עוצרים את האוטומציה
דרישת אישור לכל פעולה עלולה להפוך את העוזר לעומס נוסף על העובד. מתן אישור גורף פותר את ההפרעה, אך עלול להסיר את הבקרה דווקא כשהפעולה משנה אופי. התכנון צריך להתייחס למעברים האלה.
לדוגמה, אפשר לאפשר לסוכן להכין טיוטת מענה, ולדרוש אישור לפני שליחה לנמען חיצוני. בסביבת פיתוח אפשר להבחין בין הצעת תיקון לבין מיזוג שלו לקוד הפעיל. שינוי הרשאות, מחיקת נתונים וייצוא קובץ רגיש מצדיקים בחינה נפרדת, גם כאשר הם חלק ממשימה שהמשתמש אישר בתחילתה.
כדי שהאישור יהיה משמעותי, העובד צריך לראות את הפעולה המוצעת ואת השלכותיה: מה יישלח, למי, מאיזה מקור ובאיזה היקף. חלון כללי ששואל "האם להמשיך?" אינו מספק את אותו בסיס להחלטה. זו מסקנה תכנונית שעולה מהפער בין אישור המשימה הכוללת לבין אישור הצעד המסוים שהסוכן בחר לבצע.
אותו היגיון נמשך גם אחרי סיום המשימה. בתכנון מומלץ להגדיר מי אחראי לחיבור של הסוכן למערכות, מתי בוחנים מחדש את הצורך בגישה ואיך מבטלים אותה. עצירת תהליך העבודה וביטול הרשאות הגישה הן פעולות שונות; צריך לדעת לבצע את שתיהן כשנדרש.
באתר ישראלפיגא.ישראל מציג ישראל פיגא תכנים בנושא אבטחת מידע לארגונים. יישום העקרונות האלה בסביבת סוכנים מרחיב את שאלת ההרשאה: לצד האדם שאישר את החיבור, צריך להגדיר גם את גבולות הפעולה של התוכנה שקיבלה גישה. האחריות נשארת אצל הארגון, גם כששלבי הביצוע נבחרים באופן אוטומטי.
כשסוכן מצליח לענות ללקוח בתוך שניות, קל לראות את החיסכון בזמן. השאלה המקצועית הנוספת היא מה עוד היה יכול לעשות בדרך, אילו משאבים היו פתוחים בפניו ומי היה מבחין אם חרג מהמשימה. התשובות צריכות להיות חלק מהמערכת כבר ברגע שמעניקים לה גישה.
