← כל המאמרים

AI Security · Agent Identity · MCP · A2A · 2026-05-31 · 8 דק׳ קריאה

מאת נתנאל סיבוני

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

התעשייה עסוקה בשאלה מה סוכן AI מסוגל לעשות. בעיניי, השאלה המסוכנת יותר היא מי הסוכן בכלל: מי יצר אותו, מי מפעיל אותו, מה מותר לו לעשות, באיזה תקציב, ובשם מי הוא פועל כשהוא נוגע בכסף, לקוחות, שרתים או מערכות production.

איור מופשט של דרכון דיגיטלי לסוכן AI עם הרשאות, תקציב ולוג פעילות
הדור הבא של סוכני AI יצטרך יותר ממודל חכם: הוא יצטרך זהות, הרשאות, תקציב, audit trail ואחריות.
התשובה הקצרה:
סוכן AI שמבצע פעולות עסקיות צריך להיחשב כישות תפעולית עם זהות. לא מספיק לתת לו API key או גישה ל-MCP. צריך לדעת מי הבעלים שלו, מה התפקיד שלו, אילו הרשאות יש לו, מה מגבלת התקציב, מתי הוא חייב אישור אנושי, ואיך מתעדים כל פעולה. בלי שכבת Agent Identity, עולם הסוכנים עלול להפוך לרשת של פעולות חכמות שאף אחד לא באמת יודע לייחס, להגביל או לחקור.

תוכן עניינים

סוכן AI הוא כבר לא כלי

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

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

וכאשר ישות דיגיטלית פועלת בתוך עסק, השאלה הראשונה היא לא רק מה היא יודעת לעשות. השאלה היא מי אחראי עליה.

דמיינו סוכן שמבצע תהליך רכש

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

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

אלה כבר לא שאלות תיאורטיות. אלה שאלות של אחריות, אבטחה, רגולציה, ביטוח, ציות וניהול סיכונים.

MCP ו-A2A חשובים, אבל הם לא שכבת זהות

MCP הוא צעד חשוב: הוא מאפשר לחשוף לסוכנים כלים, מידע ויכולות בצורה מסודרת יותר. אבל MCP לא עונה לבד על השאלה מי הסוכן. הוא לא קובע מי הבעלים שלו, מה התקציב שלו, מה רמת האמון שלו, או מי נושא באחריות לפעולה שבוצעה.

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

בדיוק כפי ששרת API אינו מחליף מערכת הרשאות, גם MCP ו-A2A אינם מחליפים מערכת זהויות. הם צינורות פעולה ותקשורת. מעליהם חייבת לשבת שכבת governance.

ההשוואה הנכונה היא לא MCP מול A2A, אלא MCP ו-A2A מול שכבת Agent Identity. כל אחת מהשכבות פותרת בעיה אחרת, והטעות המסוכנת היא לבחור פרוטוקול תקשורת כאילו הוא גם מערכת אחריות.

שכבהמה היא פותרתמה היא לא פותרת לבד
MCPחשיפת כלים, מידע ופעולות לסוכן בצורה מסודרת.בעלות, אחריות עסקית, תקציב, רמת אמון ומדיניות הרשאות מלאה.
A2Aתקשורת ושיתוף פעולה בין סוכנים.החלטה האם לסמוך על הסוכן המבקש, מי אחראי לפעולה, ומתי חייבים אישור אנושי.
Agent Identityזהות, תפקיד, בעלים, הרשאות, תקציב, audit trail ומוניטין.לא מחליפה את MCP או A2A; היא יושבת מעליהם כשכבת שליטה ואמון.

מהי Agent Identity?

Agent Identity היא שכבת זהות לסוכן AI. לא רק שם יפה ולא רק API key. זה פרופיל דיגיטלי שמגדיר את הסוכן כישות תפעולית בתוך הארגון.

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

דרכון דיגיטלי לסוכנים

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

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

הרשאות, תקציב ואישור אנושי אינם קישוט

אחת הטעויות הגדולות ביותר היא לתת לסוכן הרשאות רחבות מדי. סוכן שיכול לקרוא מידע לא בהכרח צריך למחוק אותו. סוכן שמפיק הצעת מחיר לא בהכרח צריך לחייב כרטיס אשראי. סוכן שמנתח שרת production לא בהכרח צריך לבצע deploy.

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

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

Audit Trail ומוניטין לסוכנים

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

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

זו שכבת תשתית, לא פיצ׳ר קטן

כמו שהאינטרנט לא היה יכול לצמוח בלי DNS, SSL, זהויות משתמשים ומערכות הרשאות, גם כלכלת הסוכנים לא תוכל לצמוח בלי שכבת זהות, אמון, הרשאות, ביקורת ואחריות.

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

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

העמדה שלי:
העתיד של סוכני AI לא יוכרע רק לפי איכות המודל. הוא יוכרע לפי היכולת של ארגונים לזהות, לאמת, להגביל, לתעד ולנהל סוכנים שפועלים בשם העסק.

מקורות

שאלות נפוצות

למה API key לא מספיק לזהות סוכן?

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

האם Agent Identity רלוונטי גם לעסק קטן?

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

מה ההבדל בין הרשאה לבין אחריות?

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

איך מתחילים לבנות שכבת זהות לסוכנים?

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

רוצה לחבר סוכני AI לעסק בלי לאבד שליטה?
אפשר להתחיל מבדיקת סיכונים קצרה: אילו סוכנים קיימים, לאילו מערכות הם נוגעים, מה ההרשאות שלהם, ואיפה חייבים audit trail ואישור אנושי. דבר איתי על מיפוי Agent Identity לעסק.