גבולות הגזרה של סוכן AI אינם נכתבים בפרומפט אלא במודל ההרשאות. הכלל המעשי שפרסמה Meta בנובמבר 2025, Agents Rule of Two, אומר שסוכן יכול לקיים לכל היותר שתיים משלוש התכונות: לעבד קלט לא מהימן, לגשת למידע רגיש, ולשנות מצב או לתקשר החוצה. סוכן שמקיים את שלושתן ניתן להפוך לכלי דליפת מידע באמצעות טקסט אחד מוזרק. מודל הרשאות טוב פועל בארבע שכבות — זהות, כלי, ארגומנט ותקציב — ומסמן מראש את הפעולות הבלתי הפיכות שדורשות אישור אנושי.
למה פרומפט הוא לא מנגנון אבטחה
ההוראה החוזרת ביותר בפרויקטים שאנחנו נכנסים אליהם היא משפט בסגנון: אל תמחק לקוחות, אל תשלח מיילים בלי אישור, אל תחשוף מידע פנימי. המשפט הזה יושב בפרומפט המערכת ומרגיש כמו הגנה. הוא לא.
פרומפט הוא הצעה סטטיסטית, לא הרשאה. הוא מתחרה על תשומת הלב של המודל מול כל שאר הטקסט שנכנס להקשר — כולל טקסט שהגיע ממקור חיצוני. ברגע שהסוכן קורא מייל, דף אינטרנט, קובץ שהלקוח העלה או תוצאה של כלי, הטקסט הזה נמצא באותו מרחב שבו נמצאות ההוראות שלכם. זה כל הרעיון של הזרקת פרומפט, וזו גם הסיבה שאין דרך לנסח את הבעיה החוצה.
ההפרדה הנכונה פשוטה: הפרומפט מגדיר כוונה, מודל ההרשאות מגדיר יכולת. מה שהסוכן לא יכול לעשות טכנית, הוא לא יעשה גם אם ישוכנע שצריך.
מבחן מהיר: אם ההגנה היחידה שלכם מפני פעולה הרסנית היא משפט בפרומפט, אין לכם הגנה. יש לכם בקשה מנומסת.
כלל השניים: המסגרת הפרקטית ביותר שיצאה עד היום
ב-1 בנובמבר 2025 פרסמה Meta מסגרת פשוטה במיוחד לעיצוב סוכנים בטוחים. היא מזהה שלוש תכונות, וקובעת שסוכן בסשן יחיד צריך לקיים לכל היותר שתיים מהן.
| התכונה | מה היא אומרת | דוגמה טיפוסית |
|---|---|---|
| A. קלט לא מהימן | הסוכן קורא תוכן שמישהו אחר שולט בו | מיילים נכנסים, טפסים, דפי אינטרנט, מסמכים שהועלו |
| B. גישה למידע רגיש | הסוכן יכול לקרוא נתונים פרטיים או מערכות פנימיות | CRM, מערכת שכר, בסיס ידע פנימי, תיבת דואר |
| C. שינוי מצב או תקשורת החוצה | הסוכן יכול לכתוב, לשלוח או לפרסם | שליחת מייל, קריאה ל-API חיצוני, עדכון רשומה, חיוב |
הסכנה נמצאת בצירוף של שלושתן. סוכן שקורא מייל נכנס (A), שולף נתוני לקוח מה-CRM (B) ויכול לשלוח מייל החוצה (C) הופך למכונת הוצאת מידע ברגע שמישהו שולח אליו מייל עם הוראה מוסתרת. התוקף לא צריך לפרוץ שום דבר; הוא צריך לכתוב טקסט.
Meta עצמה מדגישה שהכלל אינו קו סיום. הוא לא מגן מפני טעויות של הסוכן, מפני הזרקות שמובילות למידע שגוי בתשובה, או מפני הרשאות רחבות מדי בתוך אחד משני הצירים שנשארו. הוא כלי לצמצום התרחיש החמור ביותר, לא תחליף להגנה לעומק.
איך שוברים את הצירוף בפועל
ברוב המקרים לא צריך לוותר על יכולת; צריך לפצל אותה בין שני סוכנים או שני שלבים. אלה שלוש התבניות שעובדות.
| תבנית | מה מפצלים | מתי להשתמש |
|---|---|---|
| קורא ומבצע | סוכן אחד קורא קלט לא מהימן ומחזיר סיכום מובנה בלבד; סוכן שני פועל על הסיכום מול המערכות | עיבוד מיילים, טפסים, מסמכי לקוח |
| חתימה אנושית | הסוכן מקיים את שלוש התכונות אך פעולת ה-C עוברת דרך אישור אדם | כשלא ניתן לפצל את התהליך |
| ערוץ פלט סגור | הסוכן יכול לכתוב רק ליעדים ברשימת היתר קבועה מראש | דיווח פנימי, עדכון רשומות, יצירת טיוטות |
התבנית השנייה היא הנפוצה ביותר, והיא גם זו שנוטה להתקלקל: אישור שהופך לרפלקס מפסיק להיות בקרה. איפה בדיוק למקם את נקודת האישור ואיך לשמור עליה משמעותית מפורט במדריך האדם בלולאה.
מודל הרשאות בארבע שכבות
הרשאה לסוכן אינה שאלה בינארית של גישה למערכת. היא נבנית בארבע שכבות, וכל שכבה שנשמטת פותחת מחלקת כשלים שלמה.
| שכבה | השאלה שהיא עונה עליה | מה קורה כשהיא חסרה |
|---|---|---|
| זהות | בשם מי הסוכן פועל | פעולות מיוחסות לחשבון שירות אנונימי; אין ביקורת ואין שחזור |
| כלי | אילו פעולות בכלל קיימות עבורו | הסוכן מגלה יכולת שלא תוכננה לו, למשל מחיקה דרך כלי עדכון גנרי |
| ארגומנט | על מה מותר להפעיל את הפעולה | הכלי נכון והיקף הפעולה שגוי — עדכון על כל הרשומות במקום על אחת |
| תקציב | כמה, באיזה קצב, ועד מתי | לולאה שרצה מאות צעדים או אלפי קריאות לפני שמישהו שם לב |
שכבת הארגומנט היא זו שנשכחת הכי הרבה, והיא זו שגורמת לרוב הנזק בפועל. סוכן שקיבל הרשאה לעדכן סטטוס הזמנה ולא הוגבל בטווח, יכול לעדכן את כל ההזמנות. הכלל הפשוט: כל כלי כותב מקבל ולידציה על הארגומנטים בצד השרת, לא בהוראות למודל.
הזרקת פרומפט וניצול כלים: מה כבר קרה
OWASP פרסמה בדצמבר 2025 את רשימת עשרת הסיכונים ליישומים סוכניים. הסיכון שמסומן ASI02, ניצול והתעללות בכלים, מתאר בדיוק את המקרה שבו הסוכן משתמש בכלי מורשה בצורה הרסנית — והמיטיגציה שהיא ממליצה עליה היא הרשאות גרנולריות וולידציה קפדנית של הארגומנטים לפני ההרצה. זו אינה המלצה תיאורטית.
דוגמה קונקרטית: CVE-2025-59528 בפלטפורמת Flowise, המשמשת לבניית יישומים סוכניים בקוד נמוך, נבע מטיפול לא בטוח בהגדרות CustomMCP ואיפשר הזרקה והרצה של קוד JavaScript שרירותי. הפגיעות לא הייתה במודל. היא הייתה בשכבה שבין המודל לכלים — בדיוק המקום שרוב הצוותים מתייחסים אליו כאל אינסטלציה.
גם המפרט עצמו זז לכיוון הזה: הגרסה היציבה של Model Context Protocol מ-28 ביולי 2026 כוללת הקשחה של שכבת ההרשאות כאחד השינויים המרכזיים, לצד המעבר לפרוטוקול חסר מצב. מי שבונה שכבת כלים היום מתחיל מבסיס טוב יותר ממי שבנה אותה לפני שנה, אבל הבסיס אינו תחליף להחלטות שלכם.
מה סוכן לא עושה לבד — לעולם
הרשימה הבאה אינה תלוית תעשייה. אלה פעולות שהעלות של טעות בהן גבוהה מהעלות של חיכוך.
- העברת כסף. חיוב, זיכוי, החזר, שינוי תנאי תשלום.
- תקשורת החוצה בשם החברה. מייל ללקוח, הודעה, פרסום — טיוטה כן, שליחה לא.
- מחיקה או פעולה בלתי הפיכה. כל פעולה שאין לה כפתור ביטול.
- שינוי הרשאות. סוכן שיכול להרחיב את ההרשאות של עצמו הוא לא סוכן, הוא חור.
- פעולה על היקף רחב. עדכון המוני, ייצוא מסד נתונים, שינוי הגדרות מערכת.
- החלטה בעלת השלכה משפטית או רגולטורית. דחיית תביעה, סיווג עובד, מתן מחיר מחייב.
מה שמותר לסוכן לקרוא הוא שאלה נפרדת ולא פחות חשובה — סיווג המידע שמותר להזרים למודל מפורט במדריך סיווג המידע הארגוני.
איך זה נראה כשזה מיושם נכון
מודל הרשאות טוב הוא משעמם. הוא נראה כמו טבלה: לכל כלי יש בעלים, רמת סיכון, טווח ארגומנטים מותר, תקרת קריאות ליום, והאם הוא דורש אישור. הטבלה הזו נכתבת לפני הפרומפט הראשון ונבדקת בכל שינוי.
שלוש בדיקות שכדאי להריץ על כל סוכן לפני ייצור: לנסות להזריק הוראה דרך כל ערוץ קלט לא מהימן ולוודא שהיא לא מגיעה לכלי כותב; להריץ כל כלי כותב עם ארגומנט מחוץ לטווח ולוודא שהוא נדחה בצד השרת; ולהריץ את הסוכן עם מטרה בלתי אפשרית ולוודא שהוא נעצר בתקרת התקציב ולא ממשיך. שיטת העבודה המלאה לבדיקות האלה נמצאת במדריך ה-evals, והמבנה שעליו הכול יושב מוסבר באנטומיה של סוכן AI עסקי.
שאלות נפוצות
מה זה כלל השניים של Meta?
מסגרת אבטחה שפרסמה Meta בנובמבר 2025, שלפיה סוכן בסשן יחיד צריך לקיים לכל היותר שתיים משלוש תכונות: עיבוד קלט לא מהימן, גישה למידע רגיש, ויכולת לשנות מצב או לתקשר החוצה. צירוף של שלושתן הופך הזרקת פרומפט אחת לדליפת מידע.
האם אפשר למנוע הזרקת פרומפט לגמרי?
לא בשיטות הקיימות היום. כל טקסט שנכנס להקשר מתחרה על תשומת הלב של המודל, כולל טקסט ממקור חיצוני. לכן ההגנה אינה מניעה אלא הגבלת נזק: צמצום הרשאות, הפרדה בין קריאת קלט לבין ביצוע פעולה, ואישור אנושי לפעולות בלתי הפיכות.
מה ההבדל בין הרשאת משתמש להרשאת סוכן?
הרשאת משתמש נבדקת פעם אחת בכניסה ומניחה שיפוט אנושי לאורך הסשן. הרשאת סוכן צריכה להיבדק בכל קריאה, ברמת הכלי וברמת הארגומנט, מפני שאין שיפוט אנושי בין הצעדים. בפועל זה אומר ולידציה בצד השרת ולא הסתמכות על הוראות למודל.
איך מגבילים סוכן בלי להפוך אותו לחסר תועלת?
מפצלים במקום לחסום. סוכן קורא שמחזיר סיכום מובנה, וסוכן מבצע שפועל רק על הסיכום, שומרים על כל היכולת העסקית ומבטלים את הצירוף המסוכן. במקרים שבהם אי אפשר לפצל, מוסיפים נקודת אישור על הפעולה היוצאת בלבד.
מי צריך להיות הבעלים של מודל ההרשאות?
הגורם שיישא באחריות אם פעולה שגויה תצא החוצה — בדרך כלל בעל התהליך העסקי, לא צוות הפיתוח. הצוות הטכני מיישם, אך ההחלטה אילו פעולות בלתי הפיכות ואילו דורשות אישור היא החלטה עסקית.
