Agent Registry Architecture: התשתית שמנהלת זהות והרשאות של כל Agent בארגון

מאת צוות מדיה דיל · 08.08.2026 · Enterprise AI · 7 דק׳

מדריך ארכיטקטוני ל-Agent Registry: הבדל מ-MCP Registry, מודל זהות מכונה ל-agents, capability manifest, ואינטגרציה עם IAM ארגוני.

הבעיה: agents מתרבים מהר יותר משום מערכת ניהול קיימת

בעוד ש-MCP Registry (ראו המאמר הייעודי) עונה על השאלה "אילו כלים חיצוניים מותר להשתמש בהם", יש שאלה מקבילה וקריטית לא פחות שהוא לא עונה עליה: "אילו agents בכלל קיימים בארגון, מי הם, ומה מותר להם לעשות". agent הוא לא סתם עוד תהליך שרץ בשרת - הוא ישות עם זהות, יכולות, ותחום אחריות משלה, שיכולה לצבור הרשאות, לפעול בשם משתמשים, ולהשתנות עם הזמן. ארגונים שמנסים לנהל agents דרך אותם כלים שמנהלים שרתים או משתמשי אנוש - CMDB, IAM קלאסי - מגלים תוך זמן קצר שהמודלים האלה לא מתאימים למאפיינים הייחודיים של agent: יכולת שמשתנה בזמן ריצה (חיבור tool חדש), ריבוי גרסאות פעילות בו-זמנית, ותלות דינמית ב-MCP servers שיכולה להשתנות בלי deploy מחדש. Agent Registry הוא התשתית הייעודית שנבנתה בדיוק בשביל הפער הזה.

Agent Registry מול MCP Registry - שני קטלוגים, שתי שאלות שונות

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

סכימת נתונים: זהות מכונה, לא רק תיאור טכני

רשומת agent טובה חייבת לכלול, מעבר לפרטים טכניים, מודל זהות מלא - כי agent הוא בפועל machine identity שצריך לעבור את אותו מחזור חיים כמו כל זהות אחרת בארגון:

{
  "agent_id": "agent-support-triage-v7",
  "display_name": "Support Ticket Triage Agent",
  "owner_team": "customer-success",
  "base_model": "claude-opus-4.6",
  "capability_manifest": {
    "connected_mcp_servers": ["mcp-crm-readonly-v3", "mcp-email-send-v1"],
    "max_action_scope": "write-with-approval"
  },
  "identity": {
    "service_account": "svc-support-triage",
    "credential_rotation": "90d",
    "acts_on_behalf_of": "authenticated-support-agent-users"
  },
  "lifecycle_stage": "production",
  "last_security_test": "2026-07-20",
  "deployment_environments": ["prod-eu"]
}

שדה ה-acts_on_behalf_of חשוב במיוחד: הוא מבהיר אם ה-agent פועל עם הרשאות עצמאיות משלו, או שהוא בעצם "מייצג" משתמש אנושי ופועל בשמו - הבחנה שמשפיעה ישירות על מודל האחריות המשפטית והתפעולית כשמשהו משתבש.

Capability Manifest: התיעוד שחייב להישאר מסונכרן עם המציאות

ה-capability manifest - רשימת ה-tools, ה-MCP servers, וה-scope שה-agent מחזיק בפועל - הוא החלק הכי חשוב וגם הכי קשה לתחזוקה ברשומת ה-registry, כי הוא נוטה "להתיישן" מהר: מפתח מוסיף tool חדש ל-agent בקוד, אבל שוכח (או לא יודע) שהוא צריך לעדכן את ה-manifest ב-registry בהתאם. הפתרון הארכיטקטוני הוא לא לסמוך על עדכון ידני בכלל - ה-manifest צריך להיווצר אוטומטית מתוך קונפיגורציית ה-agent בזמן ה-deploy (בדומה לאיך ש-SBOM נוצר אוטומטית בבנייה), כך שהוא תמיד משקף את המצב האמיתי ולא דורש משמעת תיעוד ידנית מהצוותים.

אינטגרציה עם IAM ארגוני: agent כזהות מכונה לכל דבר

הטעות הנפוצה ביותר בארגונים שמתחילים עם agents היא לנהל את ההרשאות שלהם בנפרד לגמרי ממערכת ניהול הזהויות (IAM/IGA) הקיימת - כאילו agent הוא סוג שונה לחלוטין של ישות שלא שייכת לאותו מודל ממשל. בפועל, agent הוא בדיוק machine identity, וצריך לעבור את אותו מחזור חיים כמו כל service account: הקצאה עם least privilege, ביקורת גישה תקופתית (access review), רוטציית credentials, וביטול אוטומטי כשה-agent מוצא משימוש. Agent Registry שבנוי נכון לא מחליף את ה-IAM הארגוני - הוא מתחבר אליו, כך שכל agent חדש שנרשם יוצר אוטומטית service account מתאים ב-IAM, ולא נשאר "אזרח שני" שמנוהל בכלים נפרדים ולא עובר את אותם תהליכי ביקורת שכל זהות אחרת עוברת.

Access Review: איך agent עובר "ביקורת גישה" כמו כל עובד

ארגונים בשלים מבחינת ניהול זהויות מריצים access review תקופתי לכל משתמש אנושי - סקירה שבה מנהל מאשר מחדש שהעובד עדיין זקוק להרשאות שיש לו. Agent Registry שבנוי נכון מרחיב את אותו תהליך בדיוק ל-agents: כל רבעון (או בתדירות שנקבעת לפי רמת סיכון, בדומה למדיניות שתוארה במאמר על MCP Server Governance), הבעלים של כל agent נדרש לאשר מחדש במפורש שההרשאות שה-agent מחזיק עדיין נחוצות למטרתו המוצהרת. תהליך כזה, שנשמע בירוקרטי, הוא בפועל המנגנון המרכזי שתופס "privilege creep" - agent שהתחיל עם scope צר ובמהלך חודשים צבר הרשאות נוספות בלי שאף החלטה בודדת נראתה בעייתית, אבל הצבירה הכוללת יצרה חשיפה משמעותית שאף אחד לא תכנן במפורש.

Trade-offs: מודל ריכוזי מול Federation בין דומיינים

ארגון גדול עם עשרות צוותים שכל אחד בונה agents משלו עומד בפני החלטה: registry מרכזי אחד, או federation שבו כל domain מנהל registry מקומי משלו עם ממשק שאילתה משותף. registry מרכזי נותן נראות מלאה ופשוט לאכוף מדיניות אחידה, אבל הופך צוואר בקבוק ברישום ובאישור עם קנה מידה. federation מאפשר לכל צוות לזוז מהר יותר, אבל דורש סכימה אחידה בין הדומיינים ומנגנון query מרכזי שיודע "לשאול" את כל הדומיינים בבת אחת - בלי זה, נוצרים אותם איי מידע מבודדים שה-registry נועד למנוע מלכתחילה.

שיקול נוסף: כמה מפורט צריך ה-manifest להיות. manifest עשיר מדי (כל פרמטר אפשרי לכל tool) הופך כבד לתחזוקה ומייצר רעש; manifest דליל מדי (רק שם ה-agent ובעלים) לא מספיק כדי לענות על שאלות אבטחה אמיתיות. האיזון הנכון תלוי ברמת הסיכון - agents עם הרשאת כתיבה לנתונים רגישים דורשים manifest מפורט הרבה יותר מ-agent read-only פנימי בסיכון נמוך.

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

הטעות הראשונה: לבנות registry נפרד לגמרי מה-MCP Registry, בלי קישור בין השניים - מה שהופך את השאלה "אילו servers מחוברים לאיזה agent" לתרגיל התאמה ידני בין שתי מערכות שלא מדברות זו עם זו. הטעות השנייה: לתת ל-capability manifest להתיישן, כמתואר למעלה, כשהוא לא נוצר אוטומטית - ברגע שהתיעוד לא משקף מציאות, כל שאר הממשל שנבנה עליו מתמוטט. הטעות השלישית: לנהל את ה-agent כאילו הוא לא זהות מכונה אמיתית, ולוותר על אינטגרציה עם ה-IAM הקיים - מה שיוצר "orphaned permissions" שאף אחד לא סוקר או מבטל.

Agent Registry בארכיטקטורת Multi-Agent: מי מנהל את מי

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

מודל הרשאות: Scope ברמת Tool, לא רק ברמת Agent

טעות ארכיטקטונית נפוצה היא להגדיר הרשאות ברמת ה-agent כולו - "agent X מורשה" - במקום ברמת השילוב הספציפי של tool ופרמטר. בפועל, אותו agent יכול להיות מורשה לקרוא ל-tool מסוים עם פרמטר אחד ("קבל פרטי הזמנה לפי מזהה שהמשתמש הנוכחי מחזיק") אבל לא מורשה לקרוא לאותו tool בדיוק עם פרמטר אחר ("קבל פרטי הזמנה של כל לקוח במערכת"). Agent Registry שמתעד הרשאות רק ברמת "יש גישה ל-tool הזה, כן/לא" מפספס את הרזולוציה הנדרשת כדי לענות בפועל על שאלות אבטחה. מודל הרשאות בשל מתעד scope ברמת פרמטר או לפחות ברמת קטגוריית קלט, ומאפשר ל-gateway (ראו המאמר על MCP Gateway) לאכוף את הרזולוציה הזו בזמן ריצה - לא רק לבדוק "האם ה-agent בכלל מכיר את ה-tool".

שאילתות שה-Registry צריך לענות עליהן תוך שניות

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

קשר ל-Agent Lifecycle Management

ה-Agent Registry הוא לא סתם מאגר סטטי - הוא הכלי שדרכו כל שלבי מחזור החיים של agent (ראו המאמר הייעודי) מתועדים ונאכפים בפועל: כל agent חדש נרשם בשלב העיצוב, מתעדכן אוטומטית עם כל deploy, ומקבל סטטוס "decommissioned" רק אחרי שתהליך הפרישה המלא הושלם - כולל ביטול ה-service account שנוצר עבורו. בלי הקשר הזה, ה-registry הוא רק תמונת מצב רגעית שלא משקפת לאן ה-agent נמצא במסעו, ותוכנית ה-lifecycle נשארת תיאורטית בלי כלי שאוכף אותה בפועל.

מתי כן ומתי לא

ארגון עם agent בודד, ידני, שמנוהל על ידי צוות קטן, לא צריך registry ייעודי - תיעוד פשוט מספיק. ברגע שיש יותר מ-agent אחד עם הרשאות פעולה אמיתיות, ריבוי צוותים שבונים agents במקביל, או צורך לענות במהירות על "אילו agents יש להם גישה למערכת X" - צורך שרק גדל עם רגולציה כמו EU AI Act - Agent Registry הופך מרכיב חובה בארכיטקטורה, לא תוסף אופציונלי.

איך אנחנו ניגשים לזה

במדיה דיל אנחנו בונים agent registry כבר בשלב הראשון של כל פרויקט agentic, עם capability manifest שנוצר אוטומטית מקונפיגורציית ה-deploy, וחיבור ישיר למודל ה-IAM של הלקוח - כדי שכל agent חדש יוצר את זהות המכונה שלו כחלק מהזרימה, לא כפעולה ידנית נפרדת שנשכחת. אנחנו גם מוודאים מההתחלה שה-registry מסוגל לענות על שאילתות המפתח שתוארו למעלה, כי זה המבחן האמיתי לשימושיות שלו בשעת חירום.

סיכום

Agent Registry הוא הרחבה הכרחית של תשתית הממשל שמעבר ל-MCP - הוא לא מנהל את הרכיבים החיצוניים אלא את הישויות הפעילות עצמן, עם מודל זהות מכונה מלא שמתחבר ל-IAM הארגוני. הארכיטקטורה הנכונה בונה את ה-capability manifest אוטומטית מתוך ה-deploy, מתחברת ישירות למחזור החיים המלא של כל agent, ולא מסתמכת על משמעת תיעוד ידנית שנשחקת עם הזמן.

תגיות: Agent Registry · machine identity · capability manifest · IAM · AI governance · service account · agent lifecycle

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