When an AI agent claims it finished a task, skepticism is the only sane response. A log entry that reads “Task completed

ഒരു AI ഏജന്റ് ഒരു ജോലി പൂർത്തിയാക്കിയെന്ന് അവകാശപ്പെടുമ്പോൾ, സംശയം പ്രകടിപ്പിക്കുക എന്നത് മാത്രമാണ് യുക്തിസഹമായ പ്രതികരണം. “Task completed at 14:32” എന്ന് കാണിക്കുന്ന ഒരു ലോഗ് എൻട്രി വെറുമൊരു ടെക്സ്റ്റ് സ്ട്രിംഗ് മാത്രമാണ്. ഏജന്റ് നിശബ്ദമായി ക്രാഷ് ആയതാകാം, അല്ലെങ്കിൽ ഒരു ശൂന്യമായ ഫോം സമർപ്പിച്ചതാകാം, ശൂന്യമായ സെർച്ച് റിസൾട്ടുകൾക്കിടയിൽ ലൂപ്പിൽ കുടുങ്ങിയതാകാം, അല്ലെങ്കിൽ ഒരു വർക്ക്ഫ്ലോ മുഴുവനായി സങ്കൽപ്പിച്ചതാകാം (hallucinated). നിങ്ങളുടെ ആർക്കിടെക്ചറിൽ വ്യത്യസ്ത മെഷീനുകളിലോ, ക്ലൗഡ് റീജിയനുകളിലോ, അല്ലെങ്കിൽ ഐപി അഡ്രസുകളിലോ പ്രവർത്തിക്കുന്ന ഒന്നിലധികം ഏജന്റുകൾ ഉണ്ടെങ്കിൽ, പ്രശ്നം വേഗത്തിൽ സങ്കീർണ്ണമാകും. ഏജന്റ് A അതിന്റെ പ്രവൃത്തി തെളിയിക്കാൻ സാധിച്ചില്ലെങ്കിൽ, ഏജന്റ് B-ക്ക് ഏജന്റ് A-യുടെ റിപ്പോർട്ടിനെ വിശ്വസിക്കാൻ യാതൊരു കാരണവുമില്ല.

എല്ലാ വിശ്വസനീയമായ വെരിഫിക്കേഷൻ സിസ്റ്റങ്ങളും മൂന്ന് പാളികളിലായി നിർമ്മിക്കപ്പെട്ടവയാണ്. Evidence എന്നത് അതിന്റെ യഥാർത്ഥ രൂപമാണ്—സ്ക്രീൻഷോട്ട്, API റെസ്പോൺസ്, അല്ലെങ്കിൽ HTML ഡമ്പ് എന്നിവ ഇതിൽ ഉൾപ്പെടുന്നു. Attestation എന്നത് ആ തെളിവുകളെ ഒരു പ്രത്യേക ഏജന്റുമായും ഒരു പ്രത്യേക ടാസ്ക് ഐഡിയോടുമായി ബന്ധിപ്പിക്കുന്ന ഒരു സൈൻ ചെയ്തതോ ക്രിപ്റ്റോഗ്രാഫിക് ആയതോ ആയ അവകാശവാദമാണ്. Verification എന്നത് ആ തെളിവ് യഥാർത്ഥത്തിൽ ലക്ഷ്യം നിറവേറ്റുന്നുണ്ടോ എന്ന് സ്ഥിരീകരിക്കുന്ന പ്രക്രിയയാണ്, അല്ലാതെ ആ ഫയൽ അവിടെ ഉണ്ടെന്ന് മാത്രം ഉറപ്പാക്കലല്ല. അറ്റസ്റ്റേഷൻ ഇല്ലാത്ത തെളിവുകൾ ഒരു ജോലിയിൽ നിന്ന് മറ്റൊന്നിലേക്ക് വീണ്ടും ഉപയോഗിക്കാൻ (replay) സാധിച്ചേക്കാം. വെരിഫിക്കേഷൻ ഇല്ലാത്ത അറ്റസ്റ്റേഷൻ ഡാറ്റ യഥാർത്ഥമാണെന്ന് മാത്രമേ പറയു, എന്നാൽ നിങ്ങൾ ചോദിച്ച ചോദ്യത്തിന് അത് ഉത്തരം നൽകുന്നുണ്ടോ എന്ന് പറയില്ല.

വിഷ്വൽ പ്രൂഫ്: സ്ക്രീൻഷോട്ടുകളും OCR-ഉം

ഒരു ഏജന്റ് ഒരു ബ്രൗസർ നിയന്ത്രിക്കുകയോ അല്ലെങ്കിൽ ഒരു ഗ്രാഫിക്കൽ ഇന്റർഫേസുമായി ഇടപെടുമ്പോഴോ, ഏറ്റവും ലളിതമായ തെളിവ് ഒരു ചിത്രമാണ്. പ്രവർത്തനം പൂർത്തിയായ ശേഷം ഏജന്റ് ഒരു ഫുൾ-പേജ് സ്ക്രീൻഷോട്ട് എടുക്കുകയും, കാണുന്ന ടെക്സ്റ്റ് വേർതിരിച്ചെടുക്കാൻ OCR ഉപയോഗിക്കുകയും ചെയ്യുന്നു, തുടർന്ന് ചിത്രവും വേർതിരിച്ചെടുത്ത ടെക്സ്റ്റും തെളിവായി സമർപ്പിക്കുകയും ചെയ്യുന്നു.

സോഷ്യൽ മീഡിയ പോസ്റ്റുകൾ, ഫോം സമർപ്പിക്കലുകൾ, അല്ലെങ്കിൽ ചെക്ക്ഔട്ട് പ്രക്രിയകൾ എന്നിവയ്ക്ക് ഈ രീതി അനുയോജ്യമാണ്. ഒരു കമ്പനിയുടെ LinkedIn പേജിൽ ആഴ്ചതോറും അപ്‌ഡേറ്റുകൾ പ്രസിദ്ധീകരിക്കാൻ ഏജന്റിനെ ഏൽപ്പിച്ചതായി സങ്കൽപ്പിക്കുക. സ്ക്രീൻഷോട്ടിൽ സെർവർ റെൻഡർ ചെയ്ത ടൈംസ്റ്റാമ്പും URL-ൽ ഉൾപ്പെടുത്തിയ പോസ്റ്റ് ഐഡിയും ഉള്ള ലൈവ് പോസ്റ്റ് കാണാം. ആ പ്ലാറ്റ്‌ഫോമിന് മാത്രമുള്ള മാർക്കറുകൾക്കൊപ്പം കൃത്യമായ ഹെഡ്‌ലൈനും ബോഡി ടെക്സ്റ്റും പേജിൽ ഉണ്ടെന്ന് OCR വഴി സ്ഥിരീകരിക്കാൻ കഴിയും.

ഇതിലെ അപകടം വ്യക്തമാണ്: സ്ക്രീൻഷോട്ടുകൾ വ്യാജമായി നിർമ്മിക്കാൻ സാധിക്കും. ഹാക്ക് ചെയ്യപ്പെട്ട ഒരു ഏജന്റിന് ഒരു വ്യാജ വെബ് പേജ് ലോക്കലായി നിർമ്മിച്ച്, അതിന്റെ സ്ക്രീൻഷോട്ട് എടുത്ത് വിജയിച്ചതായി പ്രഖ്യാപിക്കാൻ കഴിയും. ഇതിന്റെ സുരക്ഷ വർദ്ധിപ്പിക്കാൻ, പ്രവചിക്കാൻ പ്രയാസമുള്ള ഡൈനാമിക് ടെക്സ്റ്റ് മാർക്കറുകൾ ആവശ്യപ്പെടുക. പ്ലാറ്റ്‌ഫോം നൽകുന്ന ഒരു കൺഫർമേഷൻ ഐഡി, സെർവറിൽ നിന്നുള്ള ടൈംസ്റ്റാമ്പ്, അല്ലെങ്കിൽ വെരിഫയർ ജോബ് ഇൻസ്ട്രക്ഷൻസുകളിൽ ചേർക്കുന്ന ഒരു യുണീക് നോൻസ് (nonce) എന്നിവ ഇതിനായി ഉപയോഗിക്കാം. OCR ഔട്ട്‌പുട്ടിൽ ആ പ്രത്യേക ടാസ്ക്കുമായി ബന്ധപ്പെട്ട കൺഫർമേഷൻ ഐഡി ഇല്ലെങ്കിൽ, ആ തെളിവ് പരാജയപ്പെട്ടതായി കണക്കാക്കും.

എങ്കിലും സ്ക്രീൻഷോട്ടുകൾക്ക് വലിയ വലിപ്പമുണ്ട്. അവ ബാൻഡ്‌വിഡ്ത്തും സ്റ്റോറേജും ഉപയോഗിക്കുന്നു, കൂടാതെ പ്ലാറ്റ്‌ഫോമുകൾ അവയുടെ ലേഔട്ട് മാറ്റുമ്പോൾ അവ ഉപയോഗശൂന്യമാവുകയും ചെയ്യുന്നു. UI മാത്രമാണ് ലഭ്യമായ മാർഗ്ഗമെങ്കിൽ അവ ഉപയോഗിക്കുക, എന്നാൽ അവയെ ഒരു അടിസ്ഥാനമായി മാത്രം കാണുക, അല്ലാതെ പൂർണ്ണമായ സുരക്ഷാ കവചമായി കരുതരുത്.

സൈൻ ചെയ്ത API രസീതുകൾ

ഏജന്റ് ഒരു ബാക്കെൻഡ് API വഴിയാണ് പ്രവർത്തിക്കുന്നതെങ്കിൽ, ചിത്രം ഒഴിവാക്കുക. പകരം ഒരു സൈൻ ചെയ്ത രസീത് ആവശ്യപ്പെടുക.

ഒരു ഓട്ടോമേറ്റഡ് പോസ്റ്റിന് ശേഷമോ ഡാറ്റ സ്ക്രാപ്പ് ചെയ്ത ശേഷമോ, പ്ലാറ്റ്‌ഫോം സാധാരണയായി ഒരു സ്ട്രക്ചേർഡ് പേലോഡ് (payload) തിരികെ നൽകുന്നു. ആ JSON-ൽ ഒരു ഐഡി, ടൈംസ്റ്റാമ്പ്, സ്റ്റാറ്റസ് ഫീൽഡുകൾ, ചിലപ്പോൾ റേറ്റ്-ലിമിറ്റ് ഹെഡറുകൾ എന്നിവ ഉണ്ടാകും. ഏജന്റ് ഈ പേലോഡ് മുഴുവൻ ഒരു പ്രൈവറ്റ് കീ ഉപയോഗിച്ച് സൈൻ ചെയ്യുകയും, ടാസ്ക് ഐഡി ആ സൈൻ ചെയ്ത ബ്ലോബിനുള്ളിൽ ഉൾപ്പെടുത്തുകയും, തുടർന്ന് ആ ബണ്ടിൽ സമർപ്പിക്കുകയും ചെയ്യുന്നു. വെരിഫയർ ഏജന്റിന്റെ പബ്ലിക് കീ ഉപയോഗിച്ച് സിഗ്നേച്ചർ പരിശോധിക്കുകയും പ്രവർത്തനം വിജയിച്ചുവെന്ന് ഉറപ്പാക്കാൻ രസീത് പരിശോധിക്കുകയും ചെയ്യുന്നു.

ഇതിലെ ബലഹീനത കീ കസ്റ്റഡി (key custody) ആണ്. ഏജന്റ് പ്രവർത്തിക്കുന്ന മെഷീനിൽ തന്നെ അതിന്റെ പ്രൈവറ്റ് കീ സൂക്ഷിക്കുകയാണെങ്കിൽ, ഒരു പ്രോംപ്റ്റ് ഇൻജക്ഷൻ (prompt injection), മാൽവെയർ ആക്രമണം, അല്ലെങ്കിൽ കണ്ടെയ്നർ എസ്കേപ്പ് എന്നിവയിലൂടെ അത് ചോർത്താനും നടക്കാത്ത ജോലികൾക്കായി വ്യാജ രസീതുകൾ നിർമ്മിക്കാനും സാധിക്കും. ദീർഘകാലം നിലനിൽക്കുന്ന കീകൾ ഏജന്റിന്റെ എൻവയോൺമെന്റിൽ ഉൾപ്പെടുത്തരുത്. പകരം, കുറഞ്ഞ സമയത്തേക്ക് മാത്രം ഉപയോഗിക്കാവുന്ന, ടാസ്ക് അടിസ്ഥാനത്തിലുള്ള ക്രെഡൻഷ്യലുകൾ നൽകുന്ന ഒരു കീ മാനേജ്‌മെന്റ് സിസ്റ്റം ഉപയോഗിക്കുക. ഓരോ ടാസ്കിനും കീകൾ മാറ്റിക്കൊണ്ടിരിക്കുക (Rotate). ഏജന്റിന് ഒരു അഞ്ച് മിനിറ്റ് സമയത്തേക്ക് മാത്രം ഒരു സെക്യൂർ എൻക്ലേവിൽ നിന്നോ KMS-ൽ നിന്നോ സൈനിംഗ് കീ ആവശ്യപ്പെടേണ്ടി വരുന്ന രീതിയാണെങ്കിൽ, ഒരു സുരക്ഷാ വീഴ്ച ഉണ്ടായാലും അതിന്റെ ആഘാതം പരിമിതമായിരിക്കും.

ഉയർന്ന അളവിലുള്ള ഹെഡ്‌ലെസ്സ് ഓട്ടോമേഷനുകൾക്ക് (headless automation) ഈ രീതി ഏറ്റവും അനുയോജ്യമാണ്: പരസ്യ ചെലവ് റിപ്പോർട്ടുകൾ സിങ്ക് ചെയ്യുക, സോഷ്യൽ മീഡിയ API വഴി പ്രസിദ്ധീകരിക്കുക, അല്ലെങ്കിൽ സ്ട്രക്ചേർഡ് JSON നൽകുന്ന എൻഡ്‌പോയിന്റുകൾ സ്ക്രാപ്പ് ചെയ്യുക എന്നിവ ഇതിൽ ഉൾപ്പെടുന്നു. ഇത് സ്ക്രീൻഷോട്ടുകളെക്കാൾ ഭാരം കുറഞ്ഞതും പ്രോഗ്രാമാറ്റിക് ആയി പരിശോധിക്കാൻ എളുപ്പവുമാണ്.

തുടർച്ചയായ ജോലികൾക്കായുള്ള പ്രൂഫ് ചെയിനുകൾ

ചില ജോലികൾ ഒരു ഒറ്റ...