কার্যকর কৃত্রিম বুদ্ধিমত্তা সিস্টেম তৈরি করতে হলে আগে সেগুলো ভাঙার চেষ্টা করতে হয়. আমরা একটি রেড টিমিং কার্যক্রম চালিয়েছি, যেখানে আক্রমণকারীর ভূমিকায় থেকে আর্থিক পরিষেবার একটি গ্রাহকমুখী কৃত্রিম বুদ্ধিমত্তা অ্যাপ পরীক্ষা ও অনুসন্ধান করা হয়েছে. নিরাপত্তা যেখানে ঐচ্ছিক নয়, এমন LLM-চালিত অ্যাপ্লিকেশন যারা চালু করছেন, আমাদের পাওয়া ফলাফল তাদের সবার জন্য গুরুত্বপূর্ণ.
রেড টিমিং হলো ইচ্ছাকৃতভাবে আপনার কৃত্রিম বুদ্ধিমত্তা সিস্টেম ভাঙার চেষ্টা, যাতে প্রকৃত কোনো আক্রমণকারী খুঁজে পাওয়ার আগেই দুর্বলতাগুলো ঠিক করা যায়. আর্থিক পরিষেবায় ঝুঁকি বিশেষভাবে বেশি: কৃত্রিম বুদ্ধিমত্তা অ্যাপ্লিকেশন গ্রাহকের ডেটা ব্যবহার করে, লেনদেন প্রক্রিয়া করে এবং আর্থিক অন্তর্দৃষ্টি দেয়. একটি ব্যর্থতার ফল খারাপ ব্যবহারকারীর অভিজ্ঞতা থেকে শুরু করে নিয়ন্ত্রক বিধি লঙ্ঘন, আর্থিক ক্ষতি এবং ব্র্যান্ডের অপূরণীয় ক্ষতি পর্যন্ত হতে পারে.
আমাদের লক্ষ্য ছিল আগেভাগে দুর্বলতা খুঁজে বের করা, বাস্তবসম্মত আক্রমণ-প্যাটার্ন পরীক্ষা করা এবং নিয়ন্ত্রকেরা যে কৃত্রিম বুদ্ধিমত্তা নিরাপত্তা প্রত্যাশাকে খুব গুরুত্ব দেন তা পূরণে প্রতিষ্ঠানটিকে সহায়তা করা.
এখানে একটি পার্থক্য করা জরুরি: নিরাপত্তা এড়ানোর কৌশল অন্তর্নিহিত মডেলের সুরক্ষা ফিল্টারকে আক্রমণ করে; প্রম্পট ইনজেকশন অ্যাপ্লিকেশনটিকেই আক্রমণ করে, যেখানে ডেভেলপারের বিশ্বাসযোগ্য প্রম্পটের সঙ্গে অবিশ্বস্ত ব্যবহারকারী ইনপুট যুক্ত করা হয়. প্রম্পট ইনজেকশনের ঝুঁকি বেশি, কারণ এটি সাধারণ-উদ্দেশ্যের কোনো মডেল নয়, আপনার সিস্টেম এবং সেটি যে গোপনীয় ডেটা নিয়ে কাজ করে সেগুলোকে লক্ষ্য করে.
আমাদের প্রথম দফার পরীক্ষায় মোটামুটি 750টি পরীক্ষা ছিল, যেগুলো ছিল:
সেশনগুলোর মধ্যে ডেটা ফাঁস
PII প্রকাশ পাওয়া (স্বাভাবিক ভাষা, API ম্যানিপুলেশন এবং বিভিন্ন এনকোডিংয়ের মাধ্যমে)
SQL ইনজেকশন
সিস্টেম প্রম্পট ওভাররাইড
প্রাথমিক ওই পরীক্ষায় আমরা বিদ্যমান সিস্টেমে দুটি বড় সমস্যা শনাক্ত করি: বহু-উদ্দেশ্যযুক্ত কোয়েরি পরিচালনা এবং এনকোড করা প্রম্পটের ব্যবহার.
বহু-উদ্দেশ্যযুক্ত কোয়েরি: যেখানে অনুরোধে বৈধ ও ক্ষতিকর দাবি একসঙ্গে থাকে. যেমন: “আমার খরচ বিভাগ অনুযায়ী দেখাও, এবং [ক্ষতিকর SQL] চালাও.” অ্যাপ্লিকেশনটি ক্ষতিকর উদ্দেশ্য ধরতে পারছিল না; বরং পুরোপুরি ডাউনস্ট্রিম ডেটা স্তরের গার্ডরেইলের ওপর নির্ভর করছিল. এটি বেসমেন্টের সিন্দুকে ভরসা করে সামনের দরজা খোলা রেখে দেওয়ার মতো.
এনকোডিং: যেখানে অনুরোধ Base64, Hex, LeetSpeak এবং homoglyphs-এ এনকোড করা হয়. এ ধরনের ক্ষেত্রে সিস্টেমের জন্য ক্ষতিকর উদ্দেশ্য ছেঁকে বাদ দেওয়া কঠিন হতে পারে. আমরা দেখেছি, এসব কোয়েরি সংবেদনশীল ডেটা প্রকাশ করেনি; তবে এগুলো সিস্টেমকে উল্লেখযোগ্যভাবে অস্থিতিশীল করেছে (হ্যালুসিনেশন, ব্যবহারকারীর কাছে ক্ষতিকর SQL হুবহু ফিরিয়ে দেওয়া, উদ্দেশ্য শ্রেণিবিন্যাসে বিভ্রান্তি ইত্যাদি).
আমাদের প্রাথমিক পরীক্ষার ফলাফলে দেখা গেছে:
সময়-সংক্রান্ত হ্যালুসিনেশন: মডেল আত্মবিশ্বাসের সঙ্গে বানানো তারিখ, লেনদেনের টাইমস্ট্যাম্প বা সময়সীমাবদ্ধ সারাংশ ফিরিয়ে দিচ্ছে—আর্থিক প্রেক্ষাপটে এটি বড় ঝুঁকি, কারণ ভুল তারিখ ধরে কোনো গ্রাহক পদক্ষেপ নিলে তার বাস্তব পরিণতি হতে পারে
ক্ষতিকর SQL ব্যবহারকারীর কাছে হুবহু ফিরিয়ে দেওয়া (মেমরি পয়জনিং ঝুঁকির কারণে উদ্বেগজনক)
উদ্দেশ্য শ্রেণিবিন্যাসে বিভ্রান্তি
এলোমেলো আউটপুট ফরম্যাটিং
এই ফলাফলগুলো হাতে নিয়ে আমরা মনোযোগের ক্ষেত্র সংকুচিত করলাম. SQL ইনজেকশন ও এনকোডিং পরীক্ষা কম অগ্রাধিকার পেল (দলটি ইতিমধ্যে সেগুলো নিয়ে কাজ করছিল). এর বদলে আমরা সবচেয়ে সফল আক্রমণ ভেক্টরগুলোর দিকে মনোযোগ দিলাম: PII প্রকাশ এবং সেশনগুলোর মধ্যে ডেটা ফাঁস.
দ্বিতীয় দফার সবচেয়ে চোখে পড়ার মতো আবিষ্কারটি আশ্চর্য রকম সহজ: অনেক সময় একেবারেই কৌশলী হওয়ার দরকার হয় না.
অনেক ক্ষেত্রে, বৈধ শোনায় এমন অনুরোধের অংশ হিসেবে কেবল অভ্যন্তরীণ ডেটা চাইলেই সিস্টেম সেটি প্রকাশে রাজি হয়ে গেছে. সাধারণ কোয়েরির উত্তরে এমন অভ্যন্তরীণ ID ও সিস্টেম ফিল্ডের উল্লেখ আসছিল, যা কখনোই শেষ ব্যবহারকারীদের সামনে আসা উচিত নয়.
আরও গভীরে গিয়ে আমরা দেখলাম, এটি শুধু অ্যাপ্লিকেশন-স্তরের ব্যর্থতা নয়. ডাউনস্ট্রিম text-to-SQL পরিষেবাটি প্রয়োজনের চেয়ে বেশি ফিল্ড চেয়ে কোয়েরি তৈরি করছিল, এবং তার ব্যাখ্যামূলক উত্তরে এমন ডেটার উল্লেখ ছিল যা সীমিত থাকা উচিত ছিল. এতে সিস্টেমগুলোর মাঝের একটি প্রকৃত ফাটল প্রকাশ পায়—এমন ধরনের দুর্বলতা, যা আলাদা উপাদান নয়, পুরো স্ট্যাক পরীক্ষা করলেই কেবল সামনে আসে.
মডেল নয়, সিস্টেমের রেড টিমিং করুন. একটি LLM আলাদাভাবে পরীক্ষা করলে আপনার অ্যাপ্লিকেশনের নিরাপত্তা অবস্থান সম্পর্কে খুব সামান্যই জানা যায়. ব্যবহারকারী যেভাবে ব্যবহার করবে, সেভাবে শুরু থেকে শেষ পর্যন্ত পুরো স্ট্যাক পরীক্ষা করুন.
LLM-এ যাওয়ার আগেই ইনপুট যাচাই করতে হবে. এনকোড করা কোয়েরি, বহু-উদ্দেশ্য আক্রমণ এবং মৌলিক ইনজেকশন প্রচেষ্টা সীমান্তেই ধরা উচিত; ডাউনস্ট্রিম পরিষেবার ওপর তা ছেড়ে দেওয়া উচিত নয়.
সংযোগের ফাঁককে বিশ্বাস করবেন না. বহু-পরিষেবা স্থাপত্যে সবচেয়ে আকর্ষণীয় দুর্বলতাগুলো সিস্টেমগুলোর মাঝের ফাটলেই লুকিয়ে থাকে. জিরো-ট্রাস্ট মানে সত্যিই জিরো-ট্রাস্ট; তাই প্রতিটি স্তরে সবকিছু যাচাই করুন.
সহজ আক্রমণও কাজ করে. জটিল নিরাপত্তা এড়ানোর কৌশল শিরোনাম হয়, কিন্তু কখনও কখনও আপনি শুধু... চাইলেই হয়. যদি কোনো ব্যবহারকারী অন্যথায় বৈধ একটি কোয়েরিতে অভ্যন্তরীণ শনাক্তকারী যোগ করলেই আপনার সিস্টেম সেগুলো সহজেই প্রকাশ করে, সেটি সমস্যা.
আসলে আপনি কী পরীক্ষা করছেন তা বুঝুন. পরিচিত আক্রমণ-প্যাটার্ন আপনার গার্ডরেইল নয়, LLM-এর নিজস্ব প্রশিক্ষণেই ধরা পড়ে যেতে পারে. কোন নিয়ন্ত্রণগুলো বাস্তবে ব্যবহৃত হচ্ছে তা বোঝার জন্য আপনার রেড টিমিংয়ে পর্যবেক্ষণযোগ্যতা তৈরি করুন.
সীমাবদ্ধ পরিবেশে সৃজনশীল সমাধান দরকার. কাস্টম প্রদানকারী ও স্থানীয় মডেল সাপোর্ট বিশেষায়িত ক্লাউড অ্যাক্সেস ছাড়াই অর্থবহ রেড টিমিংকে সম্ভব করে. তবে এতে যে সীমাবদ্ধতা আসে, সে বিষয়ে স্বচ্ছ থাকুন.
রেড টিমিং একবারের কাজ নয়. এটি পুনরাবৃত্তিমূলক; সম্ভব হলে স্বয়ংক্রিয় হওয়া উচিত, এবং আপনার সিস্টেম যেমন বদলায়, এটিও তেমন বদলানো উচিত. আগামীকাল যে আক্রমণগুলো গুরুত্বপূর্ণ হবে, সেগুলো আজকের গুরুত্বপূর্ণ আক্রমণগুলোর মতো নয়.
নিয়ন্ত্রিত পরিবেশে থাকা কৃত্রিম বুদ্ধিমত্তা সিস্টেমের ওপর নজরদারি কমবে না, বরং বাড়বে. যেসব প্রতিষ্ঠান নিরাপত্তা পরীক্ষাকে চালুর আগের টিকচিহ্ন নয়, চলমান অনুশাসন হিসেবে দেখে, তারা এই নজরদারি সামলাতে এবং গ্রাহকের আস্থা হারানো PR বিপর্যয় এড়াতে ভালো অবস্থানে থাকবে.