AI agent registry বানালেই শাসন হয় না—owner ও expiry না দিলে catalog-ও ঝুঁকি
নিরাপদ AI agent registry গড়তে agent, MCP server, skill ও tool-এর নাম catalog-এ তোলাই যথেষ্ট নয়। Production-এ কোনো record discoverable করার আগে তার দায়ী owner, অনুমোদিত version, evaluation evidence, access boundary, review expiry এবং অপসারণের পথ বাধ্যতামূলক করতে হবে।
কার্যকর নীতিটি হলো: অসম্পূর্ণ record সংরক্ষণ করা গেলেও সেটি discoverable হবে না। Owner না থাকলে ত্রুটি, incident বা পরিবর্তনের দায় কার তা নির্ধারণ করা যায় না; expiry না থাকলে একবারের approval অনির্দিষ্টকাল বহাল থেকে পুরোনো capability-কে গ্রহণযোগ্য বলে দেখাতে পারে।
Catalog ও governance-কে এক জিনিস ভাববেন না
Registry জানায় কোন capability আছে; governance নির্ধারণ করে সেটি কে, কোন পরিবেশে, কোন শর্তে এবং কত দিন ব্যবহার করতে পারবে। AWS Agent Registry-এর নথি অনুযায়ী এতে MCP server, tool, agent, agent skill ও custom resource প্রকাশ করা যায়; প্রতিষ্ঠানের security, compliance ও quality criteria পূরণ করে অনুমোদিত record-ই discovery-তে আসে। নথিটি IAM বা JWT দিয়ে registry ও তার MCP endpoint-এ প্রবেশ নিয়ন্ত্রণ এবং CloudTrail-এ Registry API call লগ করার সুবিধাও উল্লেখ করে।
তবে কোন metadata বাধ্যতামূলক হবে, ঝুঁকির কোন স্তরে কার review লাগবে কিংবা approval কত দিন কার্যকর থাকবে—এসব প্রতিষ্ঠানের নিজস্ব নীতির সিদ্ধান্ত। Registry সেই নীতি বাস্তবায়নের জায়গা দিতে পারে; নীতি তৈরি করে দেয় না।
Minimum viable record schema বসান
একটি production record এমন হতে হবে, যাতে নতুন reviewer আগের দলের মৌখিক ব্যাখ্যা ছাড়াই capability-টির পরিচয়, বর্তমান দায়িত্ব, অনুমোদনের ভিত্তি ও নির্ভরতা বুঝতে পারেন। Agent, MCP server, skill ও tool-এর জন্য নিচের সাধারণ fields বাধ্যতামূলক রাখুন; প্রতিটি resource type-এর descriptor আলাদা অতিরিক্ত অংশে থাকবে।
- পরিচয়: স্থায়ী record ID, resource type, সংক্ষিপ্ত উদ্দেশ্য, অনুমোদিত use case এবং নিষিদ্ধ ব্যবহার।
- Ownership: দায়ী team, named owner, backup owner, যোগাযোগের channel এবং incident escalation path।
- উৎস ও lineage: source repository, immutable artifact digest, deployment environment, parent resource এবং model, tool বা data dependency।
- Version: release identifier, পরিবর্তনের সারাংশ এবং আগের approved revision-এর reference।
- Evaluation: test suite ID, পরীক্ষার তারিখ, পরীক্ষিত artifact, deployment-সদৃশ context, ফল, threshold এবং জানা limitation।
- Access: publisher, reviewer ও consumer persona, অনুমোদিত principal, data classification, credential type এবং network boundary।
- Lifecycle: state, last_reviewed_at, expires_at, successor record এবং removal runbook।
- Audit: submitter, reviewer, decision time, policy version, evidence reference এবং state-change event ID।
CI/CD pipeline-এ schema validation বসিয়ে owner, artifact identity, evaluation reference বা expires_at অনুপস্থিত থাকলে submission আটকে দিন। পুরোনো record import করতে সাময়িক exception দিলে সেই exception-এরও owner, কারণ ও expiry রাখুন; না হলে ছাড়টিই স্থায়ী ফাঁক হয়ে যাবে।
Approval-কে নির্দিষ্ট evidence ও version-এর সঙ্গে বাঁধুন
Builder record submit করতে পারেন, কিন্তু production approval-এর একমাত্র reviewer না রাখাই ভালো। ঝুঁকি অনুযায়ী security, compliance, domain quality বা platform reviewer যুক্ত করুন এবং সিদ্ধান্তের সঙ্গে reviewer identity ও প্রযোজ্য policy version সংরক্ষণ করুন।
NIST AI RMF Core স্পষ্ট দায়িত্ব, AI system inventory, পর্যায়ক্রমিক review ও নিরাপদ decommissioning-কে governance-এর অংশ করে; নিয়মিত assessment-এ front-line developer নন এমন internal expert অথবা independent assessor যুক্ত করার কথাও বলে। Registry policy-তে reviewer separation রাখা তাই স্বার্থের সংঘাত ও নির্মাতা দলের অদেখা assumption ধরার একটি যৌক্তিক control।
Approval record-এ শুধু “tests passed” লিখবেন না। কোন artifact পরীক্ষা হয়েছে, কোন scenario ও threshold ব্যবহৃত হয়েছে, deployment context কতটা মিলেছে, residual limitation কী এবং সিদ্ধান্ত কখন শেষ হবে—এসবের machine-readable reference রাখুন। Model, prompt, permission, endpoint, dependency বা data scope বদলালে নতুন revision তৈরি করে আবার review-তে পাঠান।
Version promotion ও expiry-কে state machine করুন
Production consumer যেন সর্বশেষ edit নয়, সর্বশেষ approved revision পায়। AWS-এর record lifecycle specification অনুযায়ী approved record সম্পাদনা করলে নতুন draft revision তৈরি হয় এবং সেটি অনুমোদিত না হওয়া পর্যন্ত আগের approved revision discoverable থাকে; deprecated state terminal। এই dual-revision model অসম্পূর্ণ edit-কে production discovery-তে ঢুকে পড়া থেকে ঠেকায়।
Expiry AWS lifecycle-এর স্বয়ংক্রিয় field বলে ধরে নেবেন না; এটিকে প্রতিষ্ঠানের বাধ্যতামূলক custom metadata ও policy control হিসেবে যোগ করুন। Risk, dependency volatility ও data sensitivity অনুযায়ী review interval নির্ধারণ করুন। Expiry আসার আগে owner-কে notification দিন; সময় পেরোলে record review queue-তে পাঠিয়ে নতুন discovery বন্ধ হবে কি না, তা risk class অনুযায়ী আগেই স্থির করুন।
Runtime invocation বন্ধ করা আলাদা সিদ্ধান্ত। Critical consumer, successor ও fallback না জেনে হঠাৎ access প্রত্যাহার করলে workflow ভাঙতে পারে; তাই expiry policy-তে grace period, exception approver এবং সর্বোচ্চ exception মেয়াদও লিখে রাখুন।
Discovery ও runtime access আলাদাভাবে নিয়ন্ত্রণ করুন
Administrator, publisher, curator ও consumer persona আলাদা রাখুন। Publisher record তৈরি ও revision submit করবেন; curator evidence দেখে status বদলাবেন; consumer কেবল অনুমোদিত scope-এর record খুঁজবেন; administrator policy ও role mapping পরিচালনা করবেন। ছোট দলে একজনের একাধিক দায়িত্ব থাকতে পারে, তবে একই production পরিবর্তনে submitter ও final approver আলাদা identity হওয়া উচিত।
Catalog entry দেখতে পাওয়া এবং underlying agent বা tool invoke করা এক permission নয়। Record-এর access metadata-কে runtime IAM policy, gateway enforcement, credential broker এবং network policy-র সঙ্গে মিলিয়ে দিন। Registry-তে approval বদলালেও runtime permission অপরিবর্তিত থাকলে governance কেবল discovery স্তরে সীমাবদ্ধ থাকবে।
Incident তদন্তে ব্যবহৃত catalog revision, runtime principal ও policy decision একই correlation ID-তে ধরুন। Approved artifact শনাক্ত করতে catalog version-কে runtime trace-এর সঙ্গে যুক্ত করা ownership ও approval record থেকে বাস্তব invocation পর্যন্ত সংযোগ বজায় রাখতে সাহায্য করে।
Removal drill দিয়ে নিয়ন্ত্রণের কার্যকারিতা যাচাই করুন
Deprecated field থাকা আর resource সত্যিই সরাতে পারা এক বিষয় নয়। নীতিনির্ধারিত বিরতিতে একটি non-critical approved record বেছে নিয়ে removal drill চালান এবং প্রতিটি সিদ্ধান্ত ও state change audit trail-এ রাখুন।
- Owner, active consumer, deployed revision এবং downstream dependency শনাক্ত করুন।
- Record-টিকে নতুন discovery থেকে সরিয়ে consumer notification পৌঁছেছে কি না যাচাই করুন।
- Successor থাকলে migration করুন; না থাকলে অনুমোদিত fallback বা manual process নিশ্চিত করুন।
- Invocation permission, credential ও network route প্রত্যাহার করে সরাসরি call ব্যর্থ হচ্ছে কি না পরীক্ষা করুন।
- Record deprecate করে audit data থেকে submitter, approver, শেষ approved revision ও removal decision পুনর্গঠন করুন।
Drill ব্যর্থ হলে শুধু আরেকটি metadata field যোগ করবেন না। Notification, dependency discovery, runtime enforcement বা incident ownership—যে control কাজ করেনি সেটি সংশোধন করুন। প্রতিটি discoverable capability-র জন্য কে দায়ী, কোন version অনুমোদিত, প্রমাণ কোথায় এবং কখন সেটি review বা remove করতে হবে—এই চার প্রশ্নের কার্যকর উত্তর থাকলেই catalog শাসনযোগ্য হয়।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।