Chrome, WebMCP-ന് വേണ്ടി സുരക്ഷാ മാർഗ്ഗനിർദ്ദേശങ്ങൾ ചേർത്തിട്ടുണ്ട്. സൈറ്റുകൾ AI ഏജന്റുകൾക്കായി ടൂളുകൾ തുറന്നുകാട്ടുന്ന പുതിയ രീതിയാണിത്. ആ ടൂളുകൾ സുരക്ഷിതമായി സൂക്ഷിക്കേണ്ട ഉത്തരവാദിത്തം വെബ്‌സൈറ്റ് ഉടമകളിൽ തന്നെ നിക്ഷിപ്തമാക്കുന്നു. തങ്ങൾ “agent-ready” ആണെന്ന് പ്രഖ്യാപിക്കുന്ന ഏതൊരു സൈറ്റും, കൃത്രിമമായി നിർമ്മിച്ച manifest-കളിലൂടെയോ അല്ലെങ്കിൽ മലിനമായ ഔട്ട്‌പുട്ടിലൂടെയോ (tainted output) ഏജന്റുകളെ ഹൈജാക്ക് ചെയ്യാൻ ദുരുദ്ദേശ്യലക്ഷ്യമുള്ളവർക്ക് വഴിതുറക്കുന്നുവെന്ന് ഈ മാർഗ്ഗനിർദ്ദേശം മുന്നറിയിപ്പ് നൽകുന്നു.

എന്തുകൊണ്ടാണ് ഇപ്പോൾ WebMCP പ്രധാനമാകുന്നത്

ഡെവലപ്പർമാർ കാലങ്ങളായി ചോദിച്ചുകൊണ്ടിരിക്കുന്ന ഒരു ചോദ്യമുണ്ട്: ഒരു AI ഏജന്റിന് എന്റെ പേജ് വായിക്കാനും ഒരു ഇടപാട് (transaction) പൂർത്തിയാക്കാനും കഴിയുമോ? WebMCP ഈ രീതിയെ മാറ്റുന്നു. ഒരു ചെക്ക്ഔട്ട് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് ഏജന്റ് ഊഹിക്കുന്നതിന് പകരം, ഏത് പ്രവർത്തനങ്ങളാണ് ചെയ്യാൻ കഴിയുക (വില പരിശോധിക്കുക, കാർട്ട് അപ്‌ഡേറ്റ് ചെയ്യുക, റിവ്യൂകൾ എടുക്കുക തുടങ്ങിയവ) എന്ന് കൃത്യമായി പറയുന്ന ഒരു manifest സൈറ്റ് പ്രസിദ്ധീകരിക്കുന്നു. ഇതിന്റെ ഫലമായി കൂടുതൽ കഴിവുള്ള ഒരു അസിസ്റ്റന്റിനെ ലഭിക്കുന്നുണ്ടെങ്കിലും, ഇത് പുതിയൊരു ആക്രമണ സാധ്യതയും (attack surface) സൃഷ്ടിക്കുന്നു: ഒരു സൈറ്റ് ഒരു ഏജന്റിന് ഒരു ടൂൾ കൈമാറുന്ന നിമിഷം, ദുരുപയോഗം ചെയ്യാൻ കഴിയുന്ന നിർദ്ദേശങ്ങളുടെ ഒരു കൂട്ടം കൂടിയാണ് ഏജന്റിന് നൽകുന്നത്.

ഡെവലപ്പർമാർ ഭയപ്പെടേണ്ട രണ്ട് ഹൈജാക്ക് രീതികൾ

Malicious manifests – ഒരു അറ്റാക്കർ ടൂൾ പേരുകളിലോ വിവരണങ്ങളിലോ ഒളിഞ്ഞിരിക്കുന്ന കമാൻഡുകൾ ഉൾപ്പെടുത്തുന്നു. ഏജന്റുകൾ എല്ലാ ടെക്സ്റ്റ് സ്ട്രിംഗുകളെയും നിർദ്ദേശങ്ങളായി കണക്കാക്കുന്നതിനാൽ, ബുദ്ധിപരമായി നിർമ്മിച്ച ഒരു പേര് ഏജന്റിന്റെ യഥാർത്ഥ ദൗത്യത്തെ മറികടക്കാനും ഉദ്ദേശിക്കാത്ത കാര്യങ്ങൾ ചെയ്യിപ്പിക്കാനും കാരണമായേക്കാം.

Contaminated output – ഇതാണ് കൂടുതൽ സാധാരണമായ രീതി. ഒരു നിയമപരമായ ടൂൾ ഉപയോക്താക്കൾ നൽകുന്ന ഡാറ്റ (ഉൽപ്പന്ന റിവ്യൂകൾ, ഫോറം പോസ്റ്റുകൾ, കമന്റുകൾ) നൽകുന്നു. ഒരു ദുരുദ്ദേശ്യലക്ഷ്യമുള്ള ഉപയോക്താവ് ആ ഉള്ളടക്കത്തിൽ ഒരു കമാൻഡ് ഉൾപ്പെടുത്തിയാൽ, ആ ടൂൾ ആ കമാൻഡ് നേരിട്ട് ഏജന്റിന് എത്തിക്കുന്നു. Large language models (LLMs)-ന് ഡാറ്റയെയും നിർദ്ദേശങ്ങളെയും കൃത്യമായി വേർതിരിക്കാൻ കഴിയില്ല; അവ ഈ മുഴുവൻ സ്ട്രീമിനെയും ഒരു സിംഗിൾ പ്രോംപ്റ്റ് ആയിട്ടാണ് കാണുന്നത്.

നിങ്ങളുടെ manifest സുരക്ഷിതമാക്കാൻ പ്രായോഗികമായ നടപടികൾ

ഡെവലപ്പർമാർക്ക് അവരുടെ WebMCP manifest ഫയലുകളിൽ ചേർക്കാവുന്ന മൂന്ന് കോൺഫിഗറേഷൻ നിയമങ്ങളാണ് Chrome-ന്റെ മാർഗ്ഗനിർദ്ദേശത്തിൽ പറയുന്നത്.

  • നിങ്ങളുടെ ടൂളുകൾ ആർക്കൊക്കെ ഉപയോഗിക്കാം എന്ന് പരിമിതപ്പെടുത്തുക – വിശ്വസനീയമായ ഏജന്റ് പ്ലാറ്റ്‌ഫോമുകളെ whitelist ചെയ്യാൻ exposedTo റൂൾ ഉപയോഗിക്കുക. ഉദാഹരണത്തിന്, ഒരു പേയ്‌മെന്റ് പ്രോസസ്സിംഗ് ടൂൾ വെബിലെ എല്ലാ AI ഏജന്റുകൾക്കും ലഭ്യമാകാൻ പാടില്ല. ടൂൾ ഉപയോഗിക്കാൻ കഴിയുന്ന കൃത്യമായ origins നിർവചിക്കുകയും മറ്റുള്ളവ നിരസിക്കുകയും ചെയ്യുക.

  • വിശ്വസിക്കാൻ കഴിയാത്ത ഉള്ളടക്കം അടയാളപ്പെടുത്തുക – റിവ്യൂകൾ അല്ലെങ്കിൽ കമന്റുകൾ പോലുള്ള ഉപയോക്താക്കൾ നൽകുന്ന ഡാറ്റ നൽകുന്ന ഏതൊരു ടൂളിലും untrustedContentHint ഫ്ലാഗ് ചേർക്കുക. പേലോഡിൽ (payload) ദുരുദ്ദേശ്യപരമായ നിർദ്ദേശങ്ങൾ ഉണ്ടാകാൻ സാധ്യതയുണ്ടെന്ന് ഇത് ഏജന്റിനെ അറിയിക്കുന്നു, അങ്ങനെ ആ ടെക്സ്റ്റ് ഉപയോഗിക്കുന്നതിന് മുമ്പ് കർശനമായ സുരക്ഷാ ഫിൽട്ടറുകൾ പ്രയോഗിക്കാൻ ഇത് ഏജന്റിനെ പ്രേരിപ്പിക്കുന്നു.

  • read-only സ്വഭാവം പ്രഖ്യാപിക്കുക – ഒരു ടൂൾ ഡാറ്റ വായിക്കുക മാത്രമാണോ ചെയ്യുന്നത് അതോ ഡാറ്റ എഴുതാനോ മാറ്റം വരുത്താനോ കഴിയുമോ എന്ന് സൂചിപ്പിക്കാൻ readOnlyHint ഫ്ലാഗ് ഉപയോഗിക്കാം. ഒരു ടൂൾ read-only ആണെങ്കിൽ, ഉപയോക്താവിന്റെ അധിക അനുമതിയില്ലാതെ തന്നെ ഏജന്റിന് മുന്നോട്ട് പോകാം; എന്നാൽ എന്തെങ്കിലും മാറ്റം വരുത്താൻ കഴിയുന്നതാണെങ്കിൽ, ഏജന്റ് മുന്നോട്ട് പോകുന്നതിന് മുമ്പ് ഉപയോക്താവിനോട് ചോദിക്കണം.

ഡെവലപ്പർമാർ എതിർക്കാൻ സാധ്യതയുള്ള കാര്യങ്ങൾ

വിപുലമായ പ്രത്യാഘാതങ്ങൾ

ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

ചുരുക്കത്തിൽ

ഒരു സൈറ്റിനെ “agent-ready” ആക്കുന്നത് വെറുമൊരു വിസിബിലിറ്റി ലക്ഷ്യമായി കാണേണ്ട ഒന്നല്ല; അത് സുരക്ഷയുമായി ബന്ധപ്പെട്ട ഒരു ഉത്തരവാദിത്തമാണ്. ആക്‌സസ് പരിമിതപ്പെടുത്തുന്നതിലൂടെയും, വിശ്വസിക്കാൻ കഴിയാത്ത ഔട്ട്‌പുട്ടുകൾ അടയാളപ്പെടുത്തുന്നതിലൂടെയും, read-only ടൂളുകൾ വ്യക്തമായി സൂചിപ്പിക്കുന്നതിലൂടെയും, ഒരു സഹായകരമായ AI അസിസ്റ്റന്റിനെ ദുരുപയോഗത്തിനുള്ള ഒരു മാർഗമാക്കി മാറ്റുന്നതിൽ നിന്ന് അറ്റാക്കർമാരെ തടയാൻ ഡെവലപ്പർമാർക്ക് കഴിയും. manifest-നെ മറ്റേതൊരു പബ്ലിക് API പോലെയും കാണുക: ലോകത്തിന് മുന്നിൽ തുറന്നുകാട്ടുന്നതിന് മുമ്പ് അത് ഓഡിറ്റ് ചെയ്യുക, വേർഷൻ ചെയ്യുക, സുരക്ഷിതമാക്കുക.