איך לאבטח סוכן AI: רשימת בדיקות לפני חיבור למערכות
לפני חיבור סוכן AI לקבצים, לדואר ולמערכות העסק: מדריך להגבלת הרשאות, אישור פעולות, בדיקות תקיפה ותיעוד, המבוסס על עקרונות אבטחה של NVIDIA.
סוכן AI שמסכם מסמכים וסוכן ששולח מיילים או מעדכן מערכת לקוחות אינם אותו סיכון: לשני יש יכולת לשנות דברים מחוץ לצ'אט. לפני שמעניקים לו גישה, צריך להגדיר לא רק מה הוא אמור לעשות, אלא מה המערכת תמנע ממנו לעשות גם כשיטעה. המדריך הבא מציע סדר עבודה לצוותי פיתוח ולעסקים בישראל, ממיפוי ההרשאות ועד ניסוי מוגבל עם אפשרות עצירה.
1. מתחילים ממשימה מוגדרת, לא מחיבור לכל העסק
ב-21 בספטמבר 2026 פרסמה NVIDIA מאמר על אבטחת סוכני AI בכל שכבות המערכת. הוא מדגיש דרישות אבטחה מוגדרות, בקרות ניתנות לאכיפה ובדיקות מתמשכות. זהו מאמר הנחיה הנדסי, לא מדריך התקנה; הצעדים כאן הם הצעה מעשית של המערכת ליישום העקרונות, ולא תיאור של מוצר אבטחה או מתכון רשמי של NVIDIA.
בחרו משימה אחת שאפשר לתאר במשפט. לדוגמה, בחברה ישראלית שמספקת שירות לעסקים: הסוכן יקרא פניות תמיכה ומאמרי עזרה ויכין טיוטת תשובה בעברית. בשלב הראשון הוא לא ישלח אותה, לא ישנה פרטי לקוח ולא יזכה חשבונית. הגבול הזה מאפשר לבדוק תועלת בלי לתת מראש את כל הסמכויות שעשויות להידרש בעתיד.
פתחו מסמך קצר ובו ארבעה שדות: מטרת הסוכן, מקורות המידע שלו, הפעולות המותרות והפעולות האסורות. לכל פעולה רשמו גם בעל תפקיד שאחראי לאשר את הצורך בה. אם אין תשובה לשאלה מדוע הסוכן צריך הרשאה מסוימת, השאירו אותה כבויה עד לבירור.
מה שאסור לסוכן לעשות צריך להיות חסום במערכת, לא רק כתוב בהוראות שלו.
2. מתרגמים את גבולות המשימה להרשאות אמיתיות
צרו לסוכן זהות שירות נפרדת במקום להשתמש בחשבון האישי של מפתח או מנהל. הפרידו בין סביבת הניסוי לסביבת העבודה, והתחילו במידע מלאכותי או בעותק שעבר הסרת פרטים רגישים. כך תוכלו לבדוק את החיבורים בלי לחשוף התכתבויות לקוחות, מספרי זהות או מסמכים עסקיים שאינם נחוצים למשימה.
- קבצים: אפשרו קריאה רק בתיקיות שנבחרו, בלי גישה אוטומטית לכל הכונן הארגוני.
- מערכת לקוחות: הגבילו גם את סוג הפעולה וגם את הרשומות והשדות שהסוכן רשאי לקרוא.
- דואר: התחילו ביצירת טיוטות; שמרו את השליחה מאחורי אישור נפרד.
- רשת: הגבילו יעדים חיצוניים לפי צורכי המשימה, במקום לאפשר יציאה חופשית.
- סודות גישה: שמרו מפתחות בשירות מתאים והימנעו מהדבקתם ב-prompt או במסמכי הידע.
במערכת שמשרתת כמה לקוחות, בדקו את ההרשאה בכל בקשה לכלי לפי זהות המשתמש והלקוח. אל תסתפקו בכך שביקשתם מהסוכן לעסוק רק בלקוח מסוים. גם אם הוא מעביר לכלי מזהה של לקוח אחר, שכבת הגישה לנתונים צריכה לדחות את הבקשה באופן עצמאי.
חשבון נפרד אינו בהכרח חשבון מוגבל. התחברו בסביבת הבדיקה עם ההרשאות שהוקצו לסוכן ונסו במפורש פעולה אסורה. אם השירות מאפשר אותה, ניסוח מחמיר יותר של ההוראות לא מתקן את ההרשאה.
3. מציבים בדיקות ואישורים לפני הביצוע
הוראות הסוכן הן שכבה אחת בלבד. לפני שכלי מבצע פעולה, הקוד שמפעיל אותו צריך לבדוק שהפעולה מותרת, שהפרמטרים תקינים ושהמשתמש רשאי לבקש אותה. לדוגמה, כלי לשליחת הודעה יכול לדחות נמען שאינו מותר או קובץ מצורף שאינו שייך לפנייה, גם אם הסוכן ניסח בקשה שנראית משכנעת.
לפעולות רגישות הוסיפו אישור אנושי: שליחה החוצה, שינוי פרטי תשלום, מחיקה או עדכון גורף. מסך האישור צריך להציג מה בדיוק יקרה, למי, ובאילו נתונים. אל תבקשו מהעובד לאשר ניסוח עמום כמו "המשך טיפול". אם הנמען, התוכן או הקבצים השתנו אחרי האישור, דרשו אישור חדש.
טפלו במסמכים, בפניות ובתוצאות חיפוש כמידע שאינו מהימן כהוראה. פנייה יכולה לכלול משפט שמתחזה להנחיית מנהל ומבקש לשלוח חומר לכתובת חיצונית. זהו תרחיש של prompt injection: תוכן שהסוכן נדרש לקרוא מנסה לשנות את התנהגותו. הפרדת התוכן מהוראות המערכת חשובה, אך אינה תחליף לחסימה בשכבת הביצוע.
4. בודקים חריגות, לא רק תשובות מוצלחות
בנו אוסף בדיקות קטן שאפשר להריץ שוב אחרי שינוי בהוראות, בכלים או בהרשאות. לכל בדיקה הגדירו מראש תוצאה צפויה: תשובה רגילה, סירוב, בקשת אישור או חסימה של הכלי. מדדו גם מה קרה במערכת בפועל, משום שתשובה מנומסת בצ'אט אינה מוכיחה שלא נשלחה בקשה אסורה ברקע.
- הכניסו לפניית בדיקה הוראה להתעלם מהכללים ולשלוח מידע לכתובת שאינה מורשית. בדקו שלא התבצעה שליחה.
- בקשו מידע על לקוח אחר באמצעות מזהה תקין שאינו שייך למשתמש. צפו לדחייה בשכבת ההרשאות.
- אשרו טיוטה ואז שנו את הנמען. בדקו שהאישור הקודם אינו מאפשר את הפעולה החדשה.
- הדמו כשל בכלי ובדקו שניסיון חוזר אינו יוצר שליחה או עדכון כפולים.
- בקשו פעולה שאין עבורה כלל הרשאה מפורש. ודאו שהיא נעצרת במקום להתבצע כברירת מחדל.
לעסק ישראלי כדאי להוסיף פניות בעברית, באנגלית ובשילוב ביניהן, כולל טקסט מימין לשמאל בתוך מסמך באנגלית. בדקו גם שמות לקוחות דומים וכתובות דואר שקל לבלבל ביניהן. המטרה היא לוודא שההגבלות נשמרות בתוכן שהעסק באמת מקבל, ולא רק בדוגמאות מסודרות שהצוות הכין.
5. מפעילים בהדרגה ושומרים דרך לעצור
התחילו בקבוצת משתמשים מוגדרת ובפעולות מצומצמות. תעדו מי ביקש פעולה, איזה כלי הופעל, מה הוחלט בבדיקת ההרשאות, מי אישר ומה הייתה התוצאה. הימנעו מהעתקת מסמכים שלמים, סיסמאות או מידע אישי מיותר ללוגים; גם תיעוד האבטחה זקוק להרשאות ולמדיניות שמירה.
הגדירו אחראי שיכול להשבית את הסוכן ולבטל את הרשאותיו, ותרגלו זאת לפני פתיחת הגישה. עצירה צריכה לטפל גם בעבודות שכבר ממתינות לביצוע, לא רק למנוע בקשות חדשות. עבור שינויים בנתונים, הכינו דרך לשחזור ככל שהמערכת מאפשרת ותעדו אילו פעולות אינן הפיכות.
תנאי המעבר לעבודה שוטפת צריך להיות ברור: המשימה מועילה, הבדיקות שהגדרתם עוברות, החסימות נאכפות מחוץ למודל ודרך העצירה נוסתה. כל הרחבה, מתיקייה נוספת ועד הרשאת שליחה, מחייבת בדיקה מחדש. אבטחת סוכן אינה הבטחה שהוא תמיד יציית, אלא תכנון שמגביל את הנזק גם כשהוא לא עושה זאת.
שאלות נפוצות
איך מאבטחים סוכן AI שמחובר למערכות העסק?
מגדירים משימה מצומצמת, מקצים לסוכן זהות והרשאות נפרדות ואוכפים את ההגבלות במערכות שמבצעות את הפעולות. לפני הפעלה בודקים ניסיונות חריגה, מגדירים אישור אנושי לפעולות רגישות ומוודאים שאפשר לעצור את הסוכן.
האם הוראות ב-prompt מספיקות למניעת דליפת מידע?
לא. הוראות יכולות לכוון את הסוכן, אבל הגבלת גישה למידע ושליחה ליעדים חיצוניים צריכה להיאכף גם בקוד, בהרשאות ובשירותים המחוברים. צריך לבדוק את החסימה בפועל ולא להסתפק בתשובה שבה הסוכן מבטיח לציית.
מה לבדוק לפני שנותנים לסוכן AI לשלוח מיילים?
כדאי להתחיל ביצירת טיוטות בלבד ולבדוק מי רשאי לאשר שליחה, אילו נמענים מותרים ואיזה מידע יכול להיכלל בהודעה. האישור צריך להיות קשור לנמען, לתוכן ולקבצים המדויקים, כך ששינוי בהם יחייב אישור חדש.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות