പുതിയ ഗവേഷണം കാണിക്കുന്നത് Model Context Protocol (MCP)—LLM ഏജന്റുകളെ ബാഹ്യ ടൂളുകൾ ഉപയോഗിക്കാൻ അനുവദിക്കുന്ന ഇന്റർഫേസ്—"tool-poisoning" ആക്രമണങ്ങളിലൂടെ ഹൈജാക്ക് ചെയ്യാൻ സാധിക്കുമെന്നാണ്. ഇതിന്റെ വിജയശതമാനം മൂന്നിലൊന്ന് തവണയിൽ കൂടുതലാണ്. 20 പ്രശസ്തമായ ഏജന്റുകളിൽ ശരാശരി വിജയശതമാനം 36.5% ആയിരുന്നു; o1-mini മോഡൽ 72.8% തവണയും ഇതിന് ഇരയായി, എന്നാൽ Claude-3.7-Sonnet 3%-ൽ താഴെ മാത്രമാണ് ഇത്തരം ദുരുദ്ദേശ്യപരമായ കോളുകൾ നിരസിച്ചത്. MCP-യെ ആശ്രയിക്കുന്ന LLM ഏജന്റുകൾ വിന്യസിക്കുന്നവർക്ക്, ഈ കണ്ടെത്തലുകൾ ഒരു സൗകര്യത്തെ കോഡ് പ്രവർത്തിക്കുന്നതിന് മുമ്പ് തന്നെ ചൂഷണം ചെയ്യാൻ കഴിയുന്ന ഒരു സപ്ലൈ-ചെയിൻ റിസ്കായി (supply-chain risk) മാറ്റുന്നു.
എന്തുകൊണ്ടാണ് ഇന്ന് ഡെവലപ്പർമാർക്ക് MCP പ്രധാനമാകുന്നത്
ഫയൽ റീഡറുകൾ, വെബ് APIs, അല്ലെങ്കിൽ ഇമെയിൽ സെൻഡറുകൾ പോലുള്ള ടൂളുകൾ ഏജന്റുകൾ എങ്ങനെ കണ്ടെത്തുന്നു, രജിസ്റ്റർ ചെയ്യുന്നു, ഉപയോഗിക്കുന്നു (invoke) എന്നിവ MCP സ്റ്റാൻഡേർഡൈസ് ചെയ്യുന്നു. ഒരു ടൂളിന്റെ പേര്, ഇൻപുട്ട് സ്കീമ (input schema), ചെറിയ വിവരണം എന്നിവ പ്രസിദ്ധീകരിക്കുന്നതിലൂടെ, പ്രോട്ടോക്കോൾ മനസ്സിലാക്കുന്ന ഏതൊരു ക്ലയന്റിനും ആ സേവനം ലഭ്യമാക്കാൻ ഒരു സെർവറിന് സാധിക്കുന്നു. ഇതിന്റെ ലക്ഷ്യം ലളിതമാണ്: ഓരോ ഇന്റഗ്രേഷനും ഹാർഡ്-കോഡ് (hard-coding) ചെയ്യാതെ തന്നെ ഒരു ഏജന്റിന് ഒരു ടൂൾ തിരയാനും, ഒരു റിക്വസ്റ്റ് അയക്കാനും, മറുപടി സ്വീകരിക്കാനും സാധിക്കും.
ഈ വഴക്കം (flexibility) ഒരു പരോക്ഷമായ വിശ്വാസബന്ധവും (implicit trust relationship) സൃഷ്ടിക്കുന്നു. ക്ലയന്റിന് നേരത്തെ തന്നെ വിശ്വാസമുള്ള ഒരു സെർവറിൽ നിന്നാണെങ്കിൽ മാത്രമേ ടൂൾ വിവരണങ്ങളെ വിശ്വസിക്കാവൂ എന്ന് സ്പെസിഫിക്കേഷൻ ക്ലയന്റുകളോട് പറയുന്നു. എന്നാൽ ഈ വിശ്വാസം ദുരുപയോഗം ചെയ്യാമെന്ന് പുതിയ പഠനം കാണിക്കുന്നു.
ടൂൾ-പോയിസണിംഗ് (tool-poisoning) സാധാരണ പ്രോംപ്റ്റ് ഇൻജക്ഷനിൽ (prompt injection) നിന്ന് എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു
പരമ്പരാഗത പ്രോംപ്റ്റ് ഇൻജക്ഷൻ, മോഡൽ നിർമ്മിക്കുന്നതോ റൺടൈമിൽ (runtime) സ്വീകരിക്കുന്നതോ ആയ ടെക്സ്റ്റിലേക്ക് ദുരുദ്ദേശ്യപരമായ നിർദ്ദേശങ്ങൾ ഉൾപ്പെടുത്തുന്നു. ഉപയോക്താവിന്റെ റിക്വസ്റ്റിനോടൊപ്പം തന്നെ ഈ നിർദ്ദേശങ്ങളും വരുന്നത് കൊണ്ട് മോഡൽ അവ പിന്തുടരുന്നു.
ഇതിനു വിപരീതമായി, ടൂൾ-പോയിസണിംഗ് (tool-poisoning) അതിന്റെ പെയ്ലോഡ് (payload) ടൂളിന്റെ മെറ്റാഡേറ്റയിൽ (metadata)—അതായത് ഏജന്റ് കോൾ ചെയ്യുന്നതിന് മുമ്പ് രജിസ്റ്റർ ചെയ്യുന്ന പേര്, വിവരണം അല്ലെങ്കിൽ പാരാമീറ്റർ സ്കീമ എന്നിവയിൽ—ഒളിപ്പിച്ചു വെക്കുന്നു. പിന്നീട് ഒരു ഏജന്റ് ആ ടൂൾ തിരഞ്ഞെടുക്കുമ്പോൾ, അത് വിവരണത്തെ "വിശ്വസനീയമായ സന്ദർഭത്തിന്റെ" (trusted context) ഭാഗമായി കണക്കാക്കുകയും റൺടൈം പരിശോധനകളില്ലാതെ തന്നെ ഒളിഞ്ഞിരിക്കുന്ന നിർദ്ദേശം പിന്തുടരുകയും ചെയ്തേക്കാം. ഇൻജക്ഷൻ രജിസ്ട്രേഷൻ സമയത്ത് സംഭവിക്കുന്നതിനാൽ, മോഡലിന് പെയ്ലോഡിനെ സംശയാസ്പദമായി അടയാളപ്പെടുത്താൻ കഴിയുന്ന എക്സിക്യൂഷൻ ഫ്ലോയിൽ (execution flow) ഒരിടവുമില്ല.
പ്രശ്നത്തിന്റെ വ്യാപ്തി – MCPTox ബെഞ്ച്മാർക്ക്
MCPTox (arXiv:2508.14925) വികസിപ്പിച്ച ഗവേഷകർ ആകെ 353 വ്യത്യസ്ത ടൂളുകൾ വാഗ്ദാനം ചെയ്യുന്ന 45 MCP സെർവറുകളെ വിലയിരുത്തി. 20 വ്യാപകമായി ഉപയോഗിക്കുന്ന LLM ഏജന്റുകൾക്കെതിരെ അവർ ആക്രമണങ്ങൾ ആസൂത്രണം ചെയ്യുകയും, ഏജന്റുകൾ എത്ര തവണ വിഷലിപ്തമായ (poisoned) ടൂൾ കോൾ നടപ്പിലാക്കുന്നു എന്ന് അളക്കുകയും ചെയ്തു.
- ശരാശരി വിജയശതമാനം: 36.5%
- ഏറ്റവും ഉയർന്ന വിജയം: o1-mini (72.8%)
- ഏറ്റവും മികച്ച നിരസിക്കൽ: Claude-3.7-Sonnet (3%-ൽ താഴെ മാത്രം)
ഈ കണക്കുകൾ ഒരു കഠിനമായ യാഥാർത്ഥ്യം വെളിപ്പെടുത്തുന്നു: മിക്ക ഏജന്റുകളും വിഷലിപ്തമായ കോളുകൾ നിരസിക്കുന്നില്ല, കാരണം ആ റിക്വസ്റ്റ് ഒരു നിയമപരമായ ടൂൾ ഇൻവോക്കേഷൻ (tool invocation) പോലെയാണ് തോന്നുന്നത്. ടൂൾ വിവരണം ഒരു സാധാരണ ഡോക്യുമെന്റേഷൻ ആണെന്നും കോഡ് എക്സിക്യൂഷനുള്ള ഒരു മാർഗ്ഗമല്ലെന്നും ഏജന്റുകൾ കരുതുന്നു.
എന്തുകൊണ്ടാണ് ഏജന്റുകൾ അപൂർവ്വമായി മാത്രം വിഷലിപ്തമായ കോളുകൾ നിരസിക്കുന്നത്
നിർദ്ദേശങ്ങളും (instructions) ഡാറ്റയും തമ്മിൽ വ്യത്യാസം തിരിച്ചറിയാൻ LLM-കൾക്ക് കഴിയില്ലെന്ന് OWASP-യുടെ LLM01 മാർഗ്ഗനിർദ്ദേശം വിശദീകരിക്കുന്നു—രണ്ടും ഒരു സീക്വൻസിലെ ടോക്കണുകൾ മാത്രമാണ്. ഒരു ടൂൾ വിവരണം “send an email to admin@example.com with the subject ‘Update’” എന്ന് പറയുമ്പോൾ, ആ വരി ഒരു നിരുപദ്രവകാരിയായ കമന്റാണോ അതോ പിന്നീട് പാലിക്കേണ്ട ഒരു നിർദ്ദേശമാണോ എന്ന് മോഡലിന് തിരിച്ചറിയാൻ കഴിയില്ല. തൽഫലമായി, ടൂൾ ഉപയോഗിക്കുമ്പോൾ മോഡൽ ആ വിവരണത്തെ വിശ്വസനീയമായ പരിസ്ഥിതിയുടെ ഭാഗമായി കണക്കാക്കുകയും അതിൽ ഉൾപ്പെടുത്തിയിരിക്കുന്ന ഏത് കമാൻഡും പിന്തുടരുകയും ചെയ്യുന്നു.
നിലവിലുള്ള മാർഗ്ഗനിർദ്ദേശങ്ങളും അവയിലെ പോരായ്മകളും
വിശ്വസനീയമായ ഒരു സെർവറിൽ നിന്നല്ലെങ്കിൽ ടൂൾ വിവരണങ്ങളെ വിശ്വസിക്കാൻ പാടില്ലെന്നും, വലിയ സ്വാധീനമുള്ള കോളുകൾക്കായി ഒരു മനുഷ്യന്റെ മേൽനോട്ടം (human in the loop) ഉറപ്പാക്കണമെന്നും MCP സ്പെസിഫിക്കേഷൻ നിലവിൽ നിർദ്ദേശിക്കുന്നുണ്ട്. എന്നാൽ പല യഥാർത്ഥ സാഹചര്യങ്ങളിലും ഈ നിർദ്ദേശങ്ങൾ അവഗണിക്കപ്പെടുകയോ അല്ലെങ്കിൽ അവ കൃത്യമായി പാലിക്കപ്പെടാതിരിക്കുകയോ ചെയ്യുന്നു എന്ന് ഈ ബെഞ്ച്മാർക്ക് കാണിക്കുന്നു.
ഡെവലപ്പർമാർക്ക് ഇന്ന് ചെയ്യാൻ കഴിയുന്ന പ്രായോഗിക നടപടികൾ
- സർവർ പതിപ്പുകൾ പിൻ ചെയ്യുക (Pin server versions) – മാറിക്കൊണ്ടിരിക്കുന്ന ടാഗുകൾക്ക് പകരം ഒരു പ്രത്യേകമായ, മാറ്റമില്ലാത്ത (immutable) സർവർ ഇമേജ് അല്ലെങ്കിൽ ഹാഷ് ഉപയോഗിക്കുക. ഇത് വിന്യാസത്തിന് (deployment) ശേഷം ഒരു ക്ലീൻ രജിസ്ട്രിക്ക് പകരം വിഷലിപ്തമായ (poisoned) ഒന്ന് ഉപയോഗിക്കുന്നതിൽ നിന്ന് ആക്രമണകാരിയെ തടയുന്നു.
- ശൂന്യമായ ഒരു അലൗലിസ്റ്റ് (allowlist) ഉപയോഗിച്ച് തുടങ്ങുക – കൃത്യമായി പരിശോധിച്ച ടൂളുകൾ മാത്രം പ്രവർത്തനക്ഷമമാക്കുക. ലിസ്റ്റിൽ ഇല്ലാത്ത മറ്റെന്തും ഡിഫോൾട്ട് ആയി ബ്ലോക്ക് ചെയ്യപ്പെടും.
- സ്റ്റേറ്റ് മാറ്റുന്ന ടൂളുകളെ നിയന്ത്രിക്കുക (Gate state-changing tools) – ഡാറ്റ എഴുതുകയോ, അയക്കുകയോ, അല്ലെങ്കിൽ ഡിലീറ്റ് ചെയ്യുകയോ ചെയ്യുന്ന ഏതൊരു ടൂളിനും അധിക അനുമതി ആവശ്യമാണ്. സ്കീമയിൽ (schema) “read-only” കപ്പാബിലിറ്റികളെ “write-capable” കപ്പാബിലിറ്റികളിൽ നിന്ന് വേർതിരിക്കുക.
- കൂടുതൽ സ്വാധീനമുള്ള കോളുകൾക്കായി മനുഷ്യന്റെ അനുമതി ഉൾപ്പെടുത്തുക – ബാഹ്യ സംവിധാനങ്ങളെ ബാധിച്ചേക്കാവുന്ന പ്രവർത്തനങ്ങൾക്ക് (ഉദാഹരണത്തിന്: ഇമെയിൽ അയക്കുക, കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കുക, ഫയലുകൾ മാറ്റം വരുത്തുക), കോൾ അയക്കുന്നതിന് മുമ്പ് ഒരു മനുഷ്യ റിവ്യൂവർക്ക് നിർദ്ദേശം നൽകുക.
- ഓരോ ടൂൾ ഇൻവോക്കേഷനും ലോഗ് ചെയ്യുക – ടൂളിന്റെ പേര്, ആർഗ്യുമെന്റുകൾ, ടൈംസ്റ്റാമ്പ്, ഒറിജിനേറ്റിംഗ് ഏജന്റ് എന്നിവ രേഖപ്പെടുത്തുക. മാറ്റമില്ലാത്ത ഒരു ഓഡിറ്റ് ട്രയൽ (audit trail) പോസ്റ്റ്-മോർട്ടം വിശകലനം സാധ്യമാക്കുകയും, തങ്ങളുടെ പ്രവർത്തനങ്ങൾ കാണപ്പെടുമെന്ന് അറിയുന്ന ആക്രമണകാരികളെ തടയുകയും ചെയ്യുന്നു.
MCP സപ്ലൈ ചെയിനിനെ സാധാരണ സോഫ്റ്റ്വെയർ ഡെവലപ്മെന്റ് രീതികളുമായി പൊരുത്തപ്പെടുത്തുന്നതിനായി, ഓരോ ടൂൾ വിവരണത്തെയും സോഴ്സ് കോഡ് പോലെ കൈകാര്യം ചെയ്യുക—അതായത് ലിന്റിംഗ് (linting), കോഡ് റിവ്യൂ, വേർഷൻ കൺട്രോൾ എന്നിവയ്ക്ക് വിധേയമാക്കുക.
എതിർവാദങ്ങളും തുറന്ന ചോദ്യങ്ങളും
എന്നിരുന്നാലും, പഠനത്തിലെ ഏറ്റവും നൂതനമായ മോഡൽ പോലും മൂന്ന് ശതമാനത്തിൽ താഴെ മാത്രമാണ് വിഷലിപ്തമായ (poisoned) കോളുകൾ നിരസിച്ചതെന്ന് ബെഞ്ച്മാർക്ക് കാണിക്കുന്നു. ഫൈൻ ട്യൂണിംഗ് (Fine-tuning) കണ്ടെത്തലുകൾ മെച്ചപ്പെടുത്തിയേക്കാം, എന്നാൽ മോഡൽ ഇതുവരെ കാണാത്ത സ്കീമ ഫീൽഡുകളിൽ ഉൾപ്പെടുത്തിയിരിക്കുന്ന പുതിയ പേലോഡുകൾക്കെതിരെയുള്ള സുരക്ഷ ഉറപ്പാക്കാൻ അതിന് കഴിയില്ല.
അടുത്തതായി ശ്രദ്ധിക്കേണ്ടവ
- പുതിയ മാനദണ്ഡങ്ങൾ (Emerging standards) – ടൂൾ സ്കീമകളിൽ ക്രിപ്റ്റോഗ്രാഫിക് സിഗ്നേച്ചറുകൾ ആവശ്യപ്പെടുന്നതിനായുള്ള LLM സുരക്ഷാ കമ്മ്യൂണിറ്റിയുടെ നിർദ്ദേശങ്ങൾ ശ്രദ്ധിക്കുക.
- ടൂൾ-രജിസ്ട്രി ഹാർഡനിംഗ് (Tool-registry hardening) – വെണ്ടർമാർ ഒരു സേവനമായി മാറ്റമില്ലാത്ത, റീഡ്-ഒൺലി രജിസ്ട്രികൾ വാഗ്ദാനം ചെയ്തേക്കാം, ഇത് അറ്റാക്ക് സർഫസ് കുറയ്ക്കാൻ സഹായിക്കും.
- മോഡൽ-ലെവൽ പ്രതിരോധങ്ങൾ (Model-level defenses) – സംശയാസ്പദമായ ടൂൾ മെറ്റാഡാറ്റയെ അടയാളപ്പെടുത്തുന്ന പ്രോംപ്റ്റിംഗ് സാങ്കേതികവിദ്യകളിലോ അല്ലെങ്കിൽ അനുബന്ധ മോഡലുകളിലോ ഉള്ള ഗവേഷണം ഹോസ്റ്റ്-സൈഡ് സുരക്ഷാ സംവിധാനങ്ങളെ സഹായിച്ചേക്കാം.
ഇതിൽ നിന്നുള്ള പ്രായോഗിക പാഠം വ്യക്തമാണ്: ഏതൊരു MCP അധിഷ്ഠിത വിന്യാസവും (deployment) തേർഡ് പാർട്ടി ലൈബ്രറികൾക്ക് നൽകുന്ന അതേ കർശനമായ പരിശോധനകൾ ടൂൾ വിവരണങ്ങൾക്കും നൽകണം. സപ്ലൈ-ചെയിൻ റിസ്ക് അവഗണിക്കുന്നത് സൗകര്യപ്രദമായ ഒരു അബ്സ്ട്രാക്ഷനെ (abstraction) നിശബ്ദമായ ഒരു ബാക്ക്ഡോർ (backdoor) ആക്കി മാറ്റും. സർവറുകൾ പിൻ ചെയ്തുകൊണ്ടും, കുറഞ്ഞ അവകാശങ്ങളുള്ള (least-privilege) അലൗലിസ്റ്റുകൾ നടപ്പിലാക്കിയും, സ്റ്റേറ്റ് മാറ്റുന്ന പ്രവർത്തനങ്ങൾ നിയന്ത്രിച്ചും, ആവശ്യമുള്ള ഇടങ്ങളിൽ മനുഷ്യരെ ഉൾപ്പെടുത്തിയും, മാറ്റമില്ലാത്ത ഒരു ലോഗ് സൂക്ഷിച്ചും, ഡെവലപ്പർമാർക്ക് അവരുടെ LLM ഏജന്റുകൾ അറിയാതെ തന്നെ കുറ്റകൃത്യങ്ങളിൽ പങ്കാളികളാകുന്നത് തടയാൻ കഴിയും.