আপনার tools এমন callers-এর জন্য উন্মুক্ত, যাদের আপনি দেখতে পান না
একটি MCP server আপনার product-কে AI clients-এর জন্য ব্যবহারযোগ্য করে। এটি tools, resources এবং prompts উন্মুক্ত করে, যেগুলো assistants এবং agents খুঁজে পেতে ও call করতে পারে, Model Context Protocol specification-এ বর্ণিত JSON-RPC 2.0 messages ব্যবহার করে hosts, clients এবং servers-এর মধ্যে। এই কারণেই teams এগুলো তৈরি করে: তারা আপনার product-কে সেই workflows-এর ভেতরে নিয়ে যায়, যেখানে AI agents ইতিমধ্যেই কাজ করছে।
এর মানে আপনার server এমন clients থেকে calls পায়, যেগুলো আপনি তৈরি করেননি এবং সরাসরি observe করতে পারেন না। একটি single tool local-এ test করা একজন developer, signed-in একজন ব্যক্তির পক্ষে কাজ করা desktop assistant, রাতভর দীর্ঘ কাজ চালানো একটি autonomous agent, অথবা আপনার server-এর দুর্বলতা খুঁজে দেখছে এমন কিছু দ্বারা invoke হতে পারে। protocol আপনাকে বলে কোন tool call হয়েছে এবং কোন arguments দিয়ে। কিন্তু নিজে থেকে এটি বলে না call-এর পেছনে কী ধরনের actor আছে বা তাকে কতটা trust করা উচিত।
MCP server caller identification সেই ফাঁক পূরণ করে। Proof of Actor প্রতিটি tool call-এ evidence-backed actor result যোগ করে, যাতে আপনার server সচেতন সিদ্ধান্ত নিতে পারে কে কী পাবে। সমস্যাটির গভীরতর দৃষ্টির জন্য who is calling your MCP server পড়ুন, এবং দলগুলো কীভাবে এটি প্রয়োগ করে তা দেখতে MCP servers use case দেখুন।
শর্তাবলীর বিষয়ে একটি নোট। "Caller identity" cloud infrastructure-এ একটি সুপরিচিত অর্থও বহন করে। উদাহরণস্বরূপ, AWS STS GetCallerIdentity operation কল করতে ব্যবহৃত IAM user বা role-এর বিবরণ ফেরত দেয়। এটি উত্তর দেয় কোন cloud credential call করেছে। এই পাতায় MCP server caller identification একটি ভিন্ন প্রশ্নের উত্তর দেয়: কোন ধরনের actor, Human, Human + AI, Agent বা Unknown, আপনার MCP server-এর একটি tool call-এর পেছনে আছে, এবং কোন evidence সেই উত্তরে সমর্থন দেয়।
MCP callers কেন আলাদা
MCP callers policy-র ক্ষেত্রে গুরুত্বপূর্ণ যেসব দিক আছে, তাতে browser visitor এবং traditional API client থেকে আলাদা।
- তারা প্রায় সবসময় automated. প্রশ্নটি কম "human or bot?" এবং বেশি "কোন agent, কীভাবে কাজ করছে, এবং কী evidence নিয়ে?"
- তারা প্রায়ই কোনো ব্যক্তির পক্ষে কাজ করে। একজন assistant আপনার tool call করতে পারে কারণ একজন user তাকে তা করতে বলেছে, অথবা এটি autonomously কাজ করতে পারে। এই পরিস্থিতিগুলোর treatment আলাদা হওয়া উচিত।
- তারা নিজেদের পরিচয় দেয়। MCP lifecycle specification-এ client একটি নাম এবং version সহ একটি
clientInfoobject তারinitializerequest-এ পাঠায়। সেই declaration উপকারী context, কিন্তু এটি proof নয়। - tools-এর impact ব্যাপকভাবে আলাদা। একটি search tool এবং records delete করা একটি tool-এর জন্য একই policy হওয়া উচিত নয়।
ভালো MCP caller identification-কে এই চারটিই সম্মান করতে হবে।
Proof of Actor কীভাবে MCP callers শনাক্ত করে
আপনার server-এর signals
আপনার MCP integration প্রতিটি call-এর জন্য উপলব্ধ context Proof of Actor-কে দেয়: client-এর declared details, transport এবং request context, client যে cryptographic request signatures দেয়, যেমন RFC 9421-এ সংজ্ঞায়িত HTTP Message Signatures, এবং যে tool call করা হচ্ছে। প্রতিটি signal কোথা থেকে এসেছে তা দিয়ে labeled থাকে।
basis সহ classification
Proof of Actor চারটি class-এর একটিতে result দেয়, Human, Human + AI, Agent বা Unknown, এবং result-এর basis-ও দেয়:
- verified যখন কোনো cryptographic check, যেমন published key-এর বিরুদ্ধে request signature, pass করেছে;
- declared যখন client বা আপনার application তা stated করেছে, যেমন session-এ client name;
- inferred যখন result call-এর pattern-এর ওপর নির্ভর করে;
- unknown যখন evidence কোনো determination সমর্থন করে না।
একটি declared client name কখনও verification হিসেবে উপস্থাপিত হয় না। যখন evidence দুর্বল থাকে, result হয় Unknown, confident guess নয়, এবং আপনার server ঠিক কী নিয়ে কাজ করছে তা জানে।
আপনার tools-এর জন্য ব্যবহারযোগ্য একটি result
actor result tool call-এর সঙ্গে আসে, আপনার server-এর logic ব্যবহারের জন্য প্রস্তুত। observation mode-এ আপনি এটি record করেন। প্রস্তুত হলে, আপনার tool-level policies এটি নিয়ে action নেয়।
আপনার team কী পায়: Detect, Understand, Route
Detect
প্রতিটি tool call-এ উপলব্ধ caller evidence capture করুন এবং verified, declared ও inferred evidence আলাদা রাখুন।
Understand
কোন clients কোন tools call করছে, কতবার করছে, কী evidence নিয়ে করছে, এবং সময়ের সঙ্গে তা কীভাবে বদলাচ্ছে তা দেখুন। এমন tools খুঁজে বের করুন যেগুলোতে mostly Unknown callers আসে, যে clients আচরণ বদলায়, এবং যে calls verifiable identity বহন করে তাদের share।
Route
প্রতি tool এবং প্রতি risk tier অনুযায়ী policy লিখুন। সাধারণ patterns:
- Low-impact tools যেমন search বা read-only lookups: broadly allow করুন, standard rate limit সহ।
- Moderate-impact tools যেমন drafts তৈরি করা: verified এবং declared callers allow করুন, Unknown-কে rate-limit করুন।
- High-impact tools যেমন data delete করা, settings পরিবর্তন করা, বা কোনো user's behalf-এ messages পাঠানো: আপনার strongest authorization প্রয়োজন করুন, এবং caller Unknown হলে বা autonomously কাজ করলে confirmation বা review যোগ করুন।
protecting sensitive actions without blocking agents-এর guide দেখায় কীভাবে এই tiers design করতে হয়।
Identity evidence, credentials এবং authorization আলাদা
MCP security সবচেয়ে ভালো কাজ করে যখন তিনটি প্রশ্ন আলাদা থাকে:
- Identity evidence: কোন ধরনের client call করছে, এবং কী তা প্রমাণ করে? Proof of Actor এটি দেয়।
- Credentials: কোন account বা token দিয়ে এই call করা হচ্ছে? আপনার MCP server-এর authentication এটি দেয়। MCP authorization specification authorization-কে optional করে, এবং HTTP-based transports-এর জন্য এটিকে OAuth 2.1-এর ওপর ভিত্তি করে, যেখানে MCP server একটি resource server হিসেবে access tokens validate করে।
- Authorization: এই caller কি এই tool, এই arguments, এই account-এর জন্য ব্যবহার করতে পারে? আপনার permission model এটি দেয়।
একজন recognized client স্বয়ংক্রিয়ভাবে authorized হয় না। একটি valid signature দেখায় না যে session-এর পেছনের ব্যক্তি এই specific action-এর জন্য authority delegate করেছে। delegated authority এবং agent authorization সম্পর্কে আরও পড়ুন। Proof of Actor প্রথম প্রশ্নের জন্য আপনার server-কে আরও ভালো context দেয়, যাতে দ্বিতীয় ও তৃতীয় প্রশ্নের উত্তর আরও তথ্যভিত্তিক হয়।
শুধু client name-এ কেন ভরসা করা যায় না?
কারণ যে কোনো client যে কোনো name পাঠাতে পারে। declared name-কে proof হিসেবে ধরা নকলকে আমন্ত্রণ জানায়: একটি hostile client-কে শুধু একটি popular assistant-এর name কপি করতে হয়। Proof of Actor name-টিকে declared evidence হিসেবে record করে, যেখানে stronger evidence আছে তার সঙ্গে combine করে, এবং basis বলে দেয়। এরপর আপনার policy verified callers-কে শুধুমাত্র নিজেদের পরিচয় দেওয়া callers-এর চেয়ে বেশি সুযোগ দিতে পারে, এবং কোনোটি প্রযোজ্য না হলে Unknown fallback প্রয়োগ করতে পারে।
Observation mode-এ শুরু করুন
আপনার MCP server-এ Proof of Actor install করলে কোনো tool-এর response কীভাবে কাজ করে তা বদলে যায় না। result record করা হয়, যাতে আপনি দেখতে পারেন কারা আপনার tools call করছে, evidence কতটা strong, এবং কোথায় policy সাহায্য করবে। আপনি confidence পেলে, একটি single high-impact tool-এ policy enable করুন, outcome দেখুন, তারপর প্রসারিত করুন। How It Works পুরো flow কভার করে, এবং Detection & Limitations ব্যাখ্যা করে প্রতিটি ধরনের evidence কী স্থাপন করতে পারে আর কী পারে না।
MCP servers এবং APIs চালানো teams-এর জন্য তৈরি
Proof of Actor আপনার existing authentication, rate limiting এবং logging-এর সঙ্গে আপনার server-এর ভেতরে বসে। integration-গুলি প্রতিটি founding team-এর সঙ্গে hands-onভাবে সরবরাহ করা হয়, যাতে setup আপনার transport, hosting এবং tool design-এর সঙ্গে মেলে। MCP Servers এবং APIs use case দেখায় কীভাবে একই approach আপনার tools এবং আপনার API-জুড়ে প্রযোজ্য হয়।
আপনি যে প্রতিটি tool উন্মুক্ত করেন, তার জন্য জিজ্ঞেস করার প্রশ্ন
Tool-level policy লেখার আগে, আপনার MCP server যে প্রতিটি tool উন্মুক্ত করে, তা একটি ছোট checklist দিয়ে review করা সহায়ক:
- এই tool কী বদলাতে পারে? read-only tools এবং যেগুলো data modify করে, messages পাঠায় বা billing-এ প্রভাব ফেলে, তাদের treatment আলাদা হওয়া উচিত।
- এটি কার জন্য? কিছু tool signed-in ব্যক্তির পক্ষে কাজ করা assistants-এর জন্য; অন্যগুলো autonomous workflow-এর জন্য। প্রত্যাশিত caller সঠিক policy নির্ধারণ করে।
- ভুলের cost কত? ভুল search result-এর cost কম। ভুল deletion-এর নয়। প্রতিটি tool-কে একটি risk tier-এ map করুন।
- কী evidence প্রয়োজন হওয়া উচিত? একটি declared client যথেষ্ট কি না, নাকি tool-টির verified identity plus আপনার strongest authorization প্রয়োজন হবে তা ঠিক করুন।
- Unknown হলে কী হবে? প্রতিটি tool-এর জন্য একটি explicit fallback বেছে নিন: allow, rate-limit, user-কে confirm করতে বলা, বা review-এ route করা।
- কীভাবে জানবেন এটি কাজ করছে? কিছু enforce করার আগে observation mode-এ কোন outcome আপনি দেখবেন তা ঠিক করুন।
প্রতিটি tool-এর জন্য একবার এগুলো answer করলে caller identification স্পষ্ট, testable rules-এ পরিণত হয়, এবং আপনার server-এর behaviour আপনার সঙ্গে integrate করা clients-কে ব্যাখ্যা করা সহজ হয়।
founding developer program-এ যোগ দিন
Proof of Actor private beta-তে আছে। নির্বাচিত founding development teams agreed usage limits-এর মধ্যে up to 12 months free access পেতে পারে, tool-level policy design করার সময় আমাদের engineers-এর সরাসরি support সহ।
আপনি যদি একটি MCP server চালান এবং কে এটি call করছে তা জানতে চান, early access-এর জন্য apply করুন। আপনার server, আপনি যে tools উন্মুক্ত করেন, এবং যেসব call আপনার কাছে সবচেয়ে গুরুত্বপূর্ণ সেগুলো সম্পর্কে আমাদের জানান।
Sources
- Model Context Protocol specification (2025-06-18), modelcontextprotocol.io.
- MCP lifecycle: initialization and clientInfo, modelcontextprotocol.io.
- MCP authorization, modelcontextprotocol.io.
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- AWS STS GetCallerIdentity API reference, Amazon Web Services.