আপনার এআই-চালিত অ্যাসিস্ট্যান্ট প্রায় ৯৯% সময় তার নির্দেশাবলী মেনে চলে, কিন্তু সেই বাকি ১% অংশটিই আক্রমণকারীদের জন্য সুযোগ তৈরি করে। একটি সুপরিকল্পিত প্রম্পট প্রদানের মাধ্যমে, একজন ক্ষতিকারক ব্যবহারকারী মডেলটিকে এমন সব ফাংশন কল করতে বাধ্য করতে পারে যা তার করা উচিত নয়, যার ফলে তথ্য চুরি বা বিশেষাধিকারপ্রাপ্ত (privileged) কাজ সম্পন্ন করা সম্ভব হয়। এর সমাধান আরও নম্রভাবে কথা বলা নয়—বরং এই ত্রুটিটিকে একটি অথরাইজেশন (authorization) সমস্যা হিসেবে দেখা এবং মডেলের নাগালের বাইরে থেকে বিপজ্জনক টুলগুলো সরিয়ে ফেলা।
কেন প্রম্পট ইনজেকশন কেবল শব্দ চয়ন বা ভাষাগত সমস্যা নয়
ডেভেলপাররা প্রায়ই বড় হাতের অক্ষরে সতর্কতা (all-caps warnings), নম্বরযুক্ত নিয়ম, বা "অ্যাডমিন ফাংশন কল করবেন না" এর মতো শর্ত দিয়ে এজেন্টগুলোকে সুরক্ষিত করার চেষ্টা করেন। এই প্রতিরক্ষা ব্যবস্থাগুলো ধরে নেয় যে মডেলটি "X করবেন না" এমন একটি বাক্য মেনে চলবে। বাস্তবে, অনুরোধটি নতুনভাবে সাজিয়ে, ভিন্ন কোনো চরিত্র (persona) ধারণ করে, অথবা কেবল অতিরিক্ত প্রেক্ষাপট (context) যোগ করে মডেলটিকে নির্দেশটি উপেক্ষা করতে প্ররোচিত করা যেতে পারে। ইংরেজি ভাষার সীমানা পরিবর্তনযোগ্য; কিন্তু আক্রমণকারীর প্রম্পট সীমাহীন এবং এটি পরীক্ষা করতে কোনো খরচ নেই।
আসল দুর্বলতা লুকিয়ে আছে এজেন্ট যে টুল লিস্ট বা সরঞ্জামের তালিকা পায় তার মধ্যে। যখন প্রম্পট স্কিমাতে এমন একটি ফাংশন থাকে যা অ্যাডমিন অধিকার প্রদান করে, তখন মডেলটির কাছে সেই ক্ষমতার একটি ম্যাপ বা পথ তৈরি হয়ে যায়। এমনকি প্রম্পটে যদি বলা হয় "গ্রাহকদের জন্য এটি ব্যবহার করবেন না", তবুও মডেলটিকে সেটি কল করার জন্য প্ররোচিত করা যেতে পারে কারণ ফাংশনটি তার এক্সিকিউশন এনভায়রনমেন্টে বিদ্যমান। তাই সমস্যাটি হলো একটি অথরাইজেশন গ্যাপ বা অনুমোদনের ঘাটতি: সিস্টেমটি এমন একজন কলারের কাছে বিশেষাধিকারপ্রাপ্ত সক্ষমতা প্রকাশ করছে যার সেগুলো ব্যবহারের কোনো অধিকার নেই।
এক্সপোজার বা প্রকাশ সীমিত করার মাধ্যমে এজেন্টগুলোকে সুরক্ষিত করা
এই ঘাটতি পূরণ করার সবচেয়ে সহজ উপায় হলো মডেলটিকে এমন সব টুলের অ্যাক্সেস দেওয়া বন্ধ করা যা ব্যবহার করার জন্য সে অনুমোদিত নয়। টুল লিস্টটিকে একটি API কী-এর মতো ভাবুন: যদি কী (key) না থাকে, তবে কলটি সম্পন্ন হতে পারে না। বর্তমান প্রেক্ষাপটে নেই এমন কোনো ফাংশনকে কোনো চতুর শব্দ দিয়ে তলব করা সম্ভব নয়।
ভুল পদ্ধতি
Prompt: “You are an assistant. Do not use the adminDeleteUser function for regular customers.”
মডেলটি তার টুলবক্সে এখনও adminDeleteUser দেখতে পায় এবং এটিকে কল করার জন্য প্রতারিত হতে পারে।
সঠিক পদ্ধতি
Prompt schema for a regular customer: { “functions”: [ “searchCatalog”, “placeOrder” ] }
adminDeleteUser কখনোই সামনে আসে না, তাই মডেলটির এটি কল করার কোনো পথ থাকে না।
ডেভেলপারদের জন্য তিনটি ব্যবহারিক নিয়ম
- প্রতিটি অনুরোধের জন্য আলাদা টুল লিস্ট তৈরি করুন – অথেন্টিকেটেড কলারের অনুমতির ওপর ভিত্তি করে ডাইনামিকভাবে ফাংশন ক্যাটালগ তৈরি করুন। একজন গ্রাহক কেবল তাদের প্রয়োজনীয় ফাংশনগুলোই দেখতে পাবেন; একজন অ্যাডমিন পুরো সেটটি দেখতে পাবেন।
- ফেইল ক্লোজড (Fail closed) – যদি ব্যবহারকারীর পরিচয় যাচাই করা না যায়, তবে সাধারণ "সব টুল উপলব্ধ" এর পরিবর্তে একটি খালি তালিকা (empty list) প্রদান করুন। এটি নিশ্চিত করে যে কোনো অননুমোদিত অনুরোধ কখনোই অপ্রত্যাশিত ক্ষমতা অর্জন করতে পারে না।
- শেয়ার্ড স্টেট (Shared state) এড়িয়ে চলুন – টুল ডেফিনিশন ক্যাশ করার সময়, কখনোই কোনো শেয়ার্ড অবজেক্টে ব্যবহারকারী-নির্দিষ্ট ডেটা লিখবেন না। কপি-অন-রাইট (copy-on-write) বা প্রতিটি সেশনের জন্য আলাদা কপি ব্যবহার করুন যাতে একজন ব্যবহারকারীর অনুমতি অন্য ব্যবহারকারীর অনুরোধে মিশে না যায়।
যদি একজন সাধারণ ব্যবহারকারীর কাছে উপস্থাপিত স্কিমাটি একজন অ্যাডমিনের দেখানো স্কিমার মতোই দেখতে হয়, তবে নিরাপত্তা সীমানাটি এখনও প্রম্পট টেক্সটের ওপর নির্ভরশীল, আর প্রম্পট কোনো নির্ভরযোগ্য নিরাপত্তা ব্যবস্থা নয়।
কী আমাদের এখানে নিয়ে এল
প্রম্পট ইনজেকশন তখনই সামনে আসে যখন ডেভেলপাররা লার্জ ল্যাঙ্গুয়েজ মডেলগুলোকে (LLMs) এমন প্রোডাকশন ওয়ার্কফ্লোতে যুক্ত করতে শুরু করেন যেখানে মডেলটিকে এক্সটার্নাল API কল করা, কোড চালানো বা ডেটাবেস পরিবর্তন করার প্রয়োজন হয়। মডেলের "রিজনিং" বা যুক্তি প্রদান একটি প্রম্পট দ্বারা পরিচালিত হয় যার মধ্যে উপলব্ধ টুলের একটি তালিকাও অন্তর্ভুক্ত থাকে। প্রাথমিক প্রোটোটাইপগুলো ধরে নিয়েছিল যে মডেলটি "নন-অ্যাডমিনদের জন্য রেকর্ড মুছে ফেলবেন না" এর মতো প্রাকৃতিক ভাষার নিয়ম মেনে চলবে। আক্রমণকারীরা দ্রুত দেখিয়ে দিয়েছে যে কয়েকটি অতিরিক্ত বাক্য সেই নিয়মগুলো বাইপাস করতে পারে, যা মডেলটিকে সেই একই ডিলিট ফাংশন কল করতে প্ররোচিত করে।
কমিউনিটির প্রথম প্রতিক্রিয়া ছিল প্রম্পট ভাষা আরও কঠোর করা, "কখনও X করবেন না" এর মতো শর্ত যোগ করা, অথবা রেজেক্স (regex) ফিল্টার ব্যবহার করা যা সন্দেহজনক টোকেনগুলো সরিয়ে দেয়। এই পদক্ষেপগুলো আকস্মিক অপব্যবহার কমিয়েছিল কিন্তু একজন দৃঢ়প্রতিজ্ঞ আক্রমণকারীকে থামাতে পারেনি, যে খুব সহজেই অনুরোধটি নতুনভাবে সাজিয়ে নিতে পারে। মূল কারণটি—অর্থাৎ একজন অননুমোদিত কলারের কাছে বিশেষাধিকারপ্রাপ্ত ফাংশনগুলো প্রকাশ করা—অপরিবর্তিত থেকে গিয়েছিল।
কারা লাভবান হয়, কারা ক্ষতিগ্রস্ত হয়
যেসব এন্টারপ্রাইজ প্রতি-অনুরোধ ভিত্তিক টুল স্কোপিং (per-request tool scoping) গ্রহণ করে তারা একটি স্পষ্ট এবং কার্যকর সীমানা পায়। তাদের এজেন্টগুলো বড় পরিসরে মোতায়েন করা সম্ভব যাতে একটি মাত্র ত্রুটিপূর্ণ প্রম্পট অ্যাডমিন ক্ষমতা উন্মোচন করে ফেলবে এমন ভয় না থাকে। কমপ্লায়েন্স টিমগুলো অডিট ট্রেইলকেও পছন্দ করে: মডেলের কাছে পাঠানো ফাংশনগুলোর তালিকা একটি সুনির্দিষ্ট প্রমাণ যা লগ করা এবং পর্যালোচনা করা সম্ভব।
যেসব ডেভেলপার কেবল প্রম্পট-ভিত্তিক সুরক্ষার ওপর নির্ভর করেন তারা ক্রমাগত একটি পরিবর্তনশীল লক্ষ্যের মোকাবিলা করতে থাকেন। তাদের এজেন্টগুলো টেস্টিংয়ের সময় কার্যকর মনে হতে পারে কিন্তু বাস্তবে সেগুলো আক্রান্ত হতে পারে, যা ডেটা লঙ্ঘন (data breach), অননুমোদিত লেনদেন বা কমপ্লায়েন্স লঙ্ঘনের দিকে নিয়ে যেতে পারে। একটি নিরাপত্তা লঙ্ঘনের খরচ একটি ডাইনামিক টুল লিস্ট তৈরির প্রচেষ্টার চেয়ে অনেক বেশি।
পাল্টা যুক্তি: “আরও উন্নত প্রম্পটই যথেষ্ট”
কেউ কেউ যুক্তি দেন যে পর্যাপ্ত ইন্সট্রাকশন ইঞ্জিনিয়ারিং—লেয়ার্ড প্রম্পট, সিস্টেম মেসেজ এবং রেইনফোর্সমেন্ট লার্নিং ফ্রম হিউম্যান ফিডব্যাক—এর মাধ্যমে মডেলটিকে “do not” বা “করবেন না” সংক্রান্ত শর্তগুলো মেনে চলতে বাধ্য করা সম্ভব। বাস্তবতা হলো ল্যাঙ্গুয়েজ মডেলগুলো হলো প্রোবাবিলিস্টিক জেনারেটর; তারা সবচেয়ে সম্ভাব্য পরবর্তী অংশটি বিবেচনা করে, কোনো কঠোর নিরাপত্তা নিয়ম নয়। এমনকি সূক্ষ্মভাবে টিউন করা গার্ডরেইল থাকা সত্ত্বেও, নতুন কোনো শব্দবিন্যাস বা ফ্রেজিং এর মাধ্যমে নিরাপত্তা ভেঙে ফেলা সম্ভব, বিশেষ করে যখন আক্রমণকারী কোনো খরচ ছাড়াই বারবার চেষ্টা করতে পারে। গার্ডরেইল নয়েজ কমানোর জন্য কার্যকর হলেও, এটিকে নিরাপত্তার একমাত্র স্তর হিসেবে বিবেচনা করা উচিত নয়।
পরবর্তীতে যা লক্ষ্য রাখা উচিত
- এমন ফ্রেমওয়ার্ক যা টুল স্কোপিং-কে ফার্স্ট-ক্লাস API হিসেবে প্রকাশ করে – নতুন লাইব্রেরি আসার সম্ভাবনা রয়েছে যা আপনাকে ব্যবহারকারী অনুযায়ী সক্ষমতা ঘোষণা করতে এবং প্রম্পট তৈরির আগেই স্বয়ংক্রিয়ভাবে ফাংশন লিস্ট থেকে অপ্রয়োজনীয় অংশ বাদ দিতে সাহায্য করবে।
- মানসম্মত “ফাংশন ম্যানিফেস্ট” – ইন্ডাস্ট্রি গ্রুপগুলো এমন একটি JSON স্কিমা সংজ্ঞায়িত করতে পারে যা পাবলিক এবং প্রিভিলেজড ফাংশনগুলোকে আলাদা করবে, ফলে রিকোয়েস্ট-নির্দিষ্ট ম্যানিফেস্ট তৈরি করা সহজ হবে।
- রানটাইম এনফোর্সমেন্ট – কিছু প্ল্যাটফর্ম স্যান্ডবক্সড এক্সিকিউশন নিয়ে পরীক্ষা-নিরীক্ষা করছে যা প্রম্পট স্কোপিংয়ের বাইরে একটি দ্বিতীয় স্তর হিসেবে কাজ করে এবং কলারের টোকেনটি কল করা ফাংশনের সাথে মিলিয়ে দেখে।
মূল কথাটি পরিষ্কার: প্রম্পট ইনজেকশনকে একটি অথরাইজেশন ত্রুটি হিসেবে বিবেচনা করুন। মডেলের টুলবক্স থেকে অননুমোদিত টুলগুলো সরিয়ে দেওয়ার মাধ্যমে, আপনি সেই অ্যাটাক সারফেসটি নির্মূল করতে পারেন যা একটি চতুরভাবে সাজানো প্রম্পট ব্যবহার করে কাজে লাগানো হয়। প্রম্পট আচরণ নির্দেশ করতে পারে; কিন্তু এটি সঠিক অ্যাক্সেস কন্ট্রোলের বিকল্প হতে পারে না।