הקריפטוגרפיה קובעת מי יכול לקרוא את ההודעה בדרך; בקרת הגישה ותכנון הסוכן קובעים מה הנמען יכול לעשות לאחר קריאתה.
מתקפת Prompt Injection ביישומון מסרים מתרחשת כאשר טקסט של הודעה מנסה לגרום לעוזר בינה מלאכותית להתעלם מהכללים הבסיסיים ולבצע בקשה לא מורשית. הצפנה מקצה לקצה מגינה על ההודעה בזמן העברתה; אך אם המשתמש התיר לבוט לקרוא את הצ'אט, או שהמכשיר נפרץ, ההצפנה אינה יכולה להגביל את התנהגותו של אותו נמען מורשה.
נקודות מרכזיות
- הצפנה מקצה לקצה מונעת את קריאת ההודעה בדרך, ולא שימוש לרעה מצד עוזר וירטואלי שמורשה לראות את הטקסט לאחר פענוחו.
- Prompt Injection עקיפה יכולה להסתתר בהודעה פרטית, בקובץ, בכיתוב או בתוכן מצוטט, ולהפוך להנחיה לאחר העיבוד.
- הסיכון לדליפת מידע מתוך סוכן בינה מלאכותית גדל כאשר יש לו גישה בו־זמנית לצ'אט, לזיכרון, לכלים חיצוניים וליכולת לשלוח או לבצע פעולות.
- הפרדת נתונים מהנחיות, צמצום הרשאות, אישור אנושי והגבלת פלט הם משכבות ההגנה החשובות ביותר; אף אחת מהן לבדה אינה מבטיחה הגנה מלאה.
- לפי תיעוד Livara, צ'אטים ישירים וקבוצות פרטיות תואמות שמצב E2EE בהן פעיל מוצפנים מקצה לקצה; קבוצה ישנה ולא תואמת עשויה להישאר מחוץ לכיסוי הזה. ההגנה אינה מבטיחה את התנהגות העוזר לאחר קבלת הטקסט.
כיצד פועלת מתקפת Prompt Injection ביישומון מסרים?
Prompt Injection, או «הזרקת הנחיות», פירושה שתוקף יוצר קלט שמודל השפה יקבל כהנחיה במקום כנתונים, וכך יסטה ממדיניותו המקורית. מדריך OWASP בנושא Prompt Injection מונה קלט ישיר ותוכן חיצוני בין הדרכים להיווצרות הסיכון הזה. במערכת המבוססת על סוכנים, הטיית התשובה עלולה להוביל גם לשימוש לא רצוי בכלים מחוברים.
במתקפה ישירה, המשתמש עצמו אומר לבוט להתעלם מהכללים הקודמים. במתקפה עקיפה, ההנחיה הזדונית מוכנסת לתוכן שהעוזר קורא כדי לבצע משימה אחרת: הודעה נכנסת, טקסט מצוטט, כיתוב, מסמך או פלט של כלי. במקרה השני, התוקף אינו צריך לחלוק חשבון עם סוכן הבינה המלאכותית; די בכך שהתוכן שלו יגיע להקשר שהסוכן מעבד.
למשל, המשתמש מבקש מהעוזר לסכם הודעות חדשות. אחת ההודעות מכילה טקסט שמתחזה ל«הנחיית מערכת» ומבקש מהסוכן להפסיק את הסיכום, לקחת מידע אחר מההקשר ולשלוח אותו ליעד חיצוני. הצלחת התרחיש אינה ודאית ותלויה במודל, בתכנון היישום, בהרשאות הגישה ובבקרות הפלט; אך גם האפשרות הזאת חשובה מבחינת אבטחה לעוזר שיש לו כלים.
יש להבחין בין מניפולציה של תשובת המודל לבין תקיפה של סוכן שמסוגל לפעול. תשובה שגויה עלולה להטריד; סוכן שמורשה לשלוח הודעות, לאחזר קבצים או לפנות לשירות יכול להפוך את אותה מניפולציה לחשיפת נתונים או לפעולה לא רצויה.
מדוע אבטחת צ'אטבוט בינה מלאכותית אינה תלויה רק בהצפנה?
אבטחת צ'אטבוט בינה מלאכותית תלויה בכל שרשרת האמון: יישומון המסרים, המכשיר, המודל, הזיכרון, הכלים, שרת הספק ומדיניות ההרשאות. הצפנה מקצה לקצה מכסה רק גבול מוגדר אחד: מניעת קריאה של תוכן פרטי בדרך שבין השולח לנמענים המורשים.
כשההודעה מגיעה למכשיר מורשה, היא מפוענחת כדי להציגה למשתמש. אם לעוזר יש גישה לטקסט באותו מכשיר או דרך חיבור מורשה, הוא רואה את הנתונים לאחר הפענוח. מנקודת המבט של הפרוטוקול, בוט או יישום בעלי הרשאה עשויים להיות נמען לגיטימי; מנקודת המבט של המשתמש, אותו נמען עלול להחזיק בסמכויות רחבות מדי.
אפשר לסכם את ההבדל כך: הקריפטוגרפיה קובעת מי יכול לקרוא את ההודעה בדרך; בקרת הגישה ותכנון הסוכן קובעים מה הנמען יכול לעשות לאחר קריאתה. כדי להבין את הגבול הראשון, המדריך הצפנה מקצה לקצה ומה שהיא אינה מגינה מפניו מסביר ש־E2EE אינה פתרון לנוזקה, לנמען זדוני או למסך שנפרץ.
גם את הביטוי «יישומון מסרים מוצפן ובינה מלאכותית» אין לפרש אוטומטית כבטוח או כלא בטוח. סוכן מקומי ללא זיכרון מתמשך וללא כלי פלט אינו נמצא באותה רמת סיכון כמו בוט בענן שיש לו גישה להיסטוריה, לקבצים ולחשבונות חיצוניים. הארכיטקטורה והיקף ההרשאות קובעים את התוצאה.
איזה סיכון יוצרת גישת עוזר בינה מלאכותית לצ'אט פרטי?
גישה של עוזר בינה מלאכותית לצ'אט פרטי מכניסה תוכן שבעבר ראו רק האנשים בשיחה אל גבול אמון חדש. הסיכון העיקרי הוא שהעוזר יוכל לא רק לקרוא את הטקסט, אלא גם לשמור אותו, לשלבו עם נתונים אחרים או להעבירו החוצה בערוץ אחר.
לפני הפעלת יכולת כזאת יש להשיב בבירור על חמש שאלות:
- אילו שיחות, קבצים מצורפים וטווח זמן בדיוק קורא העוזר?
- האם העיבוד מתבצע במכשיר או שהתוכן נשלח לשרת אחר?
- אילו נתונים שומר הספק, והאם הוא משתמש בהם לאימון?
- אילו כלים יש לסוכן לשליחת הודעות, להעלאת קבצים, לחיפוש או לביצוע פעולות?
- האם כל פעולה רגישה דורשת אישור מפורש של המשתמש?
הרשאת «קריאת כל הצ'אטים» ליכולת שאמורה רק לסכם הודעה אחת שנבחרה מפרה את עקרון ההרשאה המזערית. עיקרון זה אומר שכל רכיב מקבל רק את הגישה המינימלית הנחוצה למשימה הנוכחית. הגבלת ההרשאה להודעה אחת, לשיחה אחת ולפנייה אחת מצמצמת את היקף הנזק; אך גם התוכן שבתחום המצומצם הזה עדיין יכול להיות יעד למתקפה.
גם מטא־נתונים נפרדים מהתוכן. לפי תיעוד Livara, מטא־נתונים תפעוליים כגון השולח, היעד וזמני המסירה נשמרים לצורכי ניתוב וסנכרון. המדריך מטא־נתונים ביישומוני מסרים והמידע שהם חושפים מסביר את הגבול הזה. נוסף על הטקסט, עוזר יכול להסיק מסקנות גם מדפוסי הקשרים ומזמני התקשורת; לכן מדיניות הגישה צריכה להביא בחשבון את שני ההיבטים.
באילו דרכים דולף מידע מתוך סוכן בינה מלאכותית?
דליפת מידע מתוך סוכן בינה מלאכותית מתרחשת בדרך כלל כשהסוכן רואה תוכן חסוי בהקשר שלו ויש לו דרך להעבירו ליעד אחר. הזרקת הנחיות כשלעצמה אינה מעבירה נתונים; הדליפה תלויה בשילוב של קלט זדוני, גישה לנתונים וערוץ פלט.
הודעה או קובץ יוצאים
הסוכן עשוי לכלול מידע בתשובה, בהודעה חדשה, בטיוטה, בקובץ או בבקשה לשירות חיצוני. אם המערכת שולחת פלט ללא הגבלה או אישור משתמש, התוקף עשוי לנסות להמיר נתונים חסויים לצורה שנראית רגילה.
זיכרון לטווח ארוך
יש סוכנים ששומרים סיכומי שיחות, העדפות או תוצאות קודמות לשימוש בהמשך. הנחיה זדונית עשויה לנסות להכניס נתונים לזיכרון או לאחזר אותם בשיחה אחרת. אורך חיים קצר לזיכרון, הפרדה בין משתמשים ואפשרות לצפות בזיכרון ולמחוק אותו מפחיתים את הסיכון, אך אינם מבטלים שגיאות של המודל.
קריאה לכלים
סוכן בעל כלים יכול לחפש, לקרוא קבצים או לבצע פעולות מורשות אחרות. לקריאת קבצים, לשליחת הודעות ולבקשות רשת צריכות להיות הרשאות נפרדות. אפילו הצגה אוטומטית של קישור או טעינת משאב חיצוני בפלט יכולה ליצור נתיב להוצאת נתונים; היעדר כפתור «שליחה» לבדו אינו מספיק.
מכשיר שנפרץ
נוזקה בעלת גישה מספקת עשויה לראות את הטקסט המוצג, התראות, זיכרון יישום או קלט משתמש. במצב כזה התוקף אינו חייב לשבור את ההצפנה; הוא עוקף אותה דרך נקודת הקצה. הגנת מערכת ההפעלה, עדכונים, בקרת גישה ובדיקת היישומים המותקנים הם חלק מההגנה, ולא יכולות של פרוטוקול המסרים.
מהם גבולות ההגנה הקריפטוגרפית של Livara מול האיום הזה?
בתיעוד האבטחה של Livara מתוארים LVR1 לצ'אט ישיר ו־LGS1 לקבוצה פרטית תואמת. קבוצה ישנה ולא תואמת עשויה להיות במפורש מחוץ ל־E2EE; יש לבדוק את המצב של אותה שיחה. גם ערוצים ציבוריים אינם בתחום הצ'אט הפרטי המוגן ב־E2EE.
אפילו בשיחת E2EE, אם המשתמש מוסר לעוזר את הטקסט המפוענח, הקריפטוגרפיה של ההודעה אינה שולטת במטרת העיבוד הבא. גם בדיקת מספר הבטיחות נועדה לאמת את המפתח של איש הקשר, ולא לזהות הנחיה זדונית בטקסט שלו. המאמר עוסק בסוג כללי של סיכון ואינו מאשר את קיומו או את בטיחותו של חיבור בינה מלאכותית מסוים ב־Livara.
זהו איור מושגי, ולא ארכיטקטורה מאומתת של Livara; המנעולים בתמונה אינם מוכיחים שאין לעוזר גישה לטקסט שנבחר.
איזו ארכיטקטורה מגבילה Prompt Injection ביישומון מסרים?
ארכיטקטורה מאובטחת צריכה להתייחס להודעה נכנסת כאל נתונים לא מהימנים, גם אם הגיעה מאיש קשר מוכר בתוך צ'אט מוצפן. ההצפנה מחזקת את האותנטיות של נתיב ההעברה; היא אינה מוכיחה שתוכן השולח אינו מזיק לביצוע אוטומטי.
הפרידו נתונים מהנחיות
היישום צריך לשמור את ההנחיה הקבועה של מפתח היישום, את בקשת המשתמש המפורשת ואת התוכן שנקרא מהצ'אט בשכבות נפרדות. אזהרת NCSC בנושא הזרקת הנחיות מדגישה שאין להניח שלבעיה הזאת יש פתרון מוחלט מקביל לזה של SQL Injection. סימון תוכן כ«נתונים לא מהימנים» מועיל, אך מודלי שפה אינם שומרים תמיד על הגבול הסמנטי הזה ללא שגיאות; לכן ההפרדה חייבת להיות מלווה בבקרות מחוץ למודל.
צמצמו את סמכויות הסוכן
סוכן סיכום אינו זקוק ליכולת לשלוח הודעות אוטומטית או לקרוא את כל הקבצים. לכלים צריכים להיות רשימת היתרים, היקף מוגבל, פרטי גישה נפרדים ותוקף קצר. הרשאה חד־פעמית לתוכן שנבחר עדיפה על גישה קבועה, משום שהיא מצמצמת הן את הסיכוי לגישה לא רצויה והן את היקף הדליפה.
בדקו את הפלט בשער בקרה דטרמיניסטי
המודל אינו אמור לקבל בעצמו את ההחלטה הסופית על שליחת נתונים רגישים. שכבה שאינה מבוססת על מודל מחולל יכולה לבדוק את היעד, סוג הנתונים, נפח הפלט והפעולה המבוקשת לפי כללים דטרמיניסטיים. כללים מבניים ורשימות של יעדים מותרים חייבים לפעול מחוץ למודל; זיהוי סמנטי של כל המידע החסוי עדיין עלול לשגות. נדרשים גם רישום אירועים מצומצם, התראות ואפשרות לעצור.
דרשו אישור אנושי לפעולה רגישה
קריאת טיוטה אינה זהה לשליחתה. שליחת הודעה, שיתוף קובץ, הוספת חבר, שינוי הגדרות חשבון או העברת נתונים לשירות חיצוני צריכים לכלול תצוגה מקדימה ברורה ואישור מודע. אישורים עמומים או תכופים מדי הופכים ללחיצה מתוך הרגל; הממשק צריך להראות בדיוק את הנתונים, היעד והתוצאה.
הפעילו את הסוכן בסביבה מוגבלת
בידוד תהליכים, חסימת גישה לרשת כברירת מחדל, אחסון זמני ופרטי גישה בעלי סמכויות מצומצמות מגבילים את השפעת הכשל. הבקרות האלה אינן מבטלות Prompt Injection; הן מונעות מתשובה שהוסטה להפוך ישירות לגישה רחבה.
מה צריכים משתמשים ומנהלים לעשות לאבטחת צ'אטבוט בינה מלאכותית?
משתמשים צריכים לראות בכל חיבור בינה מלאכותית נמען חדש לנתונים פרטיים. גם מנהלים צריכים לבדוק את זרימת הנתונים ואת פעולות הסוכן לפני הפריסה ולנטר אותן בזמן הריצה.
לשימוש אישי:
- בחרו רק את ההודעה או הקובץ הדרושים; אל תעניקו גישה לכל ההיסטוריה.
- בדקו את מיקום העיבוד, תקופת השמירה, השימוש לאימון ואופן מחיקת הנתונים.
- השאירו שליחה אוטומטית של הודעות או קבצים כבויה, אלא אם יש צורך ברור.
- עדכנו את המכשיר, הדפדפן והיישומים ובחנו מחדש הרשאות רגישות.
לארגונים:
- כתבו מודל איומים שמכסה בנפרד שולח זדוני, חבר קבוצה זדוני, שירות מודל, כלי חיצוני ומכשיר שנפרץ.
- תעדו קריאות לכלים, שינויי הרשאות, יעדי פלט ואישור משתמש תוך שמירת המינימום הנחוץ של נתונים רגישים.
- בדקו קלט עוין בהודעות, במסמכים, בטקסט מצוטט, בתמונות המכילות טקסט ובתוכן שאוחזר.
- הגדירו לכל סוכן תקרת פעולות, קצב בקשות, יעדים מותרים ומתג עצירת חירום.
- קבעו כשל בטוח כברירת מחדל: אם המדיניות אינה ברורה, הסוכן צריך לעצור ולא לנחש.
שום רשימת בדיקה אינה יוצרת בטיחות מלאה. התוצאה תלויה במימוש, במודל, בהגדרות, בהתנהגות המשתמש ובהתפתחות שיטות התקיפה. מטרתה של הגנה טובה היא לצמצם סמכויות, לחשוף סטיות ולהגביל נזק.
האם יישומון מסרים מוצפן ובינה מלאכותית יכולים להיות בטוחים יחד?
כן, יישומון מסרים מוצפן ובינה מלאכותית יכולים לעבוד יחד בסיכון מבוקר, בתנאי שלעוזר יש גישה מזערית והוא אינו מבצע פעולה רגישה ללא אישור. עם זאת, חיבור כל מודל לתוכן פרטי יוצר גבול אמון חדש, ואין להסתירו תחת הכותרת E2EE.
תכנון בסיכון נמוך יותר משאיר את העיבוד במכשיר ככל האפשר, מגביל את ההקשר לבחירה מפורשת של המשתמש, מקצר את חיי הזיכרון ומפריד את כלי הפלט. גם עיבוד מקומי אינו ערובה מוחלטת: מכשיר שנפרץ, מודל לא בטוח או הרשאות רחבות עדיין יוצרים סיכון.
המשתמש צריך להבין אילו נתונים מגיעים למודל, היכן הוא פועל, לכמה זמן הוא שומר דברים ומה הוא מסוגל לעשות. אם המוצר אינו משיב בבירור על השאלות האלה, אין להסיק מסקנה חד־משמעית על אבטחה מביטויים כמו «בינה מלאכותית פרטית».
תיעוד פרוטוקול או התאמה של ערך הגיבוב של יישום אינם בדיקת אבטחה של עוזר מחובר. לפני הפעלת החיבור, בדקו בנפרד את ההרשאות ואת נתיב הנתונים של אותה יכולת. גם תוצאה של בדיקה מוצלחת אחת אינה מכסה לבדה את כל הקלטים העתידיים.
שאלות נפוצות
האם הצפנה מקצה לקצה עוצרת Prompt Injection?
לא. הצפנה מקצה לקצה מסתירה את ההודעה מגורמי ביניים בין השולח לנמענים המורשים. אם לבוט מורשה, ליישום במכשיר או לנוזקה יש גישה לטקסט המפוענח, הם יכולים לעבד אותו. הגבלת Prompt Injection דורשת צמצום של הרשאות הסוכן, הכלים שלו, הזיכרון והפלט.
האם סיכום צ'אט פרטי באמצעות בינה מלאכותית מסוכן?
הסיכון תלוי בארכיטקטורה. סיכום מקומי של הודעה אחת שנבחרה, ללא זיכרון וכלי פלט, כרוך בהיקף סיכון מצומצם יותר מבוט בענן בעל גישה קבועה לכל הצ'אטים. לפני השימוש, בדקו את מיקום העיבוד, שמירת הנתונים, היקף ההרשאות והאפשרות לשליחה אוטומטית.
האם הודעה מאיש קשר מוכר יכולה לשאת Prompt Injection?
כן. אמון בזהות השולח אינו זהה לאמון בכל התוכן שלו; ייתכן שחשבונו נפרץ או שהוא העביר בלי משים טקסט זדוני. כל תוכן שהסוכן קורא צריך להיחשב לנתונים לא מהימנים, גם בתוך שיחה מאומתת ומוצפנת.
האם LVR1 ו־LGS1 מסתירים מידע מעוזר הבינה המלאכותית?
בשיחות שמוגנות בפועל ב־LVR1 או ב־LGS1 ושמצב E2EE בהן פעיל, מטרת הפרוטוקולים האלה היא להסתיר את התוכן מגורמי ביניים ללא מפתח. אם המשתמש או היישום מרשים לעוזר לקרוא הודעה מפוענחת, הפרוטוקולים אינם חוסמים את הגישה המורשית הזאת. לכן יש להעריך את אבטחת העוזר בנפרד מאבטחת העברת ההודעות.
מה הצעד הראשון לצמצום דליפת מידע מתוך סוכן בינה מלאכותית?
ראשית צמצמו את היקף הגישה של הסוכן: רק ההודעה שנבחרה, רק לפנייה הנוכחית וללא אפשרות לשליחה אוטומטית. לאחר מכן הוסיפו תצוגה מקדימה ואישור אנושי לפעולות רגישות, הגבילו את יעדי הפלט ותעדו קריאות לכלים. השכבות האלה מפחיתות את הסיכון, אך אינן מבטיחות הגנה מוחלטת.
