עד לא מזמן, רוב מערכי ה-Identity בארגון נבנו סביב שאלה יחסית ברורה: מי המשתמש ולאילו מערכות מותר לו לגשת?
העובד מזדהה, מערכת ה-Identity מאמתת את זהותו, מדיניות הגישה נבדקת ובהתאם לכך הוא מקבל גישה לאפליקציות ולמידע שהוא צריך.
כניסתם של AI Agents לסביבת העבודה משנה את המודל הזה.
AI Agent כבר לא רק עונה על שאלות. הוא יכול לבצע פעולות בשם המשתמש, לאסוף מידע ממספר מערכות, לעבוד עם אפליקציות ארגוניות ולהשתמש במידע שנמצא בהן כדי להשלים משימה.
עובד יכול, למשל, לבקש מ-Claude להכין סיכום לקראת השקת מוצר. כדי לבצע את המשימה, ה-Agent עשוי להזדקק למידע ממספר מערכות שבהן הארגון עובד. במילים אחרות, שרשרת הגישה כבר אינה רק:
User → Application
אלא:
User → AI Agent → Application → Corporate Data
וכאן נוצרת שאלת Identity חדשה: אם Agent פועל בשם המשתמש, מי מחליט לאילו מערכות ומידע מותר לו לגשת?
כשה-AI מתחיל לפעול, הרשאות הופכות לבעיה ארגונית
ככל ש-AI Agents הופכים לחלק מתהליכי העבודה, הם זקוקים ליותר חיבורים למערכות הארגוניות.
אחד המנגנונים שמאפשרים את החיבורים האלה הוא Model Context Protocol – MCP שמאפשר ל-AI להתחבר לכלים, מקורות מידע ושירותים חיצוניים בצורה סטנדרטית יותר.
אבל עצם היכולת לחבר Agent למערכת אינה פותרת את שאלת האבטחה.
בסביבות רבות, חיבורים של Agents עדיין יכולים להסתמך על API Keys סטטיים, הרשאות OAuth נקודתיות או אישורים שהמשתמש נותן לכל חיבור בנפרד.
ככל שמספר ה-Agents והאפליקציות גדל, כך קשה יותר לענות על שאלות בסיסיות: איזה Agent מחובר לאיזו מערכת? בשם איזה משתמש הוא פועל? אילו הרשאות ניתנו לו? ומה קורה להרשאות האלה כאשר העובד עוזב את הארגון או משנה תפקיד?
מה שעובד כאשר מדובר במספר קטן של חיבורים עלול להפוך במהירות לנקודת עיוורון משמעותית כאשר AI נכנס לעשרות תהליכים ומערכות בארגון.
לחבר Agent לאפליקציה זה החלק הקל
נניח שעובד משתמש ב-Claude ורוצה לאפשר לו לגשת למערכת ארגונית כדי לבצע עבורו משימה.
מבחינת המשתמש, החיבור יכול להיראות פשוט: מאשרים גישה וממשיכים לעבוד. מבחינת צוותי ה-IT וה-Security, התמונה מורכבת יותר.
האם המשתמש בכלל רשאי לאפשר את החיבור? האם ה-Agent מקבל את אותן הרשאות שיש למשתמש? האם הוא צריך את כולן? האם צוות האבטחה יודע שהחיבור נוצר? וכיצד ניתן לבטל אותו בצורה מרכזית?
כאן בדיוק נמצא הפער בין היכולת הטכנולוגית לבצע חיבור לבין היכולת הארגונית לנהל אותו.
לחבר AI Agent לאפליקציה זו פעולה טכנולוגית. להחליט בשם מי הוא פועל, לאיזה מידע הוא רשאי להגיע ומתי צריך לבטל את הגישה שלו – זו כבר שאלת Identity.
XAA מכניס את ה-Identity לתוך החיבור
כדי להתמודד עם האתגר הזה, Okta הובילה את פיתוח Cross App Access – XAA, פרוטוקול פתוח שמרחיב את עקרונות OAuth לעולם שבו אפליקציות ו-AI Agents צריכים לקבל גישה לאפליקציות אחרות.
הרעיון המרכזי הוא להעביר את החלטת הגישה אל מערכת ה-Identity הארגונית.
במקום שכל משתמש ינהל בעצמו את החיבורים בין ה-Agent לבין האפליקציות שבהן הוא משתמש, ה-Identity Provider יכול להפוך לנקודת הבקרה.
כאשר Agent מבקש להתחבר למשאב ארגוני, ניתן לבדוק את הבקשה מול המדיניות שהארגון הגדיר, להעניק גישה בהתאם להרשאות המתאימות ולשמור על נראות ושליטה בחיבור.
XAA גם שולב בעולם ה-MCP כ-Enterprise-Managed Authorization, כך שארגונים יכולים להכניס שכבת Authorization מרכזית גם לחיבורים שנוצרים בין AI Agents לבין מערכות מבוססות MCP.
Claude ו-Okta: איך זה נראה בפועל?
החיבור בין Anthropic ל-Okta ממחיש איך המודל הזה מתחיל לעבוד בסביבה ארגונית אמיתית.
Anthropic בחרה ב-Okta כ-Featured Identity Provider בתוכנית ה-Enterprise-Managed Authorization עבור Claude.
במודל הזה, מנהלי IT יכולים לאשר ברמה הארגונית את ה-MCP Connectors שבהם Claude רשאי להשתמש, במקום להשאיר לכל עובד לנהל את החיבורים וההרשאות בעצמו.
הגישה יכולה להתבסס על משתמשים, קבוצות ותפקידים שכבר מוגדרים ב-Okta, והארגון יכול לנהל ולבטל את הגישה דרך אותה מערכת Identity מרכזית.
לדוגמה, אם עובד רשאי להשתמש ב-Claude ובמערכת מסוימת המחוברת באמצעות MCP, Claude יכול לפעול מול אותה מערכת בהתאם למדיניות שהוגדרה בארגון.
כאשר ההרשאות של העובד משתנות או כאשר המשתמש או ה-Agent יוצאים מהארגון, ניתן לבטל גם את הגישה הזו בצורה מרכזית.
כך ה-Identity Provider הופך לא רק למקום שמחליט לאן העובד יכול להיכנס, אלא גם למערכת שמסייעת לקבוע לאן ה-Agent שפועל בשמו יכול להגיע.
מ-SSO לעובדים ל-Agent SSO
ההתפתחות של XAA היא חלק משינוי רחב יותר שמתרחש כיום בעולם ה-Identity.
באוגוסט 2026 הודיעה Okta על הזמינות הכללית של Agent SSO, שמכניס את XAA לתוך יכולות ה-SSO שלה.
Agent שתומך ב-XAA יכול להירשם ב-Okta כזהות בפני עצמה ולהופיע ב-Universal Directory לצד הזהויות האנושיות בארגון.
המשמעות היא שארגונים יכולים להתחיל להתייחס ל-Agent כישות שצריך לנהל: לזהות אותו, לראות לאילו מערכות הוא מחובר ולהחיל מדיניות על הגישה שלו. במקום להסתמך על Static API Keys או Credentials שנשמרים בתוך אינטגרציות שונות, ניתן לבסס את החיבור על Tokens קצרי-חיים הנשלטים באמצעות מערכת ה-Identity.
זהו שינוי משמעותי בתפקיד של Identity בארגון.
SSO נועד במקור לרכז את הדרך שבה אנשים ניגשים לאפליקציות. Agent SSO מרחיב את אותו עיקרון לעולם שבו גם Agents צריכים לעבור בין אפליקציות כדי לבצע עבודה.
אבל Agent SSO לבדו אינו אסטרטגיית AI Identity
כמו במקרה של Passwordless, גם כאן טכנולוגיה אחת אינה פותרת את כל האתגר.
היכולת לחבר Agent בצורה מאובטחת לאפליקציה עונה על שאלה חשובה: איך ה-Agent מקבל גישה?
אבל ככל שהארגון מפעיל יותר Agents, עולות שאלות נוספות.
אילו Agents קיימים בכלל בארגון? מי הבעלים של כל Agent? אילו מהם נוצרו ואושרו על ידי ה-IT ואילו הופעלו באופן עצמאי על ידי עובדים? לאילו מערכות כל Agent יכול להתחבר? מה הוא רשאי לעשות בהן? ומה קורה כאשר כבר אין בו צורך?
כאן נכנסת תפיסה רחבה יותר של AI Identity Governance.
Okta for AI Agents מרחיבה את ניהול הזהויות מעבר לחיבור הבודד ומאפשרת לארגונים לנהל את מחזור החיים של Agents, לזהות גם Agents שאינם מנוהלים, לשייך להם Owner אנושי ולהחיל תהליכי Governance והרשאות.
המטרה היא להגיע לאותה רמת נראות ושליטה שארגונים בנו במשך שנים סביב משתמשים אנושיים – גם עבור כוח העבודה החדש שאינו אנושי.
שלוש שאלות שארגונים צריכים להתחיל לשאול
בעולם שבו AI Agents הופכים לחלק מתהליכי העבודה, ניהול Identity צריך לתת מענה לשלוש שאלות מרכזיות.
הראשונה היא מי ה-Agent? לא מספיק לדעת שמשתמש מסוים הפעיל כלי AI. הארגון צריך לזהות גם את ה-Agent עצמו ולדעת מי אחראי עליו.
השנייה היא למה הוא יכול להתחבר? Agent לא צריך לקבל גישה לכל משאב שאליו המשתמש יכול להגיע רק משום שהוא פועל בשמו. החיבורים צריכים להיות מוגדרים ומנוהלים בהתאם למדיניות הארגונית.
והשלישית היא מה מותר לו לעשות? גם לאחר שהגישה ניתנה, הארגון צריך להיות מסוגל לשלוט בהיקף ההרשאות ולנהל אותן לאורך מחזור החיים של ה-Agent.
השאלות האלה הופכות את AI Security גם לבעיית Identity.
ה-Identity Perimeter מתרחב
AI Agents לא מחליפים את המשתמשים, אבל הם משנים את הדרך שבה משתמשים עובדים עם מערכות ומידע.
ככל שהם מקבלים יותר יכולת לפעול באופן עצמאי, לבצע משימות ולנוע בין אפליקציות, כך הם הופכים לחלק ממערך הזהויות של הארגון.
ולכן השאלה כבר אינה רק מי המשתמש שנכנס למערכת?
צריך לדעת גם איזה Agent פועל, בשם מי הוא פועל, לאן הוא מנסה להגיע ומה מותר לו לעשות שם.
XAA והחיבור בין Okta ל-Claude הם דוגמה לאופן שבו עולם ה-Identity מתחיל להתאים את עצמו למציאות הזו – באמצעות העברת השליטה על חיבורי Agent-to-App אל מערכת ה-Identity הארגונית.
אינטגריטי תוכנה מסייעת לארגונים לתכנן וליישם מערכי Identity ו-Zero Trust המותאמים גם לסביבת העבודה החדשה של AI Agents – החל ממיפוי זהויות, אפליקציות והרשאות ועד לתכנון ויישום פתרונות Okta לניהול גישה, Governance ו-AI Identity.
באמצעות יכולות Okta, Cross App Access ו-Okta for AI Agents, ניתן להרחיב את מדיניות ה-Identity הארגונית מעבר למשתמשים אנושיים וליצור שכבת שליטה מרכזית גם עבור Agents שפועלים בשם המשתמשים ומתחברים למערכות הארגון.
כי בעידן של Agentic AI, לא מספיק לדעת מי המשתמש. צריך לדעת גם מי, או מה, פועל בשמו.
למידע נוסף, השאירו פרטים בטופס.