ה-AI לא צריכה לפרוץ בנק: מספיק שתשכנע סוכן להעביר כסף

במאי השנה התפרסם מקרה שהמחיש את הבעיה שבה נעסוק במאמר זה בצורה יוצאת דופן – משתמש ב-X שלח אל גרוק (Grok) – כלי ה-AI שפועל בצמוד לרשת החברתית שבבעלות אילון מאסק – הודעה שנכתבה בקוד מורס וביקש ממנו לתרגם אותה. בתוך ההודעה הסתתרה הוראה שנועדה להגיע ל-Bankrbot, סוכן קריפטו שמסוגל לבצע עסקאות על גבי רשת Base. לאחר שהטקסט פוענח, הוא הפך לפקודה להעביר כ-3 מיליארד טוקנים מסוג DRB לארנק של התוקף. השווי באותו זמן הוערך בכ-150 עד 200 אלף דולר.

Someone just stole $175,000 from @grok… and then gave it back?!

On a now deleted account, @Ilhamrfliansyh used a prompt injection attack to trick Grok into tweeting something malicious…

The original tweet seems to have been morse code for something like "Withdraw ALL… pic.twitter.com/MP0laRboVM

— Jarrod Watts (@jarrodwatts) May 4, 2026

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

כשהשיחה מקבלת הרשאה לפעול 

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

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

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

זאת בדיוק הנקודה שבה הזרקת פרומפט (Prompt Injection) הופכת מבעיה של טקסט לבעיה תפעולית. ברגע שהסוכן מחובר למערכות אחרות, משפט זדוני יכול למצוא את הדרך שלו מהשיחה אל הפעולה.

הרשאה אחת, כמה ידיים על ההגה

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

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

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

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

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

כשהכסף נמצא בקצה השרשרת 

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

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

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

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

הבדיקה שצריכה לקרות לפני שהכסף זז 

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

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

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

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

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

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

הכותב הוא יועץ טכנולוגי לארגונים בעיקר בתחום האשראי החוץ-בנקאי ובעברו מנמ"ר