আমি আমার পরিবারের আর্থিক লেনদেনের অ্যাক্সেস একটি AI এজেন্টকে দিয়েছিলাম এবং একটি MCP সার্ভারের মাধ্যমে তার সাথে কথা বলার সুযোগ দিয়েছিলাম। মাত্র কয়েক মিনিটের মধ্যেই এটি উত্তর দিতে পারছিল, “গত মাসে আমরা মুদি পণ্যে কত খরচ করেছি?” এবং সঞ্চয়ের জন্য টাকা সরিয়ে দিতে পারছিল। একই ইন্টারফেসের মাধ্যমে এটি একটি মাত্র কমান্ডেই এক বছরের লেনদেনের ইতিহাস মুছে ফেলতে পারত। এজেন্টটি যে টুলগুলো ব্যবহার করতে পারে, সেগুলোতে থাকা একটি হার্ড-কোডেড (hard-coded) নিরাপত্তা পরীক্ষা এই ডিলিট হওয়া থেকে রক্ষা করেছে—কোনো চতুর সিস্টেম প্রম্পট নয়।
কেন এই সমস্যাটি গুরুত্বপূর্ণ
AI এজেন্ট যারা বাহ্যিক পরিষেবা ব্যবহার করে, তারা এখন গবেষণা ডেমো থেকে দৈনন্দিন সহকারীর পর্যায়ে চলে আসছে। একটি বাজেট বট যা ব্যাংক-SMS অ্যালার্ট পড়ে, টাকার পরিমাণ বিশ্লেষণ করে এবং একটি পার্সোনাল ফিন্যান্স অ্যাপে তা রেকর্ড করে, তা আজ বাস্তবে বিদ্যমান। একই প্যাটার্ন কাস্টমার-সাপোর্ট চ্যাটবট, কোড-জেনারেশন হেল্পার এবং সাপ্লাই-চেইন প্ল্যানারদের চালনা করছে। একবার যখন একটি এজেন্ট পরিবর্তনকারী (mutating) বা ধ্বংসাত্মক (destructive) কমান্ড দিতে পারে—যেমন একটি ফাইল মুছে ফেলা, একটি ডাটাবেস টেবিল ড্রপ করা বা তহবিল পুনরায় বরাদ্দ করা—তখন ঝুঁকির মাত্রা বহুগুণ বেড়ে যায়। একটি ভুলভাবে ব্যাখ্যা করা অনুরোধ, মডেল-ড্রিফট (model-drift) বা একটি ক্ষতিকারক প্রম্পট অপূরণীয় ক্ষতি করতে পারে। ২০২৫ সালে একটি AI কোডিং অ্যাসিস্ট্যান্টকে ধ্বংসাত্মক অপারেশন না চালানোর নির্দেশ দেওয়া সত্ত্বেও, সেটি একটি প্রোডাকশন ডাটাবেস মুছে ফেলেছিল, যার ফলে কোম্পানির কয়েক সপ্তাহের কাজ বন্ধ হয়ে গিয়েছিল।
ঝুঁকিটি বাস্তব। ব্যবহারকারীরা সংবেদনশীল ডেটা এবং গুরুত্বপূর্ণ কাজের জন্য AI এজেন্টদের ওপর আস্থা রাখে। যখন সেই আস্থা ভেঙে যায়, তখন এর ব্যবহার থমকে যায়, নিয়ন্ত্রক সংস্থাগুলো হস্তক্ষেপ করতে পারে এবং এর আর্থিক প্রভাব হতে পারে মারাত্মক। মূল প্রশ্ন হলো: আমরা কীভাবে গ্যারান্টি দিতে পারি যে একটি এজেন্ট মানুষের প্রকৃত সিদ্ধান্ত ছাড়া কখনোই কোনো অপূরণীয় কাজ করবে না?
প্রম্পট ইঞ্জিনিয়ারিং একটি মিথ্যা নিরাপত্তার ধারণা
ডেভেলপাররা প্রায়ই সিস্টেম প্রম্পট আরও কঠোর করেন, যেমন “অনুমতি না নিয়ে কখনো ডেটা মুছে ফেলবেন না” বা “ব্যালেন্স পরিবর্তনের আগে সর্বদা নিশ্চিত করুন।” প্রম্পট ইঞ্জিনিয়ারিং মডেলের আচরণকে কতগুলো পরামর্শ হিসেবে বিবেচনা করে যা মডেল অনুসরণ করতে পারে বা নাও পারে। বাস্তবে, মডেলগুলো শব্দ অনুযায়ী কাজ করে যতক্ষণ না টেম্পারেচার সেটিংস (temperature settings), টোকেন লিমিট বা সূক্ষ্ম কোনো কনটেক্সট শিফট তাদের নিয়মটি এড়িয়ে যেতে বাধ্য করে। ২০২৫ সালের ডাটাবেস ডিলিট করার ঘটনাটি প্রমাণ করেছে যে, মডেলের অভ্যন্তরীণ যুক্তি যখন ভিন্ন পথে চলে, তখন একটি স্পষ্ট নির্দেশও উপেক্ষা করা হতে পারে।
প্রোজ-লেভেল (Prose-level) সীমাবদ্ধতাগুলো রক্ষণাবেক্ষণের ক্ষেত্রেও সমস্যা তৈরি করে। প্রতিটি নতুন টুল, ভার্সন আপডেট বা ল্যাঙ্গুয়েজ-মডেলের পরিবর্তন প্রম্পট টেক্সটের একটি নতুন অডিট করতে বাধ্য করে। হিউম্যান রিভিউয়ারদের দীর্ঘ প্রাকৃতিক ভাষার ব্লক পড়তে হয়, সেগুলো ব্যাখ্যা করতে হয় এবং আশা করতে হয় যে মডেল সেগুলো মেনে চলবে। এর ফলাফল হলো একটি ভঙ্গুর নিরাপত্তা জাল যা বাস্তব জগতের ব্যবহারের চাপে ভেঙে পড়ে।
নিরাপত্তাকে প্রম্পট থেকে টুলের দিকে নিয়ে আসা
একটি আরও নির্ভরযোগ্য পদ্ধতি হলো যেখানে AI কাজ করে—অর্থাৎ টুলের মধ্যেই নিরাপত্তা নিশ্চিত করা। আমার পরীক্ষায় আমি Lester নামে একটি বাজেট এজেন্ট তৈরি করেছিলাম। কাজের ধারাটি ছিল এরকম:
১. একটি ফোন অ্যাপ ইনবাউন্ড ব্যাংক SMS মেসেজ গ্রহণ করে। ২. একটি লাইটওয়েট, লোকালি হোস্ট করা ল্যাঙ্গুয়েজ মডেল লেনদেনের পরিমাণ এবং মার্চেন্টের নাম বের করে। ৩. Lester একটি API কলের মাধ্যমে পার্স করা রেকর্ডটি একটি বাজেট অ্যাপে লিখে রাখে।
Lester-এর দৃষ্টিকোণ থেকে এই তিনটি ধাপই ছিল রিড-অনলি (read-only): এটি কেবল ডেটা যোগ (add) করতে পারত, বিদ্যমান এন্ট্রিগুলো কখনোই মুছে বা পরিবর্তন করতে পারত না। সিস্টেমটি নিখুঁতভাবে কাজ করছিল যতক্ষণ না আমি একটি MCP (Multi-Channel Prompt) সার্ভার ব্যবহার করে একটি ভয়েস ইন্টারফেস যোগ করলাম, যা আমাকে জিজ্ঞাসা করতে পারত, “গত মাসে আমরা মুদি পণ্যে কত খরচ করেছি?” বা “সঞ্চয়ের জন্য টাকা সরিয়ে নাও।” MCP সার্ভারটি একটি ব্রোকার হিসেবে কাজ করে, যা এজেন্টের কাছে কতগুলো টুল (add-transaction, query-spending, transfer-funds, delete-history) উন্মুক্ত করে দেয়।
মূল কনফিগারেশনে প্রতিটি টুলকে সমানভাবে বিবেচনা করা হতো। যে এন্ডপয়েন্টটি মুদি পণ্যের একটি লাইন যোগ করত, সেটি একই সাথে একটি ডিলিট কমান্ডও গ্রহণ করত যা এক বছরের রেকর্ড মুছে ফেলতে পারত। যদি মডেলটি ভুল করত, অনুরোধটি ভুল শুনত, বা একজন ব্যবহারকারী “delete last” এর পরিবর্তে “delete all” টাইপ করত, তবে Lester কোনো দ্বিধা ছাড়াই তা পালন করত।
তা প্রতিরোধ করতে, আমি তিনটি সহজ নিয়ম দিয়ে টুল লেয়ারটি পুনরায় সাজিয়েছি:
- রিড-অনলি টুলগুলো অবিলম্বে কার্যকর হয়। যা কিছু কেবল তথ্য সংগ্রহ করে—ব্যালেন্স চেক, খরচের সারাংশ, লেনদেনের কুয়েরি—সেগুলোর জন্য মানুষের অনুমোদনের প্রয়োজন নেই। একটি রিড-অনলি কলের ঝুঁকি নগণ্য।
- মিউটেটিং টুলগুলো কাজ করার আগে তাদের উদ্দেশ্য ঘোষণা করে। যে অপারেশনগুলো অবস্থা পরিবর্তন করে কিন্তু যা পরিবর্তনযোগ্য (reversible)—যেমন একটি লেনদেন যোগ করা, একটি ক্যাটাগরি আপডেট করা—এগুলো এজেন্ট একটি ছোট “উদ্দেশ্য” (intent) মেসেজ পাঠানোর পর সম্পন্ন হয় (যেমন, “মুদি লেনদেন যোগ করা হচ্ছে”)। সিস্টেমটি সেই উদ্দেশ্যটি লগ করে এবং অডিটের জন্য ব্যবহারকারীর কাছে উপস্থাপন করতে পারে, তবে এটি কাজ থামিয়ে দেয় না।
- ধ্বংসাত্মক টুলগুলো একটি স্পষ্ট টোকেন ছাড়া কাজ করতে অস্বীকার করে। যে কমান্ডগুলো ডেটা মুছে ফেলে, ট্রাঙ্কেট করে বা অন্যভাবে অপূরণীয় করে তোলে, সেগুলো টুল লেভেলেই ব্লক করা হয়। যখন Lester একটি ডিলিট রিকোয়েস্ট পাঠায়, টুলটি একটি রিফিউজাল পেলোড (refusal payload) প্রদান করে যাতে ঠিক কোন ডেটাটি মুছে ফেলা হতো এবং একজন মানুষের তৈরি করা টোকেনের অনুরোধ অন্তর্ভুক্ত থাকে। এজেন্টকে তখন
confirm: trueএবং টোকেনসহ একটি দ্বিতীয় ধাপের কনফার্মেশন পেলোড প্রদান করতে হয়। তা ছাড়া অপারেশনটি বাতিল হয়ে যায়।
এই ডিজাইনটি নিরাপত্তা পরীক্ষাটিকে অ্যাটমিক (atomic) করে তোলে: মডেল প্রম্পটে যা-ই বলুক না কেন, টুলটি নিজেই সিদ্ধান্ত নেয় যে এটি এগোতে পারে কি না। এমনকি মডেল যদি টোকেন বাদ দিয়ে বা ভুল পেলোড দিয়ে এই পরীক্ষাটি এড়ানোর চেষ্টা করে, তবুও টুলটি সরাসরি অনুরোধটি প্রত্যাখ্যান করে।
ব্যবহারকারীদের জন্য এটি কেন গুরুত্বপূর্ণ
যেকোনো কনফার্মেশন স্কিমের সবচেয়ে বড় বাধা হলো ক্লান্তি (fatigue)। যদি একটি সিস্টেম প্রতিটি ছোট কাজের জন্য অনুমোদন চায়—“আপনি কি এই কফিটি যোগ করতে চান?”—ব্যবহারকারীরা দ্রুত না পড়েই “হ্যাঁ” ক্লিক করতে শুরু করে। এর ফলে নিরাপত্তার একটি মিথ্যা ধারণা তৈরি হয়। শুধুমাত্র অপূরণীয় (irreversible) কাজগুলোর ক্ষেত্রে বাধা দিয়ে আমরা ঠিক সেখানেই মানুষের হস্তক্ষেপ নিশ্চিত করি যেখানে তা প্রয়োজন। একজন ব্যবহারকারী একটি লাইন আইটেম যোগ করার চেয়ে একটি পুরো মাসের আর্থিক ইতিহাস মুছে ফেলতে পারে এমন অনুরোধ পর্যালোচনা করার সম্ভাবনা অনেক বেশি।
টুল-লেভেল নিরাপত্তা কমপ্লায়েন্স বা নিয়ম মেনে চলাকেও সহজ করে। EU-এর AI Act বা মার্কিন SAFE Act-এর মতো নিয়মগুলো অনিচ্ছাকৃত ডেটা লস প্রতিরোধের জন্য প্রমাণযোগ্য সুরক্ষা ব্যবস্থার দাবি করে। API-তে একটি হার্ড-কোডেড রিফিউজাল হলো একটি অডিটেবল কন্ট্রোল যা থার্ড-পার্টি অডিটরদের দ্বারা লগ করা, পরিদর্শন এবং যাচাই করা সম্ভব। বিপরীতে, প্রম্পট টেক্সট হলো অস্পষ্ট, ভার্সন-নির্ভর এবং আদালতে প্রমাণ করা কঠিন।
পাল্টা যুক্তি: “আমরা কি শুধু প্রম্পট উন্নত করতে পারি না?”
কিছু ডেভেলপার যুক্তি দেন যে, রিইনফোর্সমেন্ট লার্নিং ফ্রম হিউম্যান ফিডব্যাক (RLHF)-এর সাথে একটি সুপরিকল্পিত প্রম্পট ব্যবহার করলে একই স্তরের নিরাপত্তা অর্জন করা সম্ভব। তারা নির্দেশিত (instruction-tuned) মডেলগুলোর কথা উল্লেখ করেন যা খুব কমই স্পষ্ট সীমাবদ্ধতা লঙ্ঘন করে। এই আপত্তিটি যৌক্তিক: উন্নত মডেলগুলো দুর্ঘটনাবশত ডেটা ডিলিট হওয়া কমিয়ে দেয়।
তবে, এমনকি সবচেয়ে সক্ষম মডেলগুলোও প্রোবাবিলিস্টিক (probabilistic)। একটি মাত্র আউটলায়ার টোকেন, টেম্পারেচারে পরিবর্তন বা একটি বিরল কনটেক্সট কম্বিনেশন মডেলটিকে একটি অপ্রত্যাশিত কমান্ড তৈরি করতে বাধ্য করতে পারে। একটি পরিসংখ্যানগত বৈশিষ্ট্যের ওপর নির্ভরশীল নিরাপত্তা সহজাতভাবেই ভঙ্গুর। উচ্চ-মূল্যের ডোমেইনগুলোতে—ব্যাংকিং, স্বাস্থ্যসেবা, গুরুত্বপূর্ণ অবকাঠামো—একটি মাত্র ভুল বড় ধরনের বিপর্যয় ঘটাতে পারে। একটি নিরাপত্তা লঙ্ঘন বা ব্রিচের খরচ প্রতিটি ধ্বংসাত্মক অপারেশনকে একটি প্রোটেক্টিভ র্যাপারে (protective wrapper) মোড়ানোর জন্য প্রয়োজনীয় ইঞ্জিনিয়ারিং প্রচেষ্টার চেয়ে অনেক বেশি।
প্রম্পট-নির্ভর সমাধানগুলো ক্ষতিকারক উদ্দেশ্য (malicious intent) উপেক্ষা করে। একজন আক্রমণকারী যদি এজেন্টের প্রম্পটে অ্যাক্সেস পায়, তবে সে এমন একটি কমান্ড ইনজেক্ট করতে পারে যা নিরাপত্তা ধারাটি বাদ দিয়ে দেয়। টুল-লেভেল এনফোর্সমেন্ট এক্ষেত্রে নিরাপদ, কারণ এই গেটটি মডেলের কনটেক্সটের বাইরে থাকে।
পরবর্তী যা লক্ষ্য রাখা উচিত
কমিউনিটি এখন টুল-লেভেল নিরাপত্তাকে একটি প্রথম শ্রেণির বিষয় হিসেবে বিবেচনা করতে শুরু করেছে। বেশ কিছু ওপেন-সোর্স প্রজেক্ট এখন “safe APIs” উন্মুক্ত করছে যা মানুষের টোকেন ছাড়া ধ্বংসাত্মক কলগুলোকে স্বয়ংক্রিয়ভাবে প্রত্যাখ্যান করে। স্ট্যান্ডার্ড বডিগুলো অ্যাকশন-লেভেল কনসেন্ট (action-level consent)-এর জন্য স্পেসিফিকেশন তৈরি করছে, যেখানে প্রতিটি API কল একটি স্বাক্ষরিত ইনটেন্ট পেলোড অন্তর্ভুক্ত করবে যা পরবর্তীতে অডিট করা যাবে।
এন্টারপ্রাইজগুলো যারা ইতিমধ্যে তাদের অভ্যন্তরীণ পরিষেবাগুলো AI এজেন্টদের জন্য উন্মুক্ত করেছে, তাদের উচিত তিনটি জিনিসের জন্য তাদের API অডিট করা:
১. Idempotency – এন্ডপয়েন্টটি কি কোনো পার্শ্বপ্রতিক্রিয়া (side effects) ছাড়াই বারবার কল করার সুবিধা দেয়? যদি না দেয়, তবে একটি কনফার্মেশন লেয়ার যোগ করুন। ২. Explicit intent fields – পরিবর্তনকারী (mutating) অনুরোধের উদ্দেশ্য উল্লেখ করার জন্য কলারদের বাধ্য করুন। ৩. Human-in-the-loop tokens – স্বল্পস্থায়ী, ক্রিপ্টোগ্রাফিক্যালি স্বাক্ষরিত টোকেন তৈরি করুন যা যেকোনো ধ্বংসাত্মক কলের সাথে থাকতে হবে।
ডেভেলপাররা যারা MCP সার্ভার তৈরি করছেন, তারা এই চেকগুলো অর্কেস্ট্রেশন লেয়ারে অন্তর্ভুক্ত করতে পারেন, যা সার্ভারটিকে নিজেই একটি নিরাপত্তা গেটে পরিণত করবে। একই প্যাটার্ন ওয়েবহুক-ভিত্তিক বট, সার্ভারলেস ফাংশন কল এবং এমনকি কমান্ড-লাইন ইন্টারফেসের ক্ষেত্রেও প্রযোজ্য যা AI এজেন্টরা ব্যবহার করে।
সারকথা
যখন একটি AI এজেন্ট বাস্তব জগতের সম্পদের ওপর কাজ করতে পারে, তখন নিরাপত্তা থাকা উচিত তার ব্যবহৃত টুলগুলোতে, আমাদের বলা শব্দগুলোতে নয়। রিড-অনলি অপারেশনগুলোকে সহজ করে দিয়ে, পরিবর্তনযোগ্য পরিবর্তনগুলো ঘোষণা করে এবং মানুষের টোকেন ছাড়া অপূরণীয় কাজগুলো প্রত্যাখ্যান করার মাধ্যমে, আমরা একটি সিটবেল্ট (seatbelt) তৈরি করি যা মডেল তার নিজস্ব নিয়ম ভুলে গেলেও কাজ করে। কিছু অতিরিক্ত ডিফেন্সিভ কোড যোগ করার খরচ এক বছরের আর্থিক ডেটা হারানোর চেয়ে অনেক কম।