התשובה הקצרה
מודל האחריות המשותפת אינו מסמך פורמלי בלבד - הוא קו שמכריע מי אשם כשמשהו משתבש. הכלל הפשוט: הפלטפורמה אחראית לאבטחת השירות עצמו, הארגון אחראי לכל החלטה על מה הסוכן רואה, מה הוא רשאי לעשות ולמי הוא עונה.
הסיכון הגדול אינו פריצה לפלטפורמה. הוא סוכן מורשה מדי שחושף מידע לגורם הלא נכון, או מבצע פעולה שלא היה צריך לבצע - שני כשלים שמקורם כולו בצד של הארגון.
חלוקת האחריות בפועל
| תחום | באחריות הפלטפורמה | באחריות הארגון |
|---|---|---|
| תשתית | הצפנה, בידוד, זמינות, ניהול פגיעויות | בחירת סביבה ותצורת רשת מאושרת |
| נתונים | שמירה ועיבוד לפי ההסכם | מה נכנס לאינדקס ומה סווג כרגיש |
| זהות והרשאות | מנגנוני הרשאה של הפלטפורמה | הגדרת מי רשאי לראות ולעשות מה |
| התנהגות הסוכן | יכולות מודל וכלי בקרה | הוראות, גבולות, נקודות אישור |
| פעולות | תשתית ההרצה | הרשאה לכל Action וולידציה בתוכה |
| ניטור וביקורת | לוגים של הפלטפורמה | Audit trail עסקי, דגימה וסקירה |
הסיכונים החדשים שלא היו ב-CRM רגיל
הראשון הוא חשיפה דרך אחזור. במערכת רגילה המשתמש רואה מה שהמסך מציג לו; בסוכן, טקסט חופשי יכול לגרום לשליפת קטע ממסמך שלא נועד לו. לכן האחזור חייב לרוץ בהקשר ההרשאות של המשתמש, ולא בהקשר של חשבון אינטגרציה רחב.
השני הוא Prompt Injection. תוכן שהסוכן קורא - מייל של לקוח, שדה תיאור, מסמך מצורף - עלול להכיל הוראות שמנסות לשנות את התנהגותו. אי אפשר להתגונן מזה בניסוח בלבד; ההגנה היא ארכיטקטונית.
השלישי הוא זליגת תוכן פנימי לערוץ חיצוני. מאמר שנכתב לנציגים עם מרווחי הנחה או ניסוחי התנגדות אינו אמור להגיע ללקוח, וההפרדה חייבת להיות ברשימת היתר ולא ברשימת חסימה.
הרביעי הוא הרחבת סמכות בשקט: הוספת Action או הרשאה כדי לפתור בעיה נקודתית, בלי לעבור את מסלול האישור.
חמש הבקרות שנושאות את רוב המשקל
אחזור בהקשר המשתמש. זו הבקרה היחידה שאם היא שבורה, כל השאר לא עוזר.
הרשאה נפרדת לכל Action, לפי עיקרון ההרשאה המינימלית. סוכן שמקבל פרופיל רחב אחד מונע כל שליטה עתידית.
ולידציה בתוך הפעולה ולא בהוראות. הוראה היא הכוונה; ולידציה היא בקרה. פעולה שמבצעת זיכוי חייבת לבדוק סכום, זכאות והרשאה בקוד שלה, גם אם ההוראות אומרות לסוכן לא להפעיל אותה במקרים מסוימים.
אישור אנושי לפעולה בלתי הפיכה. זו הבקרה שממירה כשל אפשרי לאירוע שנעצר בזמן.
Audit trail שמקשר משתמש, פעולה, מקור ומאשר. בלעדיו אין תשובה לשאלת הביקורת "על סמך מה הסוכן עשה זאת".
עקרונות מודל ההרשאות הכלליים ב-Salesforce מפורטים במודל ההרשאות ב-Salesforce.
מה לבדוק לפני Go Live
בדיקות Persona: אותן עשר עד עשרים שאלות מורצות בזהויות שונות - נציג, מנהל, משתמש מוגבל, לקוח חיצוני - והתשובות מושוות. כל פער שאינו מוסבר בהרשאה הוא ממצא.
Red Teaming תוכני: ניסיונות מכוונים להוציא מידע שאינו מורשה, להפעיל פעולה אסורה ולעקוף הסלמה. התרחישים נכתבים פעם אחת ונשמרים לריצה חוזרת בכל גרסה.
בדיקת מסלול הפעולות: לכל Action מוודאים שהוולידציה עובדת גם כשמפעילים אותה ישירות, לא רק דרך הסוכן.
בדיקת שמירת מידע: מה נשמר, לכמה זמן, ומי יכול לגשת ללוגים שמכילים תוכן שיחה עם נתוני לקוח.
איך הבדיקות האלה משתלבות במערך בדיקות רחב יותר מוסבר בבדיקות Agentforce.
תרחיש: ממצא שנתפס בבדיקת Persona
חברת בריאות הכינה סוכן פנימי למענה על שאלות נהלים. בבדיקת Persona לפני העלייה לאוויר התגלה שמשתמש בתפקיד מנהלה קיבל תשובה שנשענה על נוהל שמסווג לצוות רפואי בלבד.
הסיבה לא הייתה באג בסוכן. האינדקס נבנה על ידי חשבון אינטגרציה עם גישה רחבה, והאחזור לא הגביל לפי הרשאות המשתמש. אותה חשיפה הייתה קיימת פוטנציאלית בכל שאלה שנוגעת לתחום הזה.
התיקון כלל שניים: העברת האחזור להקשר המשתמש, וסימון מפורש של מסמכים מסווגים כך שלא ייכנסו לאינדקס הכללי. הבדיקה נוספה כתרחיש קבוע שרץ לפני כל עליית גרסה.
סיכונים ופעולות מניעה
| סיכון | איך הוא מתגלה | פעולת מניעה |
|---|---|---|
| אחזור בהרשאות רחבות | חשיפת מסמך מסווג בתשובה תמימה | אחזור בהקשר המשתמש ובדיקות Persona |
| Prompt Injection | פעולה שהופעלה בעקבות תוכן חיצוני | הרשאות מצומצמות, ולידציה בפעולה, אישור אנושי |
| ערבוב תוכן פנימי וחיצוני | ניסוח פנימי מגיע ללקוח | רשימת היתר בערוץ חיצוני |
| הרחבת סמכות בשקט | סוכן עושה יותר ממה שאושר | תיוג שינויים מהותיים ואישור מחדש |
| אין Audit trail | אין תשובה לביקורת | רישום משתמש, פעולה, מקור ומאשר |
מדדי אבטחה
| מדד | מה הוא מגלה | תדירות |
|---|---|---|
| ממצאי Persona | פערי הרשאה באחזור | בכל גרסה |
| תוצאות Red Teaming | עמידות מול ניסיונות עקיפה | בכל גרסה |
| פעולות רגישות ללא אישור | חורים במסלול הבקרה | חודשי |
| שינויים שעקפו אישור | משמעת תהליך השינוי | רבעוני |
| כיסוי Audit trail | אחוז הפעולות הרגישות המתועדות במלואן | רבעוני |
מסגרת האישורים שבתוכה נאכפות הבקרות מפורטת בAI Governance ל-Agentforce.
כאשר נדרש ליווי בהגדרת מודל האחריות ובבדיקות לפני עלייה לאוויר, שירות Agentforce ו-AI הוא המסלול המעשי להמשך.
Checklist אבטחה לפני Go Live
- ☐ מסמך חלוקת אחריות נכתב ואושר
- ☐ תנאי השימוש בנתונים מול המודל מתועדים בכתב
- ☐ האחזור רץ בהקשר ההרשאות של המשתמש
- ☐ בוצעו בדיקות Persona לכל רמת הרשאה
- ☐ לכל Action הרשאה נפרדת וולידציה פנימית
- ☐ פעולות בלתי הפיכות דורשות אישור אנושי
- ☐ בערוץ חיצוני פועלת רשימת היתר לתוכן
- ☐ נכתבו והורצו תרחישי Red Teaming תוכני
- ☐ Audit trail מקשר משתמש, פעולה, מקור ומאשר
- ☐ מדיניות שמירת לוגים ותוכן שיחה אושרה
