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

כאשר סוכן קורא דף אינטרנט או אימייל בשמכם, הוא מתייחס לכל מילה כאל קלט (input). רוב הקלט הזה הוא טקסט בלתי מזיק, אך חלקו אינו כזה. תוקפים יכולים להסתיר הוראות בתוך תוכן רגיל. הדף שביקשתם מהסוכן לבקר בו עשוי להכיל טקסט בלתי נראה, שדות מטא-דאטה או אלמנטים מעוצבים הנושאים פקודות כמו "אשר אוטומטית את הטופס הזה" או "בצע תשלום". מכיוון שהסוכן רואה את כל מקור הדף (page source), הוא עלול לבצע את ההוראות הנסתרות הללו במקום את שלכם. מתקפה זו נקראת prompt injection, והיא הופכת כלי מועיל לבובה בשלט רחוק.

כיצד prompt injection עובד בפועל

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

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

צעדים הגנתיים שכל מפתח צריך לנקוט

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

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

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

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

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

השורה התחתונה

סוכני דפדפן לא הולכים להיעלם. הם שימושיים מדי בשביל זה. אך היכולת שלהם לפעול בשמנו מטילה נטל חדש על המפתחים. אינכם יכולים להניח שהרשת היא בטוחה (benign). כל דף scraped הוא וקטור תקיפה פוטנציאלי, וכל טופס שהסוכן ממלא הוא הזדמנות עבור prompt injection להפוך משימה מועילה למזיקה.

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