Meta Muse email ও কেনাকাটা করবে—Confidential VM কিন্তু এখনো আসেনি
Meta ৮ সেপ্টেম্বর ২০২৬ যুক্তরাষ্ট্রে Muse নামে ব্যক্তিগত AI agent চালু করেছে। Meta-র আনুষ্ঠানিক ঘোষণায় ইমেইল পাঠানো, ভ্রমণ বুক করা ও কেনাকাটার ক্ষমতার পাশাপাশি বর্তমান Secure VM এবং বছরের শেষ দিকে আনার পরিকল্পনায় থাকা Confidential VM—দুই ব্যবস্থার আলাদা অবস্থান স্পষ্ট করা হয়েছে।
AP-এর স্বাধীন প্রতিবেদনে launch, যুক্তরাষ্ট্রে ১৮ বছর বা তার বেশি বয়সীদের জন্য সীমিত প্রাপ্যতা, আলাদা app ও WhatsApp থেকে ব্যবহারের সুযোগ এবং dedicated VM নিশ্চিত করা হয়েছে। তবে WIRED-এর privacy পর্যালোচনা দেখায়, launch-day Secure VM থাকা সত্ত্বেও Meta-র প্রযুক্তিগত data access এখনো অসম্ভব নয়; সেই শক্তিশালী সীমা ভবিষ্যৎ Confidential VM-এর প্রতিশ্রুতি।
Muse উত্তর নয়, পুরো কাজ এগিয়ে নিতে পারে
Muse সাধারণ chatbot-এর মতো শুধু খসড়া বা নির্দেশনা তৈরি করে থেমে থাকে না। ব্যবহারকারী একটি লক্ষ্য দিলে এটি নিজস্ব browser খুলতে, website ঘুরে তথ্য নিতে, form পূরণ করতে এবং সংযুক্ত service-এ একাধিক ধাপের কাজ এগিয়ে নিতে পারে। দীর্ঘ কাজ হলে ব্যবহারকারী app বন্ধ করার পরও তা background-এ চলতে পারে; পরিস্থিতি বদলালে বা অনুমোদন লাগলে agent আবার ফিরে আসে।
এই ক্ষমতার মধ্যে ইমেইল পাঠানো, ভ্রমণ বুক করা ও online purchase রয়েছে। ব্যবহারকারী কোন app যুক্ত করবেন এবং প্রতিটি সংযোগে কতটুকু access দেবেন, তা বেছে নিতে পারেন। ইমেইলের ক্ষেত্রে শুধু পড়ার অনুমতি ও পাঠানোর অনুমতি আলাদা রাখা যায়; পরে access বদলানো বা service বিচ্ছিন্ন করার ব্যবস্থাও আছে।
তাই শিরোনামের “করবে” শব্দটি কাজ সম্পাদনের সক্ষমতা বোঝায়, অবাধ স্বাধীনতা নয়। Muse প্রস্তুতিমূলক ধাপ নিজে এগিয়ে নিতে পারলেও sensitive action-এর আগে approval ব্যবস্থার মুখোমুখি হয়। আগে থেকে দেওয়া সীমিত permission-এর মধ্যে কোনো routine operation পড়লে প্রতিবার নতুন prompt নাও দেখা যেতে পারে।
Secure VM, Sentinel ও credential isolation-এর ভূমিকা
প্রত্যেক ব্যবহারকারীর Muse একটি dedicated Muse Secure VM-এ চলে। এর runtime container-এ agent-এর workspace, file ও ব্যবহৃত tool থাকে; credential store এবং অন্য security-sensitive service runtime থেকে আলাদা রাখা হয়। এই বিন্যাসের লক্ষ্য এক ব্যবহারকারীর environment-কে অন্যদের থেকে বিচ্ছিন্ন রাখা এবং agent ক্ষতিকর content দ্বারা প্রভাবিত হলে তার নাগাল সীমিত করা।
Sentinel মূল Muse agent থেকে system level-এ আলাদা permission authority। Muse কোনো connector ব্যবহার বা network request করার প্রস্তাব দিলে Sentinel destination, action ও ব্যবহারকারীর নির্ধারিত policy পরীক্ষা করে সেটি অনুমোদন, প্রত্যাখ্যান অথবা ব্যবহারকারীর কাছে পাঠানোর সিদ্ধান্ত নেয়। Approval লাগলে কাজ থামে এবং request সরাসরি Muse client-এ যায়—agent-এর কথোপকথনের ভেতর দিয়ে নয়।
Meta-র কারিগরি স্থাপত্যের বিবরণে বলা হয়েছে, password ও authentication token runtime-এর বাইরে isolated credential store-এ থাকে; browser-এ দেওয়া login তথ্যও মূল agent দেখতে পায় না। Connector worker-এর credential access allowlist দিয়ে সীমিত, আর email connector one-time code, password-reset link ও magic login link filter করার চেষ্টা করে।
এগুলো defense-in-depth ব্যবস্থা, নিখুঁত নিরাপত্তার প্রমাণ নয়। Meta নিজেই স্বীকার করেছে, prompt injection এখনো অমীমাংসিত সমস্যা এবং Muse ভুল করতে পারে। ফলে Sentinel, classifier, runtime isolation ও human approval-এর কাজ হলো কোনো একটি স্তর ব্যর্থ হলে সম্ভাব্য ক্ষতির পরিসর কমানো।
ইমেইল, কেনাকাটা ও background task-এ approval এক নয়
Launch-day protection তিন ধরনের কাজে তিনভাবে বোঝা দরকার:
- ইমেইল: account যুক্ত করার সময় read ও send access আলাদা করা যায়। পাঠানোর মতো sensitive action-এর আগে Muse approval চায়; তবে আগে দেওয়া permission-এর scope-ও সিদ্ধান্তে প্রভাব ফেলে।
- কেনাকাটা: checkout-এর প্রতিটি ঘটনায় purchase-এর নির্দিষ্ট বিবরণ দেখিয়ে human approval নেওয়ার কথা। Launch-এ Stripe Link নতুন merchant-এর জন্য merchant, অর্থের পরিমাণ ও সীমিত সময়ের সঙ্গে বাঁধা single-use card number দেয়; retailer প্রকৃত card number পায় না।
- Background task: গবেষণা, পরিকল্পনা বা form তৈরির মতো ধাপ app বন্ধ থাকার পরও চলতে পারে। কিন্তু outbound network action Sentinel-এর পরীক্ষার বাইরে যায় না; বিদ্যমান অনুমতি যথেষ্ট না হলে execution থামিয়ে ব্যবহারকারীর সিদ্ধান্ত চাওয়া হয়।
Approval এবং audit trail একই বিষয় নয়। Approval ভবিষ্যৎ action চালানো বা থামানোর সিদ্ধান্ত দেয়; audit trail দেখায় Muse কী করেছে এবং এরপর কী করার পরিকল্পনা আছে। ব্যবহারকারীর নিয়ন্ত্রণ কতটা কার্যকর হবে, তা শুরুতে দেওয়া permission কত বিস্তৃত এবং পরের request সেই scope-এর মধ্যে পড়ে কি না—তার ওপরও নির্ভর করে।
Confidential VM না আসা পর্যন্ত privacy-র সীমা কোথায়
বর্তমান Secure VM provider-blind ব্যবস্থা নয়। এটি ব্যবহারকারীদের data পরস্পর থেকে আলাদা রাখে এবং Meta কর্মীদের access operational policy দিয়ে সীমিত করে। কিন্তু service support, security বা operation-এর প্রয়োজনে Meta-র পক্ষে data-তে প্রযুক্তিগতভাবে প্রবেশ করা সম্ভব থাকে। তাই “Meta-ও data দেখতে পারবে না” দাবি launch সংস্করণের ক্ষেত্রে প্রযোজ্য নয়।
Meta বছরের শেষ দিকে Muse Confidential VM দেওয়ার পরিকল্পনা করেছে। প্রস্তাবিত ব্যবস্থায় পুরো VM trusted execution environment-এ চলবে এবং access key ব্যবহারকারীর device-এ থাকবে, যাতে Meta-সহ service provider cryptographicভাবে data access করতে না পারে। বর্তমানে এটি ছোট trusted-tester গোষ্ঠীর ব্যবহারে আছে; design ও source code external auditor-দের দেওয়া শুরু হলেও সাধারণ release এবং প্রকাশ্য continuous audit এখনো ভবিষ্যতের বিষয়।
Data ব্যবহারের আরেকটি সীমাও আলাদা করে দেখা দরকার। Muse conversation ও VM data সরাসরি Meta-র advertising system-এর সঙ্গে ভাগ করা হয় না বলে কোম্পানির নীতি জানায়; তবে Muse কোনো retailer-এর website ঘুরলে সেটি ব্যবহারকারীর activity হিসেবে ধরা পড়তে পারে এবং ওই retailer পরে বিজ্ঞাপন দেখাতে পারে। কথোপকথন, tool call ও subagent handoff থেকে তৈরি trajectory পরিচয়সূচক তথ্য বাদ দিয়ে model training-এ ব্যবহৃত হতে পারে, যদিও settings থেকে opt out করার সুযোগ আছে।
সুতরাং launch-এর বাস্তব সুরক্ষা হলো dedicated Secure VM, বিচ্ছিন্ন credential, Sentinel-এর policy checks, sensitive action approval এবং user-controlled connection। Meta-র access প্রযুক্তিগতভাবে বন্ধ করার প্রতিশ্রুতি তখনই বর্তমান বৈশিষ্ট্য হবে, যখন Confidential VM সাধারণভাবে প্রকাশিত হবে এবং ঘোষিত audit ও user-held key ব্যবস্থা বাস্তবে যাচাই করা যাবে।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।