Agent-to-Agent Trust Handshake — אימות הדדי בין סוכנים לפני שיתוף פעולה
מאת צוות מדיה דיל · 12.08.2026 · Agent Protocols · 5 דק׳
איך שני סוכנים אוטונומיים, שכל אחד שייך לארגון אחר, מקימים אמון הדדי לפני שהם מתחילים לשתף מידע ולבצע פעולות — מעבר לאימות OAuth בסיסי.
סוכן רכש בארגון תעשייתי גדול קיבל בקשה מ"סוכן ספק" לעדכן פרטי הזמנה — אבל איך הוא אמור לדעת שהבקשה הזו אכן מגיעה מהספק המורשה, ולא מסוכן זדוני שמתחזה לו כדי להטות תשלומים לחשבון אחר? אימות OAuth2 סטנדרטי עונה על השאלה "מי אתה" ברמת הזהות הארגונית, אבל לא עונה על השאלה החשובה יותר במערכות multi-agent: "האם אני יכול לסמוך על מה שהסוכן הזה יגיד לי, ברמת המשימה הספציפית הזו". Trust Handshake הוא השכבה שמעל האימות הבסיסי — פרוטוקול משא ומתן שבו שני סוכנים מבססים רמת אמון הדדית לפני שהם חולקים מידע רגיש או מבצעים פעולה בלתי הפיכה.
למה אימות זהות לבדו לא מספיק
אימות זהות (authentication) עונה על "מי הצד השני", ולעיתים גם על הרשאות ברמת מערכת (authorization) — "האם יש לו זכות לקרוא לפעולה הזו בכלל". אבל במערכת סוכנים אוטונומיים יש שכבה שלישית שקריטית לא פחות: "האם התוכן שהצד השני שולח אמין ברמת התוכן עצמו". סוכן יכול להיות מאומת לגמרי — מפתח API תקין, חתימת mTLS תקינה — ועדיין להיות תחת השתלטות, להריץ גרסה פגיעה, או פשוט "להזות" מידע שגוי בביטחון מלא. Trust Handshake מוסיף בדיקות שמעבר לזהות: גרסת פרוטוקול נתמכת, רמת provenance של המידע שהסוכן מספק, ולעיתים גם attestation קריפטוגרפי שהסוכן רץ בסביבה לא מזוהמת.
ההבחנה הזו קריטית כי היא משנה את מודל האיום: לא מספיק לשאול "מי מתקשר אליי" אלא גם "האם אני מוכן לסמוך על מה שהוא אומר לגבי המשימה הזו". הרחבה על ההבדל בין רבדי אימות שונים במערכות סוכנים נמצאת במדריך ארכיטקטורת MCP, שם מפורט מודל דומה ברמת שרת-לקוח.
מבנה משא ומתן האמון בפועל
תהליך Trust Handshake טיפוסי מתחיל ב-capability probe: הסוכן היוזם שולח בקשה קטנה שבודקת אילו רמות אמון הצד השני תומך בהן, בלי לחשוף עדיין מידע רגיש. הצד הנענה מחזיר את רמות האמון הנתמכות — לדוגמה basic (אימות זהות בלבד), verified (אימות זהות פלוס attestation), ו-audited (אימות מלא כולל היסטוריית ביקורת חתומה). שני הצדדים מסכימים על הרמה הנדרשת למשימה הספציפית: בקשת מידע ציבורי מסתפקת ב-basic, אבל עדכון פרטי תשלום דורש audited ולא פחות מכך.
ברגע שהרמה סוכמה, מתבצע חילופי אסימונים חתומים — לרוב JWT עם claims מותאמים שמתארים בדיוק את היקף האמון שהוסכם: אילו סוגי פעולות מותרות, לכמה זמן ההסכמה תקפה, ומה גבולות הסמכות של כל צד. חשוב שהאסימון הזה יהיה ספציפי למשימה, לא כללי — אמון שהוענק לביצוע בירור מלאי לא אמור להספיק לביצוע עדכון תשלום, גם אם מדובר באותם שני סוכנים בדיוק.
Provenance ו-Attestation — מעבר לחתימה פשוטה
ברמת האמון הגבוהה ביותר, Trust Handshake כולל attestation — הוכחה קריפטוגרפית שהסוכן פועל בגרסת קוד ידועה ובסביבת ריצה לא פגומה, בדומה למנגנוני TEE (Trusted Execution Environment) שכבר נפוצים בעולם ה-cloud. זה קריטי כשמדובר בסוכנים שמנהלים כספים או מידע רגיש במיוחד, כי חתימה קריפטוגרפית לבדה מוכיחה רק שמפתח פרטי מסוים היה בשימוש, לא שהסוכן שמפעיל אותו לא נחטף או שונה מאז הבדיקה האחרונה.
- Basic trust — אימות זהות בלבד, מתאים למידע ציבורי בלבד
- Verified trust — אימות זהות + attestation לגרסת קוד ידועה
- Audited trust — הכול לעיל + היסטוריית ביקורת חתומה וניתנת לבדיקה
מנגנון provenance מלווה גם את התוכן עצמו: כשסוכן מעביר מידע שהתקבל מצד שלישי (למשל תוצאת חיפוש מסוכן אחר לגמרי), הפרקטיקה הנכונה היא לצרף שרשרת provenance מלאה — מי יצר את המידע במקור, מי העביר אותו, ומתי — כדי שהצד המקבל יוכל להעריך את מהימנותו לבד, ולא לסמוך עיוורת על השרשור.
מה קורה כשהאמון לא מספיק
כשסוכן מקבל בקשה שדורשת רמת אמון גבוהה מזו שהוסכמה, ההתנהגות הנכונה היא לא לבצע חלקית ולא לנחש — אלא להחזיר סטטוס מפורש שמבקש העלאת רמת אמון, בדומה למצב input-required ב-A2A שכבר מתואר במדריך A2A 1.0. הצד היוזם יכול אז לבחור להעלות את רמת האמון (למשל דרך אימות אנושי נוסף) או לוותר על המשימה. ההימנעות מ"לנחש" את כוונת המשתמש היא בדיוק מה שמונע פעולות בלתי הפיכות שמתבצעות על סמך הנחה שגויה.
לבניית מערכת שבה סוכנים ממספר ארגונים מתאמים ביניהם באופן שוטף, Trust Handshake הוא לא שכבת אבטחה אופציונלית — הוא תנאי בסיסי לכל תיאום שחוצה גבול ארגוני. שילוב שלו עם משא ומתן על יכולות, שמתואר במדריך משא ומתן על יכולות, יוצר את שתי השכבות שנדרשות לכל שיתוף פעולה בין סוכנים זרים: קודם קובעים כמה סומכים, ואז קובעים מה בדיוק אפשר לעשות יחד.
עלות מול תועלת — מתי לא כדאי להגזים
לא כל אינטראקציה בין סוכנים מצדיקה handshake מלא ברמת audited. תקשורת פנימית בין סוכנים באותו ארגון, שכבר עברו אימות ברמת הרשת, יכולה להסתפק ב-basic כל עוד שני הצדדים ידועים מראש. הגזמה בדרישת אמון גבוהה לכל אינטראקציה יוצרת latency מיותר ומורכבות תפעולית — כל handshake נוסף הוא round-trip נוסף לפני שהעבודה בכלל מתחילה. הכלל המעשי הוא לדרג את רמת האמון לפי רגישות הפעולה בפועל, לא לפי "כמה שיותר בטוח תמיד", כי בטיחות מוגזמת שגורמת לצוותים לעקוף את המנגנון בסוף מזיקה יותר ממנו.
שמירת תוצאות ה-Handshake ל-Session
ברגע שהאמון נקבע, אין טעם לחזור על כל התהליך בכל קריאה בודדת — התוצאה נשמרת כ-session מוגבל בזמן, עם תוקף שנקבע לפי רגישות המשימה: דקות ספורות לפעולה כלכלית רגישה, שעות או ימים לתקשורת שגרתית בין שותפים מוכרים. ה-session token שנוצר מכיל את רמת האמון שהוסכמה, כדי שכל קריאה עוקבת תוכל להסתמך עליו בלי לפתוח מו"מ מחדש, אבל גם עם מנגנון ביטול מיידי אם מתגלה חשד לפגיעה באמון — למשל אם הצד השני מדווח שהוא זוהה כמותקף. תכנון נכון של תוקף ה-session הוא לרוב ההבדל בין מערכת שמרגישה זריזה לבין מערכת שכל קריאה בה עוברת דרך שכבת אבטחה שמאיטה אותה שלא לצורך.
תגיות: Trust Handshake · A2A security · agent authentication · attestation · provenance · zero trust agents