MCP server নিরাপদ করতে OAuth যথেষ্ট নয়—৮ ধাপের deployment audit

Production MCP server নিরাপদ করতে OAuth চালু করাই যথেষ্ট নয়। বৈধ token ভুল resource-এ গ্রহণ করা হচ্ছে কি না, agent কোন tool কত ক্ষমতায় চালাতে পারে, tool metadata বদলেছে কি না এবং compromise হলে ক্ষতি কোথায় থামবে—deployment-এর আগে এসবের পরীক্ষাযোগ্য প্রমাণ দরকার।

এই আট ধাপের audit-এ প্রতিটি control-এর জন্য তিনটি সিদ্ধান্ত আছে: কী পরীক্ষা করবেন, ব্যর্থ হলে কী হবে এবং ন্যূনতম নিরাপদ অবস্থা কী। প্রমাণহীন control-কে pass না দিয়ে release blocker অথবা ঝুঁকি-মালিক অনুমোদিত exception হিসেবে নথিবদ্ধ করুন।

১. Transport ও OAuth flow যাচাই করুন

Remote HTTP endpoint, authorization server এবং redirect flow-এর সীমানা প্রথমে পরীক্ষা করুন। অননুমোদিত request-এ server সঠিক 401 challenge ও protected-resource metadata দেয় কি না, authorization code flow-তে PKCE ব্যবহৃত হয় কি না এবং redirect URI পূর্বনিবন্ধিত মানের সঙ্গে হুবহু মেলে কি না দেখুন।

MCP authorization specification HTTP transport-এর জন্য OAuth 2.1, protected-resource metadata, resource indicator, PKCE, audience validation এবং exact redirect URI matching নির্ধারণ করে। ব্যর্থতা: code interception, phishing redirect বা অনির্ভরযোগ্য authorization endpoint। ন্যূনতম অবস্থা: HTTPS, যাচাই করা metadata, PKCE, exact redirect allowlist এবং client ও server—দুই পাশে fail-closed error handling।

২. Token audience ও resource binding পরীক্ষা করুন

বৈধ access token যে এই MCP server-এর জন্যই ইস্যু করা, তা আলাদাভাবে প্রমাণ করুন। অন্য API বা MCP resource-এর token দিয়ে negative test চালান; একই সঙ্গে issuer, signature, expiry ও audience ভুল হলে প্রতিটি request প্রত্যাখ্যাত হয় কি না দেখুন। Authorization ও token request—দুটিতেই server-এর canonical URI-সহ resource parameter থাকা দরকার।

ব্যর্থতা: এক service-এর token অন্য service-এ replay হতে পারে, আর inbound token downstream API-তে পাঠালে confused-deputy ঝুঁকি তৈরি হয়। ন্যূনতম অবস্থা: audience-bound token, প্রতি request-এ claim validation এবং downstream service-এর জন্য আলাদা token। Token URL, application log বা error response-এ রাখবেন না; platform credential store বা encrypted secret store ব্যবহার করুন।

৩. Scope-এর পরে tool-level authorization বসান

OAuth scope-কে চূড়ান্ত অনুমতি ধরে নেবেন না। প্রতিটি tool call-এ authenticated actor, tenant, target resource ও action মিলিয়ে policy পরীক্ষা করুন; read, write, delete ও administrative কাজ আলাদা permission-এ ভাগ করুন। Server-এর execution identity এবং caller-এর authorization পৃথক রাখুন, যাতে বিস্তৃত server credential কম-অনুমতিসম্পন্ন caller-কে ক্ষমতা ধার না দেয়।

ব্যর্থতা: broad scope পাওয়া agent অপ্রয়োজনীয় data পড়তে বা destructive action নিতে পারে। ন্যূনতম অবস্থা: default deny, per-tool policy, সংকীর্ণ RBAC এবং সম্ভব হলে স্বল্পমেয়াদি workload identity। Destructive, আর্থিক বা data-sharing action-এর আগে ব্যবহারকারীকে পূর্ণ tool parameters দেখিয়ে স্পষ্ট অনুমোদন নিন।

৪. Tool poisoning ও shadowing আটকান

Tool name নয়, সম্পূর্ণ definition audit করুন: description, parameter name ও type, input schema, return schema, annotation এবং version। অনুমোদিত baseline-এর সঙ্গে diff চালিয়ে লুকানো নির্দেশ, পরিচিত tool-এর কাছাকাছি নাম, নতুন external destination, অঘোষিত property অথবা update-এর পর বাড়তি capability শনাক্ত করুন।

OWASP MCP Security Cheat Sheet tool poisoning, rug pull, tool shadowing, excessive permission, supply-chain attack ও sandbox escape-কে পৃথক ঝুঁকি হিসেবে চিহ্নিত করে এবং strict JSON Schema ও tool-definition pinning সুপারিশ করে। ব্যর্থতা: agent দূষিত নির্দেশ মানতে বা trusted tool-এর পরিবর্তে malicious tool ডাকতে পারে। ন্যূনতম অবস্থা: approved manifest, অঘোষিত property প্রত্যাখ্যান, integrity hash, schema-diff gate এবং পরিবর্তনের পর পুনরায় মানব অনুমোদন।

৫. Input, output ও prompt boundary কঠোর করুন

Validation শুধু client-এ রাখলে হবে না; server-এ type, format, length ও allowed value enforce করুন। Canonicalization-এর পরে file path যাচাই, command argument allowlist এবং outbound host policy পরীক্ষা করুন। Tool output-কে instruction নয়, untrusted data হিসেবে agent context-এ প্রবেশ করান; structured extraction সম্ভব হলে raw content সরাসরি পাঠাবেন না।

ব্যর্থতা: malformed input থেকে command injection, path traversal বা SSRF হতে পারে; দূষিত output পরের tool call-কে প্রভাবিত করতে পারে। ন্যূনতম অবস্থা: strict schema, unknown field rejection, request ও response size limit, egress allowlist এবং model-visible data ও executable control-এর স্পষ্ট বিচ্ছেদ। Negative test-এ cloud metadata address, internal hostname, unsafe path ও oversized payload block হওয়া চাই।

৬. Sandbox-এ blast radius মাপুন

Configuration review-এর পাশাপাশি adversarial runtime test চালান। Tool process কোন filesystem path পড়তে পারে, child process চালাতে পারে কি না, host secret বা internal network-এ পৌঁছায় কি না এবং CPU, memory, execution time বা concurrency সীমা অতিক্রম করলে কী ঘটে—প্রতিটি ফল সংরক্ষণ করুন।

ব্যর্থতা: compromised tool host credential, পাশের workload বা internal service-এ পৌঁছাতে পারে। ন্যূনতম অবস্থা: non-root isolated runtime, read-only base filesystem, আলাদা writable scratch space, প্রয়োজনভিত্তিক secret mount, deny-by-default network policy এবং enforce করা resource limit। Payment, identity বা ব্যক্তিগত তথ্য ব্যবহারের server-কে general-purpose tool থেকে পৃথক trust boundary-তে রাখুন।

৭. Third-party server ও supply chain যাচাই করুন

Third-party MCP server যোগ করার আগে publisher, source repository, security contact, dependency lock, release provenance ও vulnerability-response process যাচাই করুন। Artifact digest pin করুন; update প্রথমে staging-এ চালিয়ে manifest, schema, requested permission ও outbound destination-এর diff review করুন। Credential, filesystem ও network context trusted server-এর সঙ্গে ভাগ করবেন না।

Microsoft-এর Azure MCP Server guidance সংকীর্ণ RBAC, workload identity, tool-schema change control, sandboxing, rate limiting, auditability এবং third-party server isolation একসঙ্গে প্রয়োগের পরামর্শ দেয়। ব্যর্থতা: package update বা পাশের malicious server trusted tool-এর আচরণ প্রভাবিত করতে পারে। ন্যূনতম অবস্থা: যাচাই করা publisher, pinned artifact, বিচ্ছিন্ন credential context, অনুমোদিত baseline ও পরীক্ষিত rollback।

৮. Rate limit, audit trail ও containment পরীক্ষা করুন

Per-user, per-agent, per-tool ও per-tenant rate limit দিয়ে automated loop এবং retry storm থামে কি না পরীক্ষা করুন। Audit event-এ timestamp, authenticated actor, client, tool ও version, policy decision, target resource, outcome এবং correlation ID রাখুন; access token, secret, পূর্ণ prompt বা অপ্রয়োজনীয় ব্যক্তিগত data redact করুন।

ব্যর্থতা: automation দ্রুত খরচ ও ক্ষতি বাড়াতে পারে, অথচ incident-এর সময় কোন actor কোন tool চালিয়েছে তা পুনর্গঠন করা যাবে না। ন্যূনতম অবস্থা: কেন্দ্রীয়ভাবে সুরক্ষিত log, deny ও anomaly alert, নির্ধারিত retention, synchronized clock, kill switch এবং token revoke, tool disable ও server isolate করার rehearsal। Release record-এ আট control-এর configuration snapshot, rejected request, policy test, schema diff, sandbox result ও containment drill-এর প্রমাণ যুক্ত করুন; যেকোনো একটি অনিষ্পন্ন থাকলে OAuth সফল হলেও production readiness সম্পূর্ণ নয়।