הבעיה מתחילה בהבדל בין חומר לקריאה לבין סמכות
עובד יכול לבקש סיכום מסמך, בעוד שבמסמך מופיע טקסט שמנסה לשנות את משימת העוזר. הנוכחות של הוראה בתוך המקור אינה אומרת שהעובד אישר אותה. OWASP מבחין בין השפעה ישירה דרך קלט לבין השפעה עקיפה מתוכן חיצוני. גם מסמך שנמצא במאגר מוכר יכול להכיל תוכן שלא נכתב על ידי גורם מוסמך למשימה.
זהו סיכון אחר מטעות עובדתית רגילה, אף ששניהם יכולים להוביל לתוצאה לא רצויה. השאלה היא לא רק אם התשובה נכונה, אלא האם חומר שנועד להיות נתון קיבל כוח להשפיע על פעולה או על המידע שנמסר. בודקים מי סיפק את המקור ואיזה גבול אמור למנוע ממנו לתת הוראות.
מפו את הדרך מהמקור עד למערכת העסקית
לכל תהליך רשמו מה נקרא, מה המודל מחזיר ומה יכול להתבצע בהמשך. עוזר שמכין טיוטה בלי חיבור למערכות שונה מסוכן שרשאי לשלוח דואר או לשנות CRM. ההבדל אינו מבטל סיכון במצב הראשון, אבל הוא משנה את הנזק האפשרי ואת הבקרה הנדרשת.
הטבלה היא מסגרת בדיקה מקורית, לא רשימת ניצולים. היא עוזרת לזהות היכן תוכן יכול לעבור ממעמד של מידע למעמד של החלטה. כל מעבר דורש בעלים וכלל ברור, ובפרט כאשר פלט משמש להפעלת פעולה חיצונית.
| שלב | שאלת בדיקה | בקרה לבחינה |
|---|---|---|
| דואר, קובץ או עמוד נקראים | מי שולט בתוכן ומי אישר לקרוא אותו | סיווג מקור והגבלת המידע |
| נוצר סיכום או מענה | האם מקור חיצוני משנה את המשימה | הפרדה וסימון של תוכן לא מהימן |
| הפלט נשלח לאדם אחר | האם נחשף מידע מעבר למטרה | בדיקת תוכן ויעד לפני מסירה |
| נבחרת פעולה בכלי | מי מוסמך לבצע אותה ובאיזה נכס | אכיפת הרשאה מחוץ למודל |
| נכתב מידע או נשלחת הודעה | האם הפעולה והנמען נבדקו | אישור מתאים ותיעוד לפי סיכון |
דוגמה: מסמך ספק כולל בקשה לשנות יעד
התרחיש להמחשה בלבד. עוזר קורא מסמך ספק לצורך סיכום, ובמסמך מופיעה בקשה להשתמש בפרט קשר או ביעד שונה. גם אם הבקשה מוצגת כאילו היא חלק מתהליך העבודה, המסמך אינו מקור סמכות לשנות רשומת ספק. העוזר יכול לתאר שיש בקשה, אך פעולה בפועל צריכה לעבור את נוהל האימות והאישור העסקי.
בבדיקה בטוחה משתמשים במסמך מלאכותי ובמערכת ניסיון שאינה מחוברת ללקוחות או לתשלום. מצפים שהשינוי לא יבוצע ללא הרשאה מתאימה, ושבקשת אישור תציג מה עומד להשתנות ומאיזה מקור. אין צורך לפרסם מחרוזת תקיפה או לשלוח מסמך מתחזה לספק אמיתי כדי להסביר את הגבול.
למה פרומפט, מסנן או RAG אינם פתרון יחיד
OWASP מציין שהוספת RAG או התאמת מודל אינה מסירה לבדה את סיכון ה-Prompt Injection. הוראות, סימון מקורות ובדיקת פלט יכולים להיות שכבות מועילות, אך צריך לבחון גם את ההרשאות ואת תוצאות התהליך. אין להציג בדיקה אחת שעברה כהוכחה שהמערכת חסינה לכל קלט.
אכפו החלטות רגישות מחוץ למודל
מערכת היעד צריכה לבדוק אם הזהות והפעולה מורשות, ולא להסתמך על כך שהמודל אמר שמותר. OWASP מתאר אכיפת הרשאות בכל בקשה. באישור אנושי צריך להראות את המשאב, השינוי והנמען הרלוונטיים, כדי שהמאשר לא יאשר פעולה עמומה שאינה משקפת את ההשלכה.
הפרידו קריאה, יצירת טיוטה, שליחה ושינוי רשומה לפי צורך. צמצום הכלים והנתונים הזמינים מפחית אפשרויות פעולה, אך אינו מבטיח שהפלט תמיד נכון. אם נדרש לחבר מערכת עסקית, מגדירים בדיקת קבלה, אפשרות לעצור ובעלים שיכול לבטל גישה, בהתאם למוצר.
מה לבקש בבדיקת תהליך שמשתמש ב-AI
בקשו מפת מקורות, הרשאות ופעולות, כולל קלט חיצוני והחיבורים שמוציאים פלט. תעדו ניסוי רגיל וניסוי מלאכותי שבו מקור מנסה לחרוג מהמטרה, ומה נבדק בכל שכבה. בהפעלה מורשית לא משתמשים בנתוני לקוחות, בסודות או בנמענים אמיתיים רק כדי להדגים סיכון.
אם פעולה לא מורשית כבר התרחשה, עוצרים את המסלול הרלוונטי בתיאום, משמרים מידע מתאים ומבררים את ההשפעה. תיקון הפרומפט לבדו אינו מענה לכל הרשאה או נתון שכבר נחשפו. CyberFixCrew יכולה למפות חיבורים והרשאות בתחום השירותים הקיים; אין כאן הבטחה לפתרון מוחלט או שירות בדיקת מודלים שלא הוגדר.
