MCP সুরক্ষা-সীমা: AI এজেন্টের জন্য নিরাপদ অনুমতি

MCP টোকেন আসলে আপনার অ্যাকাউন্টের পাসওয়ার্ড, যার সঙ্গে একটা API জোড়া। এটা কোনো এজেন্টকে দিলে আপনি এমন এক ইউজার পাবেন যে কখনো ক্লান্ত হয় না, যে পেজে পাঠাবেন সেটাই পড়ে, আর তার কনটেক্সটের শেষ নির্দেশ যা বলে ঠিক তা-ই করে। বেশিরভাগ সময় আপনি এটাই চান। এই পেজটা বাকি সময়গুলো নিয়ে।

নিচের সবকিছু পেজের ওপরে লেখা তারিখে লাইভ সার্ভারে যাচাই করা: টুলের তালিকা এসেছে https://mcp.eqvps.com/mcp-এর tools/list থেকে, সীমাগুলো সরাসরি API থেকে। আপনি নতুন হলে আগে MCP ক্লায়েন্ট সংযোগ আর API টোকেন পড়ুন, তারপর ফিরে আসুন।

হুমকির মডেল: বাস্তবে কী ভুল হয়

তিনটি জিনিস, যে ক্রমে আমরা দেখি:

1. এজেন্ট ভুল বোঝে। "টেস্ট মেশিনটা পরিষ্কার করো" হয়ে যায় ভুল সার্ভার রিইনস্টল। কোনো খারাপ উদ্দেশ্য নেই, মডেল শুধু নির্দেশের ফাঁকা জায়গাটা নিজে ভরে নিয়েছে।
2. Prompt injection. এজেন্ট এমন কোনো লেখা পড়ে যা আপনি লেখেননি (README, সাপোর্টের উত্তর, স্ক্র্যাপ করা পেজ), আর সেই লেখা তাকে কিছু করতে বলে। এজেন্টের হাতে পূর্ণ অধিকারের টোকেন থাকলে, ঢুকিয়ে দেওয়া নির্দেশও সেই অধিকার পায়।
3. টোকেন ফাঁস হয়। সেটা shell হিস্ট্রি, পাবলিক repo, শেয়ার করা MCP কনফিগ বা কোনো লগ লাইনে গিয়ে পড়ে।

MCP সার্ভার যাচাই করে টোকেনটি বৈধ কি না এবং সার্ভারটি ওই অ্যাকাউন্টের (বা তাকে ডেলিগেট করা) কি না। আপনি আসলে কী বোঝাতে চেয়েছিলেন, তা সে জানে না। নিচের প্রতিটি সুরক্ষা-সীমা একটাই প্রশ্নের উত্তর দেয়: নির্দেশ ভুল হলে ক্ষতি সর্বোচ্চ কতদূর যেতে পারে?

সব MCP টুল, ঝুঁকির স্তর অনুযায়ী

গ্রাহক টোকেন দেখে ৪৫টি টুল (MCP সার্ভার 1.6.0)। রিসেলার টোকেন (rk_…) দেখে ৩০টি রিসেলার টুলের আলাদা সেট, আর এগুলোর একটাও না, তাই endpoint-এ মোট ৭৫টি টুল। আপনার ক্লায়েন্ট tools/list থেকে শুধু নিজের সেটটাই পায়।

এই পেজ টুলগুলোকে ঝুঁকি অনুযায়ী সাজায়। প্রতিটি টুলের প্যারামিটার ও কলের উদাহরণ আছে প্যারামিটার রেফারেন্সে; 30টি রিসেলার টুলসহ সব টুল এক লাইনে আছে পূর্ণ তালিকায়।

আমরা এখনো MCP টুল অ্যানোটেশন (readOnlyHint, destructiveHint) পাঠাই না, তাই আপনার ক্লায়েন্ট নিজে এগুলো ভাগ করতে পারে না। নিচের স্তর দেখে অনুমোদন হাতে সেট করুন।

স্তর ০ — পাবলিক, টোকেন লাগে না (৫)

স্তর ১ — অ্যাকাউন্ট পড়া, কোনো পার্শ্বপ্রতিক্রিয়া নেই (১৫)

স্তর ২ — অবস্থা বদলায়, কিছু খরচ করে না (১৭)

স্তর ৩ — টাকা খরচ করে, ডেটা মোছে বা অ্যাক্সেস দেয় (৮)

টুল সেটের পরিবর্তন-লগ

চলমান সংস্করণ পাবলিক: curl -s https://mcp.eqvps.com/healthz। এটা বদলালে এই টেবিলও সঙ্গে বদলাবে।

ব্যালান্সই খরচের সীমা

EQVPS প্রিপেইড। কোনো সেভ করা কার্ড নেই, ক্রেডিট লাইন নেই, ব্যালান্স মাইনাসে যায় না: এজেন্ট সর্বোচ্চ ততটাই খরচ করতে পারে যতটা ব্যালান্সে আছে। তিনটি টুল টাকা খরচ করে: order_vps, change_plan আর create_sandbox। আপনার বর্তমান সার্ভারগুলোর নবায়নও একই ব্যালান্স থেকে কাটে।

এজেন্ট টাকার অনুরোধ তৈরি করতে পারে, কিন্তু পরিশোধ করতে পারে না। topup_balance আর pay_invoice একটি ক্রিপ্টো পেমেন্ট লিংক ফেরত দেয়, আর পেছনে ওয়ালেট না থাকলে লিংক কিছুই করে না। টাকা তোলার কোনো endpoint-ও নেই: ব্যালান্সের টাকা আপনার অ্যাকাউন্টে সার্ভিস কিনতে পারে, বাইরে যেতে পারে না। তাৎক্ষণিক বাতিলের রিফান্ডও ব্যালান্সেই ফেরে।

একটা সতর্কতা, এবং সেটা গুরুতর। এজেন্টকে আটকাতে ব্যালান্স খুব কম রাখলে আপনার নিজের সার্ভারের নবায়ন ব্যর্থ হতে শুরু করবে, আর সার্ভারগুলো গ্রেস পিরিয়ডে চলে যাবে। আমাদের নিয়ম: যা চলছে তার এক দফা নবায়নের টাকা, সঙ্গে এজেন্টের বর্তমান কাজের বাজেট। এজেন্ট বাজেট গাইড-এ হিসাবটা দেখানো আছে। আর এজেন্টকে টাকাসহ তার নিজের ওয়ালেট দিলে, সেই ওয়ালেট হয়ে যায় দ্বিতীয় সীমা, যার দিকেও নজর রাখতে হবে।

ন্যূনতম অধিকার: শুধু পড়ার টোকেন (এখনো) নেই

সোজা কথা: প্রতিটি গ্রাহক টোকেনের অধিকার ড্যাশবোর্ডের অ্যাকাউন্টের মতোই। টোকেনের নাম আর মেয়াদ ঠিক করা যায়, স্কোপ নয়।

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

delegate_service  { "service_id": "EQ-XXXX", "email": "agent@yourdomain.com", "expires_days": 30 }

REST দিয়েও একই কাজ:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/services/EQ-XXXX/delegations" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"email":"agent@yourdomain.com","expires_days":30}'

আমন্ত্রণটি ওই ইমেইলে লগ-ইন অবস্থায় গ্রহণ করতে হয় (accept_delegation), আর expires_days ১ থেকে ৩৬৫ হতে পারে। স্ক্রিনশটসহ ধাপে ধাপে: অ্যাক্সেস ডেলিগেট করা আর ডকুমেন্টেশনে অ্যাক্সেস।

বাঁ দিকের শেষ দুই সারি খেয়াল করুন। ডেলিগেট আপনার টাকা খরচ করতে পারে না, কিন্তু ওই সার্ভার মুছে দিতে পারে। এজেন্ট যে সার্ভার রিইনস্টল করতে পারে, তার প্রতিটিতে ব্যাকআপ চালু রাখুন।

টোকেন সুরক্ষা

প্রতি এজেন্টের জন্য একটি টোকেন, নামসহ। এটি তৈরি করুন ড্যাশবোর্ড → সেটিংস → এজেন্টদের জন্য API টোকেন থেকে, অথবা এভাবে:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/auth/tokens" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"backup-agent","expires_in_days":90}'

টোকেন একবারই দেখানো হয়। মেয়াদ ১ থেকে ১৮২৫ দিন, কিছু না বললে ৩৬৫। এজেন্টের জন্য আমরা ৯০ বেছে নিতাম।

এমন ফাইলে রাখুন যা শুধু আপনিই পড়তে পারেন, repo-তে নয়, প্রম্পটে নয়, আর এমন shell ভেরিয়েবলে নয় যা আপনি এখানে-সেখানে কপি করেন:

mkdir -p ~/.config/eqvps && chmod 700 ~/.config/eqvps
( umask 077; read -rsp 'EQVPS token: ' T; echo; printf 'EQVPS_TOKEN=%s\n' "$T" > ~/.config/eqvps/agent.env )
ls -l ~/.config/eqvps/agent.env   # প্রত্যাশিত: -rw-------

তারপর এজেন্টের সার্ভিসে EnvironmentFile= (systemd) বা set -a; . ~/.config/eqvps/agent.env; set +a দিয়ে লোড করুন।

মেয়াদ শেষের আগে বদলে নিন। refresh_token টুল বা POST /auth/tokens/{id}/refresh একই নামের নতুন টোকেন দেয় এবং পুরোনোটা সঙ্গে সঙ্গে বাতিল করে। টোকেন যদি MCP ক্লায়েন্টের কনফিগে সরাসরি লেখা থাকে, তাহলে সঙ্গে সঙ্গে সেটা আপডেট করুন, নইলে পরের সেশন 401 পাবে।

কে কী ব্যবহার করছে, দেখুন: GET /auth/tokens প্রতিটি টোকেন নাম, মেয়াদ আর last_used_at সহ দেখায়। অচেনা টোকেন, বা এজেন্ট বন্ধ করার পরেও ব্যবহৃত টোকেন, আপনার জন্য সতর্কসংকেত।

টোকেন ফাঁস হলে

এই ক্রমে:

1. বাতিল করুন। ড্যাশবোর্ড → সেটিংস → এজেন্টদের জন্য API টোকেন → বাতিল, অথবা curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>। পরের অনুরোধ থেকেই এটা আর কাজ করে না।
2. নতুন টোকেন খুঁজুন যা আপনি বানাননি, সেগুলোও বাতিল করুন।
3. কী কী প্রভাবিত হতে পারে দেখুন: প্রতিটি সার্ভারের পরিষেবার ইতিহাস, ইনভয়েস আর ব্যালান্স, এবং list_delegations-এ এমন অ্যাক্সেস যা আপনি দেননি।
4. root পাসওয়ার্ড বদলান সেই টোকেন যত সার্ভার দেখতে পেত সবগুলোতে। reveal: true সহ get_vps_status root পাসওয়ার্ড দিয়ে দেয়, তাই ফাঁস হওয়া টোকেন মানেই ফাঁস হওয়া root পাসওয়ার্ড। সঙ্গে ~/.ssh/authorized_keys-ও দেখে নিন।
5. পাসওয়ার্ডের দরজা বন্ধ করুন। আপনার অ্যাকাউন্টে কখনো পাসওয়ার্ড না থাকলে, টোকেন যার হাতে ছিল সে set_password দিয়ে একটা সেট করে থাকতে পারে। ইমেইল কোড দিয়ে লগ-ইন করে পাসওয়ার্ড বদলান।

পঞ্চম ধাপের প্রতিরোধে খরচ নেই: এখনই নিজে অ্যাকাউন্টের পাসওয়ার্ড সেট করুন, তাহলে আপনার পরে যে-ই set_password ডাকুক, 409 পাবে।

মানুষের অনুমোদন

সার্ভার যা প্রয়োগ করে:

• reinstall_vps, reset_password আর type: immediate সহ cancel_service-এর জন্য confirm-এ হুবহু hostname লাগে (রিইনস্টল ও রিসেটে DELETE-ও চলে)।
• change_plan-এর জন্য confirm: true লাগে।
• ডিফল্ট বাতিল হলো end_of_period: সার্ভার পরিশোধিত মেয়াদের শেষ পর্যন্ত চলে, আর undo_cancel দিয়ে ফেরানো যায়।
• প্রতি অ্যাকাউন্টে হারের সীমা: রিইনস্টল মিনিটে ৪, পাসওয়ার্ড রিসেট মিনিটে ৬, পাওয়ার মিনিটে ২০, অর্ডার মিনিটে ২০। লুপে আটকে যাওয়া এজেন্ট যাতে একই কাজ পঞ্চাশবার না করে তার জন্য যথেষ্ট, কিন্তু একটা ভুল কল থামানোর জন্য নয়।

confirm আসলে কী, পরিষ্কার জানুন। এটা এজেন্টকে "ওখানে পরিষ্কার করো" শুনেই কাজে নামা থেকে আটকায়। আক্রমণকারীকে থামায় না, কারণ hostname মাত্র একটা get_vps_status কলের দূরত্বে। আসল অনুমোদন থাকে আপনার MCP ক্লায়েন্টে। বেশিরভাগ ক্লায়েন্ট প্রতিটি টুল কলের আগে জিজ্ঞেস করতে পারে: স্তর ০ আর ১ অবাধে চলতে দিন, স্তর ৩-কে সবসময় জিজ্ঞেস করতে দিন। যেসব ক্লায়েন্টে টুল ধরে ধরে অনুমতি দেওয়া যায়, যেমন Claude Code-এর settings.json (সার্ভার eqvps নামে নিবন্ধিত):

{
  "permissions": {
    "ask": ["mcp__eqvps__order_vps", "mcp__eqvps__change_plan", "mcp__eqvps__create_sandbox", "mcp__eqvps__reset_password", "mcp__eqvps__delegate_service"],
    "deny": ["mcp__eqvps__reinstall_vps", "mcp__eqvps__cancel_service", "mcp__eqvps__kill_sandbox"]
  }
}

এজেন্টের নির্দেশনায়ও একটা লাইন যোগ করুন। একা এটা নিরাপত্তা ব্যবস্থা নয়, তবে ভুল বোঝার ঘটনা কমায় (ইংরেজিতেই রাখুন, মডেল একইভাবে বোঝে):

Never call reinstall_vps, reset_password, cancel_service (type=immediate), change_plan,
order_vps, create_sandbox, kill_sandbox or delegate_service unless the human has typed
the target server's hostname in this conversation for that specific action.

এজেন্ট যদি দীর্ঘমেয়াদি টোকেন রাখার বদলে ইমেইল কোডে লগ-ইন করে, তাহলে MCP দিয়ে এজেন্ট লগ-ইন দেখুন।

অডিট: পরে কী দেখা যায়

• টোকেন তালিকা (GET /auth/tokens, অথবা সেটিংস → এজেন্টদের জন্য API টোকেন): নাম, তৈরির তারিখ, মেয়াদ, last_used_at। এই কারণেই এজেন্ট অনুযায়ী টোকেনের নাম রাখা দরকার।
• পরিষেবার ইতিহাস (ড্যাশবোর্ড, সার্ভার পেজ): পাওয়ার অ্যাকশন, রিইনস্টল, পাসওয়ার্ড রিসেট, প্ল্যান বদল, পেমেন্ট, প্রতিটি সময় ও কর্তাসহ: আপনি, সহায়তা বা স্বয়ংক্রিয়। কোন টোকেন বা কোন ডেলিগেট কাজটা করেছে, তা বলে না, শুধু বলে কাজটা আপনার দিক থেকে এসেছে।
• ইনভয়েস আর ব্যালান্স: প্রতিটি কাটা আর রিফান্ড।
• list_delegations: কার কাছে কীসের অ্যাক্সেস আছে, কতদিন পর্যন্ত।

পরিষেবার ইতিহাসের এই ফাঁকটাই আজ সার্ভার-সাইড অডিটের সৎ সীমা। কোন এজেন্ট কী করেছে জানতে হলে, এজেন্টের দিকে প্রতিটি টুল কল তার আর্গুমেন্টসহ (গোপন তথ্য বাদে) লগ করুন।

আমরা যে সেটআপ বেছে নিতাম

একটি প্রোডাকশন সার্ভার দেখাশোনা করা এজেন্টের জন্য:

1. এজেন্টের জন্য আলাদা অ্যাকাউন্ট, শূন্য ব্যালান্স, সার্ভার expires_days: 90 দিয়ে ডেলিগেট করা।
2. আপনার মালিক-টোকেন আপনার কাছেই থাকবে, কোনো এজেন্ট কনফিগে নয়।
3. ওই সার্ভারে ব্যাকআপ, কারণ ডেলিগেট রিইনস্টল করতে পারে।
4. ক্লায়েন্টে স্তর ৩-এর টুলগুলো "ask" বা "deny"-তে।
5. এজেন্টের টোকেন 600 অনুমতির ফাইলে, মেয়াদ শেষের আগে রিফ্রেশ করা।

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