Delegated Authorization — מתן הרשאה זמנית לסוכן לפעול בשם המשתמש

מאת צוות מדיה דיל · 12.08.2026 · AI Security · 5 דק׳

איך מעניקים ל-Agent הרשאה לפעול בשם משתמש בלי להעביר אליו את הזהות עצמה - OAuth Token Exchange, שרשרת האצלה מבוקרת, וביטול מיידי כשמשהו משתבש.

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

ה-Flow הסטנדרטי: OAuth Token Exchange

הפתרון המבוסס בתעשייה הוא RFC 8693 - OAuth 2.0 Token Exchange, שמגדיר בדיוק את המקרה הזה: שירות A (ה-Agent) פועל בשם משתמש B מול שירות C (ה-API החיצוני), בלי שה-Agent יראה אי פעם את הסיסמה או את האסימון המקורי של המשתמש. במקום זאת, כשהמשתמש מאשר את ה-Agent, מונפק לו Access Token נפרד עם Scope מצומצם ("קריאה בלבד ליומן", לא "כל הרשאות Google") ותוקף מוגבל בזמן. כשה-Agent צריך לפעול, הוא מציג את האסימון הזה - לא את זהות המשתמש - ושרת ה-API בודק את ה-Scope שנחתם על האסימון, לא את מי שביקש אותו במקור. זה מבטיח שגם אם ה-Agent נפגע, מה שדולף הוא אסימון מוגבל בהיקף ובזמן, לא מפתח-על לכל חשבון המשתמש.

שרשרת האצלה: מה קורה כשה-Agent מאציל הלאה

בארכיטקטורת Multi-Agent, הבעיה מסתבכת: Agent ראשי מקבל הרשאה מהמשתמש, ואז מאציל חלק מהמשימה ל-Sub-Agent או לכלי חיצוני. אם ה-Sub-Agent מקבל את אותו אסימון המקורי במלואו, נוצרת שרשרת אצלה בלתי מבוקרת - כל חוליה בשרשרת יורשת את מלוא ההרשאה, גם אם היא צריכה רק חלק קטן ממנה כדי לבצע את תת-המשימה שלה. הפתרון הנכון הוא צמצום Scope בכל שלב אצלה: כל חוליה מנפיקה לחוליה הבאה אסימון חדש שהוא תת-קבוצה קפדנית של מה שהיא עצמה קיבלה, לעולם לא רחב יותר. RFC 8693 תומך בזה ישירות דרך actor claim, שמתעד את כל שרשרת ההאצלה בתוך האסימון עצמו - כך שבכל רגע ניתן לדעת בדיוק מי האציל למי, ובאיזה Scope.

{
  "sub": "user_4471",
  "act": { "sub": "agent_calendar_v2" },
  "scope": "calendar.read",
  "exp": 1723459200
}

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

ביטול: הנקודה שרוב המערכות שוכחות

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

הבדל חד מ-Authorization כללי: מי בעל הכוונה

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

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

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

מלכודת נפוצה: הרשאה שנשארת אחרי שהמשימה נגמרה

הטעות המעשית הכי שכיחה בהטמעה לא נמצאת בבחירת הפרוטוקול אלא במחזור החיים בפועל של האסימון אחרי שהמשימה שבשבילה הוא הונפק כבר הסתיימה. צוותים רבים מנפיקים אסימון עם Scope סביר ותוקף סביר - אבל שוכחים לבטל אותו ברגע שהמשימה המקורית הושלמה, כי אין Trigger טכני שמזכיר לעשות זאת. אסימון שנשאר תקף שבועיים אחרי שהמשתמש כבר קיבל את מה שביקש הוא חלון הזדמנות מיותר לחלוטין לתוקף פוטנציאלי, בלי שום תועלת תפעולית מקבילה. הפתרון המעשי: לצמד כל הנפקת אסימון מואצל למשימה קונקרטית עם תנאי סיום ברור (Task ID), ולהריץ Job תקופתי שסורק אסימונים "יתומים" - כאלה שהמשימה שלהם הסתיימה אך האסימון עצמו עדיין פעיל - ומבטל אותם אוטומטית. זו לא תוספת אקזוטית; זו בעצם אותה בעיה בדיוק שמופיעה בניהול הרשאות משתמשים אנושיים שעוזבים פרויקט ("Account שנשאר פעיל אחרי שהעובד עזב"), רק שקצב היווצרות המשימות אצל Agent גבוה בהרבה, ולכן גם קצב היווצרות ה"יתומים" הפוטנציאליים. מדד תפעולי פשוט שכדאי לעקוב אחריו: יחס בין מספר האסימונים הפעילים כרגע לבין מספר המשימות הפעילות בפועל - יחס שגדל עם הזמן מעיד כמעט תמיד על דליפת אסימונים יתומים שאף אחד לא מבטל.

תגיות: Delegated Authorization · OAuth Token Exchange · RFC 8693 · on-behalf-of · scoped tokens · token revocation

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