tool calling agent: תכנון הרשאות לפי פעולה (Action-level RBAC)

כש‑ה־ai agent מקבל יותר מדי כוח: למה הרשאות לפי פעולה הן החגורה והכתפיות של עידן הסוכנים

אי שם באמצע יום עבודה שגרתי, מנהל מוצר בחברת פינטק ישראלית הבחין במשהו מוזר. ה־ai agent החדש שהטמיעו רק שבוע קודם — agent חכם שמבצע פעולות אוטומטיות במערכת הבנקאית שלהם — התחיל לבצע סדרת קריאות ל־API שלא תוכננו. לא משהו דרמטי, לא פריצה, לא כותרת ראשית. אבל כן היה שם שינוי בהרשאות לקוח שלא היה אמור לקרות בכלל. זה לא היה האקר. זה לא היה מפתח רשלן. זו הייתה… אוטומציה. או יותר מדויק: סוכן חכם, tool calling agent, שקיבל קצת יותר מדי חופש. מכאן מתחיל הסיפור של Action-level RBAC — תכנון הרשאות לפי פעולה. לא עוד “לתת בוט גישה לטבלת משתמשים”, אלא לשאול: איזה ai agent רשאי לעשות איזו פעולה ספציפית, באיזה הקשר, ולא פחות חשוב — באיזה *לא*. ברגע שעוברים מ־chatbot נחמד לקצה של מערכת הפעלה עסקית מופעלת בידי ai agent, משחק ההרשאות משתנה לגמרי.

מה זה בעצם tool calling agent — ולמה הוא דומה למתכנת חדש בצוות

כולנו כבר הכרנו צ’אטבוטים. שואלים שאלה, מקבלים תשובה. זה נוח, זה חמוד, זה אפילו יעיל. אבל tool calling agent זה משהו אחר. כאן מדובר ב־ai agent שלא רק מדבר, אלא גם *עושה*. הוא קורא לפונקציות, מפעיל APIs, מעדכן דאטהבייסים, פותח קריאות שירות, יוצר מסמכים, מעבד תשלומים. אם תרצו: לא עוד “מודל טקסט”, אלא סוג של מתכנת junior אוטונומי, שיושב על חיבור ישיר למערכות הייצור שלכם. וכמו כל מתכנת חדש בצוות — השאלה הראשונה היא לא “כמה הוא גאון”, אלא “מה *מותר* לו לעשות”.

ai agent שיודע לקרוא כלים: מתנה או סיכון מובנה?

הקסם של tool calling agent הוא היכולת שלו לבחור לבד איזה כלי להפעיל ומתי. מודל השפה מחליט: עכשיו צריך לשלוף נתוני לקוח, אחר כך לעדכן סטטוס הזמנה, ובסוף לשלוח מייל. הכול לבד, על בסיס התיאור הטקסטואלי של המשתמש. מהצד הטכנולוגי זה מדהים. מהצד הארגוני־אבטחתי — זה כמעט מתכון לסיפור ב־Post Mortem. במערכות מסורתיות, RBAC (ניהול הרשאות לפי תפקיד) הגיוני כשמדובר בבני אדם: מנהל מכירות, נציג שירות, מנהל מערכת. לכל אחד סט של הרשאות. אבל ai agent הוא לא “תפקיד” קלאסי. סוכן אחד יכול לתפקד בתוך כמה הקשרים שונים, לבצע פעולות מסוגים שונים, עבור מחלקות שונות — לפעמים תוך כמה שניות. וזה בדיוק המקום שבו Action-level RBAC נכנס לתמונה.

Action-level RBAC: לא אילו טבלאות מותר, אלא אילו פעולות מותר

תכנון הרשאות לפי פעולה (Action-level RBAC) מסתכל על המערכת לא כמאגר טבלאות, אלא כאוסף של **פעולות עסקיות**. לא “הרשאה לגשת לטבלת לקוחות”, אלא: - מותר ל־ai agent לבצע: - `GetCustomerSummary` - `UpdateCustomerAddress` - אסור ל־ai agent לבצע: - `UpdateCustomerCreditLimit` - `CloseCustomerAccount` כלומר, הזזנו את יחידת ההרשאה מהמשאב (resource) אל ה־action, אל הפעולה העסקית עצמה.

למה זה מתאים בדיוק לעולם של סוכנים חכמים

tool calling agent עובד בצורה טבעית עם פעולות: הוא מקבל “תיאור” של פונקציות (tools), ובוחר מה להפעיל. אז אם מראש מגדירים את כל ה־tools כפעולות עסקיות מובהקות, קל הרבה יותר לבנות מדיניות הרשאות ברורה. במקום לתת גישה גורפת ל־“customer_service_api”, מגדירים עשרות פעולות קטנות ומקצועיות, וכל ai agent מקבל סט מוגדר, מדויק, כמעט כירורגי של פעולות מותרות. התוצאה? טעויות עדיין יכולות לקרות — הן תמיד קורות — אבל הנזק הפוטנציאלי מצטמצם דרמטית.

הפער הפסיכולוגי: למה אנחנו עדיין נותנים לבוטים יותר גישה ממה שהיינו נותנים לבני אדם

באופן קצת מוזר, ארגונים מתייחסים לפעמים ל־ai agent כמו ל”משתמש־על” מופשט. “נו, זה רק בוט, הוא לא באמת ‘משתמש’”. וכאן מתחילה הבעיה. בפועל, tool calling agent הוא משתמש לכל דבר. משתמש זריז, חכם, אוטומטי — אבל משתמש, עם יכולת לבצע פעולות בעולם האמיתי. לפעמים אפילו מהר יותר מבני אדם, ועם פחות מחסומים פסיכולוגיים. תחשבו על זה: - עובד חדש שמקבל גישה לייצור עובר הדרכה, חותם על נהלים, מכירים אותו. - ai agent חדש? מישהו מגדיר לו permissions בקובץ JSON, וזהו. לא בגלל רוע, אלא בגלל אינרציה. מודלים חכמים עדיין נתפסים כ”פיצ’ר”, לא כ”משתמש מערכת”. Action-level RBAC מנסה להחזיר אותנו לקרקע: אם היית נותן את ההרשאה הזו לבן אדם — היית ישן טוב בלילה? אם לא — למה אתה נותן אותה ל־ai agent שפועל 24/7, בלי עייפות, בלי ציניות, ובלי חוש הומור שיעצור אותו ויסתכל פעם שנייה?

איך זה נראה בפועל: מיפוי פעולות, לא רק APIs

ניקח רגע דוגמה קצת פרוזאית, אבל מאוד אמיתית: מערכת CRM ארגונית שבה רוצים להטמיע ai agent לשירות לקוחות. הנטייה הראשונית תהיה: “בואו ניתן ל־agent גישה ל־‘Customer API’ ול־‘Ticket API’ ונגמור עניין”. אבל בעולם של Action-level RBAC, השאלה היא לא לאילו APIs הוא ניגש, אלא: - האם מותר לו לפתוח קריאת שירות חדשה על שם הלקוח? - האם מותר לו למחוק קריאת שירות קיימת? - האם מותר לו להחזיר כסף ללקוח ללא אישור? ואם כן — עד איזה סכום? - האם מותר לו לעדכן את כתובת המשלוח? מה לגבי מספר תעודת זהות? פתאום, אנחנו לא מגדירים “access level” גס, אלא **רשימת פעולות מאוד ספציפית**, שכל אחת מהן היא tool בפני עצמו.

ai agent רב־יכולות: סוכן אחד, כמה פרסונות הרשאה

עכשיו השאלה מסתבכת עוד קצת: מה קורה כשאותו ai agent עובד גם מול שירות לקוחות, גם מול גבייה, וגם מול מכירות? אם נחשוב עליו כ”משתמש” אחד — מהר מאוד נקלע לבלגן. או שהוא יקבל מעט מדי גישה ולא יהיה אפקטיבי, או יותר מדי גישה והפחד יחזור. הפתרון שעולה בשנים האחרונות בעולם הסוכנים הוא להפריד: לא ai agent אחד עם הרשאות גורפות, אלא סוכן אחד, עם **פרופילי הרשאה שונים לפי הקשר**. - כשמשתמש פונה מתצוגת “שירות לקוחות” — ה־agent עובד עם סט פעולות מוגבל אחד - כשאיש מכירות מפעיל אותו ממסך מכירה — הוא פתאום “לובש” פרופיל אחר, עם פעולות אחרות כלומר, Action-level RBAC לא חי רק ברמת “מי הסוכן”, אלא גם ברמת “מאיפה ולשם מה הוא פועל”.

השאלה שלא מדברים עליה מספיק: למי הסוכן *לא* צריך גישה?

עולם אבטחת המידע מלא בשאלות של “מה צריך לפתוח”. בעולמות ai agent, השאלה המעניינת יותר היא לפעמים ההפוכה: מה אנחנו *מסרבים* לתת לסוכן. למשל: - האם למוקדן וירטואלי מותר לראות מספרי כרטיסי אשראי מלאים? - האם ai agent שמסייע לעובד ב־HR יכול לגשת לקבצי שכר? - האם סוכן תפעול לוגיסטי רשאי לראות היסטוריית רכישות מלאה של לקוח — או רק הזמנות פתוחות? Action-level RBAC מאפשר לבנות “איזורי איסור" שהם לא רק טכניים, אלא גם אתיים ורגולטוריים. עם כל ההתלהבות מ־tool calling agent שמסדר לנו את החיים, צריך לזכור שלפעמים הדבר הכי חכם שהוא יכול לעשות — זה לא לדעת דברים מסוימים.

ישראל כמעבדה חיה: רגולציה, בנקים, וקצת חרדה בריאה

בישראל, אולי בגלל הגודל ואולי בגלל התרבות הארגונית הישירה, הרבה חברות נכנסות לעולמות ai agent די מהר. סטארטאפים מקומיים רצים לבנות סוכנים אוטונומיים, בנקים בודקים הטמעה פנימית, וגופי בריאות מתחילים לבחון מענה אוטומטי. אבל אנחנו גם יושבים על מצרף מעניין של רגולציה: - בנקאות תחת פיקוח הדוק של הפיקוח על הבנקים - בריאות תחת משרד הבריאות והנחיות פרטיות מחמירות - תחום הנתונים האישיים, שמתיישר בהדרגה עם ה־GDPR האירופי במציאות הזו, tool calling agent ללא Action-level RBAC הוא כמעט מתכון ליום רע ביומן. ארגון ישראלי שלא יגדיר במדויק איזה ai agent יכול לבצע איזו פעולה — מסתכן לא רק בטעות טכנית, אלא גם בהפרת רגולציה, פגיעה בפרטיות, ולעיתים גם אירוע תקשורתי לא נעים (וכאן כבר נכנסים עיתונאים אחרים לתמונה). מצד שני, ארגונים שמבינים מוקדם את הצורך באדריכלות הרשאות חכמה — מגלים משהו מפתיע: כשמתכננים את ה־actions נכון, אפשר להיות גם אמיצים טכנולוגית וגם שמרנים איפה שצריך.

איך בונים Action-level RBAC חכם ל־ai agent — לא כמדריך, אלא כתובנה

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

1. להתחיל מפעולות עסקיות, לא מקוד

במקום לשאול “מה ה־API שלנו מאפשר?”, כדאי להתחיל מ: מהן 30–50 הפעולות העסקיות המרכזיות שהארגון מבצע ביומיום, ושיכול להיות הגיוני לשים עליהן ai agent. לאחר שממפים פעולות עסקיות ברורות — רק אז מתרגמים אותן לפונקציות (tools), עם שמות חד־משמעיים. ההיפך (לכתוב פונקציות ואז לנסות להבין מה ההשלכות העסקיות שלהן) בדרך כלל מסתיים בהרשאות פרוצות מדי.

2. לחשוב ב”רמות רגישות” של פעולות

לא כל פעולה דומה לאחרת: - קריאה בלבד (“הצג סטטוס הזמנה”) — ברמת רגישות נמוכה יחסית - שינוי נתונים לא קריטיים (“עדכון כתובת למשלוח”) — בינונית - שינוי נתונים פיננסיים / משפטיים (“זיכוי לקוח”, “סגירת חשבון”) — גבוהה מאוד Action-level RBAC מאפשר לתייג כל פעולה ברמת רגישות, ולבנות סביב זה מדיניות. למשל: ai agent פנימי יכול לבצע באופן אוטונומי רק פעולות ברמת רגישות נמוכה־בינונית; פעולות רגישות דורשות אישור אנושי, או לפחות “dual control” בסגנון בנקאי.

3. להפריד בין הסוכן כמודל לבין ה־policy

אחד הלקחים המשמעותיים בעבודה עם tool calling agent הוא לא “לשרוף” את המדיניות בתוך הקוד. במקום לקמפל את מדיניות ההרשאות לתוך הלוגיקה עצמה, יותר חכם להחזיק policy חיצוני, שניתן לעדכן בלי לגעת בקוד של ה־agent. זה יכול להיות ב־YAML, JSON, או שירות מדיניות ייעודי. הרעיון הוא שכל שינוי בהרשאות (למשל, הוספת פעולה חדשה לסוכן שירות לקוחות) לא יצריך שינוי בקוד ה־ai agent עצמו, אלא רק ב־policy.

4. לזכור שלפעמים “לא” הוא פיצ’ר, לא באג

tool calling agent שיגיד “אין לי הרשאה לבצע את הפעולה הזו, אבל אני יכול להציע חלופה” — הוא לא סוכן חלש, הוא סוכן מתוכנן היטב. זה גם מסר חשוב למשתמשים בארגון: הai agent לא בא “לעקוף” את הכללים, אלא לעבוד לפיהם. באיזשהו מקום, עצם ההיתקלות במחסומי הרשאה היא חלק מהחינוך הארגוני לדור החדש של הכלים האלו.

שאלות ותשובות: מה כולם שואלים על ai agent ו־Action-level RBAC

האם כל ai agent חייב Action-level RBAC, או שזה מוגזם למקרים פשוטים?

לא כל בוט קטן צריך אדריכלות הרשאות מורכבת. אם יש לכם ai agent שעונה רק על שאלות ידע פנימיות, בלי שום גישה ל־tools או לנתונים חיים — אפשר להסתפק במינימום. אבל מהרגע שהסוכן מתחיל לבצע פעולות אמיתיות במערכות: לפתוח קריאות, לעדכן נתונים, להפעיל APIs — בלי Action-level RBAC אתם בעיקר בונים “משתמש־על” שקשה מאוד לשלוט בו.

האם Action-level RBAC מאט את הפיתוח והאימוץ של ai agent?

בטווח הקצר — כן, קצת. צריך לחשוב, לתכנן, להגדיר actions, לכתוב policy. בטווח הארוך — זה דווקא מאיץ. ארגונים שמקימים מראש שכבת הרשאות לפי פעולה יכולים להוסיף סוכנים חדשים, או להרחיב יכולות של tool calling agent קיים, בלי להיכנס כל פעם לדיון סבוך על כל הרשאה ספציפית. יש שפה משותפת, יש מסגרת.

איך מסבירים להנהלה למה צריך להשקיע בתכנון הרשאות לסוכנים חכמים?

אפשר לדבר על סיכונים, על רגולציה, על פרטיות — וזה נכון. אבל במקרים רבים, המסר הכי אפקטיבי הוא פשוט: “אנחנו נותנים ל־ai agent לבצע פעולות שבני אדם היו עושים עד היום. לכל עובד חדש אנחנו משקיעים בהגדרת הרשאות. פה מדובר במשתמש שיכול לפעול במהירות של מערכת, ב־24/7. לא לתת לו מודל הרשאות מדויק זה פשוט חוסר אחריות בסיסית”.

מה ההבדל בין Action-level RBAC לבין ACLs רגילות או הרשאות בטבלאות?

ACLs קלאסיות מדברות בדרך כלל על משאבים: טבלאות, קבצים, endpoints. Action-level RBAC מדבר על **פעולות עסקיות מוגדרות היטב** — שגם אם מתורגמות בסוף ל־API calls או לפעולות DB, מבחינת המדיניות הן “שחור על גבי לבן”: פעולה מסוימת, בשם ברור, עם משמעות עסקית אחת. זה הבדל קטן במבנה — וגדול מאוד בהבנה.

האם אפשר להנחות את ה־ai agent “לא לעשות דברים מסוימים” בלי להגדיר הרשאות?

אפשר, אבל זה שברירי. אפשר לכתוב ל־agent בהנחיות: “אל תעדכן קרדיט ללקוח בלי אישור”. מבחינה פרקטית, זה אומר שאנחנו סומכים על מודל שפה — מערכת הסתברותית — ש”יזכור” תמיד את ההוראה הזו, בכל הקשר, בכל ניסוח. Action-level RBAC מעביר את האחריות מהמודל אל התשתית: גם אם המודל “יחליט” לקרוא לפעולה אסורה, שכבת ההרשאות פשוט לא תאפשר לבצע אותה.

טבלה: עיקרי ההבדל בין גישת הרשאות קלאסית לבין Action-level RBAC עבור ai agent

היבט	RBAC / ACL קלאסי	Action-level RBAC ל־ai agent
יחידת ההרשאה	משאב (טבלה, קובץ, API כללי)	פעולה עסקית ספציפית (Action / Tool)
פרסונה עיקרית	משתמש אנושי או קבוצה	ai agent, לעיתים עם כמה הקשרים (context) שונים
רמת פירוט	יחסית גסה: קריאה/כתיבה/מחיקה למשאב	מדויקת: “פתח קריאה”, “עדכן כתובת”, “אשר החזר כספי”
התמודדות עם טעויות	נשענת על זהירות המשתמש	נשענת על מניעת פעולות מסוכנות בשכבת המדיניות
עדכון הרשאות	שינויי תפקידים או הרשאות על משאב	ניהול policy לפי סט פעולות מוגדרות היטב
התאמה לסוכנים אוטונומיים	מוגבלת, דורש פתרונות אד־הוק	גבוהה, מותאם לעבודת tool calling agent
יישום ראשוני	מהיר יותר, אבל פחות מבוקר	דורש מיפוי פעולות, מאפשר שליטה עדינה יותר

ומה הלאה? מ־Action-level RBAC ל”מדיניות חכמה” עבור סוכנים

אם מסתכלים קצת קדימה, Action-level RBAC הוא כנראה רק השלב הראשון. כבר היום רואים מגמה שבה מדיניות הרשאות הופכת ליותר דינמית: לא רק “לסוכן הזה מותר לבצע את הפעולה הזו תמיד”, אלא: - רק בשעות מסוימות - רק על לקוחות מסוימים - רק אם הפעולה לא חורגת מתנאים עסקיים מוגדרים (למשל, סכום החזר כספי מקסימלי) - רק אם לא בוצעו יותר מדי פעולות רגישות בפרק זמן קצר ופה נכנס עוד נדבך מעניין: מדיניות הרשאות עצמה מתחילה להתבסס על ניתוח התנהגות. אם ai agent בסטייה מהשגרה מתחיל להשתמש בפעולות מסוימות יותר מדי — המערכת יכולה לעצור, לתעד, לבקש אישור אנושי. כלומר, אנחנו לא מדברים רק על “מי רשאי לעשות מה”, אלא גם על “איך נראית התנהגות נורמלית של סוכן, ואיפה אנחנו שמים קווים אדומים”.

מחשבה לסיום: ai agent כשותף, לא כקוסם מאחורי וילון

בסוף, הדבר הכי מסוכן ב־ai agent הוא לא העובדה שהוא חכם, אלא העובדה שהוא עלול להיות שקוף מדי. קל מאוד להתאהב ב־tool calling agent שמסדר משימות, סוגר פינות, מצמצם עומסים, ולשכוח שיש מאחורי הקסם הזה יכולת ביצוע אמיתית במערכות הליבה של הארגון. Action-level RBAC מחזיר אותנו למקום קצת יותר מפוכח: סוכן חכם הוא שותף. שותף צריך גבולות. צריך שפה ברורה. צריך לדעת מה נכנס לתחום האחריות שלו — ומה נשאר בידי בני אדם. אם אתם נמצאים היום בצומת הזה — שוקלים להכניס ai agent לתוך תהליכים קריטיים, מתלבטים לגבי כמה חופש לתת לסוכן שלכם — זה בדיוק השלב לדבר ברצינות על תכנון הרשאות לפי פעולה. לא כסעיף “אבטחת מידע” שמוחבאים בנספח, אלא כנדבך אדריכלי בסיסי של המערכת. נשמח לסייע בייעוץ ראשוני ללא עלות — לחשוב יחד איפה כדאי להתחיל, אילו פעולות למפות, ואיך להפוך את ה־ai agent שלכם מעוזר מסוכן לעוזר אחראי.