Agent Identity & Authentication — זהות דיגיטלית ל-AI Agents

מאת צוות מדיה דיל · 09.08.2026 · AI · 8 דק׳

כשעשרות AI Agents פועלים במקביל מול מסדי נתונים, APIs ומערכות פנימיות, שאלת "מי בדיוק ביצע את הפעולה הזו" הופכת קריטית. מדריך טכני לבניית שכבת זהות ואימות ל-Agents.

בארגון עם עשרה AI Agents שרצים בפרודקשן, תרחיש נפוץ נראה כך: כולם משתמשים באותו API Key, שמור באותו Secret Manager, עם אותן הרשאות רחבות. יום אחד מתגלה שאחד ה-Agents ביצע פעולת מחיקה לא צפויה במסד נתונים. השאלה "איזה Agent, באיזו הרצה, מכוח איזו בקשת משתמש" — אין לה תשובה, כי מבחינת המערכת כולם פשוט "השירות". זו לא בעיית לוגים, זו בעיית זהות: כשאין ל-Agent זהות ייחודית ובת-אימות, אין גם דרך אמיתית להטיל עליו אחריות, להגביל אותו, או לחקור אירוע. Agent Identity הוא התשתית שבלעדיה כל שיחה על אבטחת AI Agents נשארת תיאורטית.

מה זה Agent Identity ולמה זה שונה מזהות אנושית

זהות דיגיטלית ל-AI Agent היא ייצוג ייחודי, ניתן לאימות, של "מי" מבצע פעולה — לא אדם, לא שירות מונוליטי, אלא ישות תוכנה אוטונומית עם היסטוריית פעולות משלה. זה שונה מזהות משתמש בכמה מובנים מהותיים:

• קצב פעולות — Agent יכול לבצע מאות קריאות בדקה, כך שמנגנוני אימות שנועדו לבני אדם (סשן דפדפן, MFA אינטראקטיבי) פשוט לא מתאימים.
• ריבוי מופעים — אותו קוד Agent יכול לרוץ כעשרות instances מקבילים, וכל אחד צריך זהות משלו כדי שיהיה אפשר להבדיל ביניהם באודיט.
• שרשראות האצלה — Agent לעיתים פועל "בשם" משתמש שהפעיל אותו, ולפעמים גם קורא ל-Agent אחר, כך שנוצרת שרשרת זהויות שצריך לשמר לאורך כל הקריאה.
• מחזור חיים קצר — instance של Agent יכול לעלות ולרדת תוך שניות (במיוחד בארכיטקטורת serverless), כך שזהות סטטית וארוכת-טווח היא סיכון מובנה.

הקטגוריה המקצועית לזה נקראת Non-Human Identity (NHI) — תחום שהתפתח סביב service accounts ומיקרו-שירותים, אבל ה-Agentic AI מכניס אליו קנה מידה ואוטונומיה שלא היו קודם.

המודל השגוי: Shared Service Account

הדפוס הנפוץ ביותר, וגם הבעייתי ביותר, הוא Agent שמקבל API Key או Service Account יחיד, ואז כל instance וכל הרצה משתמשים באותו credential. זה נוח להטמעה אבל שובר שלוש יכולות קריטיות בו-זמנית: אודיט (אי אפשר לשייך פעולה ל-instance ספציפי), הכלת נזק (דליפת המפתח = פגיעה בכל ה-Agents), וביטול סלקטיבי (אי אפשר לחסום Agent אחד בלי להפיל את כולם). כל ארגון שמריץ יותר מ-Agent אחד בפרודקשן צריך לצאת מהדפוס הזה מוקדם ככל האפשר — המעבר הופך יקר יותר ככל שיש יותר אינטגרציות תלויות ב-credential המשותף.

מנגנוני אימות מעשיים ל-Agents

API Keys — נקודת התחלה, לא פתרון סופי

API Keys סטטיים קלים להטמעה אבל חסרי מחזור חיים אמיתי: הם בדרך כלל לא פגי-תוקף, קשה לרוטט אותם בלי downtime, ואין בהם הקשר (context) מובנה — מפתח לא "יודע" מי הנפיק אותו או למה. מתאימים לשלבי POC בלבד.

mTLS — זהות ברמת התעבורה

Mutual TLS נותן לכל Agent תעודה קריפטוגרפית שמאמתת אותו ברמת החיבור עצמו, לפני שבכלל הגיעה בקשת HTTP. זה חזק במיוחד בתקשורת service-to-service בתוך רשת סגורה, ומשתלב טבעי עם SPIFFE/SPIRE — סטנדרט פתוח להנפקת זהויות workload קצרות-טווח (SVID) שמתחדשות אוטומטית כל דקות ספורות, כך שגם אם תעודה דלפה, חלון הניצול שלה מוגבל מאוד.

OAuth2 Client Credentials — הסטנדרט למרבית המקרים

זהו הדפוס המומלץ לרוב תרחישי ה-Agent-to-API: ל-Agent יש client_id ו-client_secret ייחודיים (או certificate-bound credential), הוא פונה ל-Identity Provider ומקבל access token קצר-טווח עם scopes מוגדרים. ה-token הזה, לא ה-credential הקבוע, הוא מה שעובר בכל קריאה בפועל.

POST /oauth/token
grant_type=client_credentials
client_id=agent-invoice-processor-7f3a
client_assertion_type=jwt-bearer
client_assertion=<signed JWT with agent identity claims>
scope=invoices:read documents:write

# תגובה: access_token עם TTL של 5-15 דקות
# ה-token כולל claim ייחודי לכל instance: agent_instance_id

Delegated Identity — כש-Agent פועל בשם משתמש

כאשר Agent מבצע פעולה מטעם משתמש קונקרטי (למשל, "תזמן לי פגישה"), הזהות הנכונה היא לא זהות ה-Agent לבדה אלא שרשרת האצלה: מי המשתמש, איזה Agent פועל בשמו, ואיזה טוקן מייצג את הצירוף הזה. תבניות כמו Token Exchange (RFC 8693) ו-On-Behalf-Of flows מאפשרות ל-Agent להחליף טוקן משתמש בטוקן "Agent-פועל-בשם-משתמש" עם scope מצומצם מזה של המשתמש המקורי — עיקרון שמתקשר ישירות לLeast Privilege ל-Agents.

ניהול מחזור חיים: הנפקה, רוטציה, ביטול

זהות בלי מחזור חיים מנוהל היא סיכון עצור-שעון. שלושה עקרונות תפעוליים:

• Short-lived by default — טוקנים לדקות, לא לימים. אם Agent צריך הרשאה ליותר זמן, זה סימן שצריך refresh flow, לא TTL ארוך.
• רוטציה אוטומטית — credentials בסיסיים (client secrets, certificates) מתחלפים במחזוריות קבועה ללא התערבות אנושית, כדי שדליפה ישנה תפוג מעצמה.
• ביטול מיידי (Revocation) — כשמתגלה חריגה, צריך יכולת לבטל זהות של Agent ספציפי תוך שניות, בלי להשפיע על Agents אחרים. זה דורש שה-Identity Provider יתמוך ב-token introspection או רשימות ביטול, לא רק בפגיעת TTL.

ארכיטקטורה מומלצת: Agent Identity Broker

בקנה מידה, הפתרון הנכון הוא שכבת Identity Broker ייעודית ל-Agents, שיושבת בין ה-Agent Runtime ל-Identity Provider הארגוני: כל instance של Agent מקבל ממנה זהות ייחודית בעת ההפעלה (spawn), מבקש דרכה טוקנים לכל יעד, והיא זו שאוכפת מדיניות רוטציה ומתעדת כל הנפקה ל-שכבת האודיט. הבroker הזה גם מהווה את נקודת האינטגרציה הטבעית עם מנוע מדיניות שמחליט אילו scopes מותר להנפיק לאיזה Agent, ובאילו תנאים.

Identity Sprawl — כשהפתרון הנכון נעשה בעיה בפני עצמו

ברגע שארגון מבין שכל Agent צריך זהות ייחודית, קל ליפול למלכודת ההפוכה: מאות זהויות, כל אחת עם client secret משלה, בלי בעלים ברור, בלי תיעוד למה היא נוצרה ומה ה-scope שלה. זה נקרא Identity Sprawl, והוא בעצם אותה בעיית "אי אפשר לבקר את המערכת" מזווית הפוכה — במקום זהות אחת גדולה מדי, יש עשרות זהויות קטנות שאף אחת מהן לא נסקרת. הפתרון המעשי הוא רישום מרכזי (Identity Registry) שמחייב לכל זהות Agent: בעלים אנושי אחראי, מטרה מתועדת, תאריך יצירה, ותאריך סקירה מחדש. בלי הרישום הזה, גם ארכיטקטורה נכונה עקרונית הופכת בלתי ניתנת לביקורת בפועל.

פדרציה בין סביבות: Dev, Staging, Production

נקודה שקל לפספס בתכנון ראשוני: Agent שרץ בסביבת פיתוח, ואותו Agent שרץ בפרודקשן, חייבים להיות בעלי זהויות נפרדות לחלוטין — לא רק scope מוגבל יותר, אלא Identity Provider ותצורת רוטציה נפרדים. הסיבה היא שסביבת פיתוח נוטה להיות פחות מאובטחת (יותר אנשים עם גישה, פחות ניטור), ולכן דליפת credential שם לא צריכה לחשוף שום דבר שרלוונטי לפרודקשן. דפוס נפוץ ומסוכן הוא "בדיקה מהירה בפרודקשן" עם credential שנוצר לצורך dev — כל ארכיטקטורת Agent Identity בשלה חוסמת את זה מבנית, לא רק במדיניות כתובה.

טעויות נפוצות

• שיוך זהות לקוד ולא ל-instance — כל ה-deployments של אותו Agent חולקים credential אחד, כך שאי אפשר להבדיל ריצה בעייתית מהאחרות.
• העדר separation בין זהות ה-Agent לזהות המשתמש שבשמו הוא פועל — מוביל לחוסר יכולת להסביר "למה זה קרה".
• credentials בקוד או במשתני סביבה סטטיים — במקום שילוב עם ניהול Secrets ייעודי שמנפיק ומחדש credentials דינמית.
• אין תוכנית ביטול — יודעים איך להנפיק זהות אבל לא איך לשלול אותה תחת לחץ, באירוע אמת.

מדדים לבדיקת בריאות תשתית הזהות

כדי לדעת אם ארכיטקטורת Agent Identity אכן עובדת, ולא רק "קיימת על הנייר", כדאי לעקוב אחרי כמה מדדים תפעוליים קבועים: אחוז הזהויות הפעילות שיש להן בעלים אנושי מתועד (המדד המרכזי נגד Identity Sprawl), זמן ממוצע מרגע גילוי דליפת credential ועד ביטולה בפועל, מספר הזהויות עם TTL ארוך מהנדרש (סימן אזהרה לתצורה רשלנית), ותדירות רוטציית secrets בפועל מול המדיניות המוצהרת. ארגונים שמנטרים את זה כחלק משגרה, לא רק בתגובה לאירוע, מגלים בעיות תצורה הרבה לפני שהן הופכות לאירוע אבטחה אמיתי — עיקרון שדומה למה שמתואר בניטור תשתית AI באופן כללי.

דוגמה מהשטח

ארגון שמריץ מספר Coding Agents אוטונומיים במקביל למד את זה בדרך הקשה: כל ה-Agents שיתפו token אחד ל-GitHub API, ולאחר תקלה בקוד שנוצר על ידי אחד מהם לא היה אפשר לדעת אילו commits הגיעו מאיזה Agent Run. המעבר לזהות ייחודית לכל instance, עם JWT שכולל run_id ו-triggering_user, פתר את זה — ואגב, גם אפשר rate limiting פר-Agent במקום rate limit גלובלי שחנק את כולם יחד.

היבט רגולטורי: תיעוד זהות כדרישת ציות

ככל שיותר ארגונים פועלים תחת מסגרות רגולציה שדורשות מעקב ברור אחרי מי ביצע פעולה על נתונים רגישים (במיוחד בתחומי פיננסים ובריאות), זהות Agent ייחודית ובת-אימות הופכת מדרישה הנדסית לדרישת ציות. רגולטורים ומבקרים לא מקבלים "המערכת ביצעה את זה" כתשובה מספקת — הם דורשים יכולת להראות בדיוק איזו ישות, עם אילו הרשאות, ביצעה כל פעולה על נתון רגיש. ארגונים שבונים את שכבת הזהות נכון מהתחלה חוסכים לעצמם עבודת שיפוץ יקרה כשמגיע ביקורת ראשונה שדורשת הוכחת traceability מלאה.

שאלות נפוצות

האם צריך Identity Provider ייעודי ל-Agents, או שאפשר להשתמש בזה שכבר יש לעובדים?

אפשר להתחיל עם אותו IdP (למשל תשתית OAuth2/OIDC קיימת) אבל להגדיר client type נפרד ל-Agents, עם מדיניות TTL, scopes ורוטציה שונה מזו של משתמשים אנושיים. בקנה מידה גדול, ארגונים רבים עוברים ל-broker ייעודי כפי שתואר למעלה.

מה ההבדל בין Authentication ל-Authorization בהקשר של Agents?

Authentication עונה על "מי אתה" — האם הטוקן תקף ושייך לזהות הזו. Authorization עונה על "מה מותר לך לעשות" בהינתן הזהות. מדריך זה מתמקד באימות; ההרשאה נדונה בהרחבה כאן.

האם SPIFFE/SPIRE רלוונטי גם מחוץ ל-Kubernetes?

SPIFFE הוא סטנדרט אגנוסטי לפלטפורמה, אבל האימוץ הרחב שלו כן מגיע מסביבות container orchestration. ל-Agents שרצים ב-serverless או VMs פשוטים יותר, OAuth2 Client Credentials עם short-lived tokens נותן ערך דומה בפשטות הטמעה גבוהה יותר.

איך מטפלים בזהות כש-Agent אחד קורא ל-Agent אחר?

זה בדיוק תרחיש ה-Delegated Identity: הזהות שמועברת היא לא רק "Agent B", אלא שרשרת "Agent A פועל בשם משתמש X, קורא ל-Agent B". שרשרת ההאצלה צריכה להישמר בכל hop כדי שאודיט וניתוח פוסט-מורטם יהיו אפשריים, נושא שנוגע גם לארכיטקטורת multi-agent.

מה קורה כשה-Identity Provider עצמו לא זמין?

זו נקודת כשל קריטית שצריך לתכנן אליה מראש: אם ה-IdP לא זמין, Agents שצריכים טוקן חדש לא יכולים לפעול. תכנון נכון כולל TTL שמאפשר לטוקנים קיימים להמשיך לעבוד לפרק זמן קצר גם בזמן תקלה זמנית, לצד ניטור זמינות ה-IdP עצמו כרכיב קריטי בתשתית, לא כשירות משני.

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

תגיות: Agent Identity · AI Authentication · Non-Human Identity · OAuth2 · mTLS · SPIFFE · Zero Trust AI

← חזרה לבלוג · צור קשר