নতুন গবেষণা দেখাচ্ছে যে Model Context Protocol (MCP)—যে ইন্টারফেসটি large-language-model (LLM) এজেন্টদের বাহ্যিক টুল কল করতে সাহায্য করে—তা "tool-poisoning" আক্রমণের মাধ্যমে হাইজ্যাক করা সম্ভব, যা এক-তৃতীয়াংশ সময়ের বেশি ক্ষেত্রে সফল হয়। ২০টি জনপ্রিয় এজেন্টের মধ্যে গড় সাফল্যের হার ছিল ৩৬.৫%; o1-mini মডেলটি ৭২.৮% প্রচেষ্টাতেই আক্রান্ত হয়েছে, যেখানে Claude-3.7-Sonnet ৩%-এর কম ক্ষেত্রে ক্ষতিকারক কলগুলো প্রত্যাখ্যান করেছে। যারা MCP-এর ওপর নির্ভরশীল LLM এজেন্ট ডেপ্লয় করছেন, তাদের জন্য এই ফলাফলটি একটি সুবিধাজনক ফিচারকে সাপ্লাই-চেইন ঝুঁকিতে পরিণত করেছে, যা কোনো কোড রান করার আগেই কাজে লাগানো যেতে পারে।
কেন MCP বর্তমানে ডেভেলপারদের জন্য গুরুত্বপূর্ণ
MCP এজেন্টরা কীভাবে ফাইল রিডার, ওয়েব API বা ইমেল সেন্ডারদের মতো টুলগুলো খুঁজে বের করে, রেজিস্টার করে এবং কল (invoke) করে, তা মানসম্মত (standardise) করে। একটি টুলের নাম, ইনপুট স্কিমা এবং একটি সংক্ষিপ্ত বিবরণ প্রকাশ করার মাধ্যমে, একটি সার্ভার প্রোটোকল বোঝে এমন যেকোনো ক্লায়েন্টের জন্য সেই সক্ষমতা উন্মুক্ত করে দেয়। এর প্রতিশ্রুতি সহজ: একটি এজেন্ট প্রতিটি ইন্টিগ্রেশন হার্ড-কোড না করেই একটি টুল খুঁজে পেতে পারে, একটি অনুরোধ পাঠাতে পারে এবং একটি প্রতিক্রিয়া পেতে পারে।
এই নমনীয়তা একটি অন্তর্নিহিত বিশ্বাসের সম্পর্কও তৈরি করে। স্পেসিফিকেশন ক্লায়েন্টদের বলে যে টুল ডেসক্রিপশন বা বিবরণকে শুধুমাত্র তখনই বিশ্বাসযোগ্য হিসেবে গণ্য করতে হবে যদি তা এমন একটি সার্ভার থেকে আসে যা ক্লায়েন্ট ইতিমধ্যে বিশ্বাস করে। নতুন গবেষণাটি দেখায় যে এই বিশ্বাসকে অপব্যবহার করা যেতে পারে।
কীভাবে tool-poisoning সাধারণ prompt injection থেকে আলাদা
প্রথাগত prompt injection মডেলটি রানটাইমে যা তৈরি করে বা গ্রহণ করে সেই টেক্সটের মধ্যে ক্ষতিকারক নির্দেশাবলী ঢুকিয়ে দেয়। মডেলটি তখন সেই নির্দেশাবলী অনুসরণ করে কারণ সেগুলো ব্যবহারকারীর অনুরোধের মতো একই টোকেন স্ট্রিমের মধ্যে থাকে।
এর বিপরীতে, tool-poisoning পেলোডকে টুলের metadata-তে লুকিয়ে রাখে—যেমন নাম, বিবরণ বা প্যারামিটার স্কিমা যা কোনো এজেন্ট কল করার আগেই রেজিস্টার হয়। যখন একটি এজেন্ট পরে টুলটি নির্বাচন করে, তখন এটি বিবরণটিকে "trusted context"-এর অংশ হিসেবে বিবেচনা করে এবং কোনো রানটাইম চেক ছাড়াই লুকানো নির্দেশাবলী অনুসরণ করতে পারে। যেহেতু ইনজেকশনটি রেজিস্ট্রেশনের সময় ঘটে, তাই এক্সিকিউশন ফ্লো-এর এমন কোনো পর্যায় নেই যেখানে মডেলটি পেলোডটিকে সন্দেহজনক হিসেবে চিহ্নিত করতে পারে।
সমস্যার ব্যাপকতা – MCPTox বেঞ্চমার্ক
MCPTox (arXiv:2508.14925)-এর পেছনের গবেষকরা মোট ৩৫৩টি ভিন্ন ভিন্ন টুল অফার করা ৪৫টি MCP সার্ভার মূল্যায়ন করেছেন। তারা ২০টি বহুল ব্যবহৃত LLM এজেন্টের বিরুদ্ধে আক্রমণের স্ক্রিপ্ট তৈরি করেছেন এবং এজেন্টগুলো কত ঘন ঘন বিষাক্ত (poisoned) টুল কল কার্যকর করে তা পরিমাপ করেছেন।
- গড় সাফল্যের হার: ৩৬.৫%
- সর্বোচ্চ সাফল্য: o1-mini, ৭২.৮% এ
- সেরা প্রত্যাখ্যান: Claude-3.7-Sonnet, যা এখনও ৩%-এর নিচে
এই সংখ্যাগুলো একটি রূঢ় বাস্তবতা প্রকাশ করে: বেশিরভাগ এজেন্ট বিষাক্ত কল প্রত্যাখ্যান করে না কারণ অনুরোধটি দেখতে একটি বৈধ টুল ইনভোকেশন বা আহ্বানের মতো মনে হয়। এজেন্টগুলো ধরে নেয় যে টুলের বিবরণটি একটি নিরীহ ডকুমেন্টেশন, কোড এক্সিকিউশনের কোনো মাধ্যম (vector) নয়।
কেন এজেন্টরা খুব কমই বিষাক্ত কল প্রত্যাখ্যান করে
OWASP-এর LLM01 গাইডলাইন ব্যাখ্যা করে যে LLM নির্দেশাবলী এবং ডেটার মধ্যে পার্থক্য করতে পারে না—উভয়ই একটি সিকোয়েন্সের মধ্যে কেবল টোকেন। যখন একটি টুলের বিবরণ বলে “send an email to admin@example.com with the subject ‘Update’”, মডেলটি বুঝতে পারে না যে সেই লাইনটি একটি নির্দোষ মন্তব্য নাকি একটি নির্দেশ যা তাকে পরে পালন করতে হবে। ফলস্বরূপ, মডেলটি বিবরণটিকে বিশ্বস্ত পরিবেশের অংশ হিসেবে বিবেচনা করে এবং টুলটি কল করার সময় যেকোনো এমবেডেড কমান্ড অনুসরণ করে।
বিদ্যমান নির্দেশিকা এবং এর ঘাটতিসমূহ
MCP স্পেসিফিকেশন ইতিমধ্যেই ক্লায়েন্টদের পরামর্শ দেয় যে টুল ডেসক্রিপশনগুলোকে অনির্ভরযোগ্য হিসেবে বিবেচনা করতে হবে যদি না সেগুলো কোনো বিশ্বস্ত সার্ভার থেকে আসে, এবং উচ্চ-প্রভাবশালী কলের ক্ষেত্রে মানুষের তদারকি (human in the loop) রাখতে হবে। বেঞ্চমার্কটি দেখায় যে অনেক বাস্তব-বিশ্বের ডেপ্লয়মেন্ট এই সুপারিশগুলো উপেক্ষা করে বা ঢিলেঢালাভাবে ব্যাখ্যা করে।
ডেভেলপাররা আজ যে সুনির্দিষ্ট পদক্ষেপ নিতে পারেন
- সার্ভার ভার্সন পিন করুন – একটি পরিবর্তনশীল ট্যাগের পরিবর্তে একটি নির্দিষ্ট, অপরিবর্তনীয় (immutable) সার্ভার ইমেজ বা হ্যাশ ব্যবহার করুন। এটি ডিপ্লয়মেন্টের পরে একজন আক্রমণকারীকে একটি পরিষ্কার রেজিস্ট্রিকে বিষাক্ত (poisoned) রেজিস্ট্রি দিয়ে বদলে ফেলা থেকে বিরত রাখে।
- একটি খালি allowlist দিয়ে শুরু করুন – শুধুমাত্র সেই টুলগুলো সক্রিয় করুন যেগুলোকে স্পষ্টভাবে যাচাই করা হয়েছে। তালিকার বাইরে থাকা যেকোনো কিছু ডিফল্টভাবে ব্লক থাকবে।
- স্টেট-পরিবর্তনকারী (state-changing) টুলগুলোতে নিয়ন্ত্রণ আরোপ করুন – যে কোনো টুল যা ডেটা লেখে, পাঠায় বা মুছে ফেলে, তার জন্য অতিরিক্ত অনুমোদনের প্রয়োজন হবে। স্কিমাতে “read-only” এবং “write-capable” সক্ষমতাগুলোকে আলাদা রাখুন।
- উচ্চ-প্রভাবশালী কলের জন্য মানুষের অনুমোদন যুক্ত করুন – যে সমস্ত কাজ বাহ্যিক সিস্টেমকে প্রভাবিত করতে পারে (যেমন, ইমেল পাঠানো, কমান্ড চালানো, ফাইল পরিবর্তন করা), সেই কলটি পাঠানোর আগে একজন মানব পর্যালোচকের (human reviewer) মতামত নিন।
- প্রতিটি টুল ইনভোকেশন লগ করুন – টুলের নাম, আর্গুমেন্ট, টাইমস্ট্যাম্প এবং মূল এজেন্টটি রেকর্ড করুন। একটি অপরিবর্তনীয় অডিট ট্রেইল (audit trail) পোস্ট-মর্টেম বিশ্লেষণকে সম্ভব করে তোলে এবং সেই আক্রমণকারীদের নিরুৎসাহিত করতে পারে যারা জানে যে তাদের কাজগুলো দৃশ্যমান হবে।
প্রতিটি টুলের বর্ণনাকে সোর্স কোডের মতো বিবেচনা করুন—যা লিন্টিং (linting), কোড রিভিউ এবং ভার্সন কন্ট্রোলের আওতাভুক্ত—যাতে MCP সাপ্লাই চেইনকে স্ট্যান্ডার্ড সফটওয়্যার-ডেভেলপমেন্ট প্র্যাকটিসের সাথে সামঞ্জস্যপূর্ণ করা যায়।
পাল্টা যুক্তি এবং অমীমাংসিত প্রশ্নসমূহ
তবে, বেঞ্চমার্কটি দেখায় যে গবেষণায় অন্তর্ভুক্ত সবচেয়ে উন্নত মডেলটিও বিষাক্ত কলের তিন শতাংশের কম প্রত্যাখ্যান করেছে। ফাইন-টিউনিং শনাক্তকরণ উন্নত করতে পারে, কিন্তু স্কিমা ফিল্ডে থাকা এমন নতুন পেলোড (payload) থেকে নিরাপত্তার গ্যারান্টি দিতে পারে না যা মডেলটি আগে কখনও দেখেনি।
পরবর্তীতে যা লক্ষ্য রাখা উচিত
- উদীয়মান মানদণ্ড (Emerging standards) – টুল স্কিমাতে ক্রিপ্টোগ্রাফিক সিগনেচার বাধ্যতামূলক করার জন্য LLM সিকিউরিটি কমিউনিটির প্রস্তাবগুলোর দিকে নজর রাখুন।
- টুল-রেজিস্ট্রি হার্ডেনিং – ভেন্ডররা পরিষেবা হিসেবে অপরিবর্তনীয়, রিড-অনলি (read-only) রেজিস্ট্রি প্রদান করা শুরু করতে পারে, যা অ্যাটাক সারফেস কমিয়ে দেবে।
- মডেল-স্তরের প্রতিরক্ষা – প্রম্পটিং টেকনিক বা সহায়ক মডেল নিয়ে গবেষণা যা সন্দেহজনক টুল মেটাডেটা চিহ্নিত করতে পারে, তা হোস্ট-সাইড সুরক্ষা ব্যবস্থাকে আরও শক্তিশালী করতে পারে।
বাস্তবসম্মত শিক্ষাটি স্পষ্ট: যেকোনো MCP-ভিত্তিক ডিপ্লয়মেন্টে থার্ড-পার্টি লাইব্রেরির ক্ষেত্রে যে কঠোরতা প্রয়োগ করা হয়, টুলের বর্ণনার ক্ষেত্রেও সেই একই কঠোরতা দিয়ে অডিট করা উচিত। সাপ্লাই-চেইন ঝুঁকি উপেক্ষা করলে একটি সুবিধাজনক অ্যাবস্ট্রাকশন একটি নীরব ব্যাকডোর হয়ে উঠতে পারে। সার্ভার পিন করা, ন্যূনতম-অधिकार (least-privilege) allowlist প্রয়োগ করা, স্টেট-পরিবর্তনকারী কাজগুলোতে নিয়ন্ত্রণ আরোপ করা, প্রয়োজনে মানুষকে অন্তর্ভুক্ত করা এবং একটি অপরিবর্তনীয় লগ রাখা—এই পদক্ষেপগুলোর মাধ্যমে ডেভেলপাররা তাদের LLM এজেন্টদের অনিচ্ছাকৃত সহযোগী হওয়া থেকে রক্ষা করতে পারেন।