بنیاد لینوکس در ۱۴ ژوئیه ۲۰۲۶، تأسیس بنیاد x402 را اعلام کرد و به پروتکل پرداخت عاملهای هوش مصنوعی (AI-agent) یک خانه رسمی بخشید. ویزا، مسترکارت، استرایپ و گوگل به عنوان اعضای مؤسس در این بنیاد حضور یافتند.
این اعلامیه هیچ راهی برای اثبات اصالت ادعای پرداخت ارائه نداد. هیچ مجموعه انطباق (conformance suite)، پروفایل امنیتی، برنامه صدور گواهینامه و رویه اعتبارسنجی وجود ندارد. زیرساختها تعریف شدهاند، اما اثبات اینکه یک عامل واقعاً اجازه پرداخت دریافت کرده است، مفقود است.
راهاندازی و قطعه گمشده
پروتکل x402 نحوه تبادل رسیدها و شواهد پرداخت توسط عاملهای نرمافزاری خودمختار را استاندارد میکند. این استانداردسازی گامی ضروری است، اما تنها نیمی از نیازهای یک سیستم پرداخت را پوشش میدهد. در امور مالی سنتی، یک تراکنش صرفاً به دلیل صحیح بودن قالب پیام پذیرفته نمیشود؛ بلکه باید از مجموعهای از بررسیهای امنیتی عبور کند که قصد پرداختکننده، اصالت درخواست و یکپارچگی زنجیره رمزنگاری را تأیید میکنند.
اسناد تأسیس x402 قالب پیام را با جزئیات شرح میدهند، اما از تعیین یک چارچوب تست (test harness) که بررسی کند آیا یک پیادهسازی، بررسیهای امنیتی لازم را اعمال میکند یا خیر، بازماندهاند. بدون یک مجموعه تست بیطرف، هر فروشندهای میتواند ادعا کند که «ما از مشخصات فنی پیروی میکنیم»، در حالی که بهطور پنهانی از اعمال تدابیر حفاظتی حیاتی خودداری میکند.
چرا یک رسید کافی نیست
یک رسید پرداخت در دنیای x402 سه ادعا را مطرح میکند:
- عملیات انجام شده است.
- عملیات مجاز بوده است.
- بررسیهای امنیتی واقعاً اجرا شدهاند.
امضاهای دیجیتال میتوانند ادعای اول را تضمین کنند – آنها ثابت میکنند که شخصی یک رکورد خاص را امضا کرده است. اما برای ادعاهای دوم و سوم هیچ کمکی نمیکنند. یک مهاجم میتواند رسیدی جعلی که معتبر به نظر میرسد بسازد، یک رسید قدیمی را بازپخش (replay) کند، یا زمانبندی پیامها را دستکاری کند تا مجوز اصلی هرگز صادر نشده باشد. استاندارد فعلی روشی برای شناسایی یا جلوگیری از این حملات تجویز نمیکند.
یک حمله عینی که از بررسیهای استاندارد عبور میکند
مقاله اخیر ShareLock (arXiv 2606.27027) دستهای از حملات را نشان میدهد که برای یک تجزیهگر (parser) که هر بخش از رسید را بهصورت مجزا اعتبارسنجی میکند، نامرئی خواهد بود. نویسندگان نشان میدهند که چگونه یک مهاجم میتواند دستورالعملهای مخرب را در چندین توصیف ابزار جاسازی کند. هر توصیف بهتنهایی تمام بررسیهای نحوی و امضا را پشت سر میگذارد، اما وقتی سیستم قطعات را کنار هم قرار میدهد، اثر ترکیبی آنها یک فرمان مخفیانه است که بدون رضایت پرداختکننده، اجازه پرداخت میدهد.
از آنجایی که مشخصات x402 تنها مستلزم تجزیه صحیح هر جزء است، حمله توصیفشده در ShareLock علیه هر پیادهسازی که صرفاً به قوانین اعتبارسنجی موجود متکی باشد، موفق خواهد بود. مشکل، نقص در رمزنگاری نیست؛ بلکه شکافی در اطمینان از این است که ادعای مجوز در هنگام ترکیب اجزا همچنان معتبر باقی میماند.
چه کسی باید مجوز را آزمایش کند
نویسنده یک پروتکل نمیتواند بدون سوگیری، طراحی خود را مورد حمله (red-team) قرار دهد و یک فروشنده نیز نمیتواند امنیت محصول خود را بدون یک دیدگاه مستقل تأیید کند. بنابراین، صنعت به یک چارچوب تست بیطرف و تقابلی (adversarial) نیاز دارد که:
- مجموعه کامل تستهای انطباق را در برابر نحوه مدیریت رسیدها، امضاها و تغییرات وضعیت در یک پیادهسازی اجرا کند.
- سناریوهای حمله مدلسازیشده بر اساس تهدید، مانند تزریق چندبخشی نشان داده شده توسط ShareLock، را برای تأیید اینکه ادعای مجوز در هنگام ترکیب اجزا پابرجا میماند، اجرا کند.
- تنها پس از اینکه یک آزمایشگاه مستقل نشان داد پیادهسازی در برابر حملات بازپخش، جعل و از همگامسازی خارج شدن (desynchronisation) مقاوم است، گواهینامه صادر کند.
راهاندازی x402 از روز اول این لایه را خالی گذاشت. بدون یک مجموعه تست شخص ثالث، هر ادعایی مبنی بر «مطابقت» (compliant) میتواند صرفاً به معنای «گذراندن بررسی نحوی» باشد.
جمعبندی
پروتکل x402 اکنون خانهای دارد، اما بدون یک چارچوب تست امنیتی و انطباق بیطرف نسبت به فروشندگان، اعتبار پشت هر پرداخت تأیید نشده باقی میماند. تا زمانی که یک نهاد مستقل نتواند ثابت کند که ادعای «مجاز بودن» یک رسید در برابر حملات دنیای واقعی مقاومت میکند، وعده تجارت امن توسط عاملهای هوش مصنوعی دور از دسترس خواهد ماند.