קרן Linux הכריזה על הקמת קרן x402 ב-14 ביולי 2026, מה שמעניק לפרוטוקול התשלומים של סוכני AI בית רשמי. Visa, Mastercard, Stripe ו-Google הצטרפו כחברות מייסדות.
ההכרזה לא הציעה שום דרך להוכיח שטענת תשלום היא אמיתית. אין סט בדיקות תאימות (conformance suite), אין פרופיל אבטחה, אין תוכנית הסמכה ואין הליך אימות. המסילות מוגדרות; ההוכחה לכך שסוכן אכן קיבל הרשאה לשלם חסרה.
ההשקה והחלק החסר
פרוטוקול x402 מתקנן את האופן שבו סוכני תוכנה אוטונומיים מחליפים קבלות וראיות לתשלום. התקינה הזו היא צעד הכרחי, אך היא מהווה רק מחצית ממה שמערכת תשלומים צריכה. בפיננסים מסורתיים, עסקה אינה מתקבלת רק משום שפורמט ההודעה נכון; היא חייבת לעבור גם סדרה של בדיקות אבטחה שמאמתות את כוונת המשלם, את אותנטיות הבקשה ואת שלמות השרשרת הקריפטוגרפית.
מסמכי ההקמה של x402 מתארים את פורמט ההודעה בפירוט, אך הם עוצרים לפני שקובעים מנגנון בדיקה (test harness) שבודק האם מימוש מסוים אוכף את בדיקות האבטחה הנדרשות. ללא סט בדיקות ניטרלי, כל ספק יכול לטעון ש"אנחנו עומדים במפרט" תוך שהוא משמיט בשקט אמצעי הגנה קריטיים.
מדוע קבלה אינה מספיקה
קבלה של תשלום בעולם ה-x402 מציגה שלוש טענות:
- הפעולה התבצעה.
- הפעולה אושרה.
- בדיקות האבטחה אכן רצו.
חתימות דיגיטליות יכולות להבטיח את הטענה הראשונה – הן מוכיחות שמישהו חתם על רשומה מסוימת. הן אינן עושות דבר עבור הטענות השנייה והשלישית. תוקף יכול לזייף קבלה שנראית תקפה, להשתמש מחדש (replay) בקבלה ישנה, או לתמרן את עיתוי ההודעות כך שההרשאה שבבסיסן מעולם לא התרחשה. התקן הנוכחי אינו קובע כיצד לזהות או למנוע התקפות אלו.
התקפה קונקרטית שחומקת מבדיקות סטנדרטיות
מאמר ShareLock האחרון (arXiv 2606.27027) מדגים סוג של התקפות שיהיו בלתי נראות עבור מנתח (parser) שרק מאמת כל חלק בקבלה בנפרד. המחברים מראים כיצד יריב יכול להטמיע הוראות זדוניות על פני מספר תיאורי כלים. כל תיאור בודד עובר את כל בדיקות התחביר והחתימה, אך כאשר המערכת מרכיבה את החלקים, האפקט המשולב הוא פקודה סמויה המאשרת תשלום ללא הסכמת המשלם.
מכיוון שמפרט x402 דורש רק שכל רכיב ינותח בצורה נכונה, ההתקפה המתוארת ב-ShareLock תצליח נגד כל מימוש המסתמך אך ורק על כללי האימות הקיימים. הבעיה אינה פגם בקריפטוגרפיה; היא פער בהבטחה שטענת ההרשאה שורדת את תהליך ההרכבה (composition).
מי צריך לבדוק את ההרשאה
מחבר פרוטוקול אינו יכול לבצע Red Teaming לעיצוב שלו ללא הטיות, וספק אינו יכול להסמיך את האבטחה שלו ללא נקודת מבט עצמאית. לכן, התעשייה זקוקה למסגרת בדיקה ניטרלית ואדברסרית (adversarial) אשר:
- מבצעת את סט המלא של בדיקות התאימות אל מול הטיפול של המימוש בקבלות, חתימות ומעברי מצב (state transitions).
- מריצה תרחישי התקפה מבוססי מודל איומים, כגון ההזרקה הרב-חלקית שהוצגה ב-ShareLock, כדי לוודא שטענת ההרשאה נשמרת תחת הרכבה.
- מנפיקה הסמכות רק לאחר שמעבדה עצמאית הוכיחה שהמימוש עומד בפני התקפות replay, זיוף ואיבוד סנכרון (desynchronisation).
השקת x402 הותירה את השכבה הזו ריקה מהיום הראשון. ללא סט בדיקות של צד שלישי, כל טענה ל"תאימות" (compliant) יכולה פשוט להצביע על כך שהמערכת "עוברת בדיקת תחביר".
שורה תחתונה
לפרוטוקול x402 יש כעת בית, אך ללא מסגרת בדיקות תאימות ואבטחה ניטרלית לספקים, ההרשאה שמאחורי כל תשלום נותרת ללא אימות. עד שגוף עצמאי יוכל להוכיח שטענת ה"מאושר" (authorized) של קבלה שורדת התקפות בעולם האמיתי, ההבטחה למסחר בטוח באמצעות סוכני AI תישאר רחוקה מהישג יד.