আপনার MCP সিস্টেম সুরক্ষিত করুন: ১১টি সাধারণ ঝুঁকি এবং সেগুলো থেকে সুরক্ষার উপায়

এই গাইডে MCP নিরাপত্তা ব্যাখ্যা করা হয়েছে, যেখানে পরোক্ষ প্রম্পট ইনজেকশন থেকে লোকাল সার্ভার আপস পর্যন্ত MCP সিস্টেমের ১১টি সাধারণ ঝুঁকি এবং প্রতিটি থেকে সুরক্ষায় সহায়ক ব্যবহারিক পদক্ষেপগুলো তুলে ধরা হয়েছে।

Diagram of how MCP works: the MCP host (the AI app) sends tool requests through an MCP client to an MCP server, which offers its tools and returns results to the host.

MCP-এর ঝুঁকিগুলো মোটামুটি তিনটি শ্রেণিতে পড়ে: LLM ম্যানিপুলেশন, ডেটা ও অ্যাক্সেস নিরাপত্তা, এবং অবকাঠামোগত দুর্বলতা।

যেহেতু MCP সার্ভারগুলো প্রায়ই বিস্তৃত পরিসরের অভ্যন্তরীণ সিস্টেমে অ্যাক্সেস দেয়, তাই সম্ভাব্য নিরাপত্তা ঝুঁকি বেশি। তবে ঝুঁকির সম্ভাবনা অনেকাংশে সেটআপের ওপর নির্ভর করে।

ব্যক্তি ও প্রতিষ্ঠান তাদের সিস্টেম সুরক্ষিত রাখতে অনেক পদক্ষেপ নিতে পারে, এবং সংযুক্ত MCP সার্ভারগুলো যে সক্ষমতা ও ডেটা উন্মুক্ত করতে পারে, নিরাপত্তা প্রোটোকল সবসময় সেগুলোর সাথে সামঞ্জস্যপূর্ণ হওয়া উচিত।

MCP এবং MCP নিরাপত্তা কী?

Model Context Protocol (MCP) হলো Anthropic-এর তৈরি একটি উন্মুক্ত মানদণ্ড, যা LLM-ভিত্তিক অ্যাপ (বা হোস্ট)-কে বাহ্যিক সিস্টেমের সাথে সংযুক্ত করে।

একটি MCP সিস্টেমে তিনটি মূল উপাদান থাকে: হোস্ট, ক্লায়েন্ট এবং সার্ভার। হোস্ট, যা প্রায়ই একটি AI সহকারী, একটি ক্লায়েন্টের মাধ্যমে বাহ্যিক MCP সার্ভারের সাথে সংযুক্ত হয়। এরপর এটি বাহ্যিক কার্যকারিতা (টুল) চালানোর, ডেটা (রিসোর্স) সংগ্রহের, অথবা LLM-এর কনটেক্সট উইন্ডোতে যোগ করার জন্য প্রম্পট আনার অনুরোধ পাঠাতে পারে।

MCP নিরাপত্তা বলতে সেই প্রোটোকলগুলোকে বোঝায়, যা একটি MCP সিস্টেমের সংযোগ ও উপাদানগুলোকে সুরক্ষিত রাখে। MCP-এর কিছু নিজস্ব মূল চ্যালেঞ্জ রয়েছে, যার মধ্যে আছে AI অ্যাপগুলোর প্রায়ই এজেন্টিক সক্ষমতা থাকা এবং বার্তার মধ্যে ক্ষতিকর নির্দেশনা লুকিয়ে রাখা সম্ভব হওয়া।

যেসব প্রতিষ্ঠিত সমস্যা কেবল MCP-এর জন্য নির্দিষ্ট নয়, যেমন প্রম্পট ইনজেকশন, দুর্বল অথেনটিকেশন এবং অনিরাপদ তৃতীয় পক্ষের ইন্টিগ্রেশন, সেগুলোও সমস্যা তৈরি করে। অন্য যেকোনো কম্পিউটার সিস্টেমের মতোই, সুরক্ষার জন্য MCP পদ্ধতিগত প্রোটোকল, যেমন কেবল বিশ্বস্ত সার্ভার ব্যবহার করা, এবং প্রযুক্তিগত নিয়ন্ত্রণ, যেমন API গেটওয়ে—এই দুইয়ের সমন্বয়ের ওপর নির্ভর করে।

MCP-এর হুমকিগুলো কতটা গুরুতর?

MCP দ্রুতই একটি জনপ্রিয় LLM প্রযুক্তিতে পরিণত হয়েছে, এবং অনেক প্রতিষ্ঠান ও গ্রাহকমুখী অ্যাপ এটি ব্যবহার করে। যেহেতু MCP সার্ভারগুলো কোডে লেখা প্রোগ্রাম, তাই অন্য যেকোনো অ্যাপ্লিকেশনের মতো এগুলোরও দুর্বলতা রয়েছে।

তবে প্রতিষ্ঠানগুলো যখন নিয়ন্ত্রিত ডিপ্লয়মেন্টে MCP ব্যবহার করে, তখন এটি সাধারণত নিরাপদ। বিশ্বস্ত সার্ভার ও যাচাইকৃত অনুমতি দিয়ে একটি সিস্টেম তৈরি করা আর একটি স্বায়ত্তশাসিত এজেন্টকে এক ডজন অযাচাইকৃত সার্ভারের সাথে জুড়ে দেওয়ার মধ্যে বিশাল পার্থক্য রয়েছে।

হুমকি #১: পরোক্ষ প্রম্পট ইনজেকশন

একজন আক্রমণকারী LLM-কে লক্ষ্য করে লেখা নির্দেশনা এমন কোনো ডকুমেন্ট, ওয়েবপেজ বা টুল আউটপুটের মধ্যে রাখতে পারে, যা একটি MCP সার্ভার ফেরত দেয়। হোস্ট যদি এই উপাদান কনটেক্সট উইন্ডোতে যোগ করে, তাহলে LLM এটিকে আসল নির্দেশনা ভেবে ভুল করতে পারে।

তার ওপর, এই নির্দেশনাগুলো বাহ্যিকভাবে যথাযথ মনে হতে পারে। যেমন, সংগৃহীত একটি সাপোর্ট টিকিট LLM-কে উত্তর তৈরির আগে সংবেদনশীল গ্রাহক রেকর্ড এক্সপোর্ট করতে বলতে পারে।

পরোক্ষ প্রম্পট ইনজেকশন থেকে কীভাবে সুরক্ষা পাবেন

প্রম্পট ইনজেকশন সাধারণত হোস্ট পর্যায়ে মোকাবিলা করা উচিত। বাহ্যিক কনটেন্টকে অবিশ্বস্ত হিসেবে চিহ্নিত করা উচিত, এবং সংবেদনশীল তথ্যের অনুরোধের ক্ষেত্রে প্রক্রিয়ায় যুক্ত একজন মানুষের সচেতন অনুমোদন বাধ্যতামূলক হওয়া উচিত। হোস্ট ও LLM কীভাবে সাড়া দেয় তা দেখতে ক্ষতিকর ডকুমেন্ট বা ডেটা কল করে নিরাপত্তা পরীক্ষা চালানোও সহায়ক হতে পারে।

হুমকি #২: টুল পয়জনিং এবং রাগ পুল

টুল পয়জনিং আক্রমণে একটি MCP টুলের বিবরণ বা স্কিমায় ক্ষতিকর কোড যোগ করা হয়। এটি ডিসকভারি পর্যায়ে, অর্থাৎ যখন MCP প্রথমবার উপলভ্য টুলগুলো উন্মুক্ত করে, তখন LLM-কে প্রভাবিত করতে পারে।

রাগ পুল হলো এক বিশেষ ধরনের টুল পয়জনিং, যেখানে অনুমোদিত মেটাডেটা পরিবর্তন করা হয়। এই ধরনের টুল পয়জনিং সরাসরি কোনো ক্ষতিকর টুল চালু না করে, বরং একটি মডেল বিশ্বস্ত টুলগুলো যেভাবে ব্যবহার করে তা বদলে দিতে পারে।

টুল পয়জনিং ও রাগ পুল থেকে কীভাবে সুরক্ষা পাবেন

প্রতিটি টুল ব্যবহারের আগে হোস্টের উচিত সেটির পূর্ণ সংজ্ঞা পরীক্ষা করা এবং অনুমোদিত বিশ্বস্ত টুলের তালিকার সাথে মিলিয়ে দেখা, যাতে যেকোনো পরিবর্তন শনাক্ত করা যায়। প্যারামিটার যাচাই বিপজ্জনক সক্ষমতার সম্ভাবনা শনাক্ত করতে এবং সেগুলো চিহ্নিত করতে সাহায্য করতে পারে।

হুমকি #৩: অতিরিক্ত অনুমতি

ব্যবহারকারীরা প্রায়ই MCP সার্ভার ও (হোস্টের মাধ্যমে) সংযুক্ত LLM-গুলোকে কোনো কাজের জন্য প্রয়োজনের চেয়ে বেশি অনুমতি দিয়ে থাকেন। যেমন, কেবল রিড-অনলি অ্যাক্সেস যথেষ্ট হলেও রাইট অনুমতি দেওয়া, অথবা কোনো অভ্যন্তরীণ ফাইল সিস্টেমে (যেমন Google Drive) সম্পূর্ণ অ্যাক্সেস দেওয়া।

অনুমতির এই ব্যাপক বিস্তার ক্ষতিকর টুল কলের মতো অন্যান্য দুর্বলতার ক্ষতির পরিধি বাড়িয়ে দিতে পারে। কোনো প্রতিষ্ঠানে AI টুল নিয়ে দৈনন্দিন কাজের সময় ব্যবহারকারীরা একের পর এক বিশেষাধিকার দিতে থাকায় অনুমতিগুলো “জমে যাওয়া” সাধারণ ব্যাপার (বিশেষাধিকার পুঞ্জীভবন)।

অতিরিক্ত অনুমতি থেকে কীভাবে সুরক্ষা পাবেন

এই সমস্যা থেকে সুরক্ষার সবচেয়ে সরাসরি উপায় হলো অনুমতি ও OAuth স্কোপ (রিড, রাইট, সম্পূর্ণ অ্যাক্সেস ইত্যাদি) সীমিত করা। ব্যবহারকারীর অনুমোদন, বিশেষত সংবেদনশীল কাজের ক্ষেত্রে, এর একটি গুরুত্বপূর্ণ অংশ, তবে অনুমতিগুলো সিস্টেম পর্যায়েও (অপারেটিং সিস্টেম, MCP হোস্ট এবং সার্ভার) নিয়ন্ত্রণ করা উচিত।

হুমকি #৪: দুর্বল অথেনটিকেশন ও অথরাইজেশন

অথেনটিকেশন একটি MCP সার্ভারের সাথে সংযুক্ত হওয়া ব্যবহারকারী বা অ্যাপ্লিকেশনের পরিচয় যাচাই করে। অথরাইজেশন নির্ধারণ করে তারা কোন কোন টুল ও রিসোর্স অ্যাক্সেস করতে পারবে।

ভুলভাবে কনফিগার করা MCP সার্ভারগুলো ব্যবহারকারীদের সঠিকভাবে অথেনটিকেট না করে বা অ্যাক্সেস সীমাবদ্ধতা প্রয়োগ না করেই অনুরোধ বা টোকেন গ্রহণ করতে পারে। এছাড়া, যাচাই দুর্বল হলে চুরি হওয়া ক্রেডেনশিয়াল ব্যবহার করে দুর্বৃত্তরা অ্যাক্সেস পেয়ে যেতে পারে।

দুর্বল অথেনটিকেশন ও অথরাইজেশন থেকে কীভাবে সুরক্ষা পাবেন

রিমোট MCP সার্ভারের জন্য OAuth-ভিত্তিক অথেনটিকেশন, স্বল্পমেয়াদি টোকেন এবং রোল-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ (RBAS)—এগুলো সবই দুর্বল অথরাইজেশনের ঝুঁকি কমাতে সাহায্য করে। রোল-ভিত্তিক অ্যাক্সেস কার্যকর, কারণ সার্ভারের নিজের অ্যাক্সেস থাকলেও এটি ব্যবহারকারীদের তাদের অনুমতির বাইরের ডেটা ও টুল অ্যাক্সেস করতে বাধা দেয়।

হুমকি #৫: ক্রেডেনশিয়াল ফাঁস ও অপব্যবহার

বাহ্যিক সেবার সাথে সংযুক্ত হতে MCP সার্ভারগুলো নিয়মিতভাবে API কী ও OAuth অ্যাক্সেস টোকেনের মতো ক্রেডেনশিয়াল ব্যবহার করে। এগুলো উন্মুক্ত বা অপব্যবহৃত হলে আক্রমণকারীরা সংবেদনশীল ডেটা ও কার্যকারিতায় অ্যাক্সেস পেতে পারে।

এর একটি উদাহরণ হলো টোকেন পাসথ্রু, যেখানে একটি MCP সার্ভার কোনো অ্যাক্সেস টোকেন আসলেই গ্রহণকারী সেবার জন্য নির্ধারিত কি না তা যাচাই না করেই অন্য একটি সেবায় পাঠিয়ে দেয়। গ্রহণকারী সেবার সুরক্ষা অপর্যাপ্ত হলে এর ফলে তথ্য ফাঁস হতে পারে।

ক্রেডেনশিয়াল ফাঁস ও অপব্যবহার থেকে কীভাবে সুরক্ষা পাবেন

ফাঁস হওয়া ডেটা দুর্বৃত্তরা কতটা ব্যবহার করতে পারবে তা সীমিত রাখতে স্বল্পমেয়াদি, সংকীর্ণ পরিসরের টোকেন এবং ক্রেডেনশিয়াল রোটেশন কার্যকর। API কী ও ক্রেডেনশিয়াল সবসময় একটি সিক্রেট ম্যানেজার ব্যবহার করে নিরাপদে সংরক্ষণ করা উচিত।

হুমকি #৬: কনফিউজড ডেপুটি আক্রমণ

কনফিউজড ডেপুটি আক্রমণ ঘটে যখন একজন আক্রমণকারী কৌশলে একটি বিশ্বস্ত অ্যাপ্লিকেশনকে দিয়ে তার নিজের অনুমতি ব্যবহার করে এমন কোনো কাজ করিয়ে নেয়, যা কোনো বৈধ ব্যবহারকারী অনুমোদন করেননি। এক্ষেত্রে MCP সার্ভারটিই হলো ডেপুটি।

আক্রমণকারী একটি MCP সার্ভারের দুর্বলতা (যেমন দুর্বল OAuth যাচাই) কাজে লাগিয়ে কোনো ক্ষতিকর প্রক্রিয়া চালাবে, যেমন একটি টুল কল বা ডেটা সংগ্রহ।

কনফিউজড ডেপুটি আক্রমণ থেকে কীভাবে সুরক্ষা পাবেন

অথরাইজেশন যাচাই, যেখানে প্রতিটি টুল কল একজন নির্দিষ্ট ব্যবহারকারীর কি না তা যাচাই করা হয়, কনফিউজড ডেপুটি আক্রমণ সীমিত করতে সাহায্য করে। এছাড়া, ডেটা এক্সপোর্টের মতো সংবেদনশীল কাজের জন্য সুস্পষ্ট অথরাইজেশন বাধ্যতামূলক হওয়া উচিত।

হুমকি #৭: ক্ষতিকর সার্ভার ও আপসকৃত ডিপেনডেন্সি

MCP সার্ভারে ক্ষতিকর কোড থাকতে পারে (এগুলো মূলত বাহ্যিক প্রোগ্রাম) অথবা এগুলো তৃতীয় পক্ষের লাইব্রেরির মতো আপসকৃত ডিপেনডেন্সির ওপর নির্ভর করতে পারে। এটি কেবল MCP-এর নিজস্ব সমস্যা নয়, বরং একটি সফটওয়্যার সাপ্লাই চেইন সমস্যা।

এটি ঘটার একটি সহজ উপায় হলো, কোনো আক্রমণকারী বৈধ বলে মনে হয় এমন একটি ইন্টিগ্রেশন বিতরণ করে। একবার সেটআপ হয়ে গেলে এটি ক্রেডেনশিয়াল চুরি ও পুনরায় ব্যবহার করতে, সংবেদনশীল ডেটা অ্যাক্সেস করতে এবং অননুমোদিত কার্যক্রম চালাতে পারে।

ক্ষতিকর সার্ভার ও আপসকৃত ডিপেনডেন্সি থেকে কীভাবে সুরক্ষা পাবেন

কেবল বিশ্বস্ত ও যাচাইকৃত উৎস থেকে MCP সার্ভার ইনস্টল করুন। সম্ভব হলে সেগুলোর কোড পর্যালোচনা করুন, এবং বাইরের যেকোনো ডিপেনডেন্সি সবসময় যাচাই করুন। সার্ভারগুলো নিয়মিত আপডেট ও প্যাচ করা নিশ্চিত করুন।

হুমকি #৮: সার্ভার-সাইড রিকোয়েস্ট ফরজারি (SSRF)

সার্ভার-সাইড রিকোয়েস্ট ফরজারি (SSRF) হলো এমন পরিস্থিতি, যখন একজন আক্রমণকারী কৌশলে একটি MCP সার্ভারকে দিয়ে এমন অভ্যন্তরীণ ঠিকানায় নেটওয়ার্ক অনুরোধ পাঠায়, যেগুলোতে ব্যবহারকারী অ্যাক্সেস করতে চাননি।

যখন কোনো MCP সার্ভার এমন একটি টুল উন্মুক্ত করে যা কোনো URL থেকে তথ্য সংগ্রহ করে, তখন এমনটি ঘটতে পারে। আক্রমণকারী যদি URL প্যারামিটারকে প্রভাবিত করতে পারে, তবে সে এটিকে নিজের পছন্দের নেটওয়ার্ক ঠিকানায়, যেমন কোনো অভ্যন্তরীণ API বা ক্লাউড সেবায়, বদলে দিতে পারে। এর ফলে সংবেদনশীল ডেটা সংগৃহীত হয়ে সম্ভাব্যভাবে অন্যদের নাগালে চলে যেতে পারে

সার্ভার-সাইড রিকোয়েস্ট ফরজারি (SSRF) থেকে কীভাবে সুরক্ষা পাবেন

MCP সার্ভারগুলোর উচিত সবসময় URL যাচাই করা, সীমাবদ্ধ অভ্যন্তরীণ নেটওয়ার্ক ঠিকানায় অ্যাক্সেস ব্লক করা এবং আউটবাউন্ড নেটওয়ার্ক অ্যাক্সেস প্রতিরোধ করা। রিডাইরেক্টের ক্ষেত্রেও এই প্রোটোকল অনুসরণ করা উচিত।

হুমকি #৯: সেশন হাইজ্যাকিং

সেশন হাইজ্যাকিংয়ে একজন আক্রমণকারী একটি MCP ক্লায়েন্ট ও সার্ভারের মধ্যকার সক্রিয় সংযোগের নিয়ন্ত্রণ নিয়ে নেয়।

যেমন, তারা দুর্বলভাবে সুরক্ষিত কোনো MCP অ্যাপ্লিকেশন (যেমন একটি হোস্ট বা সার্ভার) থেকে সেশন আইডেন্টিফায়ার চুরি করতে পারে। MCP সার্ভার যদি এই আইডেন্টিফায়ার গ্রহণ করে, তবে আক্রমণকারী সম্ভাব্যভাবে ব্যবহারকারীর বৈধ অনুমতি নিয়ে টুল কল করতে পারে।

কীভাবে সুরক্ষা পাবেন

একটি MCP সিস্টেমের সব অ্যাপ্লিকেশনে কঠোর পরিচয় যাচাইয়ের মাধ্যমে সেশন হাইজ্যাকিংয়ের ঝুঁকি কমানো যায়। সেশন আইডেন্টিফায়ার যাতে শনাক্ত হয়ে না যায়, সেজন্য MCP ক্লায়েন্ট ও রিমোট সার্ভারের মধ্যে এনক্রিপশনও অপরিহার্য।

হুমকি #১০: মিক্স-আপ আক্রমণ

মিক্স-আপ আক্রমণে আক্রমণকারী কৌশলে একটি MCP ক্লায়েন্টকে দিয়ে ক্লায়েন্ট ও MCP সার্ভারের মাঝখানে থাকা একটি ক্ষতিকর অথরাইজেশন সার্ভারে অথরাইজেশন কোড পাঠায়। অথরাইজেশন সার্ভার হলো এমন একটি অ্যাপ্লিকেশন, যা অনুরোধকৃত অ্যাক্সেস অনুমোদিত কি না তা যাচাই করার পর OAuth অ্যাক্সেস টোকেন ইস্যু করে।

যদি একটি MCP হোস্ট একাধিক সেবার সাথে সংযুক্ত থাকে এবং প্রতিটি সেবা আলাদা অথরাইজেশন সার্ভার ব্যবহার করে, তবে একজন আক্রমণকারী সম্ভাব্যভাবে একটির নিয়ন্ত্রণ নিতে পারে (সম্ভবত একটি ক্ষতিকর সেবা নিবন্ধন করে) এবং ক্লায়েন্টকে দিয়ে বৈধ সার্ভারের ইস্যু করা অথরাইজেশন কোড ক্ষতিকর সার্ভারে পাঠাতে পারে। এই মিক্স-আপের ফলে আক্রমণকারী অনুমোদিত অ্যাপ্লিকেশনের ছদ্মবেশ ধারণ করে সুরক্ষিত সেবাগুলোতে অ্যাক্সেস পেতে পারে।

মিক্স-আপ আক্রমণ থেকে কীভাবে সুরক্ষা পাবেন

পুরো OAuth প্রক্রিয়া জুড়ে MCP ক্লায়েন্টদের উচিত অথরাইজেশন সার্ভারের পরিচয় যাচাই করা। বিশেষভাবে, তাদের উচিত সার্ভারের ইস্যুয়ার আইডেন্টিফায়ার (iss) প্রত্যাশিত পরিচয়ের সাথে মিলিয়ে দেখা এবং অমিল থাকলে তা প্রত্যাখ্যান করা।

হুমকি #১১: লোকাল MCP সার্ভার আপস

অনেক MCP সার্ভার ব্যবহারকারীর লোকাল মেশিনে চলে। ব্যবহারকারীরা হয়তো তৃতীয় পক্ষের কাছ থেকে সার্ভারটি ইনস্টল করেন অথবা নিজেরাই তৈরি করেন। কোনো আক্রমণকারী যদি এই লোকাল MCP সার্ভারকে আপস করতে পারে, তবে সে সম্ভাব্যভাবে লোকাল সিস্টেমের বড় অংশে অ্যাক্সেস পেতে পারে।

একজন আক্রমণকারী নানা উপায়ে অ্যাক্সেস পেতে পারে। সে বৈধ ইন্টিগ্রেশনের ছদ্মবেশে একটি ক্ষতিকর সার্ভার বিতরণ করতে পারে, একটি MCP হোস্টের কনফিগারেশন এমনভাবে পরিবর্তন করতে পারে যাতে সেটি ক্ষতিকর কমান্ড দেয়, অথবা অপর্যাপ্ত নিরাপত্তা নিয়ন্ত্রণযুক্ত পরিবেশে চলা কোনো MCP সার্ভারে অ্যাক্সেস নিতে পারে, যেমন DNS রিবাইন্ডিংয়ের মাধ্যমে, যা কৌশলে একটি ব্রাউজারকে দিয়ে localhost সেবায় অনুরোধ পাঠায়।

লোকাল MCP সার্ভার আপস থেকে কীভাবে সুরক্ষা পাবেন

লোকাল MCP সার্ভার ব্যবহারের সময় স্যান্ডবক্স ব্যবহার ও কঠোর সম্মতি প্রোটোকল গুরুত্বপূর্ণ। MCP সার্ভার কেবল বিশ্বস্ত প্রদানকারীর কাছ থেকেই ইনস্টল করা উচিত, এবং সেগুলো কোন কোন ডিরেক্টরিতে অ্যাক্সেস করতে পারবে তা অপারেটিং সিস্টেমের অনুমতির মাধ্যমে সীমাবদ্ধ করা উচিত।

MCP-এর দুর্বলতাগুলো প্রায়ই নতুন মোড়কে পুরোনো হুমকি

MCP-এর দুর্বলতাগুলো প্রায়ই প্রতিষ্ঠিত ঝুঁকি ও আক্রমণ পদ্ধতির নতুন প্রয়োগ থেকে আসে। LLM, MCP সার্ভার এবং বাহ্যিক সেবাগুলোর মধ্যকার মিথস্ক্রিয়ার মাধ্যমে MCP আক্রমণকারীদের জন্য এই দুর্বলতাগুলো কাজে লাগানোর নতুন উপায় তৈরি করে।

অবশ্যই, MCP-নির্দিষ্ট হুমকি রয়েছে। তবে মনে রাখা দরকার যে প্রচলিত নিরাপত্তা প্রোটোকল, যেমন কঠোর অথরাইজেশন প্রয়োগ, বিশ্বস্ত প্রদানকারী ব্যবহার এবং প্রম্পট ইনজেকশন থেকে সুরক্ষা, যেকোনো MCP বাস্তবায়নকে সুরক্ষিত রাখতে অনেকখানি কার্যকর ভূমিকা রাখবে।