פורסם: 4 בנובמבר 2026 · ההכרזה: 3 בנובמבר 2026
Supabase מקבלת כעת מענקי זהות שמנפיק Claude לצורך הרשאת גישה ארגונית מנוהלת דרך MCP. בצד Supabase התכונה זמינה באופן כללי לארגוני Team ו־Enterprise עם SSO. החיבור האוטומטי בצד Claude עדיין בבטא, במסלולי Team ו־Enterprise.
ההשקה ב־24 באוגוסט כבר הציגה גישת MCP באישור מנהל, באמצעות מענקים שמנפיק ספק הזהויות.
מה עדיין נדרש לחיבור
המדריך של Supabase מחייב הגדרת SSO, כניסה קודמת דרכו לכל משתמש וכתובות דוא״ל תואמות. בעלים או מנהל בארגון צריכים לאשר את Claude. רשמו את כתובת Claude בשדה ID-JAG Issuer. כל כתובת מנפיק משרתת ארגון Supabase אחד בלבד. מענק ID-JAG, קיצור של Identity Assertion JWT Authorization Grant, מאפשר לקבל אסימון קצר־חיים עם הרשאות המשתמש הקיימות.
לפי התיעוד של Anthropic, Claude בודק חברות בארגון ודוא״ל, אך אינו בודק אימות אצל ספק הזהויות, אימות רב־שלבי או את כללי הכניסה לשירות המחובר. ההנפקה באמצעות Claude עצמה אינה דורשת SSO; דרישות השירות עדיין חלות.
שתי החלטות לפני המעבר
Supabase סומכת על מנפיק אחד לכל ספק SSO. החלפת המנפיק ב־Claude גורמת לדחיית מענקים שחתם ספק הזהויות ועלולה לקטוע גישה של כלי בינה מלאכותית אחרים.
בעת סיום גישה יש להסיר את המשתמש גם מ־Claude וגם מ־Supabase. השעיית החשבון אצל ספק הזהויות לבדה אינה מספיקה. אסימונים שכבר הונפקו תקפים עד פקיעתם, ולכן הסרה אינה מבטלת אותם מיד.
בסנכרון ספריות באמצעות SCIM, מחיקה בספרייה מסירה את המשתמש מ־Claude, אבל השעיה או סימון כלא פעיל אינם מספיקים. Anthropic גם מזהירה משימוש חוזר בכתובת דוא״ל לפני הסרת החשבונות הישנים מהשירותים המחוברים.
בדיקה מעשית לפני הרחבת השימוש
הרשימה הבאה היא המלצת המערכת, ולא דרישה נוספת של הספקים. התייחסו למעבר כהחלטה ניהולית שצריכה אחראים מוגדרים ותיעוד של בדיקת הקבלה. חיבור מוצלח הוא ראיה שימושית, אך אינו עונה על כל השאלות הנוגעות לאופן שבו הארגון מתכוון לנהל גישה.
- הגדירו קודם את המטרה. ציינו לאיזה צוות מיועד החיבור, איזו עבודה עליו לבצע ולאיזה מידע הוא אמור להגיע. בקשו מהאחראי לשירות לאשר את התיאור לפני בחירת ההגדרות. כך תהיה לבודקים נקודת ייחוס ברורה להערכת התוצאה, במקום להסתפק בכך שהמערכת מאפשרת לבצע פעולה.
- הפרידו בין הביצוע לבדיקה. תנו לאדם אחד להגדיר את החיבור ולאדם אחר לבחון את הגישה שנוצרה. השתמשו בזהויות בדיקה רגילות ולא רק בחשבונות מנהלים. תעדו פעולות שאמורות להידחות לצד בקשות שאמורות להצליח, ובררו כל פער בין התכנון לתוצאה בפועל.
- תרגלו את העברת האחריות. קיימו תרגיל שולחני עם צוות המחשוב, האחראי ליישום ומי שמטפל בעזיבת עובדים. הגדירו לכל משתתף פעולה מסוימת, ראיות שעליו לאסוף וכתובת להסלמה. כללו גם מקרה שבו העזיבה מתרחשת מחוץ לשעות התמיכה הרגילות, כדי שהנוהל לא יהיה תלוי באדם יחיד.
- הכינו פריסה שאפשר לסגת ממנה. תעדו את ההגדרות הקודמות, את התלויות ואת האחראי לחזרה לאחור לפני ביצוע השינוי. התחילו בקבוצה קטנה מספיק כדי לספק לה תמיכה ישירה. הגדירו מראש אילו תוצאות יעצרו את ההרחבה, ובחנו את הממצאים בפועל במקום לראות בהיעדר פניות לתמיכה הוכחה להצלחה.
התוצאה הרצויה היא החלטה מתועדת: מי רשאי להשתמש בחיבור, מי מתחזק אותו וכיצד הארגון יוודא שהגישה מסתיימת במועד המתוכנן. השאירו שאלות שלא נפתרו גלויות לפני הרחבת השימוש, והקצו להן אחראי במקום לדחות אותן לשלב שבו יותר צוותים כבר תלויים בחיבור. קבעו מועד לבדיקה חוזרת ושמרו את הראיות במקום שמנהל המערכות הבא יוכל למצוא. רישום קצר שמתוחזק עדיף על מסמך הגדרות מפורט שאין לו אחראי.