אימות פרוטוקול A2A: למה המפרט דליל והיכן נמצאים החורים
פרוטוקול ה-A2A (Agent2Agent) הופך לסטנדרט לתקשורת בין סוכני AI. גוגל הכריזה עליו ב-2025 וה-Linux Foundation מנהלת אותו כעת.
כשבחנו את סעיף האימות במפרט, כמעט לא מצאתי דבר. הוא אינו מגדיר מנגנון אימות חדש. הוא פשוט אומר לך להשתמש בסטנדרטים קיימים כמו OAuth2, OpenID Connect, או mTLS.
הדלילות הזו היא מכוונת. A2A מגדיר את המסגרת אך מפקיד את התוכן על סטנדרטים אחרים. זה יוצר חורי אבטחה אם לא נזהרים.
איך A2A עובד A2A הוא פרוטוקול שמאפשר לסוכן אחד להעביר משימה לסוכן אחר. הוא משתמש ב-JSON-RPC על גבי HTTP.
• Client Agent: הסוכן ששולח את הבקשה. • Remote Agent: הסוכן שמקבל את המשימה. • Agent Card: קובץ JSON שבו ה-Remote Agent מפרט את היכולות שלו ואת דרישות האימות שלו.
ה-Agent Card הוא החלק החשוב ביותר. לקוח קורא את הכרטיס הזה תחילה כדי ללמוד כיצד לבצע אימות לפני שליחת בקשה.
חורי האבטחה A2A משאיר מספר משימות קריטיות למממש. אם לא תטפלו בהן, הסוכנים שלכם נמצאים בסיכון.
- Card Tampering: חתימה על ה-Agent Card היא אופציונלית (MAY). אם לא תחתמו עליו, תוקף יוכל להפנות את הסוכן שלכם לשרת זדוני.
- Replay Attacks: ל-A2A אין דרך לקשור טוקנים (tokens) ללקוח ספציפי. אם מישהו גונב bearer token, הוא יכול להתחזות לסוכן שלכם.
- Privilege Escalation: ההרשאה (Authorization) נשארת באחריות תשתית חיצונית. אם לא תאכפו בדיקות ברמת המיומנות (per-skill), סוכן "לקריאה בלבד" עלול לקבל גישת "כתיבה".
- Identity Chaining: A2A אינו מטפל באופן שבו זהות המשתמש עוברת דרך שרשרת של סוכנים.
איך לבנות את זה בצורה בטוחה אל תסתמכו על המפרט לבדו. עליכם להפוך את הכללים האופציונליים לכללים מחייבים.
• תמיד תחתמו על ה-Agent Cards שלכם. השתמשו ב-JWS וב-JCS. • השתמשו ב-mTLS עבור נתיבים בין סוכנים. זה מונע ממקרה של גניבת טוקן להיות מספיק כדי לפגוע במערכת שלכם. • אכפו הרשאות ברמת המיומנות (per-skill authorization) ב-API Gateway שלכם. • השתמשו בטוקנים מוגבלים לשולח (כמו DPoP) כדי למנוע מתקפות Replay.
A2A הוא הצנרת. האבטחה מגיעה מהמים שזורמים דרכה. השתמשו בסטנדרטים מוכחים כמו SPIFFE או Identity Chaining כדי למלא את הפערים.
קהילת למידה אופציונלית: https://t.me/GyaanSetuAi