Agent Authorization — מי נותן ל-Agent הרשאה לעשות מה

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

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

נניח שיש Agent שמטפל בבקשות תמיכה: קורא כרטיסים, מציע פתרונות, ולפעמים מזכה לקוחות בהחזר כספי. מישהו נתן לו תפקיד "support-agent" עם הרשאת "refunds:write" — כי זה נוח, וכי אחרת צריך לבנות לוגיקת הרשאות מותאמת. חצי שנה אחר כך מתגלה שה-Agent זיכה לקוח אחד פי עשרה מהסכום שהיה אמור, כי פרומפט injection במייל תמיכה גרם לו "לחשוב" שזו הוראה לגיטימית. הבעיה כאן היא לא זהות — ידעו בדיוק איזה Agent ביצע את הפעולה. הבעיה היא Authorization: המודל ההרשאות היה גס מדי, סטטי מדי, ולא ידע להגביל "כמה" ו"באילו תנאים", רק "כן/לא" ברמת הפעולה.

Authentication מול Authorization — ולמה הבלבול ביניהם מסוכן

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

RBAC — נקודת ההתחלה שלא מספיקה לבד

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

ABAC ו-ReBAC — מודלים עשירים יותר להקשר

Attribute-Based Access Control (ABAC)

ABAC מחליט הרשאה על בסיס שילוב תכונות: מי מבצע הפעולה, על איזה משאב, באיזה הקשר (זמן, IP, ערוץ), ומה הפעולה. זה מאפשר לבטא בדיוק את הכלל "Agent X מותר לו לזכות עד 200 ש"ח, רק בעסקאות שהוא פתח בעצמו, רק בשעות עבודה" — כלל שקשה לבטא ב-RBAC טהור.

Relationship-Based Access Control (ReBAC)

ReBAC מבסס הרשאה על יחסים בגרף — "Agent מותר לו לגשת למסמך אם הוא שייך לפרויקט שהמשתמש ששלח את הבקשה חבר בו". זה רלוונטי במיוחד ל-Agents שעובדים על נתונים היררכיים או ארגוניים, ומתחבר לרעיון Knowledge Graphs כתשתית להחלטות הרשאה, לא רק לאחזור מידע.

ReBAC בפועל: דוגמה מעולם המסמכים הארגוניים

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

Capability-Based Security — הרשאה כאובייקט עובר

גישה שונה לחלוטין, שמתאימה טוב ל-Agents: במקום שהמערכת תבדוק בכל קריאה "האם למשתמש הזה יש הרשאה", ה-Agent מקבל capability token — אובייקט חתום שמייצג הרשאה ספציפית וממוקדת (למשל "מותר לקרוא למסמך מזהה 4471 פעם אחת, בתוקף 10 דקות"). זה הופך את ההרשאה למשהו שאפשר להעביר, לצמצם ולפוג בקלות, במקום מדיניות גלובלית שצריך להעריך מחדש בכל פעולה. capability tokens משתלבים טבעי עם function calling מאובטח, כשכל tool call נבדק מול capability ולא מול role כללי.

Just-In-Time Permissions — הרשאה שנוצרת לרגע, לא מראש

העיקרון החזק ביותר ל-Agents אוטונומיים הוא לא להעניק הרשאה קבועה מראש, אלא להנפיק אותה ברגע הצורך, בהיקף המדויק הנדרש, לזמן מוגבל. Agent שצריך לגשת למסד נתונים לצורך משימה קונקרטית מקבל טוקן עם scope שמכיל בדיוק את הטבלאות והפעולות הרלוונטיות למשימה הזו — לא "db:read/write" גורף. זה מצריך תשתית שיודעת לגזור scope מההקשר של המשימה בזמן אמת, בדרך כלל דרך מנוע מדיניות שיושב בין ה-Agent למשאבים.

{
  "capability": "refund.issue",
  "constraints": {
    "max_amount": 200,
    "currency": "ILS",
    "ticket_owner_only": true,
    "requires_approval_above": 500
  },
  "issued_for_task": "ticket-88213",
  "ttl_seconds": 600
}

הרשאות תלויות מקור נתונים — כשההקשר עצמו לא אמין

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

בדיקת מדיניות הרשאה כמו קוד (Policy Testing)

אחד המאפיינים שמייחדים ארכיטקטורת הרשאה בשלה הוא שהיא לא רק "קיימת" — היא נבדקת. בדיוק כמו שכל שינוי בקוד עובר טסטים, כל שינוי בכללי הרשאה צריך לעבור סוויטת בדיקות שבודקת תרחישי גבול: "האם Agent X עדיין לא יכול לגשת למשאב Y", "האם הסף החדש של 300 ש"ח לא פתח בטעות גישה למשהו אחר". זה קריטי כי שגיאות במדיניות הרשאה נוטות להיות שקטות — המערכת ממשיכה "לעבוד", היא פשוט מרשה יותר ממה שהתכוונו. ארגונים בשלים מריצים את בדיקות המדיניות כחלק מ-CI, כך שכל Pull Request שמשנה כלל הרשאה חייב לעבור את הסוויטה לפני מיזוג, בדיוק כפי שמתואר גם בCI/CD מותאם ל-AI.

ריבוי מדיניויות: כשכל Agent מגדיר הרשאות בעצמו

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

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

• הרשאה ברמת ה-API בלבד — נותנים ל-Agent מפתח עם הרשאת כתיבה מלאה על שירות, ומסתמכים על "הפרומפט יגביל אותו". פרומפטים הם הנחיה, לא בקרת גישה.
• אין הבחנה בין הרשאת קריאה לכתיבה בפעולות מורכבות — Agent שיכול לקרוא הכול לצורך RAG מקבל לפעמים בטעות גם יכולת כתיבה על אותם משאבים.
• הרשאות שלא פגות — טוקן שהונפק למשימה חד-פעמית נשאר תקף הרבה אחרי שהמשימה הסתיימה.
• התעלמות משרשראות האצלה — Agent A מעניק בפועל ל-Agent B הרשאות רחבות משלו כי אין אכיפה על "אי אפשר להאציל יותר ממה שיש לך" (no privilege escalation via delegation).

מה קורה כשמנוע ההרשאה עצמו לא בטוח

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

דוגמה מהשטח

במערכת שמטפלת בבקשות שירות באמצעות כמה Agents מתמחים, המעבר ממודל RBAC סטטי למודל היברידי — ABAC לקביעת scope כללי, ו-capability tokens חד-פעמיים לכל פעולת כתיבה רגישה — צמצם דרמטית את היקף הנזק האפשרי מכל פעולה בודדת, גם כשמודל השפה עצמו "טעה". זו בדיוק המטרה: לא למנוע כל טעות של המודל, אלא להגביל את הרדיוס שלה.

מקרה בוחן: הרשאות מדורגות לפי סוג לקוח

דוגמה שממחישה טוב את הצורך במודל הרשאה עדין: Agent שירות לקוחות שצריך להתנהג אחרת מול לקוח פרטי לעומת לקוח עסקי גדול. עבור לקוח פרטי, סף ההחזר האוטומטי יכול להיות נמוך וללא תנאים מיוחדים. עבור לקוח עסקי עם הסכם שירות (SLA) חתום, אותה פעולה עשויה לדרוש התייחסות לתנאי ההסכם הספציפיים שלו — משהו שקשה מאוד לבטא כתפקיד RBAC קבוע, אבל טבעי לבטא ב-ABAC שמעריך את תכונות הלקוח (contract_tier, sla_terms) כחלק מההחלטה. זה גם מדגים למה מודל הרשאה סטטי, שנבנה פעם אחת ולא מתעדכן, הופך עם הזמן לפער הולך וגדל בין המדיניות בפועל למדיניות העסקית הרצויה.

שאלות נפוצות

האם ABAC תמיד עדיף על RBAC ל-Agents?

לא בהכרח — RBAC פשוט יותר לתחזוקה ומספיק לתרחישים עם מספר קטן של תפקידים ברורים. ABAC/ReBAC משתלמים כשההרשאה תלויה בהקשר דינמי שלא ניתן לבטא כתפקיד קבוע.

מה זה privilege escalation בהקשר של Agents, ולמה זה שונה מבבני אדם?

אצל בני אדם privilege escalation הוא בדרך כלל ניצול באג. אצל Agents זה יכול לקרות גם דרך שכנוע לגיטימי-לכאורה — למשל Agent ששוכנע דרך תוכן חיצוני "לבקש" מ-Agent אחר בעל הרשאות גבוהות יותר לבצע פעולה בשמו.

איך זה מתחבר ל-Least Privilege?

Least Privilege הוא העיקרון; Authorization היא המנגנון שמממש אותו בפועל. בלי מודל הרשאה עדין, אי אפשר לאכוף Least Privilege מעבר לרמת "הכול או כלום".

מי אחראי להגדיר את מדיניות ההרשאות — צוות האבטחה או צוות הפיתוח?

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

האם capability tokens מתאימים גם לפרויקטים קטנים?

לרוב לא כדאי להתחיל שם — capability tokens מוסיפים מורכבות תשתיתית שמשתלמת בעיקר כשיש הרבה Agents ופעולות רגישות. לפרויקט קטן, ABAC פשוט או אפילו RBAC עם מספר תפקידים מצומצם בדרך כלל מספיק, עם אפשרות מעבר ל-capability tokens כשההיקף גדל.

איך יודעים מתי הגיע הזמן לעבור מ-RBAC ל-ABAC?

סימן ברור הוא כשמתחילים ליצור תפקידים דומים מאוד זה לזה רק בגלל הבדל בהקשר אחד ("support-agent-morning-shift", "support-agent-vip-only") — זה סימן שהמודל הבינארי של תפקידים כבר לא מבטא את ההיגיון האמיתי, וצריך מעבר לתכונות דינמיות במקום ריבוי תפקידים.

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

תגיות: Agent Authorization · RBAC · ABAC · Capability-based security · Just-In-Time Permissions · Zero Trust AI

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