צ'ק-ליסט אבטחה ל-CISO: כך פורסים סוכני AI בארגון בבטחה

סוכני AI כבר לא מסתפקים בצ'אט: הם פותחים Pull Requests, קוראים מסמכים פנימיים ומריצים פעולות במערכות הליבה של הארגון. עם ה-Release Candidate של מפרט MCP שיהפוך לסופי ב-28 ביולי 2026, והדרישה של GitHub שמנהלי ארגון יאשרו ידנית כל מודל חדש ב-Copilot, נוצרה לראשונה תשתית ארגונית אמיתית לניהול זהויות והרשאות של סוכנים. המדריך הזה מתרגם את השינויים לצ'ק-ליסט מעשי ל-CISO ולמנהלי DevOps, לפני שמחברים סוכן ראשון למערכת פנימית.

01מה השתנה: Enterprise Auth נכנס למפרט MCP

ה-RC של מפרט MCP 2026-07-28 פורסם ב-21 במאי 2026 על ידי המתחזקים הראשיים David Soria Parra ו-Den Delimarsky, שתיארו אותו כרוויזיה הגדולה ביותר של הפרוטוקול מאז השקתו. בצד האבטחה, שרתי MCP מחויבים כעת לממש OAuth 2.0 Protected Resource Metadata (RFC 9728), ולקוחות מחויבים לממש Resource Indicators (RFC 8707) כדי להצהיר במפורש לאיזה שרת מיועד הטוקן. המשמעות בפועל: שרת זדוני לא יכול עוד ללכוד טוקן שיועד לשרת אחר, אחת ממתקפות ה-confused deputy הנפוצות בעולם הסוכנים.

אבל השינוי המשמעותי ביותר לארגונים הוא הרחבת Enterprise-Managed Authorization (EMA), שהוכרזה כיציבה ב-18 ביוני 2026. במקום ש-כל עובד יעבור OAuth נפרד מול כל שרת MCP, הארגון מנהל את הגישה מרכזית דרך ספק הזהויות: המשתמש מתחבר פעם אחת ומקבל את כל השרתים שהארגון אישר. טכנית, הזרימה מבוססת ID-JAG (Identity Assertion JWT Authorization Grant), JWT קצר-מועד שה-IdP מנפיק בבקשת token-exchange לפי RFC 8693, והלקוח מציג אותו לשרת ההרשאות של ה-MCP לפי RFC 7523 כדי לקבל access token.

מי כבר בפנים? Okta היא ספקית הזהויות הראשונה שתומכת בזרימה. בצד הלקוח: Claude, Claude Code ו-Cowork של Anthropic, וכן VS Code. בצד השרת: Asana, Atlassian, Canva, Figma, Granola, Linear ו-Supabase, כש-Slack בדרך. אם הארגון שלכם עובד עם חלק מהכלים האלה, סביר שכבר יש לכם נקודת אחיזה להתחיל ממנה.

02GitHub מחמירה: אישור ידני למודלים ובקרה על הסוכן

במקביל, GitHub הידקה את הבקרות בצד ה-Copilot. בתוכניות Business ו-Enterprise, מודלים חדשים מושבתים כברירת מחדל מטעמי אבטחה ותאימות, ומנהל הארגון נדרש להפעיל את המדיניות של כל מודל ידנית. ב-26 במאי 2026 נוספו ב-public preview גם targeted model rules: בעלי Enterprise יכולים לקבוע אילו מודלים זמינים לכל ארגון בנפרד, במקום הגדרה אחת גורפת.

גם סוכן הקוד עצמו כפוף לעיקרון human-in-the-loop: כשה-Copilot coding agent פותח PR או דוחף שינויים, הוא מטופל כתורם חיצוני, ו-workflows של GitHub Actions לא רצים עד שאדם לוחץ על Approve and run workflows. זו הגנה ישירה מפני גישה לא מבוקרת לטוקנים, סודות והרשאות ריפו. במרץ 2026 נוספה אמנם הגדרת ריפו שמאפשרת לדלג על האישור, אך ברירת המחדל נותרה דרישת אישור אנושי, וכדאי מאוד להשאיר אותה כך בריפואים רגישים.

03הצ'ק-ליסט: 8 צעדים לפני חיבור סוכן למערכת פנימית

הנה רשימת הבדיקות שכדאי לעבור עליה סעיף-סעיף עם צוות ה-DevOps וה-IT לפני שסוכן כלשהו מקבל גישה למערכת פרודקשן או למידע ארגוני:

1. מיפוי זהויות: בדקו את תהליך ה-onboarding הנוכחי. אם השרתים שלכם עדיין דורשים redirect להסכמת משתמש פרטנית, ודאו שה-IdP והלקוח תומכים בהרחבת ה-token-exchange הארגונית (EMA). שימו לב: כרגע אין נתיב IdP חלופי לארגונים שאינם על Okta.
2. ולידציית טוקנים: ודאו ולידציה של iss, הצהרת application_type וקשירת credentials ל-issuer. אל תסתפקו בבדיקת חתימה בלבד.
3. טוקנים קצרי-מועד: המפרט מדגים ID-JAG של חמש דקות ו-access token של 24 שעות. אם הטוקנים שלכם חיים שבועות, זה הזמן לקצר.
4. Resource Indicators: ודאו שכל לקוח MCP בארגון מצהיר במפורש (RFC 8707) לאיזה שרת מיועד כל טוקן, כדי לחסום token replay בין שרתים.
5. Offboarding: EMA נותנת נקודת ניהול אחת להוספה וביטול גישה. בנו נוהל שמנתק עובד עוזב מכל שרתי ה-MCP בלחיצה אחת דרך ה-IdP, ובדקו אותו בפועל.
6. מדיניות מודלים ב-Copilot: השאירו מודלים חדשים מושבתים כברירת מחדל, והגדירו תהליך הערכה מסודר (סקירת תאימות, בדיקת data residency) לפני הפעלת מודל לארגון ספציפי דרך targeted model rules.
7. אישור אנושי ל-workflows: אל תפעילו את הדילוג על Approve and run workflows בריפואים שמכילים סודות, גישה לפרודקשן או pipelines של deployment.
8. Guardrails בזמן ריצה: הציבו policy engine או gateway בין הסוכן לכלים, שמחליט על כל קריאת כלי בנפרד. EMA לא עושה את זה בשבילכם.

04איך זה נראה בקוד: מדיניות גישה לסוכן

כדי להמחיש את עקרון ההפרדה בין אימות (מי הסוכן) להרשאה בזמן ריצה (מה מותר לו עכשיו), הנה דוגמה סכמטית למדיניות שאפשר לאכוף ב-gateway שיושב בין הסוכן לשרתי ה-MCP:

# מדיניות gateway לסוכן AI - דוגמה סכמטית
agent_policy:
  identity: ema-idp        # אימות חיבור דרך ה-IdP בלבד
  token_max_ttl: 24h
  tools:
    - name: jira.create_issue
      allow: true
    - name: db.query
      allow: true
      constraints:
        schemas: ["analytics"]   # קריאה בלבד, סכמה מוגדרת
        readonly: true
    - name: deploy.production
      allow: false               # לעולם לא אוטונומי
      require_human_approval: true
  audit:
    log_every_call: true
    retention_days: 365

05הזווית הישראלית: למה זה דחוף דווקא עכשיו

ארגונים ישראליים, ובראשם חברות פינטק, ביטחון ובריאות דיגיטלית, נמצאים תחת דרישות רגולטוריות מחמירות של ניהול הרשאות ותיעוד גישה. עד עכשיו, חיבור סוכן AI למערכת פנימית היה בור אבטחתי: כל עובד אישר OAuth בעצמו, טוקנים חיו ללא בקרה מרכזית, ולביקורת לא היה מסלול מסודר. EMA משנה את התמונה בדיוק בנקודה הזאת, עם נקודת ניהול אחת ומסלול ביקורת מובנה, וזה בדיוק מה שמבקר פנימי או רגולטור ירצה לראות.

לצוותי DevOps בארץ שכבר עובדים עם Copilot Business או Enterprise, ההמלצה המעשית היא לנצל את חלון הזמן עד 28 ביולי: לעבור על רשימת המודלים המופעלים בארגון, לוודא שאף מודל לא הופעל בלי הערכה, ולהתחיל פיילוט EMA על שרת MCP אחד לא-קריטי, למשל Linear או Asana, לפני שמתקדמים למערכות רגישות.

06מה הלאה: מה לשים ביומן

המפרט הסופי של MCP 2026-07-28 ישוחרר ב-28 ביולי, ורשימת התומכים ב-EMA צפויה להתרחב, עם Slack בדרך בצד השרתים. בינתיים, הפער המרכזי שנותר פתוח הוא היעדר נתיב IdP למי שאינו לקוח Okta, וכדאי לעקוב אחרי הכרזות של ספקי זהויות נוספים. עד אז, העיקרון המנחה פשוט: אימות מרכזי בכניסה, מדיניות פרטנית בזמן ריצה, ואדם בלולאה בכל פעולה שנוגעת לפרודקשן. סוכן AI הוא כוח עבודה חדש, וכמו כל עובד חדש, הוא מתחיל עם ההרשאות המינימליות ומרוויח אמון בהדרגה.