Linux Foundation ২০২৬ সালের ১৪ জুলাই x402 Foundation গঠনের ঘোষণা দিয়েছে, যা AI-agent পেমেন্ট প্রোটোকলটিকে একটি আনুষ্ঠানিক ঠিকানা প্রদান করেছে। Visa, Mastercard, Stripe এবং Google এর প্রতিষ্ঠাতা সদস্য হিসেবে এতে যোগ দিয়েছে।
এই ঘোষণায় একটি পেমেন্ট দাবি যে আসল কিনা তা প্রমাণ করার কোনো উপায় জানানো হয়নি। এখানে কোনো conformance suite, কোনো security profile, কোনো certification program এবং কোনো validation procedure নেই। কাঠামো বা রেইলস (rails) নির্ধারিত করা হয়েছে; কিন্তু একজন এজেন্ট প্রকৃতপক্ষে পেমেন্ট করার কর্তৃত্ব বা অথরিটি পেয়েছে কিনা তার প্রমাণ নেই।
লঞ্চ এবং অনুপস্থিত অংশটি
x402 প্রোটোকলটি স্বায়ত্তশাসিত (autonomous) সফটওয়্যার এজেন্টগুলো কীভাবে রসিদ এবং পেমেন্টের প্রমাণ আদান-প্রদান করবে তা মানসম্মত (standardise) করে। এই মান নির্ধারণ একটি প্রয়োজনীয় পদক্ষেপ, তবে এটি একটি পেমেন্ট সিস্টেমের প্রয়োজনের অর্ধেক মাত্র। প্রথাগত অর্থব্যবস্থায়, শুধুমাত্র মেসেজ ফরম্যাট সঠিক হওয়ার কারণে কোনো লেনদেন গ্রহণ করা হয় না; এটিকে অবশ্যই কতগুলো নিরাপত্তা যাচাইকরণ (security checks) প্রক্রিয়ার মধ্য দিয়ে যেতে হয়, যা পেমেন্টকারীর উদ্দেশ্য, অনুরোধের সত্যতা এবং ক্রিপ্টোগ্রাফিক চেইনের অখণ্ডতা যাচাই করে।
x402-এর প্রতিষ্ঠাতা নথিপত্রগুলোতে মেসেজ ফরম্যাট বিস্তারিতভাবে বর্ণনা করা হয়েছে, তবুও কোনো implementation প্রয়োজনীয় নিরাপত্তা যাচাইকরণ নিশ্চিত করছে কিনা তা পরীক্ষা করার জন্য কোনো test harness নির্দিষ্ট করতে তারা ব্যর্থ হয়েছে। একটি নিরপেক্ষ test suite না থাকলে, যেকোনো ভেন্ডর গুরুত্বপূর্ণ সুরক্ষা ব্যবস্থাগুলো বাদ দিয়েও দাবি করতে পারে যে “we follow the spec”।
কেন একটি রসিদ যথেষ্ট নয়
x402 বিশ্বে একটি পেমেন্ট রসিদ তিনটি দাবি করে:
- কাজটি সম্পন্ন হয়েছে।
- কাজটি অনুমোদিত (authorized) ছিল।
- নিরাপত্তা যাচাইকরণ (security checks) প্রকৃতপক্ষে সম্পন্ন হয়েছে।
ডিজিটাল সিগনেচার প্রথম দাবিটি নিশ্চিত করতে পারে – তারা প্রমাণ করে যে কেউ একটি নির্দিষ্ট রেকর্ড স্বাক্ষর করেছে। তবে দ্বিতীয় এবং তৃতীয় দাবির ক্ষেত্রে তারা কিছুই করতে পারে না। একজন আক্রমণকারী একটি বৈধ দেখায় এমন রসিদ জাল করতে পারে, একটি পুরনো রসিদ পুনরায় ব্যবহার (replay) করতে পারে, অথবা মেসেজের সময় পরিবর্তন করে মূল অনুমোদনটি যাতে কখনোই ঘটেনি তা নিশ্চিত করতে পারে। বর্তমান স্ট্যান্ডার্ডে এই ধরনের আক্রমণ শনাক্ত বা প্রতিরোধের কোনো নির্দেশিকা নেই।
একটি সুনির্দিষ্ট আক্রমণ যা স্ট্যান্ডার্ড চেকগুলোকে ফাঁকি দেয়
সাম্প্রতিক ShareLock পেপার (arXiv 2606.27027) এমন এক ধরনের আক্রমণের কথা দেখিয়েছে যা একটি parser-এর কাছে অদৃশ্য থাকবে যদি সেটি রসিদের প্রতিটি অংশকে আলাদাভাবে যাচাই করে। লেখকরা দেখিয়েছেন কীভাবে একজন প্রতিপক্ষ (adversary) বেশ কয়েকটি টুল ডেসক্রিপশনের মধ্যে ক্ষতিকারক নির্দেশাবলী লুকিয়ে রাখতে পারে। প্রতিটি আলাদা ডেসক্রিপশন সমস্ত সিনট্যাকটিক (syntactic) এবং সিগনেচার চেক পাস করে, কিন্তু যখন সিস্টেমটি অংশগুলো একত্রিত করে, তখন সম্মিলিত ফলাফল হিসেবে একটি গোপন কমান্ড তৈরি হয় যা পেমেন্টকারীর সম্মতি ছাড়াই পেমেন্ট অনুমোদন করে দেয়।
যেহেতু x402 স্পেসিফিকেশন শুধুমাত্র প্রতিটি কম্পোনেন্ট সঠিকভাবে parse করার প্রয়োজন নির্দেশ করে, তাই ShareLock-এ বর্ণিত আক্রমণটি এমন যেকোনো implementation-এর বিরুদ্ধে সফল হবে যা শুধুমাত্র বিদ্যমান ভ্যালিডেশন নিয়মের ওপর নির্ভর করে। সমস্যাটি ক্রিপ্টোগ্রাফির কোনো ত্রুটি নয়; বরং এটি হলো অথরিটি বা কর্তৃত্বের দাবিটি কম্পোজিশনের (composition) পরেও টিকে আছে কিনা তা নিশ্চিত করার ক্ষেত্রে একটি ঘাটতি।
কার উচিত অথরিটি বা কর্তৃত্ব পরীক্ষা করা
একজন প্রোটোকল লেখক পক্ষপাতিত্ব ছাড়াই নিজের ডিজাইনকে red-team করতে পারেন না, এবং একজন ভেন্ডর স্বাধীন দৃষ্টিভঙ্গি ছাড়া নিজের নিরাপত্তা সার্টিফিকেট দিতে পারেন না। তাই শিল্পের প্রয়োজন একটি নিরপেক্ষ, adversarial testing framework যা:
- রসিদ, সিগনেচার এবং স্টেট ট্রানজিশন (state transitions) হ্যান্ডলিংয়ের ক্ষেত্রে একটি implementation-এর বিরুদ্ধে পূর্ণাঙ্গ conformance test পরিচালনা করে।
- ShareLock-এর দেখানো মাল্টি-পার্ট ইনজেকশনের মতো threat-modelled attack scenario পরিচালনা করে, যাতে যাচাই করা যায় যে কম্পোজিশনের অধীনে অথরিটি বা কর্তৃত্বের দাবিটি বজায় থাকে কিনা।
- একটি স্বাধীন ল্যাব প্রমাণ করার পরেই কেবল সার্টিফিকেশন প্রদান করে যে implementation-টি replay, forgery এবং desynchronisation আক্রমণ প্রতিরোধ করতে সক্ষম।
x402-এর লঞ্চ প্রথম দিন থেকেই সেই স্তরটিকে শূন্য রেখে গেছে। তৃতীয় পক্ষের test suite ছাড়া, "compliant" বা মানসম্মত হওয়ার যেকোনো দাবি কেবল "সিনট্যাক্স চেক পাস করা" বোঝাতে পারে।
সারসংক্ষেপ
x402 প্রোটোকল এখন একটি ঠিকানা পেয়েছে, কিন্তু ভেন্ডর-নিরপেক্ষ conformance এবং security testing framework ছাড়া প্রতিটি পেমেন্টের পেছনের অথরিটি বা কর্তৃত্ব যাচাইহীন থেকে যায়। যতক্ষণ না একটি স্বাধীন সংস্থা প্রমাণ করতে পারে যে একটি রসিদের “authorized” বা অনুমোদিত দাবিটি বাস্তব জগতের আক্রমণ মোকাবিলা করতে পারে, ততক্ষণ নিরাপদ AI-agent বাণিজ্যের প্রতিশ্রুতি নাগালের বাইরে থাকবে।