Least Privilege ל-Agents — הרשאות מינימליות לכל כלי

מאת צוות מדיה דיל · 09.08.2026 · AI · 8 דק׳

כמעט כל Agent שנבנה מהר מקבל הרשאות רחבות 'כדי שיעבוד'. מדריך לעיצוב מודל הרשאות מדויק, כלי-אחר-כלי, כולל RBAC מול ABAC ו-JIT, שמצמצם את הנזק כשמשהו משתבש.

הדרך הכי מהירה לגרום ל-Agent "לעבוד" היא לתת לו מפתח API אחד עם הרשאות admin לכל מה שהוא עשוי להזדקק לו - מסד נתונים, שירותי ענן, מערכות פנימיות. זה גם הדרך הכי מהירה ליצור נקודת כשל קטסטרופלית: אם ה-Agent הזה מבצע פעולה שגויה, בין אם בגלל תקלה, הזיה (hallucination), או תקיפה, הנזק הפוטנציאלי נמדד בהיקף כל ההרשאות שיש לו - לא רק בהיקף המשימה שהוא באמת אמור לבצע. Least Privilege הוא העיקרון שקובע: כל Agent, וכל כלי שהוא משתמש בו, מקבלים בדיוק את ההרשאות הדרושות למשימה הספציפית שלהם, ולא גרם אחד יותר.

מקורו של העיקרון, ולמה הוא לא חדש

Least Privilege אינו המצאה חדשה שנולדה עם AI - זהו עיקרון יסוד בתכנון מערכות מאובטחות עוד מהעשורים הראשונים של מחשוב ארגוני, ומיושם בכל דבר, ממתן הרשאות משתמש במערכת הפעלה ועד תפקידים (roles) בבסיס נתונים. מה שכן חדש עם Agents הוא קצב וגמישות ההרשאה הנדרשת. תפקיד אנושי בארגון מוגדר פעם, ולעיתים רחוקות משתנה. Agent, לעומת זאת, עשוי לבצע עשרות סוגי משימות שונות באותו יום, כל אחת עם צרכי הרשאה שונים במקצת - מה שהופך הרשאה "סטטית וקבועה" (כמו שמקובל למשתמשי אנוש) לפחות מתאימה, ומחייב חשיבה דינמית יותר על איך ומתי מעניקים כל יכולת.

למה זה קריטי יותר עם Agents מאשר עם קוד רגיל

עם שירות backend מסורתי, ה"כוונה" של הקוד קבועה - נכתבה על ידי מפתח ונבדקה. עם Agent מבוסס LLM, ה"כוונה" נגזרת בזמן ריצה מהפרומפט ומההקשר, ולכן היא פחות צפויה. Agent שמקבל הרשאת מחיקה מלאה על מסד נתונים "למקרה שיצטרך" עלול להשתמש בה גם כשלא היה צריך - בגלל טעות בפרשנות המשימה, בגלל הזרקת הוראה נסתרת, או פשוט בגלל שהמודל "פירש" בקשה מעורפלת בצורה רחבה מדי. ככל שההרשאות רחבות יותר, כך תחום ה"טעות האפשרית" גדול יותר.

RBAC מול ABAC: איזה מודל הרשאות מתאים ל-Agents

בעולם ההרשאות המסורתי יש שתי גישות עיקריות: RBAC (Role-Based Access Control) שמקצה הרשאות לפי תפקיד קבוע ("Agent מסוג תמיכה מקבל הרשאות X"), ו-ABAC (Attribute-Based Access Control) שמקצה הרשאות דינמית לפי תכונות הבקשה עצמה (מי המשתמש, מה ההקשר, מה רמת הסיכון של הפעולה הספציפית). עם Agents, ABAC מתאים בדרך כלל טוב יותר, כי המשימה של אותו Agent יכולה להשתנות מהותית מבקשה לבקשה - Agent תמיכה שמטפל בבקשת מידע כללית שונה לגמרי, מבחינת רמת הסיכון הנכונה, מאותו Agent שמטפל בבקשת החזר כספי. מודל RBAC סטטי ייטה "לתת לכל Agent מסוג X" את אותה רמת הרשאה קבועה, בעוד ABAC מאפשר לצמצם או להרחיב לפי ההקשר בפועל של כל קריאה - בדיוק העיקרון שדורש Least Privilege אמיתי, לא רק תיאורטי.

וקטור התקיפה: הרשאה רחבה שהופכת לנזק אמיתי

דוגמה נפוצה: Agent שמסייע בניתוח נתונים ומחובר למסד נתונים דרך חיבור עם הרשאות קריאה-כתיבה מלאות על כל הסכמה, כי "קל יותר לתת הרשאה אחת גורפת מאשר לנהל הרשאות בכל טבלה". כאשר המשתמש מבקש "תנקה רשומות כפולות בטבלת הזמנות", ה-Agent - שיש לו טכנית גישה לכל הטבלאות - עלול לפרש את המשימה בצורה רחבה מדי ולגעת בטבלאות קשורות (לקוחות, תשלומים) שלא היו אמורות להיות בטווח הפעולה. עם הרשאות מצומצמות לטבלה הרלוונטית בלבד, זה פשוט לא היה אפשרי מבחינה טכנית, ללא קשר לאיך המודל "פירש" את הבקשה.

איך בונים מודל הרשאות מינימלי - שכבה אחר שכבה

1. הרשאות ברמת הכלי, לא ברמת ה-Agent

במקום "ל-Agent יש גישה למסד הנתונים", מגדירים בדיוק אילו כלים (functions) הוא יכול לקרוא, ולכל כלי - איזה scope מדויק יש לו. כלי "read_orders" שונה מכלי "delete_order", וכל אחד עם הרשאה נפרדת ברמת התשתית, לא רק ברמת "המדיניות שהמודל אמור לכבד".

2. הרשאות דינמיות לפי הקשר המשימה

Agent שמטפל בבקשה של משתמש ספציפי מקבל הרשאה על הנתונים של אותו משתמש בלבד (row-level security), לא על כל מסד הנתונים. זה נכון גם ל-Agents פנימיים - אם המשימה היא "סכם את הפניות מהיום", אין סיבה שיהיה גישת כתיבה בכלל.

3. הפרדה בין קריאה לכתיבה, ובין כתיבה הפיכה לבלתי הפיכה

פעולות קריאה, פעולות כתיבה הפיכות (עדכון סטטוס), ופעולות בלתי הפיכות (מחיקה, שליחת כסף, שליחת מייל ללקוח) צריכות רמות אישור שונות. הבלתי הפיכות עוברות שער אישור אנושי כברירת מחדל.

4. Credentials קצרי-טווח במקום קבועים

טוקנים עם תוקף קצר שמונפקים לכל משימה בנפרד, ולא מפתח API קבוע ש"חי" לנצח וזמין לכל בקשה. פירוט בניהול Secrets ל-AI.

// דוגמת הגדרת כלי עם scope מצומצם
{
  "tool": "update_order_status",
  "scope": "orders:write:own_tenant",
  "allowed_transitions": ["pending->confirmed", "confirmed->shipped"],
  "requires_approval": false,
  "max_calls_per_session": 20
}
{
  "tool": "delete_order",
  "scope": "orders:delete",
  "requires_approval": true
}

Just-In-Time Privilege: הרשאה שנעלמת אחרי המשימה

שכבה נוספת שמשלימה את מודל ה-Least Privilege הסטטי היא Just-In-Time (JIT) Privilege Escalation - הרשאה שמורחבת זמנית, רק לאורך משימה ספציפית, ונעלמת אוטומטית ברגע שהמשימה הסתיימה או פג התוקף שהוגדר. במקום Agent שמחזיק כל הזמן הרשאת "delete_order" (גם אם היא לא בשימוש ברוב הזמן), הוא מבקש אותה נקודתית כשמשימה ספציפית דורשת זאת, מקבל אותה לחלון זמן קצר, ומאבד אותה מיד אחר כך. זה מצמצם משמעותית את "חלון הפגיעות" - גם אם ה-Agent נפגע, ברוב הזמן אין לו בכלל את ההרשאה המסוכנת להשתמש בה לרעה. המחיר הוא מורכבות נוספת בניהול בקשות ההרחבה עצמן, אבל עבור פעולות בעלות סיכון גבוה זה בדרך כלל שווה את ההשקעה.

Trade-offs: גרנולריות מול תחזוקה

ככל שההרשאות מדויקות יותר, כך יש יותר "טבלאות" הרשאה לתחזק - וזה עלול להפוך לעומס תפעולי כבד אם כל כלי חדש דורש הגדרת scope חדשה ידנית. הפתרון המעשי הוא לבנות טקסונומיה של רמות סיכון (קריאה בלבד / כתיבה הפיכה / כתיבה בלתי הפיכה) ולמפות כלים חדשים אליה באופן שיטתי, במקום להמציא כללים אד-הוק לכל כלי. זה גם מקל להטמיע מנוע מדיניות אחיד שכל הכלים עוברים דרכו.

חשוב גם לא להגזים לכיוון השני: הרשאות מצומצמות מדי גורמות ל-Agent "להיתקע" באמצע משימות לגיטימיות ולדרוש אישור אנושי בתדירות שהופכת אותו לא שימושי. המטרה היא צמצום מדויק, לא צמצום מקסימלי.

דוגמה מהשטח: Agent DevOps

Agent שעוזר לצוות תפעול לנטר ולתקן תקלות (self-healing infrastructure) מקבל בדרך כלל גישה נרחבת "כי הוא צריך לתקן דברים". בפועל, מודל הרשאות טוב מפריד: הרשאת קריאה מלאה על לוגים ומטריקות (סיכון נמוך), הרשאת הפעלה מחדש של שירות ספציפי מתוך רשימה מאושרת (סיכון בינוני, עם rate limit), והרשאת שינוי תשתית קריטית (רשת, IAM) שדורשת אישור אנושי תמיד. כך ה-Agent יעיל ברוב המקרים ובטוח גם כשהוא טועה.

דוגמה נוספת ומורכבת יותר היא Agent שמטפל בבקשות תמיכה טכנית ומחובר גם למערכת הכרטיסים וגם לתשתית הפרודקשן עצמה, כדי לבדוק לוגים כשמדובר בתקלה. כאן קל ליפול למלכודת "צריך לתת לו הרשאה רחבה כי אי אפשר לדעת מראש איזה שירות תהיה בו התקלה הבאה". הפתרון המעשי הוא לא הרשאה רחבה, אלא הרשאת קריאה (לא כתיבה) על כלל השירותים בסביבת הפרודקשן, בשילוב עם הרשאת כתיבה מצומצמת רק לפעולות "תיקון סטנדרטיות" מוגדרות מראש (הפעלה מחדש, ניקוי cache) - כל פעולה שחורגת מהרשימה הזו, גם אם היא נראית "הגיונית" בהקשר התקלה, עוברת לאישור אנושי. כך ה-Agent שומר על יכולת אבחון מלאה בלי לקבל יכולת שינוי בלתי מוגבלת.

איך מודדים אם רמת ההרשאות נכונה

שני כשלים נפוצים באותה מידה: הרשאות רחבות מדי (סיכון אבטחה), והרשאות מצומצמות מדי (Agent שכל הזמן "נתקע" וממתין לאישור, עד שהוא הופך ללא שימושי בפועל ואנשים עוקפים אותו). כדי לאזן בין השניים, כדאי לעקוב לאורך זמן אחר שני מדדים משלימים: שיעור הבקשות שנחסמו - אם הוא גבוה מדי, סימן שההרשאות מצומצמות מדי ביחס למשימות בפועל; ושיעור הפעולות בעלות סיכון גבוה שבוצעו ללא אישור - אם הוא לא אפס, סימן שההרשאות עדיין רחבות מדי במקום כלשהו. הכיוונון הזה הוא תהליך מתמשך שנשען על Audit Log מפורט, לא החלטה חד-פעמית בעיצוב הראשוני.

טעויות נפוצות

• "נתחיל עם הרשאות רחבות ונצמצם אחר כך" - כמעט אף פעם לא קורה בפועל, כי זה דורש מאמץ ייעודי שלא נראה דחוף עד שקורה אירוע.
• הרשאות משותפות בין סביבות - אותו מפתח API עם אותן הרשאות ב-staging וב-production.
• לבלבל בין "המודל הבטיח שלא יעשה X" לבין "המערכת לא מאפשרת לו טכנית לעשות X" - רק השני הוא אבטחה אמיתית.
• לא לבדוק מחדש הרשאות כשמוסיפים כלי חדש ל-Agent קיים - כל כלי חדש הוא הרחבת משטח תקיפה שדורשת בדיקה.

הקשר בין הרשאות ל-Guardrails

שווה להבהיר יחס שלעיתים מבלבל: Guardrails בודקים אם תוכן (קלט או פלט) עומד במדיניות - האם התשובה מכילה מידע פוגעני, האם הבקשה חורגת ממדיניות שיחה. הרשאות (Least Privilege) בודקות אם פעולה מותרת מבחינה טכנית - האם ל-Agent יש בכלל גישה לבצע אותה. אלה שני צירים שונים לגמרי, שיכולים לפעול בו-זמנית: תשובה יכולה לעבור את בדיקת ה-Guardrails (התוכן תקין) אך הפעולה שהיא מציעה יכולה להיחסם ברמת ההרשאות (אין ל-Agent גישה לבצע אותה). מערכת בטוחה צריכה את שתי השכבות במקביל - אחת לא מחליפה את השנייה.

שאלות נפוצות

איך מתחילים ליישם Least Privilege ב-Agent קיים שכבר יש לו הרשאות רחבות?

ממפים את כל הפעולות שה-Agent ביצע בפועל בפרק זמן משמעותי (מה-Audit Log), ומצמצמים את ההרשאות לקבוצת הפעולות שבאמת נדרשה, פלוס מרווח סביר. זה תהליך הדרגתי, לא מתג בינארי.

האם צריך שער אישור אנושי לכל פעולת כתיבה?

לא. רק לפעולות בלתי הפיכות או בעלות השפעה משמעותית. פעולות כתיבה שגרתיות והפיכות יכולות לרוץ אוטונומית עם ניטור.

מה ההבדל בין Least Privilege ל-Zero-Trust?

Least Privilege הוא עיקרון על "כמה גישה לתת". Zero-Trust הוא מודל רחב יותר שכולל גם "איך מאמתים כל בקשה". פירוט מלא במדריך Zero-Trust ל-AI Agents.

האם זה רלוונטי גם לכלים פנימיים בין Agents במערכת Multi-Agent?

כן, ואפילו יותר - במערכת Multi-Agent כל Agent צריך הרשאות מצומצמות משלו, כי Agent אחד שנפגע לא צריך להעניק גישה לכל השאר.

עיצוב מודל הרשאות מדויק ל-Agents הוא עבודה שמשלבת הבנת המשימה העסקית עם ידע אבטחה מעשי. צוות מדיה דיל בונה את זה כחלק מפרויקטי פתרונות AI - מוזמנים לפנות בוואטסאפ.

תגיות: Least Privilege · AI Agents permissions · scope-based access · tool permissions · approval gates · agent security

← חזרה לבלוג · צור קשר