Access Governance למערכות AI: מי מורשה לגשת למה, ולמה זה מסובך יותר מ-RBAC רגיל

מאת צוות מדיה דיל · 02.08.2026 · Enterprise AI · 12 דק׳

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

הבעיה: המודל לא יודע מי שואל אותו

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

ההבדל בין הרשאות מסורתיות ל-Access Governance ב-AI

RBAC (Role-Based Access Control) מסורתי מגדיר מה כל תפקיד רשאי לראות ברמת מסך, endpoint או טבלה. במערכות AI, ההרשאה חייבת לחול על רמה עדינה הרבה יותר - כל chunk בודד במאגר ה-RAG, כל tool שהסוכן יכול להפעיל, וכל פעולה שהמודל יכול לבצע מטעם המשתמש. זה דורש מעבר מ-RBAC פשוט ל-ABAC (Attribute-Based Access Control), שבו ההרשאה נקבעת דינמית לפי שילוב של תכונות - תפקיד המשתמש, המחלקה שלו, רמת הביטחון שלו, וסיווג הדאטה המבוקש - ולא רק לפי תפקיד קבוע מראש.

Retrieval-Time Filtering: אכיפת הרשאות ברגע השליפה

הפתרון הטכני המרכזי הוא Retrieval-Time Filtering - כל שאילתת retrieval מה-Vector Database חייבת לכלול את הרשאות המשתמש כפילטר מובנה, לא כבדיקה שמתבצעת אחרי קבלת התוצאות. זה קריטי כי בדיקה 'אחרי העובדה' (post-hoc filtering) עדיין חושפת את התוכן הרגיש לשכבת ה-LLM עצמה, מה שיכול לגרום לדליפה חלקית גם אם התוצאה הסופית מסוננת - למשל, המודל עדיין 'ראה' את המידע הרגיש ועלול לרמוז עליו בתשובה גם בלי לצטט אותו במפורש.

ניהול הרשאות ל-AI Agents עם גישה לכלים

כשמדובר בסוכני AI שיכולים לבצע פעולות (לא רק לענות על שאלות) - שליחת אימיילים, עדכון רשומות, הרצת שאילתות - Access Governance מקבל ממד נוסף וקריטי יותר. כל tool שהסוכן יכול להפעיל צריך להיות מוגדר עם היקף הרשאות מצומצם (Principle of Least Privilege), ולא לרשת אוטומטית את מלוא ההרשאות של המשתמש שהפעיל אותו. אם סוכן AI מקבל גישה לכלי 'שליחת אימייל' עם הרשאות רחבות מדי, פרומפט זדוני (prompt injection) שמגיע ממקור לא מהימן - למשל תוכן במסמך שהמערכת מעבדת - עלול לגרום לסוכן לשלוח מידע רגיש לכתובת לא מורשית.

דוגמת קוד: אכיפת הרשאות בשכבת ה-Tool

class ToolGate:
    def __init__(self, tool_name, required_scopes):
        self.tool_name = tool_name
        self.required_scopes = required_scopes

    def authorize(self, user_context):
        missing = self.required_scopes - set(user_context.scopes)
        if missing:
            raise PermissionError(f'Missing scopes: {missing}')
        return True

send_email_tool = ToolGate('send_email', required_scopes={'email:send:internal'})

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

Audit Trail: תיעוד מי גישה למה, מתי ולמה

Access Governance ללא Audit Trail מספק חצי פתרון בלבד. כל גישה לדאטה רגיש דרך המערכת - כולל כל chunk שנשלף ב-RAG וכל tool שהופעל - צריכה להירשם עם זהות המשתמש, timestamp, וההקשר של השאילתה. תיעוד כזה קריטי לא רק לזיהוי דליפות בדיעבד אלא גם לצורכי ציות רגולטורי (SOC2, ISO 27001, GDPR) שדורשים הוכחה שיש בקרת גישה אפקטיבית, לא רק מדיניות כתובה.

ניהול מחזור חיים של הרשאות

היבט שלרוב נשכח הוא מחזור החיים של ההרשאות עצמן - מה קורה כשעובד עוזב את הארגון או עובר תפקיד. אם הרשאות הגישה שלו למאגרי RAG שונים לא מתעדכנות אוטומטית בסנכרון עם מערכת ה-HR או ה-Identity Provider, נוצר חלון זמן שבו הרשאות ישנות עדיין תקפות. פתרון נכון משלב את שכבת ה-Access Governance של ה-AI עם מערכת ה-IAM הארגונית הקיימת (כמו Okta או Azure AD), כך שעדכון הרשאה במקום אחד מתפשט אוטומטית לכל המערכות, כולל שכבת ה-AI.

טעויות נפוצות בפרודקשן

• סינון הרשאות שמתבצע אחרי שליפת הדאטה מה-Vector DB, במקום כחלק מהשאילתה עצמה.
• סוכני AI עם הרשאות רחבות מדי לכלים שהם לא צריכים לרוב פעולות המערכת.
• העדר Audit Trail מפורט שמתעד כל גישה לדאטה רגיש דרך המודל.
• הרשאות שלא מתעדכנות אוטומטית בסנכרון עם מערכת ה-IAM הארגונית הראשית.
• הנחה שגויה שסינון ברמת ה-prompt (בקשה מהמודל 'לא לחשוף מידע רגיש') מהווה בקרת גישה אמיתית.

מתי כדאי להשקיע ב-Access Governance מלא

לכלי פנימי קטן שמשרת צוות אחד עם רמת אמון גבוהה, Access Governance מורכב הוא לרוב מיותר. אבל ברגע שהמערכת משרתת ארגון שלם עם מחלקות שונות ורמות רגישות דאטה שונות, או כשמדובר בסוכן AI עם גישה לכלים פעילים, בקרת גישה עדינה ברמת retrieval וברמת tool היא לא תוספת - היא תנאי סף לשימוש בטוח. ב-מדיה דיל אנחנו בונים את שכבת ה-Access Governance כחלק בלתי נפרד מכל פרויקט RAG או Agentic ארגוני, לא כתוספת מאוחרת.

סיכום

Access Governance למערכות AI דורש מעבר ממחשבת RBAC פשוטה לבקרת גישה עדינה ברמת ה-retrieval וה-tool, עם Audit Trail מלא וסנכרון מתמיד עם מערכת ה-IAM הארגונית. ההשקעה הזו היא ההבדל בין מערכת AI שאפשר לפרוס בבטחה בכל הארגון לבין מערכת שדולפת מידע רגיש בשקט.

תגיות: Access Governance · ABAC · RBAC · AI Agents Security · Retrieval-Time Filtering · Audit Trail · IAM

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