এজেন্টের ওপর আস্থা রাখা বন্ধ করুন: অনুমোদনকে নির্দিষ্ট টুল কলের সাথে যুক্ত করুন
বেশিরভাগ এজেন্টিক সিস্টেম (agentic systems) ফাইল রাইট বা টাকা ট্রান্সফারের মতো বিপজ্জনক কাজগুলোকে একটি সাধারণ অনুমোদনের মাধ্যমে সুরক্ষিত রাখে।
সাধারণত, এই অনুমোদনটি সিস্টেম স্টেটে একটি boolean flag হিসেবে থাকে।
উদাহরণস্বরূপ: approved: true।
এটি একটি ভুল। একটি boolean তিনটি উপায়ে ব্যর্থ হতে পারে যা আক্রমণকারীরা কাজে লাগায়:
- Flip (ফ্লিপ): একজন আক্রমণকারী প্রম্পট ইনজেকশন বা কোডের ত্রুটির মাধ্যমে স্টেটটিকে false থেকে true-তে পরিবর্তন করে দেয়।
- Replay (রিপ্লে): আপনি "read file"-এর মতো একটি নিরাপদ কমান্ড অনুমোদন করেন। সিস্টেম "true" দেখে এবং দ্বিতীয় একটি বিপজ্জনক কমান্ড যেমন "delete database" চালানোর অনুমতি দেয়।
- Argument Drift (আর্গুমেন্ট ড্রিফট): আপনি "send $10" অনুমোদন করেন। কিন্তু এক্সিকিউশনের আগে একজন আক্রমণকারী অ্যামাউন্ট পরিবর্তন করে $10,000 করে দেয়। ফ্ল্যাগটি তখনও "true" দেখায়।
সমস্যাটি হলো আপনি অনুমোদনকে পুরো সেশনের একটি বৈশিষ্ট্য (property) হিসেবে মডেল করছেন। এটি একটি নির্দিষ্ট কলের জন্য প্রমাণ হিসেবে কাজ করা উচিত।
এটি কীভাবে সমাধান করবেন:
যখন একজন মানুষ একটি কল অনুমোদন করেন, তখন একটি সিকিউর ট্যাগ (secure tag) তৈরি করুন। এই ট্যাগে নিচের চারটি বিষয় লক করা থাকতে হবে:
- ইউনিক টুল কল আইডি (unique tool call ID)।
- সঠিক আর্গুমেন্টগুলোর একটি হ্যাশ (hash)।
- ইউজারের পরিচয় (user identity)।
- একটি এক্সপায়ারেশন টাইম (expiration time)।
এক্সিকিউশনের ঠিক সেই মুহূর্তে এই ট্যাগটি যাচাই করুন। একটি সিক্রেট কি (secret key) ব্যবহার করুন যা শুধুমাত্র সিস্টেমটি জানে।
ইমপ্লিমেন্টেশনের জন্য এই নিয়মগুলো অনুসরণ করুন:
- Canonicalization ব্যবহার করুন: অনুমোদনকারী এবং এক্সিকিউটর—উভয়কেই ঠিক একই বাইট হ্যাশ করতে হবে। নম্বর এবং কি (keys) যেন মিলে যায় তা নিশ্চিত করতে RFC 8785 ব্যবহার করুন।
- Fail Closed: যদি কোনো ট্যাগ অনুপস্থিত, মেয়াদোত্তীর্ণ বা ভুল হয়, তবে একটি নির্দিষ্ট "not approved" এরর রিটার্ন করুন। এটিকে সাধারণ টুল রেজাল্ট হিসেবে গণ্য করবেন না।
- Deny by Default: শুধুমাত্র সেই টুলগুলোকেই অনুমতি দিন যেগুলোর জন্য স্পষ্ট অনুমোদনের প্রয়োজন। অন্য সবকিছু প্রত্যাখ্যান করুন।
- Replays হ্যান্ডেল করুন: আপনি যদি Temporal-এর মতো ইঞ্জিন ব্যবহার করেন, তবে নিশ্চিত করুন যে আপনার সিক্রেট কি (secret key) ডিটারমিনিস্টিক (deterministic)। সিস্টেম রিস্টার্টের পর যদি কি পরিবর্তিত হয়ে যায়, তবে সমস্ত বিদ্যমান অনুমোদন ব্যর্থ হবে।
অথরাইজেশন (Authorization) কোনো ভাসমান স্টেট হওয়া উচিত নয়। এটি একটি বাউন্ড এনভেলাপ (bound envelope) হওয়া উচিত যা প্রমাণ করে: "এই নির্দিষ্ট ব্যক্তি এই নির্দিষ্ট সময়ের জন্য এই নির্দিষ্ট টুলের জন্য এই নির্দিষ্ট আর্গুমেন্টগুলো অনুমোদন করেছেন।"
বুলিয়ান (boolean) ব্যবহার করা বন্ধ করুন। এগুলো কোনো সরলীকরণ নয়; এগুলো একটি বাগ (bug)।
ঐচ্ছিক লার্নিং কমিউনিটি: https://t.me/GyaanSetuAi