GitHub דורשת הוכחת נוכחות לפעולות רגישות — גם כדי לעצור סוכנים שפועלים בלי ידיעתכם

עובדות — מה קרה

ב־24 בספטמבר 2026 GitHub פתחה בתצוגה מקדימה ציבורית את Proof of Presence, מנגנון שמוסיף שכבת אימות טרייה לפני פעולות בעלות השפעה גבוהה ב־GitHub Enterprise Cloud. במקום להסתפק בכך שהדפדפן מחזיק סשן תקף או שטוקן ארוך־חיים עדיין עובד, GitHub יכולה להחזיר את המשתמש לספק הזהות הארגוני ולבקש הוכחה אינטראקטיבית שהוא אכן נמצא מול המערכת עכשיו.

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

הפיצ'ר אינו שינוי לכל חשבונות GitHub. בתצוגה המקדימה הוא מוגבל לארגוני Enterprise Managed Users ב־github.com ול־GHEC־DR שמשתמשים ב־Microsoft Entra ID כספק זהות, דרך SAML או OIDC. לכן סטארט־אפ קטן או חשבון GitHub אישי לא יראה בהכרח את האפשרות, גם אם הוא מפעיל Copilot או סוכן קוד.

עובדות — איך האימות עובד

מנהל הארגון בוחר ב־Authentication security אם לדרוש Re-authentication או MFA. בשני המצבים המשתמש נשלח לספק הזהות שהוגדר ב־SSO. ב־Re-authentication ייתכן שסיסמה מספיקה, בהתאם למדיניות הארגונית. ב־MFA נדרשת גם בדיקה נוספת, למשל אפליקציית מאמת, ביומטריה או כלל תאימות מכשיר שהוגדר אצל הספק.

לאחר שהמשתמש משלים את האתגר וחוזר ל־GitHub עם הוכחה מתאימה, הפעולה יכולה להמשיך. המנגנון משתמש במודל הסשן של sudo mode: ההוכחה תקפה עד שפג חלון של שעתיים, וכל פעולה רגישה נוספת באותו חלון אינה דורשת בהכרח אתגר חדש. אם המשתמש אינו מצליח להשלים את האימות, עליו לפנות למנהל הארגון או למנהל ה־IdP.

GitHub מונה בין הפעולות הרגישות יצירת טוקן, עריכת Webhooks, שינוי הגדרות אבטחה בארגון וצפייה בקודי שחזור. תמיכה בהוכחת נוכחות לפני מיזוג pull requests מתוכננת להגיע בהמשך, ולכן אין להציג את התצוגה המקדימה ככיסוי מלא לכל פעולת סוכן או מפתח.

ניתוח PRESS AI — למה זה חשוב בעולם של סוכנים

הניתוח של PRESS AI: ככל שסוכני קוד ואוטומציות מקבלים הרשאות רחבות יותר, לא מספיק לשאול מי התחבר בבוקר. צריך לשאול מי נוכח ברגע שבו נוצר טוקן, משתנה Webhook או נפתחת דלת חדשה למערכת. Proof of Presence מחזק את ההפרדה בין הרשאה מתמשכת לבין אישור אנושי רענן, ולכן הוא מתאים במיוחד לפעולות שקשה לבטל או שעלולות להשפיע על הרבה משתמשים.

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

החיבור ל־Entra ID חשוב לא פחות מהשם השיווקי. ארגון שכבר מנהל מדיניות MFA, תאימות מכשיר ו־SSO במקום מרכזי יכול ליישם כללי אבטחה בלי לבנות מנגנון חדש בתוך GitHub. מצד שני, ארגון שאינו משתמש ב־Entra ID או שאינו מנהל Enterprise Managed Users לא יכול להסיק שהתכונה זמינה לו רק מפני שראה את ההכרזה.

מה זה לא אומר — ומה כדאי לעשות עכשיו

ההשקה אינה אומרת שכל פעולת AI דורשת אישור ידני, שכל סוכן מסוכן, או ש־MFA פותר לבדו סיכון של שרשרת אספקה. היא גם אינה זמינה כרגע לכל ארגון, אינה מכסה עדיין מיזוגי pull requests, ואינה הופכת הרשאה רחבה להרשאה בטוחה. יש לראות בה מנגנון נוסף סביב פעולות מוגדרות, עם תנאי שימוש שיכולים להשתנות כי מדובר בתצוגה מקדימה ציבורית.

אם הארגון מתאים לתנאים, התחילו בפיילוט מצומצם: בחרו קבוצה מנוהלת, תעדו את פעולות ה־high-impact שאתם רוצים להגן עליהן, והחליטו מתי Re-authentication מספיק ומתי נדרש MFA. בדקו תרחיש רגיל, תרחיש של סוכן שמנסה להמשיך, תרחיש של משתמש בלי גישה ל־IdP ותרחיש התאוששות. מדדו חסימות, זמן עבודה וחריגים לפני הרחבה.

השורה התחתונה: GitHub מתייחסת ברצינות לעובדה שסוכן יכול להחזיק הרשאה ולפעול מהר יותר מהאדם. Proof of Presence הוא צעד הגיוני לקשור פעולות רגישות לאדם מאומת ברגע הנכון, אך הערך האמיתי יגיע רק כחלק ממדיניות של least privilege, ניטור ותכנון עצירות. כדאי להכיר את המנגנון עכשיו, בלי להבטיח שהוא לבדו יפתור את אבטחת הארגון.

• בדקו אם הארגון עומד בתנאי Enterprise Managed Users ו־Entra ID
• מפו פעולות שקשה לבטל לפני שמפעילים מדיניות חדשה
• התחילו בקבוצת פיילוט ומדדו חסימות וחריגים
• שלבו את האימות עם הרשאות מינימליות ויומני פעילות