בעולם אבטחת המידע התרגלנו לחשוב על זהויות דרך אנשים: עובד, מנהל מערכת, ספק חיצוני או לקוח. לכל אחד חשבון, הרשאות, תהליך הצטרפות ועזיבה, ולעיתים גם MFA ובקרות גישה.
אבל בסביבה הארגונית המודרנית חלק הולך וגדל מהפעולות כלל אינו מבוצע על ידי בני אדם.
אפליקציות מתקשרות זו עם זו, שירותי ענן ניגשים למאגרי מידע, תהליכי אוטומציה מפעילים APIs, סקריפטים מתחברים למערכות, ורכיבי תוכנה מקבלים Tokens, Certificates ו־API Keys שמאפשרים להם לבצע פעולות בשם הארגון.
כל אלה הם Non-Human Identities – NHIs, או בעברית: זהויות שאינן אנושיות.
ועם הכניסה המהירה של AI Agents לארגונים, הנושא הופך משאלה טכנית של ניהול Service Accounts לסוגיה מרכזית של אבטחת מידע, הרשאות, Governance וניהול סיכונים.
מהי Non-Human Identity?
Non-Human Identity היא זהות דיגיטלית שמאפשרת ליישום, שירות, Workload, API, Bot, אוטומציה או רכיב תוכנה אחר להזדהות ולקבל הרשאה לגשת למשאב.
NHIs יכול להיות מוגדר כזהויות המשמשות לזיהוי, אימות והרשאה של ישויות תוכנה כגון אפליקציות, Workloads, APIs, Bots ומערכות אוטומטיות. בניגוד לזהות אנושית, הן אינן בהכרח קשורות באופן ישיר לאדם מסוים, וגם מנגנוני ההזדהות שלהן שונים לעיתים משמעותית מאלה של משתמשים אנושיים.
דוגמאות נפוצות כוללות:
- Service Accounts
- Applications ו־Service Principals
- Cloud Roles ו־Managed Identities
- API Keys
- Access Tokens
- Certificates
- Secrets המשמשים אפליקציות ומיקרו־שירותים
- Bots ותהליכי אוטומציה
- CI/CD Pipelines
- AI Agents
Microsoft, לדוגמה, מגדירה Workload Identity כזהות שניתנת ליישום, שירות, Script או Container כדי שיוכלו להזדהות מול מערכות אחרות. Workload identities וזהויות של התקנים מהוות יחד קטגוריה רחבה של Machine או Non-Human Identities.
למה מדובר בבעיה שונה מניהול משתמשים רגיל?
לעובד בארגון יש בדרך כלל תהליך מסודר יחסית.
הוא נקלט בחברה, נפתח עבורו משתמש, הוא מקבל הרשאות בהתאם לתפקיד, ולעיתים מתבצעות Access Reviews תקופתיות. כשהוא עוזב, קיים תהליך Offboarding שאמור לבטל את החשבון והגישה שלו.
עבור זהויות שאינן אנושיות התמונה מורכבת יותר.
Service Account יכול להיווצר עבור פרויקט זמני ולהישאר פעיל במשך שנים. מפתח יכול ליצור API Key לצורך אינטגרציה, אבל לאחר שהמערכת משתנה איש כבר לא זוכר מדוע המפתח קיים. אפליקציה יכולה לקבל הרשאות Administrator לצורך בדיקה ולהמשיך להחזיק אותן גם לאחר העלייה לייצור.
בנוסף, זהות אחת יכולה להחזיק מספר Credentials שונים ולהתחבר באמצעותם למספר מערכות.
OWASP מצביע בין היתר על ארבע בעיות מרכזיות: הרשאות עודפות, שימוש ב-Credentials ארוכי טווח כאשר ניתן להשתמש במנגנונים זמניים יותר, ניהול לקוי של Secrets וחוסר בניטור מספק.
במילים אחרות, האתגר אינו רק מי יכול להיכנס למערכת, אלא גם:
איזה רכיב תוכנה יכול לפעול, באיזו סמכות, בשם מי, מול איזה מידע – ולכמה זמן.
ואז הגיעו סוכני ה-AI
AI Agents משנים משמעותית את מודל הסיכון.
מערכת AI רגילה יכולה לענות על שאלה או לסכם מסמך. Agent, לעומת זאת, יכול לקבל משימה ולפעול כדי להשלים אותה: לקרוא מידע, להפעיל כלי, לפנות ל־API, לעדכן CRM, לשלוח הודעה, לפתוח Ticket או לבצע פעולה במערכת עסקית.
NIST כבר מתייחס במפורש לסוגיה הזו. בפברואר 2026 פרסם ה־NCCoE של NIST מסמך העוסק בזהות ובהרשאות של Software ו־AI Agents, מתוך הכרה בכך שהרחבת יכולות הסוכנים מחייבת פתרונות ברורים לזיהוי, Authentication, Authorization, Delegation ו־Auditing.
גם Microsoft מגדירה כיום AI Agent Identity כקטגוריה מובחנת של Machine Identity. הסיבה היא שסוכן AI אינו בהכרח Workload מסורתי שמבצע רצף קבוע של פעולות. הוא יכול לקבל החלטות דינמיות, לבחור Tools ולבצע פעולות שונות בהתאם להקשר.
וזה מעלה שאלה חדשה עבור ה-CISO:
אם הסוכן מסוגל לפעול כמו עובד – איזו זהות והרשאות צריך לתת לו?
סוכן AI לא צריך לקבל את ההרשאות של המשתמש כברירת מחדל
אחת הטעויות האפשריות בהטמעת Agentic AI היא לחבר Agent למספר מערכות באמצעות חשבון שירות אחד בעל הרשאות רחבות.
זה נוח מאוד מבחינה תפעולית.
וזו גם נקודת סיכון משמעותית.
נניח שסוכן AI שנועד לסייע לצוות המכירות מחובר ל־CRM, למייל, למערכת ניהול המסמכים ולמערכת ERP. כדי לפשט את ההטמעה, הארגון מעניק לזהות שלו הרשאות רחבות לכל ארבע המערכות.
במקרה כזה, היכולת של הסוכן גדולה משמעותית מהמשימה שעבורה הוקם.
Microsoft ממליצה במפורש שלא לרכז משתמש, אפליקציה, Agent ו־Tool תחת Secret משותף אחד או Service Account בעל הרשאות רחבות, אלא לשמור על הפרדה שתאפשר להבין מי ביצע כל פעולה ובאיזו סמכות.
גם בהנחיות Zero Trust העדכניות שלה ל־AI מודגש כי יש להתייחס לכל Agent ולכל הפעלת Tool כהחלטת אמון נפרדת, להשתמש בזהויות ייחודיות, Tokens מוגבלים וקצרי חיים ולדרוש אישור מוגבר לפעולות בעלות השפעה גבוהה.
הבעיה היא לא רק Credential שנגנב
כשמדברים על NHI קל לחשוב מיד על API Key או Secret שנחשפו.
זה בהחלט סיכון, אבל ב־AI Agents קיימת שכבה נוספת.
הזהות עצמה יכולה להיות תקינה לחלוטין — וה-Agent עדיין עלול לנסות לבצע פעולה שלא התכוונו לאפשר לו.
לדוגמה, Agent שקורא מקור מידע חיצוני עלול להיחשף להוראות זדוניות כחלק מ־Prompt Injection. אם אותו Agent מחזיק בהרשאות רחבות למערכות הארגון, הפער בין "מודל שקרא תוכן בעייתי" לבין "מערכת שמסוגלת לבצע פעולה רגישה" הופך קטן מאוד.
לכן הרשאות הן חלק ממנגנון ההגנה על AI, ולא רק חלק מתשתית ה־IAM.
OWASP ממליץ בהקשר של Agentic AI על Least Privilege עבור Tools ונתונים, אישור אנושי לפעולות בלתי הפיכות או בעלות השפעה גבוהה, אימות של תקשורת בין Agents ותיעוד של פעולות.
חמש שאלות שכל ארגון צריך לשאול על Non-Human Identities
1. האם אנחנו בכלל יודעים כמה NHIs קיימות אצלנו?
זהו השלב הראשון.
ארגון שמנהל אלפי עובדים אבל אינו יודע כמה Service Accounts, Applications, Secrets, Tokens, Bots ו־AI Agents פעילים בסביבה שלו אינו מחזיק תמונת Identity מלאה.
נדרש Inventory שמאפשר להבין:
מי יצר את הזהות, עבור איזו מערכת, מי הבעלים שלה, מתי נעשה בה שימוש לאחרונה, לאילו מערכות היא מחוברת ואילו הרשאות היא מחזיקה.
2. האם לכל זהות יש Owner אנושי?
זהות לא אנושית עדיין צריכה אחריות אנושית.
לכל Agent, Service Account או Application צריכה להיות בעלות ברורה: צוות עסקי או טכנולוגי שאחראי על הצורך בה, ההרשאות שלה ומחזור החיים שלה.
גם Microsoft מציגה Human Sponsorship ו־Lifecycle Governance כעקרונות מרכזיים בזהויות ייעודיות ל־AI Agents.
3. האם ההרשאות מתאימות למשימה?
Least Privilege אינו עיקרון חדש, אבל עבור AI Agents הוא מקבל משמעות חדשה.
Agent שקורא מידע אינו חייב לקבל הרשאת כתיבה.
Agent שמנהל פגישות אינו צריך גישה למידע פיננסי.
Agent שמשרת מחלקה אחת אינו צריך להחזיק הרשאות רוחביות לכל הארגון.
ההרשאה צריכה להיקבע לפי המשימה ולא לפי מה שנוח לחיבור הראשוני.
4. האם ה-Credentials שלנו קבועים כאשר הם יכולים להיות זמניים?
API Keys ו־Secrets ארוכי חיים מגדילים את חלון הסיכון במקרה של חשיפה.
ככל שהארכיטקטורה מאפשרת זאת, עדיף להשתמש ב־Managed Identities, Federation ו־Short-Lived Credentials במקום Secrets סטטיים שמוטמעים בקוד או נשמרים במשך שנים.
Microsoft אף ממליצה על Workload Identity Federation ו־Managed Identities כדי לאפשר ל־AI services ול־Workloads להזדהות בלי לנהל Secrets קבועים.
5. האם אנחנו יכולים להסביר בדיעבד מי עשה מה?
Audit הוא חלק קריטי מניהול NHI.
כשעובד משנה רשומה רגישה, הארגון רוצה לדעת מי ביצע את הפעולה.
אותו עיקרון צריך לחול גם על Agent.
נדרש להיות מסוגלים להבין איזו זהות ביצעה פעולה, איזה משתמש או תהליך הפעיל אותה, איזה Tool הופעל, מול איזה Resource ובאיזה Authorization Context.
השאלה היא כבר לא רק "האם הפעולה בוצעה על ידי Agent", אלא גם מטעם מי ובאיזו סמכות הוא פעל.
NIST מציין במפורש Auditing ו־Non-Repudiation כאחת הסוגיות המרכזיות שיש לפתור סביב זהויות של AI Agents.
מחזור החיים חשוב לא פחות מההרשאה
אחת הבעיות המסוכנות ביותר של NHI היא זהות שנשכחה.
פרויקט נסגר, אפליקציה הוחלפה, עובד עזב או Agent ניסיוני הפסיק להיות בשימוש — אבל הזהות, ה-Token או ה־API Key נשארו פעילים.
ניתן להציב את Improper Offboarding במקום הראשון ברשימת סיכוני ה-Non-Human Identities שלו ל-2025 ונחכה לראות מה יהיה בדוחת שנת 2026.
לכן ניהול NHI חייב לכלול Lifecycle מלא בעל שמונה שלבים:
- Discovery
- Ownership
- Provisioning
- Authorization
- Monitoring
- Review
- Rotation
- Revocation
זהות שנוצרה צריכה לקבל גם תנאי לסיום חייה.
ומה הקשר ל-Zero Trust?
Non-Human Identities הן למעשה המחשה מצוינת לעיקרון של Zero Trust.
NIST כבר קבע במסגרת SP 800-207 שארגון הפועל לפי Zero Trust צריך להכיר לא רק משתמשים אנושיים אלא גם Non-Person Entities, כגון Service Accounts, שמתקשרים עם משאבים ארגוניים.
המשמעות היא שלא מעניקים אמון רק משום שהבקשה מגיעה מתוך הרשת, מתוך ה-Cloud Tenant או מאפליקציה "שלנו".
יש לזהות את הישות, לאמת אותה, לבדוק את ההרשאה שלה ולבחון את ההקשר בכל גישה למשאב.
עבור Agents המשמעות אף רחבה יותר: גם Agent שהארגון עצמו יצר לא צריך לקבל אמון בלתי מוגבל.
AI Agent צריך זהות משלו
אחד העקרונות החשובים שעולים כיום הוא הפרדה בין:
המשתמש,
האפליקציה,
ה-Agent,
ה-Tool,
ו-המשאב שאליו ניגשים.
כאשר הכול פועל תחת Service Account משותף אחד, קשה לדעת מי באמת עשה מה וקשה מאוד ליישם מדיניות הרשאות מדויקת.
כאשר לכל Agent קיימת זהות מובחנת, ניתן להגדיר עבורה הרשאות, Owner, Lifecycle, מדיניות גישה וניטור.
זה גם מאפשר לענות על שאלה חשובה מאוד:
האם הפעולה בוצעה על ידי המשתמש – או על ידי Agent שפעל עבורו?
ההבחנה הזו תהפוך חשובה יותר ככל שארגונים יעברו מעוזרי AI שמציעים פעולות למערכות שמבצעות אותן באופן אוטונומי.
איך נכון להתחיל?
הטיפול ב-Non-Human Identities לא חייב להתחיל בפרויקט טכנולוגי גדול.
השלב הראשון הוא Governance.
כדאי להתחיל במיפוי של NHIs משמעותיות: Service Accounts, Applications, Cloud Identities, API Keys, Automation Accounts וכעת גם AI Agents.
לאחר מכן יש לזהות Owner, לבדוק הרשאות, לאתר Credentials ארוכי חיים, למצוא זהויות ללא שימוש ולבחון האם התהליך הארגוני מטפל ביצירה, שינוי וסיום של הזהויות האלה.
עבור AI Agents כדאי להוסיף שכבה נוספת: להגדיר מראש אילו Tools ונתונים הסוכן רשאי לצרוך, אילו פעולות הוא רשאי לבצע עצמאית, ואילו פעולות מחייבות Human-in-the-Loop.
איך אינפוגארד יכולה לסייע?
באינפוגארד אנחנו מסתכלים על Non-Human Identities כחלק מתמונת ניהול הזהויות, אבטחת המידע, ה־AI Governance וניהול הסיכונים הארגוני הרחבה.
הליווי יכול לכלול מיפוי NHIs ו־AI Agents, סקרי סיכונים ופערים, בחינת Service Accounts והרשאות, סקירת תהליכי Provisioning ו־Offboarding, מדיניות Secrets ו־Credentials, יישום עקרונות Least Privilege ו־Zero Trust, הגדרת Governance לסוכני AI ובחינת יכולות Audit וניטור.
בהטמעות AI ניתן לשלב את הנושא גם במסגרת ממשל רחבה יותר, לרבות ISO/IEC 42001, מדיניות AI ארגונית והיערכות לדרישות רגולטוריות רלוונטיות כגון ה־EU AI Act.
המטרה היא להבין לא רק אילו משתמשים יכולים להגיע למידע הארגוני, אלא גם אילו מערכות, שירותים וסוכני AI מסוגלים להגיע אליו – ובאיזו סמכות הם יכולים לפעול.
בעידן של AI Agents, זהות כבר אינה בהכרח אדם. מודל אבטחת הזהויות של הארגון צריך להשתנות בהתאם.
יצירת קשר עם מומחי אבטחת מידע של אינפוגארד
אנחנו באינפוגארד מאמינים שכל ארגון חייב נדרש לבחון את צרכיו, הסיכונים והדרישות החלות עליו באמצעות אנשי מקצוע מתאימים. ואנחנו באינפוגארד כאן ללוות אתכם.
המידע המוצג במאמר זה נועד למטרות מידע והעשרה בלבד ואינו מהווה תחליף לייעוץ מקצועי, רגולטורי, משפטי, סייבר, אבטחת מידע, הגנת הפרטיות או ייעוץ טכנולוגי.
המאמר נכתב בשיתוף מומחי אבטחת המידע והסייבר של Infoguard מקבוצת IDOR, ונערך על ידי רועי קיש, חובב פרטיות, אבטחת מידע, סייבר ומנהל השיווק של קבוצת חברות עידור (Messagent, Infoguard, Idornext).
יצירת קשר עם מומחי אבטחת המידע של אינפוגארד
