Agent Identity (זהות סוכן)

הבעיה: סוכן שפועל בזהות שאולה

זהות סוכן (Agent Identity), הנקראת גם "זהות לא-אנושית" (Non-Human Identity, בקיצור NHI) בהקשר-סוכנים, היא העיקרון שלפיו לסוכן-AI צריכה להיות זהות דיגיטלית משלו, נפרדת מזהות-המשתמש שבשמו הוא פועל, ומזהות-כל-סוכן-אחר באותו ארגון — ולא הרשאות שאולות שמערבבות בין מה שעשה אדם למה שעשה תהליך-אוטומטי. הבעיה המעשית שהניעה את הכיוון הזה: ברוב-המערכות, לסוכן אין זהות עצמאית, אז הוא פועל בעזרת מפתחות-API, טוקנים, וסיסמאות שהונפקו במקור לבני-אדם או לתהליכי-רקע רגילים — כלומר "לובש" הרשאות שלא נבנו במקור בשבילו. לפי מחקר של חברת-האבטחה GitGuardian שפורסם ב-2026, דליפות-אישורים בשירותי-AI גדלו ב-81% משנה לשנה, עם 1.27 מיליון אישורים חשופים ב-2025 בלבד — ובבדיקה נפרדת של אותה חברה נמצאו למעלה מ-24,000 סודות ייחודיים חשופים בקובצי-הגדרות-MCP ציבוריים באותה שנה. הבעיה, לפי אותו מחקר, היא "בעיית-סודות לפני שהיא בעיית-זהות": סוכן שמאמת עם מפתח-API סטטי ורב-שימושי, בלי ספק-זהות ארגוני (IdP) שמתווך את החיבור, פועל בפועל "במערכות שאיש לא צופה בהן", ויוצר "נקודה-עיוורת ממשלית" (Governance Blind Spot) שבדיקות-זהות רגילות, שנבנו במקור סביב עובדים אנושיים, לא נועדו לחשוף.

ההתגבשות ב-2025: שלושה מהלכי-תעשייה עצמאיים באותה שנה

מה שהופך את זהות-הסוכן ל"מנגנון שהתגבש ב-2025" ולא לרעיון-תיאורטי-בלבד הוא שכמה גופים מובילים, ללא תיאום ישיר ביניהם, הכריזו על פתרונות-תשתית קונקרטיים באותה שנה. Okta (דרך פלטפורמת Auth0) השיקה ב-9 באפריל 2025 את "Auth for GenAI" בגרסת-תצוגה-מקדימה למפתחים — חבילת-יכולות שכוללת, בין השאר, "כספת-טוקנים" (Token Vault) לניהול ולריענון של אישורים מול שירותי-צד-שלישי בשם המשתמש, הרשאה-אסינכרונית למשימות-סוכן ארוכות-טווח שאין בהן משתמש שמחכה מול המסך, והרשאה-עדינת-פירוט (Fine-Grained Authorization) מותאמת לשליפת-מידע (RAG), כדי שסוכן לא יקבל גישה למסמכים שהמשתמש-הספציפי לא מורשה לראות. מיקרוסופט הכריזה במאי 2025 על Microsoft Entra Agent ID, שמעניק לכל סוכן שנוצר בכלים כמו Copilot Studio ו-Azure AI Foundry זהות עצמאית בספריית Entra — בהשוואה, לדברי מיקרוסופט עצמה, ל"חריטת מספר-שלדה (VIN) ייחודי על כל מכונית חדשה ורישומה עוד לפני שהיא יוצאת מהמפעל", והרחיבה זאת לתצוגה-מקדימה-ציבורית בכנס Ignite בנובמבר 2025. מיקרוסופט נימקה זאת בכך ש"התקפות מבוססות-זהות מהוות כיום כמעט 80% מכלל פריצות-האבטחה". חודש אחר-כך, ביוני 2025, הכריזה Okta גם על Cross App Access (XAA) — הרחבה של תקן OAuth שמעבירה את השליטה בחיבורי-סוכן-לאפליקציה משכבת-האפליקציה הבודדת לשכבת-הזהות המרכזית, בשיתוף גופים כמו AWS, Salesforce, Box ו-Google Cloud, במקום שהמשתמש יאשר בנפרד כל חיבור-סוכן לכל שירות.

שלושת המרכיבים: הרשאות מוגבלות, אישורים קצרי-טווח, יומן-אחריותיות

מעבר לזהות הנפרדת עצמה, המנגנון כולל שלושה מרכיבים שחוזרים בכל הגישות שהוזכרו. ראשית, הרשאות מוגבלות-לתפקיד (Scoped Permissions) — לתת לסוכן גישה לפעולה הספציפית שהוא צריך, לא למערכת שלמה. שנית, אישורים קצרי-טווח (Short-lived Credentials) — טוקן שפג-תוקף תוך שעות ולא חודשים, כדי לצמצם את חלון-הפגיעה גם אם נגנב. דוגמה למימוש קונקרטי של העיקרון הזה: Auth0 Token Vault, מוצר של Okta, מיישם דפוס שהחברה מכנה "הרשאה משורשרת-זהות" (Identity-Chained Authorization) — הסוכן עצמו אינו מחזיק אף-פעם אישור קבוע; ברגע שהוא צריך לבצע פעולה, המערכת מחליפה טוקן-רענון שמור בטוקן-גישה טרי, לפי תקן חילופי-הטוקנים הסטנדרטי RFC 8693. לפי Auth0, אין שכבת-מטמון (caching) בשום שלב בתהליך: כל פעולה מוגנת שולפת טוקן חדש ברגע-הביצוע שלה ולא ברגע-ההצעה שקדם לו, והטוקן עצמו כלל אינו נחשף למודל-השפה שמפעיל את הסוכן. שלישית, יומן-אחריותיות (Accountability Logging) — תיעוד שמאפשר לשייך כל פעולה של הסוכן חזרה לגורם-אנושי שהסמיך אותה. לפי מחקר-עומק שפרסם ארגון-התעשייה Cloud Security Alliance (CSA) ב-2026, הפער בין העיקרון למציאות עדיין רחב: 51% מהארגונים מדווחים שאין להם בעלות-ברורה על זהויות-AI, ו-16% אפילו לא עוקבים אחרי יצירה של זהויות-AI חדשות. אותו מחקר מצביע גם על קצב-הגידול העצום בהיקף הבעיה: יחס הזהויות-הלא-אנושיות לזהויות-אנושיות בסביבות-ענן עומד היום על כ-144 ל-1, לעומת 92 ל-1 במחצית-הראשונה של 2024. CSA מגדירה זהות-לא-אנושית, באופן כללי, כ"אישור דיגיטלי שמשמש מערכת, עומס-עבודה, אפליקציה, או תהליך-אוטומטי לאימות ולהרשאה של פעולותיו" — אבל מדגישה שסוכני-AI שונים מהותית מצרכני-אישורים סטטיים אחרים, בדיוק כי הם "מערכות אוטונומיות בעלות היכולת לחשוב על צורכי-הגישה שלהן, לבקש הרשאות חדשות, ולפעול על-פני מערכות ברצף" — לא רק לצרוך הרשאה קבועה שהוגדרה להן מראש פעם אחת.

הפער בין המתועד לבפועל: צבירת-הרשאות בזמן-ריצה

המאפיין הכי-בעייתי של המנגנון, ולמעשה הסיבה שהרשאות-על-הנייר לא תמיד משקפות את המציאות: סוכן יכול להתחיל משימה עם קבוצת-הרשאות מוגדרת-מראש, ולצבור הרשאות נוספות תוך-כדי-ריצה כשהוא נתקל במשאב שדורש גישה שלא הייתה לו בהתחלה — מבקש הרשאה חדשה, מקבל תפקיד-IAM אחר, או משיג טוקן-OAuth נוסף — בלי שהמסמך-המקורי שתיעד "מה מותר לסוכן הזה" עודכן בהתאם. דוגמה מוחשית לכך קיימת בתקן MCP עצמו: לפי המפרט מנובמבר 2025, כשלקוח-MCP מקבל שגיאת "הרשאה-בלתי-מספקת" (insufficient_scope) תוך-כדי ריצה, הוא רשאי לבצע "אימות-מדורג" (Step-up Authorization) ולבקש טוקן חדש עם הרשאות-מורחבות, מבלי לעצור ולבקש אישור-מחדש מלא מהמשתמש בכל פעם. זו בדיוק ההמחשה למה שתיאר מחקר CSA: הרשאות-על-הנייר של הסוכן ברגע-ההקצאה יכולות להיות קטנות-משמעותית מהיקף-הגישה שבידיו בפועל באמצע ביצוע משימה ארוכה — פער שקשה לבקר בלי יומן-אחריותיות רציף שמתעד כל צעד-הרחבה בנפרד.

סיכונים: קשר להרעלת-כלים ולאימות-בלתי-מספק

זהות-סוכן חלשה היא לא סיכון בפני-עצמה בלבד, אלא מכפיל-סיכון לתקיפות אחרות בעולם-הסוכנים. אם סוכן פועל תחת אישורים שאולים ורחבים-מדי, תקיפת הרעלת-כלים (Tool Poisoning) שמצליחה לשכנע אותו לבצע פעולה זדונית — יכולה לנצל בדיוק את ההרשאות העודפות האלה כדי לגרום נזק גדול-יותר משהיה אפשרי עם הרשאות מוגבלות-כהלכה. הקשר הזה מוכר מספיק שרשימת OWASP MCP Top 10 מקדישה לו פריט-נפרד — MCP07:2025, "אימות-והרשאה בלתי-מספקים" — לצד MCP02:2025, "הסלמת-הרשאות דרך זחילת-תחום" (Privilege Escalation via Scope Creep), שמתאר במפורש את אותה תופעה של הרשאות שמתרחבות בהדרגה מעבר למה שתוכנן. במילים אחרות: זהות-סוכן מוגדרת-היטב היא לא רק שכבת-נוחות ארגונית, אלא תנאי-מקדים לכך ששכבות-הבקרה האחרות — כולל ההגנות מפני הרעלת-כלים — יוכלו בכלל לזהות מה חריג ומה תקין. בלי יומן-אחריותיות שמצליח לשייך כל קריאה-לכלי לזהות-סוכן ספציפית ולהרשאה שאושרה לה מראש, גם תיאור-כלי מורעל וגם פעולה שחורגת מהיקף-המשימה המקורי נראים, מנקודת-המבט של מערכת-הניטור, כמעט זהים לפעולה תקינה.

מבחן מהשטח: קמפיין PaperCut ומה קורה בלי מחזור-חיים לאישורים

הסיכון שזהות-סוכן נועדה לצמצם אינו תיאורטי, וקנה-המידה שלו ניכר בתקיפה שניצלה בדיוק את החולשה ההפוכה: חשבונות-שירות ישנים בלי מחזור-חיים מוגדר. ב-31 באוגוסט 2026 תיעדה חברת-המודיעין-לאיומים GreyNoise קמפיין שבו תוקף בודד — ככל-הנראה דובר-רוסית — הפעיל מאות סוכני-AI, מבוססי OpenAI Codex ומודל DeepSeek, כדי לתקוף אוטומטית שרתי-הדפסה מבוססי-PaperCut חשופים-לאינטרנט, תוך ניצול שתי פרצות (CVE-2026-81578 ו-CVE-2026-82078). לפי GreyNoise, הקמפיין פגע ב-395 ארגונים ב-48 מדינות (440 מופעי-PaperCut שנפרצו), והגיע להרשאות-דומיין-אדמין ב-12 מהם — בעזרת בדיוק סוג-האישורים שזהות-סוכן אמורה להחליף: חשבונות-שירות עם הרשאות-דומיין-אדמין רחבות, בלי תאריך-תפוגה. הקצב ממחיש את גודל-הבעיה: אחרי שהקמפיין המלא יצא לדרך, 11 ארגונים נפרצו תוך 26 שניות, ותקיפה בודדת נגד תיכון אמריקאי הגיעה מגישה-ראשונית להרשאות-דומיין-אדמין תוך 7 דקות בלבד.

לאן זה מתקדם

נכון לזמן כתיבת ערך זה, זהות-סוכן היא עדיין תחום-בהתהוות, לא תקן-אחיד-אחד שכולם אימצו — בשונה מתחום-מקביל כמו MCP עצמו, שיש לו מפרט בודד תחת ממשל אחד. במקום זאת, כמה גישות מתפתחות במקביל: המסגרת של מיקרוסופט מתמקדת בשילוב עם ספריית-הזהויות הארגונית הקיימת (Entra), זו של Okta מתמקדת בהרחבת-OAuth לתקשורת-בין-אפליקציות, וה-Cloud Security Alliance עובד על "מסגרת-ממשל לזהות-סוכנית" (Agentic Identity Governance Framework) עצמאית-מספקים שמנסה לאחד עקרונות משותפים. כיוון-ההתכנסות ברור למרות זאת: הרשאה-לפי-פעולה ולא לפי-מערכת, זהות-נפרדת לכל סוכן במידת-האפשר, אישורים שפגי-תוקף במהירות, ותיעוד שמאפשר לשייך כל פעולה חזרה לגורם-אנושי-מסמיך — עקרונות שמזכירים במפורש את הדרך שבה תעשיית-האבטחה מתייחסת כבר עשורים לחשבונות-שירות ולעובדים אנושיים, רק מותאמים למאפיין הייחודי של סוכן: יכולת לפעול, לתכנן, ולבקש הרשאות חדשות בעצמו, בלי שמישהו מקליד כל בקשה בנפרד. עד שיתגבש תקן-אחיד, ה"מסמכה" (Framework) הבין-ספקית שמנסה למלא את החלל היא Agentic Identity Governance Framework של Cloud Security Alliance — ניסיון לנסח שפה משותפת לתחום שכרגע מפוצל בין פתרונות-ספק-ספציפיים, בדיוק כפי שהיה מצב-הכלים-החיצוניים לפני MCP. באוקטובר 2026 הציגה גוגל צעד נוסף בכיוון הזה, סוכן עמית (Coworker Agent): סוכן שמקבל חשבון Workspace משלו, עם כתובת דואר, יומן, Drive ומקום בספריית העובדים, ופועל תחת הזהות שלו ולא בשם המשתמש.