2026 ജൂലൈ 14-ന് ലിനക്സ് ഫൗണ്ടേഷൻ (Linux Foundation) x402 ഫൗണ്ടേഷന്റെ രൂപീകരണം പ്രഖ്യാപിച്ചു, ഇത് AI-ഏജന്റ് പേയ്മെന്റ് പ്രോട്ടോtoലിന് ഒരു ഔദ്യോഗിക ഇടം നൽകുന്നു. Visa, Mastercard, Stripe, Google എന്നിവർ ഇതിന്റെ സ്ഥാപക അംഗങ്ങളായി ഒപ്പുവെച്ചു.
ഒരു പേയ്മെന്റ് ക്ലെയിം യഥാർത്ഥമാണെന്ന് തെളിയിക്കാൻ പ്രഖ്യാപനത്തിൽ യാതൊരു മാർഗവുമില്ല. ഇതിനായി ഒരു കൺഫോമൻസ് സ്യൂട്ട് (conformance suite), സെക്യൂരിറ്റി പ്രൊഫൈൽ, സർട്ടിഫിക്കേഷൻ പ്രോഗ്രാം അല്ലെങ്കിൽ വാലിഡേഷൻ നടപടിക്രമങ്ങൾ എന്നിവ നിലവിലില്ല. അടിസ്ഥാന ഘടനകൾ (rails) നിർവചിക്കപ്പെട്ടിട്ടുണ്ട്; എന്നാൽ ഒരു ഏജന്റിന് പണമടയ്ക്കാൻ യഥാർത്ഥത്തിൽ അധികാരം ലഭിച്ചുവെന്ന തെളിവ് ഇതിൽ വിട്ടുപോയിരിക്കുന്നു.
ലോഞ്ചും വിട്ടുപോയ ഭാഗവും
സ്വയംഭരണാധികാരമുള്ള (autonomous) സോഫ്റ്റ്വെയർ ഏജന്റുകൾ എങ്ങനെയാണ് രസീതുകളും പേയ്മെന്റ് തെളിവുകളും കൈമാറേണ്ടതെന്ന് x402 പ്രോട്ടോക്കോൾ മാനദണ്ഡവൽക്കരിക്കുന്നു. ആ മാനദണ്ഡവൽക്കരണം ഒരു ആവശ്യമായ ഘട്ടമാണ്, എന്നാൽ ഒരു പേയ്മെന്റ് സിസ്റ്റത്തിന് വേണ്ട കാര്യങ്ങളുടെ പകുതി മാത്രമാണത്. പരമ്പരാഗത സാമ്പത്തിക ഇടപാടുകളിൽ, സന്ദേശത്തിന്റെ ഫോർമാറ്റ് ശരിയായതുകൊണ്ട് മാത്രം ഒരു ഇടപാട് സ്വീകരിക്കപ്പെടില്ല; പണമടയ്ക്കുന്നയാളുടെ ഉദ്ദേശ്യം, അഭ്യർത്ഥനയുടെ ആധികാരികത, ക്രിപ്റ്റോഗ്രാഫിക് ചെയിനിന്റെ വിശ്വാസ്യത എന്നിവ പരിശോധിക്കുന്ന സുരക്ഷാ പരിശോധനകളിലൂടെയും അത് കടന്നുപോകണം.
x402 സ്ഥാപക രേഖകൾ സന്ദേശ ഫോർമാറ്റിനെക്കുറിച്ച് വിശദമായി വിവരിക്കുന്നുണ്ടെങ്കിലും, ഒരു ഇംപ്ലിമെന്റേഷൻ ആവശ്യമായ സുരക്ഷാ പരിശോധനകൾ നടപ്പിലാക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുന്ന ഒരു ടെസ്റ്റ് ഹാർനെസ് (test harness) നിർദ്ദേശിക്കുന്നതിൽ അവ പരാജയപ്പെടുന്നു. ഒരു നിഷ്പക്ഷ ടെസ്റ്റ് സ്യൂട്ട് ഇല്ലാതെ, സുപ്രധാനമായ സുരക്ഷാ മുൻകരുതലുകൾ ഒഴിവാക്കിക്കൊണ്ട് "ഞങ്ങൾ സ്പെസിഫിക്കേഷൻ പാലിക്കുന്നു" എന്ന് ഏതൊരു വെണ്ടർക്കും അവകാശപ്പെടാൻ കഴിയും.
എന്തുകൊണ്ട് ഒരു രസീത് മാത്രം പോരാ?
x402 ലോകത്തെ ഒരു പേയ്മെന്റ് രസീത് മൂന്ന് കാര്യങ്ങൾ അവകാശപ്പെടുന്നു:
- ആ പ്രവൃത്തി നടന്നു.
- ആ പ്രവൃത്തിക്ക് അനുമതി ലഭിച്ചിരുന്നു.
- സുരക്ഷാ പരിശോധനകൾ യഥാർത്ഥത്തിൽ നടന്നു.
ഡിജിറ്റൽ സിഗ്നേച്ചറുകൾക്ക് ആദ്യത്തെ അവകാശവാദം ഉറപ്പാക്കാൻ കഴിയും - ഒരാൾ ഒരു പ്രത്യേക റെക്കോർഡിൽ ഒപ്പുവെച്ചു എന്ന് അവ തെളിയിക്കുന്നു. എന്നാൽ രണ്ടാമത്തെയും മൂന്നാമത്തെയും അവകാശവാദങ്ങൾക്ക് അവയ്ക്ക് ഒന്നും ചെയ്യാൻ കഴിയില്ല. ഒരു അറ്റാക്കർക്ക് സാധുതയുള്ളതെന്ന് തോന്നിക്കുന്ന ഒരു രസീത് നിർമ്മിക്കാനോ, പഴയൊരു രസീത് വീണ്ടും ഉപയോഗിക്കാനോ (replay), അല്ലെങ്കിൽ അടിസ്ഥാനപരമായ അനുമതി ഒരിക്കലും നടന്നില്ലെന്ന് ഉറപ്പാക്കാൻ സന്ദേശങ്ങളുടെ സമയക്രമത്തിൽ മാറ്റം വരുത്താനോ കഴിയും. ഇത്തരം ആക്രമണങ്ങൾ എങ്ങനെ കണ്ടെത്തണമെന്നോ തടയണമെന്നോ നിലവിലെ മാനദണ്ഡം നിർദ്ദേശിക്കുന്നില്ല.
സാധാരണ പരിശോധനകളെ മറികടക്കുന്ന ഒരു വ്യക്തമായ ആക്രമണം
സമീപകാലത്തെ ShareLock പേപ്പർ (arXiv 2606.27027), ഒരു രസീതിലെ ഓരോ ഭാഗവും ഒറ്റപ്പെട്ടভাবে പരിശോധിക്കുന്ന ഒരു പാഴ്സറിന് (parser) കണ്ടെത്താൻ കഴിയാത്ത തരത്തിലുള്ള ആക്രമണങ്ങളെക്കുറിച്ച് വിവരിക്കുന്നു. പല ടൂൾ വിവരണങ്ങളിലായി ഒരു ശത്രുവിന് എങ്ങനെയാണ് ദോഷകരമായ നിർദ്ദേശങ്ങൾ ഉൾപ്പെടുത്താൻ കഴിയുന്നതെന്ന് രചയിതാക്കൾ കാണിച്ചുതരുന്നു. ഓരോ വിവരണവും എല്ലാ സിന്റാക്റ്റിക് (syntactic), സിഗ്നേച്ചർ പരിശോധനകളും പാസ് ചെയ്യുന്നുണ്ടെങ്കിലും, സിസ്റ്റം ഈ ഭാഗങ്ങൾ കൂട്ടിച്ചേർക്കുമ്പോൾ, പണമടയ്ക്കുന്നയാളുടെ സമ്മതമില്ലാതെ പേയ്മെന്റിന് അനുമതി നൽകുന്ന ഒരു രഹസ്യ കമാൻഡായി അത് മാറുന്നു.
x402 സ്പെസിഫിക്കേഷൻ ഓരോ ഘടകവും ശരിയായി പാഴ്സ് ചെയ്യണമെന്ന് മാത്രമേ ആവശ്യപ്പെടുന്നുള്ളൂ എന്നതിനാൽ, നിലവിലുള്ള വാലിഡേഷൻ നിയമങ്ങളെ മാത്രം ആശ്രയിക്കുന്ന ഏത് ഇംപ്ലിമെന്റേഷനും നേരെ ShareLock വിവരിക്കുന്ന ആക്രമണം വിജയിച്ചേക്കാം. പ്രശ്നം ക്രിപ്റ്റോഗ്രാഫിയിലെ പിഴവല്ല; മറിച്ച് ഘടകങ്ങൾ കൂട്ടിച്ചേർക്കുമ്പോഴും (composition) ആധികാരികത നിലനിൽക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുന്നതിലെ വിടവാണ്.
ആധികാരികത പരിശോധിക്കേണ്ടത് ആരാണ്?
ഒരു പ്രോട്ടോക്കോൾ രചയിതാവിന് പക്ഷപാതമില്ലാതെ സ്വന്തം ഡിസൈനിനെ റെഡ്-ടീം (red-team) ചെയ്യാൻ കഴിയില്ല, അതുപോലെ ഒരു വെണ്ടർക്ക് സ്വതന്ത്രമായ കാഴ്ചപ്പാടില്ലാതെ സ്വന്തം സുരക്ഷ സാക്ഷ്യപ്പെടുത്താനും കഴിയില്ല. അതിനാൽ വ്യവസായത്തിന് താഴെ പറയുന്ന ഗുണങ്ങളുള്ള ഒരു നിഷ്പക്ഷവും ശത്രുതാപരമായ (adversarial) പരിശോധനാ ചട്ടക്കൂട് ആവശ്യമാണ്:
- രസീതുകൾ, സിഗ്നേച്ചറുകൾ, സ്റ്റേറ്റ് ട്രാൻസിഷനുകൾ (state transitions) എന്നിവ കൈകാര്യം ചെയ്യുന്നതിൽ ഒരു ഇംപ്ലിമെന്റേഷനെതിരെ പൂർണ്ണമായ കൺഫോമൻസ് പരിശോധനകൾ നടത്തുക.
- ഘടകങ്ങൾ കൂട്ടിച്ചേർക്കുമ്പോഴും ആധികാരികത നിലനിൽക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ ShareLock കാണിച്ച മൾട്ടി-പാർട്ട് ഇൻജക്ഷൻ പോലുള്ള ഭീഷണി-മോഡൽled (threat-modelled) ആക്രമണ സാഹചര്യങ്ങൾ പരീക്ഷിക്കുക.
- ഒരു ഇംപ്ലിമെന്റേഷൻ റീപ്ലേ (replay), ഫോർജറി (forgery), ഡെസിൻക്രണൈസേഷൻ (desynchronisation) ആക്രമണങ്ങളെ പ്രതിരോധിക്കുന്നുണ്ടെന്ന് ഒരു സ്വതന്ത്ര ലാബ് തെളിയിച്ചതിന് ശേഷം മാത്രം സർട്ടിഫിക്കേഷനുകൾ നൽകുക.
x402 ലോഞ്ച് അതിന്റെ ആദ്യ ദിവസം മുതൽ ആ പാളി (layer) ശൂന്യമായി വിട്ടിരിക്കുകയാണ്. ഒരു തേർഡ് പാർട്ടി ടെസ്റ്റ് സ്യൂട്ട് ഇല്ലാതെ, "കമ്പ്ലയന്റ്" (compliant) എന്നതുകൊണ്ട് ഉദ്ദേശിക്കുന്നത് "സിന്റാക്സ് പരിശോധന പാസായി" എന്ന് മാത്രമായിരിക്കാം.
ചുരുക്കം
x402 പ്രോട്ടോക്കോളിന് ഇപ്പോൾ ഒരു ഇടമുണ്ട്, എന്നാൽ വെണ്ടർ-ന്യൂട്രൽ ആയ കൺഫോമൻസ്, സുരക്ഷാ പരിശോധനാ ചട്ടക്കൂട് ഇല്ലാതെ ഓരോ പേയ്മെന്റിന് പിന്നിലെയും ആധികാരികത പരിശോധിക്കപ്പെടാത്ത നിലയിൽ തുടരുന്നു. ഒരു രസീതിലെ "അനുമതി ലഭിച്ചു" (authorized) എന്ന അവകാശവാദം യഥാർത്ഥ ലോകത്തെ ആക്രമണങ്ങളെ അതിജീവിക്കുമെന്ന് ഒരു സ്വതന്ത്ര സമിതിക്ക് തെളിയിക്കാൻ കഴിയുന്നതുവരെ, സുരക്ഷിതമായ AI-ഏജന്റ് വാണിജ്യത്തിന്റെ വാഗ്ദാനം അകലെയായിരിക്കും.