MCP פרסם מפרט "Enterprise-Managed Authorization" יציב; טיוטות הזהות האחרות למכונה-למכונה (machine-to-machine) — כולל טיוטת OAuth client-credentials ושתי הצעות פתוחות — נותרו לא גמורות. עבור כל מי שמנסה להריץ סוכנים אוטונומיים (autonomous agents) באמצעות ה-Model Context Protocol, המשמעות היא שהפרוטוקול הנוכחי יכול לאמת משתמש אנושי, אך אינו מציע דרך מוכנה לשימוש להוכחה שתהליך ללא השגחה (unattended process) הוא אכן מי שהוא טוען להיות.
למה מפת הדרכים חשובה
מפת הדרכים של ה-Model Context Protocol (MCP) מציבה את זהות הסוכן ואבטחת הסוכנים בין עדיפויותיה העליונות. ארבעה פריטים תוכננו לשחרור: זרימת דפדפן ממוקדת-אדם (human-centric browser flow), זרימת OAuth client-credentials עבור שירותים, קישור אסימונים (token binding) מבוסס DPoP, ומנגנון פדרציה של זהות עומס עבודה (workload-identity federation). רק הראשון — Enterprise-Managed Authorization — הגיע למצב יציב.
מה המפרט היציב עושה בפועל
Enterprise-Managed Authorization מאפשר למנהלי IT להעניק גישה לשרת מתוך קונסולה אחת, במקום שכל עובד יצטרך לאשר כל חיבור. הזרימה משתמשת בהפניה בדפדפן (browser redirect) ובהתחברות משתמש, כך שאדם מול מחשב נייד יכול לבצע אימות (authenticate), ולאחר מכן השרת סומך על הסשן (session) של אותו משתמש.
המגבלה ברורה: התהליך דורש אדם מול המקלדת. סוכן שרץ במהלך הלילה, מעבד נתונים או מגיב להתראות, אינו יכול ללחוץ על כפתור התחברות. כתוצאה מכך, כל פריסה (deployment) שתלויה בסוכנים ללא השגחה (unattended agents) אינה יכולה להשתמש במפרט היחיד ש-MCP מבטיח כרגע.
אפשרויות הטיוטה והחסרונות שלהן
שתי הרחבות בסטטוס טיוטה שואפות להעניק לסוכנים זהות משלהם:
- SEP-1932 (DPoP) – קושר אסימונים (tokens) לצמד מפתחות ציבורי-פרטי, מה שהופך אסימונים גנובים לחסרי תועלת.
- SEP-1933 (Workload Identity Federation) – מאפשר לסוכנים לרשת זהויות שכבר הוקצו (provisioned) בפלטפורמות ענן.
שניהם קיימים כבקשות משיכה (pull requests) פתוחות; אף אחד מהם לא אוחד (merged) למפרט הרשמי. בינתיים, האפשרות המתועדת היחידה האחרת היא זרימת OAuth client-credentials הדורשת סודות (secrets) הרשומים מראש. אחסון הסודות הללו במקום שבו סוכן יכול לקרוא אותם יוצר משטח תקיפה (attack surface) קלאסי: אם הסוד דולף, כל תוקף יכול להתחזות לסוכן.
צעדים מעשיים לייצור (production) כבר היום
מכיוון שהפרוטוקול עדיין אינו מספק זהות סוכן מובנית (native), צוותים עדיין יכולים לאבטח סוכנים על ידי העברת ניהול הזהות אל מחוץ ל-MCP:
- הנפקת זהויות ניתנות לאימות בשכבת עומס העבודה (workload layer). מערכות כמו SPIRE מייצרות תעודות קצרות מועד הקשורות לשורש האמון (trust root) של המארח, ובכך מבטלות את הצורך בסודות סטטיים.
- סיום (Termination) של אישורים ב-gateway. שירות front-end מחזיק את מפתח ה-API או האסימון ומעביר בקשות בשם הסוכן, ובכך שומר על הסוד מחוץ לסביבת ההרצה (runtime environment).
- מתן הרשאה (Authorization) על בסיס הזהות המאומתת, ולא על בסיס תוכן האסימון. יש להפריד בין אימות (authentication - מי מבצע את הקריאה) לבין הרשאה (authorization - מה מותר לו לעשות), כך שניתן יהיה לאכוף מדיניות גם אם שיטת האימות משתנה.
מה כדאי לעקוב אחריו בהמשך
שתי בקשות המשיכה הפתוחות – DPoP binding ו-workload-identity federation – הן הנתיבים היחידים לתקן זהות אמיתי של מכונה-למכונה בתוך MCP. אם הקהילה תאחד אותן, סוכנים יוכלו להוכיח החזקה של מפתח פרטי או לרשת זהויות שהונפקו בענן מבלי לחשוף סודות. עד אז, כל פריסת ייצור (production deployment) חייבת להסתמך על מסגרות זהות חיצוניות או לקבל את הסיכון של אישורים סטטיים.
השורה התחתונה ברורה: MCP יכול כרגע לאמת את האדם שמאחורי הבקשה, אך הוא עדיין אינו מאמת את התוכנה שמבצעת את הבקשה. צוותים הזקוקים לסוכנים אוטונומיים מאובטחים לא צריכים לחכות שהמפרט יתקבע; עליהם לבנות זהות בשכבת עומס העבודה כבר היום ולהמשיך לעקוב אחר הצעות ה-DPoP והפדרציה הממתינות.