Safari MCP-এর ওপর ভিত্তি করে তৈরি একটি অটোমেশন টুল ডেভেলপারদের ড্যাশবোর্ড ট্যাবটি পড়ার সময় সেটি বন্ধ করে দিয়েছিল। এই ঘটনাটি সেই গার্ডের (guard) একটি লুকানো ত্রুটি প্রকাশ করেছে যা AI-চালিত এজেন্টদের তাদের নিজস্ব নয় এমন কোনো ট্যাব স্পর্শ করা থেকে বিরত রাখার কথা ছিল, এবং এটি দেখায় কেন “safe-by-default” ক্যাটাগরিগুলো একটি ঝুঁকির কারণ হতে পারে।
যে গার্ডটি কাজ করছিল—যতক্ষণ না এটি ব্যর্থ হলো
টুলটি প্রতিটি ট্যাব তৈরি করার সময় একটি অভ্যন্তরীণ আইডেন্টিফায়ার (internal identifier) ট্যাগ করে। এজেন্ট কোনো কমান্ড দেওয়ার আগে, গার্ডটি সেই মার্কারটি পরীক্ষা করে; যদি মার্কারটি না থাকে, গার্ডটি কাজ করতে অস্বীকার করে। বাস্তবে, গার্ডটি এজেন্টকে এমন একটি পেজ পড়তে বাধা দিয়েছিল যা সে নিজে খুলেনি—ঠিক যা করার জন্য এটি ডিজাইন করা হয়েছিল।
একটি ফর্ম পূরণ করার সময়, পেজটি অন্য একটি ডোমেইনে রিডাইরেক্ট (redirect) হয়ে যায়। এই রিডাইরেক্ট মার্কারটিকে সরিয়ে দেয়, ফলে ট্যাবটি আনলেবেলড (unlabelled) হয়ে পড়ে। গার্ডটি মার্কারটি না পেয়ে রিপোর্ট করে, “আমি মালিকানা যাচাই করতে পারছি না, তাই আমি এই ট্যাবটি পড়ব না।” সেই মুহূর্তে সেফটি চেকটি ঠিক যেভাবে কাজ করার কথা ছিল সেভাবেই কাজ করেছিল।
সীমা লঙ্ঘনকারী ক্লিনআপ কোড
এরপর এলো একটি ম্যানুয়াল ক্লিনআপ রুটিন (cleanup routine), যার কাজ ছিল অনাথ (orphaned) ট্যাবগুলো—যেগুলোর কোনো মার্কার নেই—সেগুলো বন্ধ করা। রুটিনটি মালিকানা নিশ্চিত না করেই টুলটিকে “close a tab” করতে বলেছিল। যেহেতু গার্ড প্রমাণ করতে পারেনি যে ট্যাবটি তার নিজস্ব, তাই টুলটি একটি ডিফল্ট অ্যাকশনে ফিরে যায়: “close the current tab।” বর্তমান ট্যাবটি ছিল সেই ড্যাশবোর্ড যা ডেভেলপার পড়ছিলেন, কোনো অনাথ ট্যাব নয়।
এর ফলে একটি ধ্বংসাত্মক অপারেশন (destructive operation) শুরু হয়, যা এমন একটি সেফটি পাথ (safety path) থেকে ট্রিগার হয়েছিল যা আসলে একটি ডেড এন্ড (dead end) হওয়ার কথা ছিল।
তিনটি স্তর যা “মালিকানা নেই” বিষয়টিকে অনুমতি হিসেবে গণ্য করেছিল
- Command categorisation – কমান্ডগুলোর তালিকা
close_tab-কে একটি বিস্তৃত “tab management” বা ট্যাবের ব্যবস্থাপনার অধীনে রেখেছিল। ডেভেলপার ধরে নিয়েছিলেন যে ওই ক্যাটাগরির সবকিছুই ক্ষতিকারক নয়, কারণ অন্যান্য কমান্ড (যেমন “list tabs”) শুধুমাত্র তথ্য পড়ে।close_tab-কে ধ্বংসাত্মক হিসেবে কোনো স্পষ্ট নোট দেওয়া হয়নি, তাই এটি তার পাশের কমান্ডগুলোর আপাত নিরাপত্তা উত্তরাধিকারসূত্রে পেয়েছিল। - Extension-level policy – Safari এক্সটেনশনটি, যা সমস্ত ব্রাউজার অ্যাকশন পরিচালনা করে, সেশন যখন কিছুরই মালিক না ছিল তখন যেকোনো অপারেশন করার অনুমতি দিয়েছিল। এই নিয়মটি শুধুমাত্র রিড-অনলি (read-only) অ্যাকশনের জন্য কার্যকর, কিন্তু এটি
close_tab-কেও কোনো প্রোভেন্যান্স চেক (provenance check) ছাড়াই কার্যকর করার সুযোগ করে দিয়েছিল। - Logic mismatch – ক্লিনআপ রুটিনটি একটি ট্যাবের মালিকানা ফ্ল্যাগ পরীক্ষা করেছিল কিন্তু তারপর ব্রাউজার যে ট্যাবটিকে “current” হিসেবে রিপোর্ট করেছিল, সেটির ওপর ক্লোজ ফাংশনটি কল করেছিল। এই অমিলটি গার্ডের মার্কার খুঁজে না পাওয়ার ব্যর্থতাকে ক্লোজ কমান্ডটি বাইপাস করতে এবং ভুল টার্গেটে রিডাইরেক্ট করতে সাহায্য করেছিল।
প্রতিটি স্তর ধরে নিয়েছিল যে “মালিকানা রেকর্ড করা নেই” মানে হলো “কাজ করা নিরাপদ,” এবং এই সব মিলে একটি ট্যাব-ক্লোজিং কমান্ড তৈরি করেছিল যা কোনো বৈধতা ছাড়াই রান করেছিল।
সমাধান: ধ্বংসাত্মক কাজের জন্য মালিকানার প্রমাণ বাধ্যতামূলক
সংশোধিত লজিকটি রিড-অনলি পাথ এবং ধ্বংসাত্মক পাথগুলোকে আলাদা করে। এখন, একটি close_tab কমান্ড কার্যকর করার আগে, টুলটিকে টার্গেট ট্যাবের জন্য একটি বৈধ মার্কার উপস্থাপন করতে হবে। যদি মার্কারটি না থাকে, তবে কমান্ডটি বর্তমান ট্যাবে ডিফল্ট হওয়ার পরিবর্তে একটি এরর (error) দেবে। গার্ড এখন আর কোনো সাধারণ “do something” ব্রাঞ্চে ফিরে যায় না।
এই পরিবর্তনটি সেই অস্পষ্ট অবস্থাটি দূর করে যেখানে একটি অনুপস্থিত মার্কারকে হয় “কিছু করার নেই” অথবা “এগিয়ে যাও এবং কাজ করো” হিসেবে পড়া হতে পারত। একটি স্পষ্ট ব্যর্থতা (explicit failure) নিশ্চিত করার মাধ্যমে, টুলটি ব্যবহারকারীর কাজকে আকস্মিক ক্ষতি থেকে রক্ষা করে।
ডেভেলপারদের যা খেয়াল রাখা উচিত
- ক্যাটাগরির নাম দিয়ে নিরাপত্তাকে নির্ধারণ করতে দেবেন না – “tab management”-এর মতো লেবেলটি এর ভেতরে থাকা প্রতিটি কমান্ডের প্রভাব সম্পর্কে কিছুই বলে না। প্রতিটি অপারেশনের খরচ (read vs. destroy) কমান্ডের পাশে লিখে রাখুন।
- গার্ড কন্ডিশন অবশ্যই কাজের গুরুত্বের সাথে সামঞ্জস্যপূর্ণ হতে হবে – একটি রিড রিকোয়েস্টের জন্য যে চেক যথেষ্ট, তা ডেটা মুছে ফেলতে পারে এমন কমান্ডের জন্য যথেষ্ট নয়। প্রতিটি প্রভাবের ক্লাসের জন্য আলাদা ভ্যালিডেশন পাইপলাইন তৈরি করুন।
- Implicit fallbacks এড়িয়ে চলুন – যখন একটি গার্ড মালিকানা যাচাই করতে পারে না, তখন সবচেয়ে নিরাপদ উপায় হলো কাজ বাতিল করা, কোনো ডিফল্ট টার্গেট বেছে নেওয়া নয়। ডিফল্ট অ্যাকশনগুলো প্রিভিলেজ-এসকেলেশন (privilege-escalation) বাগের একটি সাধারণ উৎস।
- Audit adjacency assumptions – যে তালিকায় বা মেনুতে কমান্ডগুলো পাশাপাশি থাকে, সেগুলো পর্যালোচনা করুন। যদি কোডটি স্পষ্টভাবে নিরাপত্তাকে পুনরায় মূল্যায়ন না করে, তবে একটি নিরীহ কমান্ড তার পাশের কমান্ডগুলোর ওপর রাখা বিশ্বাসের সুবিধা নিতে পারে।
মূল শিক্ষা
মালিকানা সংক্রান্ত গার্ডের অনুপস্থিতি কোনো বাগ নয়; এটি একটি ডিজাইনের ঘাটতি। প্রতিটি ধ্বংসাত্মক কমান্ডকে একটি আলাদা সিকিউরিটি ডোমেইন হিসেবে বিবেচনা করুন যার জন্য কর্তৃত্বের স্পষ্ট প্রমাণ প্রয়োজন, এবং কখনোই “no marker” বিষয়টিকে “go ahead” হিসেবে ব্যাখ্যা করতে দেবেন না। কেবল তখনই অটোমেশন টুলগুলো সেই ট্যাবগুলোকেই রক্ষা করতে পারবে যেগুলোকে ম্যানেজ করার জন্য সেগুলো তৈরি করা হয়েছে।