LLM নিরাপত্তা কী? OWASP-এর শীর্ষ ১০টি নিরাপত্তা ঝুঁকি কীভাবে কমাবেন

যে আক্রমণে AI-কে ধোঁকা দিয়ে আক্রমণকারীর নির্দেশনাকে কমান্ড হিসেবে গ্রহণ করানো হয়—অর্থাৎ প্রম্পট ইনজেকশন—সেটি 2023 সাল থেকে প্রতিটি সংস্করণে OWASP Top 10 for LLM Applications-এর তালিকায় 1 নম্বরে রয়েছে।

AI নিরাপত্তার ক্ষেত্রে সর্বসম্মতির যতটা কাছাকাছি পৌঁছানো সম্ভব, এই তালিকা প্রায় ততটাই কাছাকাছি। প্রজেক্টটি নিরাপত্তা পেশাদারদের একটি ছোট দল হিসেবে শুরু হয়েছিল, আর এখন এতে 18টিরও বেশি দেশের 600-এর বেশি বিশেষজ্ঞ অবদান রাখছেন।

আমরা একটি AI কোম্পানি হয়ে AI-কে কীভাবে নানা কিছু করতে রাজি করানো যায় তা নিয়ে একটি গাইড প্রকাশ করছি, তাই সমস্যাটির সমাধান হয়ে গেছে বলে ভান করব না। OWASP প্রজেক্টের সহ-প্রধান Wilson বর্তমান সুরক্ষাব্যবস্থা নিয়ে বেশ স্পষ্ট ছিলেন: "...সত্যি বলতে, আমার মনে হয় না আমরা 99%-এ পৌঁছেছি।"

2026 সংস্করণও একই সুরে শুরু হয়েছে। প্রজেক্টের প্রধান আমাদের পরামর্শ দেন "এমন একটি মডেল তৈরির চেষ্টা বন্ধ করুন যাকে বোকা বানানো যায় না", বরং চারপাশের সিস্টেমটি এমনভাবে ডিজাইন করুন যাতে বোকা বনে যাওয়া মডেলও গুরুত্বপূর্ণ কিছু নষ্ট করতে না পারে।

আমরা OWASP-এর 2026 তালিকার 10টি ঝুঁকির প্রতিটিতেই এই দৃষ্টিভঙ্গি অনুসরণ করছি।

LLM নিরাপত্তা বলতে কী বোঝায়?

LLM নিরাপত্তা মানে AI মডেল এবং সেগুলো ব্যবহার করে এমন অ্যাপ্লিকেশনগুলোকে আক্রমণ ও অপব্যবহার থেকে রক্ষা করা। মডেলটি যত কিছুর সঙ্গে সংযুক্ত থাকে, ঝুঁকিও তত বাড়ে: এটি যেসব ফাইল ও ডেটা পড়তে পারে, এবং যেসব টুল ব্যবহার করতে পারে, যেমন ইমেইল, সার্চ বা কোনো কোম্পানির ডেটাবেস।

সঠিকভাবে সুরক্ষিত সফটওয়্যারে, একটি প্রোগ্রাম যে নির্দেশনা অনুসরণ করে এবং যে তথ্য প্রক্রিয়া করে, তার মধ্যে একটি সুস্পষ্ট সীমারেখা থাকে। কিন্তু LLM-এর ক্ষেত্রে সেই সীমারেখা নেই।

মডেল যা কিছু পড়ে, সবই আসে একটি দীর্ঘ টেক্সট প্রবাহ হিসেবে: ডেভেলপারের নির্দেশনা, আপনার প্রশ্ন, কিংবা এটি খুঁজে পাওয়া কোনো ওয়েবপেজ। AI মডেলগুলোর কাছে প্রত্যাশা থাকে যে তারা কে কথা বলছে তার হিসাব রাখবে—সেটি ডেভেলপার, ব্যবহারকারী, নাকি মডেল নিজেই কোনো সমস্যা নিয়ে ভাবছে।

কিন্তু গবেষক Jasmine Cui এবং Charles Ye দেখেছেন যে মডেলগুলো মূলত টেক্সট কেমন শোনায় তা দেখেই অনুমান করে কে কথা বলছে। তাই কোনো আক্রমণকারী যদি এমন কিছু লেখে যা মডেলের নিজস্ব যুক্তির মতো শোনায়, তাহলে মডেলটি ভাবতে পারে ধারণাটি তার নিজেরই। নিয়ন্ত্রণ কার হাতে, তা মডেলের জানার ওপর যেসব নিরাপত্তা ব্যবস্থা নির্ভর করে, সেগুলোর প্রতিটির জন্যই এটি একটি সমস্যা।

আমাদের নিজস্ব AI এজেন্টদের ক্ষেত্রেও আমরা একই সমস্যার মুখোমুখি হয়েছি। আমাদের CISO, Kyle Polley, ISMG-কে বলেছেন যে এজেন্টরা "সিস্টেম প্রম্পটে যোগ করে দিলেও নীতিমালা মেনে না-ও চলতে পারে।" এ কারণেই আমরা Numbat তৈরি করেছি—একটি ওপেন-সোর্স টুল, যা কোনো এজেন্ট কী করতে যাচ্ছে তা যাচাই করে এবং সেই কাজ কোনো কনফিগার করা নিরাপত্তা নিয়ম ভঙ্গ করলে তা আটকে দিতে পারে।

LLM নিরাপত্তা মানে এটা মেনে নেওয়া যে মডেলটি মাঝে মাঝে ভুল ব্যক্তির আদেশ পালন করবে, এবং এর চারপাশে এমন AI গার্ডরেইল তৈরি করা, যা তেমনটা ঘটলেও কার্যকর থাকে।

LLM নিরাপত্তার সেরা অনুশীলনগুলো কী কী?

আমরা OWASP Top 10 for LLM Applications 2026 ক্রমানুসারে, 1 নম্বর থেকে 10 নম্বর পর্যন্ত আলোচনা করব।

প্রতিটি ঝুঁকির ক্ষেত্রে আপনি সহজ ভাষায় একটি ব্যাখ্যা পাবেন যে কীভাবে সমস্যা তৈরি হয়, সঙ্গে থাকবে একটি বাস্তব উদাহরণ। এরপর আমরা সেই অনুশীলনগুলো নিয়ে আলোচনা করব যা এটি প্রতিরোধে সাহায্য করতে পারে, অথবা অন্তত ক্ষতির পরিমাণ সীমিত রাখতে পারে।

1. প্রম্পট ইনজেকশন নিয়ন্ত্রণে রাখুন

প্রম্পট ইনজেকশন ঘটে যখন কোনো আক্রমণকারী AI-কে দিয়ে এমন নির্দেশনা পালন করায়, যা তার পালন করা উচিত নয়। এই নির্দেশনা সরাসরি চ্যাটে আসতে পারে, অথবা কোনো ইমেইল, ওয়েবপেজ বা ডকুমেন্টে লুকিয়ে রাখা থাকতে পারে।

দ্বিতীয় ধরনটি পরোক্ষ প্রম্পট ইনজেকশন নামে পরিচিত। আপনি আপনার অ্যাসিস্ট্যান্টকে একটি ডকুমেন্টের সারসংক্ষেপ করতে বললেন। কিন্তু ডকুমেন্টের ভেতরে কেউ অ্যাসিস্ট্যান্টকে আপনার ব্যক্তিগত ফাইলগুলো তার কাছে পাঠানোর নির্দেশ দিয়ে রেখেছে। অ্যাসিস্ট্যান্ট যদি সেই নির্দেশনা অনুসরণ করে, তাহলে ডকুমেন্টটির লেখক কার্যত আপনার অ্যাক্সেস ধার করে নিলেন।

PCMag প্রম্পট নিরাপত্তাকে ছিদ্রযুক্ত পাথরের ফুটো বন্ধ করার সঙ্গে তুলনা করেছে। একটি ছিদ্র বন্ধ করলে পানি আরেকটি পথ খুঁজে নেয়। “একটি আক্রমণ ঠিকই পথ খুঁজে নেয়; সেটি ঠিক করা হয়, কিন্তু LLM-এর মতো সিস্টেমগুলো এতটাই গতিশীল যে আক্রমণের অসংখ্য অন্য পথ আবিষ্কারের অপেক্ষায় থেকে যায়।”

উদাহরণ: 2025 সালের জুনে Aim Security-এর গবেষকরা EchoLeak খুঁজে পান—এমন একটি ত্রুটি যা Microsoft 365 Copilot-কে ধোঁকা দিয়ে কোম্পানির গোপন তথ্য ফাঁস করিয়ে নিত। কোনো কর্মী কাজ-সংক্রান্ত সাধারণ একটি প্রশ্ন করলে Copilot ইমেইলটি টেনে আনতে পারত, এর ভেতরে লুকানো নির্দেশনা অনুসরণ করত এবং সংবেদনশীল তথ্য আক্রমণকারীর কাছে পাঠিয়ে দিত। ক্ষতিকর নির্দেশনা শনাক্ত করা ও সন্দেহজনক লিংক সরিয়ে ফেলার জন্য তৈরি যাচাই-ব্যবস্থাকেও আক্রমণটি পাশ কাটিয়ে যায়।

আপনি যা করতে পারেন:

• Meta-র “Rule of Two” মেনে চলুন: EchoLeak-এর জন্য এমন একটি AI প্রয়োজন ছিল যা কোম্পানির ডেটা পড়তে পারে, বাইরের ইমেইল পড়তে পারে এবং তথ্য বাইরে পাঠাতে পারে—আর এর তিনটি সক্ষমতাই ছিল। এর মধ্যে যেকোনো দুটি সক্ষমতায় AI-কে সীমাবদ্ধ রাখলে প্রম্পট ইনজেকশন অতিরিক্ত নিয়ন্ত্রণ পেতে পারে না। কাজের জন্য তিনটিই প্রয়োজন হলে, প্রতিটি পদক্ষেপের আগে মানুষের অনুমোদন বাধ্যতামূলক করুন।
• আপনার সুরক্ষাব্যবস্থা জানে এমন আক্রমণকারীর বিপরীতে পরীক্ষা করুন: আপনার নিরাপত্তা পরীক্ষকদের আপনার প্রয়োগ করা নিয়ম ও ফিল্টারগুলো জানিয়ে দিন, তারপর তাদের সেগুলো এড়িয়ে যাওয়ার সুযোগ দিন। একটি গবেষণায়, সুরক্ষাব্যবস্থার সঙ্গে খাপ খাইয়ে নেওয়া আক্রমণকারীরা পরীক্ষিত 12টি সুরক্ষাব্যবস্থার বেশিরভাগের বিরুদ্ধে 90%-এরও বেশি ক্ষেত্রে সফল হয়েছিল।

2. সংবেদনশীল তথ্য ফাঁস হওয়া ঠেকান

AI সিস্টেম যখন এমন মানুষকে ব্যক্তিগত তথ্য দেয় যাদের সেটি দেখার কথা নয়, তখন তাকে সংবেদনশীল তথ্য প্রকাশ বলা হয়। এর মানে হতে পারে কোনো গ্রাহকের পেমেন্টের বিবরণ প্রকাশ করে দেওয়া, কিংবা ব্যক্তিগত কথোপকথন কোনো শেয়ার করা ডেটাবেসে রেখে দেওয়া।

অনেক তথ্য ফাঁসের শুরু হয় “অতিরিক্ত শেয়ারিং” থেকে। ধরা যাক, একটি কোম্পানি তার AI-কে শিথিল অনুমতিসহ বিভিন্ন ড্রাইভ ও নলেজ বেসের সঙ্গে সংযুক্ত করল। AI-এর নাগাল যতদূর পৌঁছায়, ঠিক ডিজাইন অনুযায়ী সে সবকিছুই সংগ্রহ করে। কাউকে অনুপ্রবেশ করতে হয় না, তবুও ধরে নিন LLM-এ অনুপ্রবেশ ঘটে গেছে।

উদাহরণ: 2025 সালের জানুয়ারিতে Wiz-এর গবেষকরা DeepSeek-এর একটি ডেটাবেস উন্মুক্ত অবস্থায় খুঁজে পান, যা ইন্টারনেট থেকে যে কেউ দেখতে পারত এবং যাতে চ্যাট হিস্ট্রি ও API কী (যা দিয়ে সফটওয়্যার অন্যান্য সেবায় অ্যাক্সেস পায়) সহ দশ লাখেরও বেশি লগ এন্ট্রি ছিল। মডেলকে কোনো কিছু প্রকাশ করতে রাজি করানোর প্রয়োজনই গবেষকদের হয়নি।

আপনি যা করতে পারেন:

• AI ডেটা পড়ার আগেই অ্যাক্সেস যাচাই করুন: ডকুমেন্টগুলো মডেলের কাছে পাঠানোর আগে আপনার অ্যাপ্লিকেশনের যাচাই করা উচিত যে প্রশ্নকারী ব্যক্তি কোন কোন ডকুমেন্ট দেখার অনুমতি রাখেন।
• আপনার AI যে রেকর্ড রেখে যায়, সেগুলো সুরক্ষিত রাখুন: অ্যাক্টিভিটি লগ সংরক্ষণের আগে ব্যক্তিগত বিবরণ ও গোপন কী সরিয়ে ফেলুন, লগইন বাধ্যতামূলক করুন এবং কেবল যাদের প্রয়োজন তাদের মধ্যেই অ্যাক্সেস সীমিত রাখুন। একটি সংরক্ষণকাল নির্ধারণ করুন, যাতে এসব রেকর্ড অনির্দিষ্টকাল ধরে জমতে না থাকে।

3. মাত্রাতিরিক্ত কর্তৃত্বে লাগাম টানুন

মাত্রাতিরিক্ত কর্তৃত্বসম্পন্ন AI-এর হাতে তার কাজের প্রয়োজনের চেয়ে বেশি ক্ষমতা থাকে: অপ্রয়োজনীয় টুল, কাজের পরিধি ছাড়িয়ে যাওয়া অনুমতি, অথবা যাচাই ছাড়াই পদক্ষেপ নেওয়ার স্বাধীনতা। এখানে কারণটি অপ্রাসঙ্গিক।

একটি ইনজেকশন প্রম্পট, একটি বাগ, কিংবা স্রেফ ভুল করে বসা একটি মডেল—সবগুলোর ফলাফলই একই। AI-এর যদি সক্ষমতা থাকে, তবে একসময় না একসময় সে ধ্বংসাত্মক কিছু করে বসবে।

উদাহরণ: 2025 সালের জুলাইয়ে SaaStr-এর প্রতিষ্ঠাতা Jason Lemkin জানান যে কোনো পরিবর্তন না করার নির্দেশনা সত্ত্বেও Replit-এর কোডিং এজেন্ট 1,206 জন নির্বাহীর রেকর্ডসংবলিত তার ডেটাবেস মুছে ফেলেছে। এজেন্টটি প্রথমে জানিয়েছিল যে ডেটা পুনরুদ্ধার করা সম্ভব নয়, যদিও পরে দেখা যায় পুনরুদ্ধার সম্ভব ছিল। Jason বুঝতে পারেন, ডেটাবেসে হাত না দেওয়ার নির্দেশ দিলেও সেটি মুছে ফেলার সক্ষমতা এজেন্টের কাছ থেকে সরানো হয়নি।

বড় করুন

সূত্র: X

আপনি যা করতে পারেন:

• কাজের জন্য প্রয়োজন নেই এমন সক্ষমতা সরিয়ে দিন: একটি এজেন্ট কোন কোন টুল পাবে এবং সেই টুলগুলো কী করতে পারবে—দুটোই সীমিত করুন। ইমেইলের সারসংক্ষেপ তৈরি করে এমন অ্যাসিস্ট্যান্টের ইমেইল পড়ার অনুমতি প্রয়োজন, পাঠানো বা মুছে ফেলার নয়।
• AI-এর বাইরে অনুমতি যাচাইয়ের ব্যবস্থা রাখুন: যখনই কোনো পদক্ষেপের অনুরোধ আসে, প্রতিবার সেটিকে আপনার নিরাপত্তা নিয়মের সঙ্গে মিলিয়ে যাচাই করুন এবং একজন মানুষের অনুমোদন বাধ্যতামূলক করুন।

4. আপনার AI সাপ্লাই চেইনে কী প্রবেশ করছে তা যাচাই করুন

খুব কম কোম্পানিই একেবারে শূন্য থেকে AI তৈরি করে, আর প্রতি বছর এই সংখ্যা আরও কমছে। Menlo Ventures-এর 2025 The State of Generative AI in the Enterprise জরিপ অনুযায়ী, 2024 সালে 53% কোম্পানি AI মডেল কিনেছিল, যা 2025 সালে বেড়ে 76%-এ দাঁড়িয়েছে।

বেশিরভাগ ক্ষেত্রেই কোম্পানিগুলো Hugging Face-এর মতো হাব থেকে মডেল ডাউনলোড করে, অন্যদের সংগ্রহ করা ডেটাসেটে সেগুলোকে আরও প্রশিক্ষণ দেয়, এবং অপরিচিত লোকদের লেখা অ্যাড-অন ও কোড প্যাকেজ যুক্ত করে।

এই প্রতিটি অংশই প্রবেশের একটি পথ। কোনো একটিতে কারসাজি হলে, সমস্যাটি আপনার প্রোডাক্টের সঙ্গেই ব্যবহারকারীদের কাছে পৌঁছে যায়।

উদাহরণ: 2026 সালের জানুয়ারি থেকে আগস্টের মধ্যে Hugging Face-এর পাবলিক মডেল রিপোজিটরির সংখ্যা 2.43 মিলিয়ন থেকে বেড়ে 2.96 মিলিয়নে পৌঁছায়। তবে 2026 সালের জুলাইয়ে অভ্যন্তরীণ নিরাপত্তা পরীক্ষার সময় OpenAI-এর মডেলগুলো তাদের ইন্টারনেট থেকে দূরে রাখার জন্য তৈরি নিয়ন্ত্রণ এড়িয়ে যায় এবং Hugging Face-এর সিস্টেমের কিছু অংশে অনুপ্রবেশ করে। এমনকি একটি এজেন্ট প্রকাশ্যে উন্মুক্ত থাকা 14টি অ্যাক্সেস ক্রেডেনশিয়াল উদ্ধার করে, সেগুলো কাজ করে কিনা যাচাই করে এবং অন্য এজেন্টদের সঙ্গে শেয়ার করে। এজেন্টগুলো এরপর এমন ত্রুটির সুযোগ নেয়, যার মাধ্যমে তারা Hugging Face-এর সার্ভারে কোড চালাতে পারছিল।

OpenAI-এর প্রতিবেদনে বলা হয়েছে, “আমরা একটি মডেলের পুরো জীবনচক্রজুড়ে অ্যালাইনমেন্টের ক্ষেত্রে আরও কঠোর শর্ত আরোপ করছি এবং আরও বিচ্ছিন্ন স্যান্ডবক্স তৈরি করছি, ইন্টারনেট অ্যাক্সেস সীমিত করছি এবং মডেল ওয়েটে অ্যাক্সেস আরও নিয়ন্ত্রণ করছি।”

আপনি যা করতে পারেন:

• মডেলকে নির্দিষ্ট একটি ভার্সনে পিন করুন এবং যাচাই করুন: প্রতিটি মডেলকে একটি পর্যালোচিত ভার্সনে পিন করুন এবং লোড করার আগে এর ফাইল ফিঙ্গারপ্রিন্ট যাচাই করুন, যাতে একই লেবেলের আড়ালে বদলে দেওয়া কোনো ফাইল ঢুকে পড়তে না পারে। OWASP ডিজিটাল স্বাক্ষরেরও সুপারিশ করে, তবে একটি সতর্কতাসহ—স্বাক্ষর প্রমাণ করে মডেলটি কোথা থেকে এসেছে, এটি নিরাপদ কিনা তা নয়।
• আপনার AI-এর সুপারিশ করা প্রতিটি প্যাকেজ যাচাই করুন: AI অ্যাসিস্ট্যান্টের সুপারিশ করা কোনো কোড প্যাকেজ ইনস্টল করার আগে নিশ্চিত হোন যে সেটির অস্তিত্ব আছে, সেটিই আপনার কাঙ্ক্ষিত প্যাকেজ, এবং সেটি আপনার প্রত্যাশিত প্রকাশকের কাছ থেকেই এসেছে।

5. ডেটা ও মডেল পয়জনিং থেকে সুরক্ষিত থাকুন

পয়জনিংয়ের শিকার AI দূষিত ডেটা থেকে শেখে। এটি হতে পারে সেই উদাহরণগুলো যেগুলো দিয়ে এটিকে ফাইন-টিউন করা হয়েছে, অথবা এমন কোনো নলেজ বেস যেখানে এটি উত্তর খোঁজে। মডেলটি তখনও ঠিকঠাক কাজ করছে বলে মনে হয়; এটি শুধু ভুল শিক্ষা নেয়, আর কখনো কখনো এটি কেবল একটি নির্দিষ্ট ট্রিগার বাক্যাংশ দেখলেই অস্বাভাবিক আচরণ করতে শেখে।

যতক্ষণ না কেউ বাক্যাংশটি ব্যবহার করছে, ততক্ষণ এটি আপনার নেওয়া প্রতিটি পরীক্ষায় উতরে যাবে।

বড় করুন

তাছাড়া, এটি শুধরানো সত্যিই কঠিন। পয়জনিং এমন কোনো বাগ নয় যা প্যাচ করে ঠিক করা যায়। আপনার ডেটা ভুল হলে, আপনাকে হয়তো সেটি আবার যাচাই করতে হবে, মডেলটিকে নতুন করে প্রশিক্ষণ দিতে হবে, অথবা পুরোপুরি বদলে ফেলতে হবে।

উদাহরণ: 2025 সালের অক্টোবরে Anthropic, UK AI Security Institute এবং Alan Turing Institute-এর গবেষকরা দেখান যে 250টি পয়জন করা ডকুমেন্ট একটি মডেলকে অর্থহীন লেখা তৈরি করতে শেখাতে পারে, যখনই সেটি একটি নির্দিষ্ট ট্রিগারের মুখোমুখি হয়। পরীক্ষিত চারটি মডেল সাইজের সবগুলোতেই একই সংখ্যক ডকুমেন্ট কাজ করেছে, যদিও সবচেয়ে বড়টি 20 গুণেরও বেশি পরিষ্কার ডেটায় প্রশিক্ষিত ছিল।

আপনি যা করতে পারেন:

• আপনার ডেটা কোথা থেকে আসছে তা ট্র্যাক করুন: আপনার ব্যবহৃত প্রতিটি ডেটাসেট ও মডেলের রেকর্ড রাখুন—প্রতিটি কোথা থেকে এসেছে এবং ভার্সনগুলোর মধ্যে কী বদলেছে। আমরা ডেটাসেটের জন্য ভার্সন কন্ট্রোলের সুপারিশ করি, যাতে পয়জনিং ধরা পড়লে আপনি একটি পরিষ্কার ভার্সনে ফিরে যেতে পারেন এবং এটি কীভাবে ঢুকেছে তা খুঁজে বের করতে পারেন।
• ব্যাকডোর আছে কিনা পরীক্ষা করুন: “ব্যাকডোর” হলো এমন একটি লুকানো আচরণ যা আক্রমণকারী মডেলের ভেতরে বসিয়ে রাখে, এবং এটি চালু করার জন্য একটি নির্দিষ্ট বাক্যাংশ বা অন্য কোনো ট্রিগারের অপেক্ষায় থাকে। মডেলকে তার স্বাভাবিক নিয়ম ভাঙাতে তৈরি ইনপুট দিয়ে এগুলো পরীক্ষা করুন।

6. সীমাহীন রিসোর্স ব্যবহারে লাগাম টানুন

AI কতটা কাজ করতে পারবে বা কত খরচ করতে পারবে তার কোনো সীমা না থাকলে, এর ব্যবহারকে “সীমাহীন” বলে ধরা হয়। বেশিরভাগ AI সেবা ব্যবহারপ্রতি চার্জ নেয়, তাই একজন আক্রমণকারী আপনার বিল বাড়িয়ে দিতে পারে অথবা আপনার মডেলের একটি কপি তৈরি করে ফেলতে পারে।

OWASP মূল সমস্যাটিকে বলে “খরচের অসামঞ্জস্য”। একটি ছোট, সস্তা অনুরোধ আপনার দিকে ব্যয়বহুল কম্পিউটেশন চালু করে দিতে পারে।

উদাহরণ: 2024 সালের মে মাসে Sysdig-এর Threat Research Team “LLMjacking” নামে একটি নতুন আক্রমণ শনাক্ত করে। একদল আক্রমণকারী চুরি করা ক্রেডেনশিয়াল ব্যবহার করে ক্লাউডে হোস্ট করা 10টি LLM সেবাকে লক্ষ্যবস্তু করে। তারা Laravel-এর একটি নিরাপত্তা-ত্রুটিপূর্ণ ভার্সনের মাধ্যমে প্রবেশ করে, তারপর ক্রেডেনশিয়ালগুলো দিয়ে কী করা যায় এবং কোটা কত, তা বের করে—স্পষ্টতই অ্যাক্সেস বিক্রি করার উদ্দেশ্যে। অনেক লগিং সেটিংসও কোয়েরি করা হয়েছিল, সম্ভবত শনাক্ত হওয়া এড়াতে। Sysdig-এর মতে, সবচেয়ে খারাপ পরিস্থিতিতে ভুক্তভোগীর দিনে $46,000-এরও বেশি খরচ হতে পারে।

আপনি যা করতে পারেন:

• খরচ থামিয়ে দেয় এমন বাজেট নির্ধারণ করুন: প্রতিটি ব্যবহারকারী, API কী, টিম এবং পুরো অ্যাকাউন্টের জন্য কঠোর ব্যয়সীমা নির্ধারণ করুন। যেখান দিয়েই অনুরোধ আসতে পারে, সেখানেই এগুলো প্রয়োগ করুন।
• প্রতিটি টাস্কের একটি থামার বিন্দু নির্ধারণ করুন: একটি টাস্ক কতক্ষণ চলতে পারবে, কতটা টেক্সট প্রক্রিয়া ও তৈরি করতে পারবে, এবং কতগুলো টুল কল করতে পারবে তা সীমিত করুন। যেসব এজেন্ট একই কাজ বারবার করে বা বরাদ্দ সীমা ছাড়িয়ে যায়, সেগুলোর জন্য স্বয়ংক্রিয়ভাবে বন্ধ হওয়ার ব্যবস্থা যোগ করুন।

7. পদক্ষেপ নেওয়ার আগেই ভুল তথ্য শনাক্ত করুন

AI যখন এমন ভুল কিছু তৈরি করে যা শুনতে সঠিক মনে হয়, এবং কেউ বা কোনো কিছু সেই অনুযায়ী পদক্ষেপ নেয়, তখন তাকে ভুল তথ্য বলা হয়। মূল ঝুঁকিটা ভুল উত্তরের মধ্যে ততটা নয়, যতটা সেই ভুল উত্তরকে বিশ্বাস করে ব্যবহার করার মধ্যে।

ঘটনার রেকর্ড থেকে বোঝা যায়, ভুল তথ্য নিয়ে অনুশীলনকারীদের যতটা চিন্তিত হওয়া উচিত ছিল, ততটা তারা ছিলেন না। 2026 সংস্করণের সূচনাপত্র অনুযায়ী, ভোটাররা এটিকে তালিকার প্রায় নিচের দিকে রেখেছিলেন, কিন্তু বাস্তব ঘটনাগুলো বলছে এটি প্রায় শীর্ষে।

উদাহরণ: 2025 সালে Deloitte Australia A$440,000-এর একটি সরকারি চুক্তির আওতায় কল্যাণ খাতের IT সিস্টেম নিয়ে একটি পর্যালোচনা জমা দেয়। University of Sydney-এর গবেষক Chris Rudge এতে অস্তিত্বহীন গবেষণার রেফারেন্স খুঁজে পান, সঙ্গে একটি ফেডারেল আদালতের রায় থেকে বানানো একটি উদ্ধৃতিও। সংশোধিত প্রতিবেদনে প্রকাশ করা হয় যে Deloitte তাদের পদ্ধতিতে Azure OpenAI GPT-4o ব্যবহার করেছিল, এবং প্রতিষ্ঠানটি চূড়ান্ত কিস্তির অর্থ ফেরত দিতে সম্মত হয়। দুর্ভাগ্যবশত, এটি ছিল একটি মান-নিশ্চিতকরণ পর্যালোচনা।

আপনি যা করতে পারেন:

• প্রমাণ উত্তরটিকে সমর্থন করে কিনা যাচাই করুন: দাবিগুলোকে হালনাগাদ ও নির্ভরযোগ্য উৎসের ভিত্তিতে প্রতিষ্ঠিত করুন। নীতিমালা-সংক্রান্ত কোনো উত্তরের ক্ষেত্রে অনুমোদিত নীতিমালাটি খুঁজে বের করুন এবং যাচাই করুন যে এটি ব্যতিক্রমসহ সিদ্ধান্তটিকে সমর্থন করে।
• সিস্টেম পদক্ষেপ নেওয়ার আগে যাচাই করুন: কোনো এজেন্ট যদি বলে যে একজন গ্রাহক পরিচয় যাচাইয়ে উত্তীর্ণ হয়েছেন, তাহলে পেমেন্ট ছাড়ার আগে ভেরিফিকেশন সিস্টেমের সঙ্গে মিলিয়ে তা নিশ্চিত করুন। গুরুত্বপূর্ণ সিদ্ধান্তের জন্য মানুষের অনুমোদন বাধ্যতামূলক করুন, এবং পর্যালোচকের কাছে সহায়ক প্রমাণ সহজলভ্য রাখুন।

8. গোপন কনটেক্সট ফাঁসের ক্ষতি সীমিত করুন

AI অ্যাপ্লিকেশনগুলো মডেলকে এমন নির্দেশনা ও পটভূমি তথ্য দেয়, যা ব্যবহারকারীরা সাধারণত দেখতে পান না। এর মধ্যে থাকতে পারে সিস্টেম প্রম্পট, অভ্যন্তরীণ নীতিমালা, উপলব্ধ টুলের বিবরণ, এবং কারা সেগুলো ব্যবহার করতে পারবে সে-সংক্রান্ত নিয়ম। মডেল যখন সেই তথ্য কারও কাছে প্রকাশ করে দেয়, তখন গোপন কনটেক্সট ফাঁস ঘটে।

OWASP 2026 সালে এই এন্ট্রিটিকে “সিস্টেম প্রম্পট ফাঁস” থেকে সম্প্রসারিত করেছে, কারণ যা কিছু ফাঁস হতে পারে, সিস্টেম প্রম্পট তার কেবল একটি অংশ। বিপদের মাত্রা নির্ভর করে আপনি সেখানে কী রেখেছেন তার ওপর। লেখার ধরন-সংক্রান্ত গাইড ফাঁস হওয়া কিছুটা বিব্রতকর, কিন্তু একটি API কী ফাঁস হলে কেউ আপনার গোপনীয় ডেটাবেসে অ্যাক্সেস পেয়ে যায়।

উদাহরণ: 2023 সালের ফেব্রুয়ারিতে ব্যবহারকারীরা Microsoft-এর Bing Chat-কে দিয়ে এর অভ্যন্তরীণ নির্দেশনা প্রকাশ করিয়ে নেন। এর মধ্যে একটি সফল প্রচেষ্টা ছিল Marvin von Hagen-এর, যিনি নিজেকে OpenAI-এর ডেভেলপার দাবি করে মডেলটি কনফিগার করার জন্য নির্দেশনাগুলো চেয়েছিলেন। Bing তার সার্চ, উত্তর ও নিরাপত্তা-সংক্রান্ত আচরণ নিয়ন্ত্রণকারী নিয়মগুলো প্রকাশ করে দেয়, সঙ্গে তার অভ্যন্তরীণ নাম Sydney-ও। প্রকাশিত নির্দেশনাগুলোর মধ্যে একটি ছিল সেই নির্দেশনাগুলো গোপন রাখার নির্দেশ।

আপনি যা করতে পারেন:

• মডেলের কনটেক্সট থেকে সিক্রেট দূরে রাখুন: ধরে নিন, মডেল যা কিছু পড়তে পারে তা ব্যবহারকারীদের কাছে দৃশ্যমান হয়ে যেতে পারে—পাসওয়ার্ড, API কী এবং অ্যাক্সেস টোকেন একটি আলাদা সিক্রেট-ম্যানেজমেন্ট সিস্টেমে সংরক্ষণ করুন।
• নিয়ম ফাঁস হয়ে গেলেও অনুমতিগুলো যেন কার্যকর থাকে, তা নিশ্চিত করুন: আপনার অ্যাপ্লিকেশনের কোডে অ্যাক্সেস যাচাই প্রয়োগ করুন। কোনো টুল যদি শুধু অ্যাডমিনিস্ট্রেটরদের জন্য সীমিত থাকে, তবে সেটি চালানোর আগে ব্যবহারকারীর অ্যাকাউন্টের অনুমতি যাচাই করুন।

৯. আপনার ভেক্টর ও এমবেডিং সুরক্ষিত করুন

কোনো AI যখন আপনার প্রতিষ্ঠানের ডকুমেন্টে উত্তর খুঁজতে ভেক্টর সার্চ ব্যবহার করে, তখন এটি সরাসরি টেক্সটে খোঁজে না। ডকুমেন্টগুলোকে “এমবেডিং”-এ রূপান্তর করে একটি ভেক্টর ডেটাবেসে সংরক্ষণ করা হয়—এমবেডিং হলো সংখ্যার লম্বা তালিকা, যা প্রতিটি অনুচ্ছেদের অর্থ ধারণ করে। প্রশ্নকেও একইভাবে রূপান্তর করা হয়, এবং সিস্টেম সেই অনুচ্ছেদগুলো বের করে আনে, যেগুলোর সংখ্যা সবচেয়ে কাছাকাছি।

এই ব্যবস্থাটি যে চারভাবে ব্যর্থ হয়, OWASP তা সংক্ষেপে তুলে ধরেছে: পয়জনিং সিস্টেমকে ভুল ফল দিতে বাধ্য করে, ইনভারশন একে দিয়ে তথ্য ফাঁস করায়, জ্যামিং একে নীরব করে দেয়, আর ত্রুটিপূর্ণ অ্যাক্সেস কন্ট্রোলের কারণে এটি যে কাউকে যেকোনো কিছু দিয়ে দেয়।

এই সংখ্যাগুলো দেখতে যতটা নিরাপদ বিমূর্ত রূপ মনে হয়, আসলে ততটা নিরাপদ নয়। সংরক্ষিত এমবেডিংকে আবার টেক্সটে ফিরিয়ে আনা যায়, এবং একটি পদ্ধতি পরীক্ষায় ৩২-টোকেনের ছোট অনুচ্ছেদগুলোর ৯২% হুবহু পুনরুদ্ধার করেছে। তাই ফাঁস হওয়া একটি “শুধু এমবেডিং” ব্যাকআপও ডকুমেন্টের বিষয়বস্তু প্রকাশ করে দিতে পারে।

উদাহরণ: USENIX Security 2025-এ উপস্থাপিত এক গবেষণায় গবেষকেরা দেখিয়েছেন, সযত্নে তৈরি একটিমাত্র ডকুমেন্ট একটি AI-কে নির্দিষ্ট কোনো প্রশ্নের উত্তর দেওয়া থেকে বিরত রাখতে পারে। AI যে সংগ্রহে খোঁজ করত, তাঁরা সেখানে ডকুমেন্টটি যুক্ত করেন। AI সেটি খুঁজে পেলে বলতে পারত যে তার কাছে যথেষ্ট তথ্য নেই, অথবা উত্তর দেওয়া অনিরাপদ হবে। এর জন্য ডকুমেন্টটিতে AI-কে তার নিয়ম উপেক্ষা করতে বলার প্রয়োজন হয়নি। একে বলা হয় “রিট্রিভাল জ্যামিং”।

আপনি যা করতে পারেন:

• পাবলিক ও প্রাইভেট ডেটার জন্য আলাদা ইনডেক্স রাখুন: ওয়েব থেকে স্ক্র্যাপ করা কনটেন্টকে পার্টনারের ডেটা বা গোপনীয় অভ্যন্তরীণ ডকুমেন্টের সঙ্গে মেশাবেন না। একটি ইনডেক্সে কনটেন্ট ট্যাগ করার বদলে আস্থার স্তর অনুযায়ী ভৌতভাবে আলাদা রাখুন, কারণ এতে এক ধরনের ভুল কনফিগারেশনের ঝুঁকি পুরোপুরি দূর হয়, এবং ইন্টারনেট থেকে স্ক্র্যাপ করা কনটেন্ট আপনার বোর্ড মিটিংয়ের নথিপত্রের পাশে জায়গা পায় না।
• এমবেডিংকে তাদের উৎস ডকুমেন্টের মতোই বিবেচনা করুন: এগুলো এনক্রিপ্ট করুন, সোর্স ফাইলের পাশাপাশি ভেক্টর ডেটাবেসের ব্যাকআপও সুরক্ষিত রাখুন, এবং মূল ডকুমেন্ট মুছে ফেললে এমবেডিংও মুছে ফেলুন। আপনার এমবেডিং সার্ভিসের API কী গোপন রাখা উচিত।

১০. AI আউটপুট অন্য কোথাও পাঠানোর আগে যাচাই করুন

কোনো অ্যাপ্লিকেশন যখনই AI আউটপুট অন্য কোনো সিস্টেমে ব্যবহারের জন্য নিরাপদ কি না তা যাচাই না করেই সেখানে পাঠিয়ে দেয়, তখন সেটি LLM আউটপুট ভুলভাবে হ্যান্ডল করছে।

এই এন্ট্রিতে AI কোডিং অ্যাসিস্ট্যান্টের ব্যাপক মাত্রায় তৈরি করা অনিরাপদ কোডের বিষয়টিও অন্তর্ভুক্ত। কাজেই অ্যাসিস্ট্যান্টের লেখা প্রতিটি লাইনও আউটপুট।

উদাহরণ: ২০২৫ সালে গবেষক Johann Rehberger দেখিয়েছেন, কীভাবে Sourcegraph-এর Amp কোডিং অ্যাসিস্ট্যান্ট শুধু একটি ছবি দেখিয়েই চ্যাটের কনটেন্ট ফাঁস করে দিতে পারে। তিনি প্রম্পট ইনজেকশন ব্যবহার করে Amp-কে দিয়ে একটি ছবির ওয়েব ঠিকানায় ব্যক্তিগত তথ্য যুক্ত করান। এরপর অ্যাপ্লিকেশনটি স্বয়ংক্রিয়ভাবে ছবিটি ফেচ করে, ফলে তথ্যগুলো তাঁর সার্ভারে চলে যায়। আউটপুট হ্যান্ডলিংয়ের ব্যর্থতা ছিল ওই স্বয়ংক্রিয় রিকোয়েস্টটিই—মডেলের তৈরি টেক্সট একটি বাইরের সার্ভারের সঙ্গে সংযোগে পরিণত হয়, যা সঙ্গে করে ব্যক্তিগত ডেটা নিয়ে যায়।

আপনি যা করতে পারেন:

• আউটপুটকে তার গন্তব্যের জন্য নিরাপদ করুন: রেসপন্স কোথায় যাবে, সেই অনুযায়ী সেগুলো যাচাই ও হ্যান্ডল করুন। ওয়েবপেজের ক্ষেত্রে, তৈরি হওয়া টেক্সট যেন এক্সিকিউটেবল কোডে পরিণত না হয়, তা প্রতিরোধ করুন। ডেটাবেসের ক্ষেত্রে, প্রিপেয়ার্ড কোয়েরি ব্যবহার করুন, যা সরবরাহ করা মানগুলোকে কমান্ড থেকে আলাদা রাখে।
• উত্তরগুলোকে স্বয়ংক্রিয়ভাবে বাইরের সংযোগ তৈরি করতে দেবেন না: মডেলের রেসপন্সে ছবি, লিঙ্ক প্রিভিউ এবং এমবেড করা পেজের স্বয়ংক্রিয় লোডিং ডিফল্টভাবে বন্ধ রাখুন। প্রয়োজনীয় সংযোগগুলো কেবল সুস্পষ্টভাবে অনুমোদিত গন্তব্যে সীমিত রাখুন।

Perplexity কীভাবে LLM সুরক্ষিত রাখে?

আমরা ধরে নিই যে ওপরের প্রতিটি ঝুঁকিই একসময় না একসময় বাস্তবে ঘটবে, এবং আমরা এমনভাবে ডিজাইন করি যাতে তা ঘটলেও খুব বেশি ক্ষতি করতে না পারে। কীভাবে, তা আমাদের CISO Kyle Polley একটি সাম্প্রতিক ওয়ার্কশপে বিস্তারিতভাবে ব্যাখ্যা করেছেন।

• এজেন্ট পায় নিজস্ব কম্পিউটার, আর সেটি শুরু হয় একেবারে খালি অবস্থায়: আপনার ল্যাপটপে ইনস্টল করা এজেন্ট টুলগুলো ল্যাপটপের ফাইল, অ্যাপ এবং সংরক্ষিত ক্রেডেনশিয়ালে অ্যাক্সেস পেতে পারে। Perplexity Computer কাজ করে ঠিক উল্টোভাবে। প্রতিটি টাস্ক চলে তার নিজস্ব বিচ্ছিন্ন স্যান্ডবক্সে, এবং Polley-এর ভাষায়, “ডিফল্টভাবে এর কোনো কিছুতেই অ্যাক্সেস নেই।”
• এজেন্ট কখনো পাসওয়ার্ড দেখতে পায় না: সংযুক্ত সার্ভিসগুলোর ক্রেডেনশিয়াল স্যান্ডবক্সের বাইরে সংরক্ষিত থাকে। এজেন্টকে যখন GitHub-এর মতো কোনো সার্ভিসে পৌঁছাতে হয়, তখন সেটি কোনো ক্রেডেনশিয়াল ছাড়াই একটি রিকোয়েস্ট পাঠায়। একটি গেটওয়ে যাচাই করে দেখে যে গন্তব্য ও রিকোয়েস্ট প্রত্যাশা অনুযায়ী আছে কি না, তারপর বাইরে যাওয়ার পথে ক্রেডেনশিয়াল যুক্ত করে দেয়। ফলে এজেন্ট চাবি না পেয়েও সংযোগটি ব্যবহার করতে পারে।
• আপনার অনুমতিগুলো বহাল থাকে, এবং আপনি সেগুলো আরও কঠোর করতে পারেন: OAuth-এর মাধ্যমে তৈরি সংযোগগুলো সংযুক্ত সার্ভিসে আপনার অ্যাক্সেসের অনুমতি অক্ষুণ্ণ রাখে। আপনি যা দেখতে পান না, আপনার এজেন্টও তা দেখতে পায় না।
• প্রতিটি ওয়েব পেজকে অপরিচিত হিসেবে গণ্য করা হয়: আমরা আমাদের এজেন্টিক ব্রাউজার Comet-এর জন্য BrowseSafe তৈরি করেছি, কারণ আমরা যেসব টুল পরীক্ষা করেছিলাম, সেগুলো বাস্তব ব্যবহারে আমাদের চাহিদা পূরণ করতে পারেনি। ব্রাউজারটি প্রম্পট ইনজেকশন শনাক্ত করতে ওয়েব পেজ এবং ইমেইলসহ অন্যান্য বাইরের কনটেন্ট স্ক্যান করে। আমরা মডেল ও ডেটাসেট—দুটোই ওপেন সোর্স করেছি।
• আমরা এজেন্ট এবং সেটি যেসব মেশিনে চলে, সেগুলোর ওপর নজর রাখি: Numbat এজেন্টের কোনো কাজ করার সিদ্ধান্ত নেওয়া এবং টুলটি আসলে চালু হওয়ার মাঝখানে অবস্থান করে। Numbat সমর্থিত কোডিং এজেন্টগুলোর কার্যকলাপ লগ করে এবং কনফিগার করা পলিসি লঙ্ঘন করে এমন কাজ এক্সিকিউট হওয়ার আগেই ব্লক করতে পারে। Bumblebee ল্যাপটপ, সার্ভার ও বিল্ড পাইপলাইন জুড়ে সফটওয়্যার প্যাকেজের তালিকা তৈরি করে এবং পরিচিত ক্ষতিকর প্যাকেজগুলো চিহ্নিত করে। দুটোই ওপেন সোর্স।
• মডেল প্রোভাইডাররা আপনার ডেটা রাখে না: আমাদের থার্ড-পার্টি LLM প্রোভাইডারদের সঙ্গে আমাদের জিরো ডেটা রিটেনশন চুক্তি রয়েছে। এছাড়া Enterprise অ্যাডমিনরা Perplexity-এর নিজস্ব ডেটা রিটেনশনের সময়সীমা সর্বনিম্ন ২৪ ঘণ্টা পর্যন্ত কমিয়ে আনতে পারেন।

আমরা আগেভাগেই Numbat তৈরি করেছি, আর এর কারণটি Polley এক লাইনে সংক্ষেপে বলেছেন: “আপনি একটি এজেন্টকে যত বেশি স্বাধীনতা দেবেন, ঝুঁকিও তত বেশি।”

LLM নিরাপত্তা নিয়ে সচরাচর জিজ্ঞাসিত প্রশ্ন

সবচেয়ে নিরাপদ LLM কোনটি?

কোনো LLM একাই একটি অ্যাপ্লিকেশনকে নিরাপদ করে না—মডেলগুলো এখনো যে কনটেন্ট শুধু পড়ার কথা, সেটিকে অনুসরণ করার মতো নির্দেশনা বলে ভুল করতে পারে। স্ট্যান্ডার্ড পরীক্ষায় যে প্রতিরক্ষাগুলো শক্তিশালী মনে হয়, চাপের মুখে সেগুলোও ভেঙে পড়তে পারে।

এর চেয়ে ভালো প্রশ্ন হলো, আপনার ব্যবহারের ক্ষেত্রে কোন সেটআপ সবচেয়ে নিরাপদ। এর অর্থ সীমিত অনুমতি, মডেল থেকে দূরে রাখা ক্রেডেনশিয়াল, ঝুঁকিপূর্ণ কাজের জন্য মানুষের অনুমোদন, এবং আপনার প্রতিরক্ষা ব্যবস্থা সম্পর্কে জানেন এমন ব্যক্তিদের দিয়ে পরীক্ষা।

LLM-এর দুর্বলতাগুলো কী?

LLM-এর দুর্বলতা হলো এমন সব ত্রুটি, যার কারণে কোনো AI সিস্টেমকে ধোঁকা দেওয়া যায়, সিস্টেমটি ডেটা ফাঁস করে, বা ক্ষতি করে—সেটা কোনো আক্রমণকারীর মাধ্যমে হোক কিংবা সিস্টেমের নিজের ভুলে।

প্রধান দশটি ঝুঁকি হলো প্রম্পট ইনজেকশন, সংবেদনশীল তথ্য প্রকাশ, অতিরিক্ত এজেন্সি, সাপ্লাই চেইন, ডেটা ও মডেল পয়জনিং, সীমাহীন রিসোর্স ব্যবহার, ভুল তথ্য, লুকানো কনটেক্সট প্রকাশ, ভেক্টর ও এমবেডিংয়ের দুর্বলতা, এবং ত্রুটিপূর্ণ আউটপুট হ্যান্ডলিং।

প্রাইভেট LLM কি নিরাপদ?

কিছু ক্ষেত্রে এটি তুলনামূলক নিরাপদ বিকল্প, তবে ডিফল্টভাবে নয়। নিজের ইনফ্রাস্ট্রাকচারে বা ক্লাউড এনভায়রনমেন্টে মডেল চালালে ডেটা হ্যান্ডলিংয়ের ওপর আপনার নিয়ন্ত্রণ বেশি থাকে। তবে প্রম্পট ইনজেকশন, অতিরিক্ত এজেন্সি, পয়জনিং বা ভুল তথ্য স্বয়ংক্রিয়ভাবে প্রতিরোধ করার কোনো উপায় নেই।

সেলফ-হোস্টিংয়ের অংশ হিসেবে, আপনি যে মডেল ডাউনলোড করেন তার দায়িত্বও আপনার, যার মধ্যে রয়েছে সাপ্লাই চেইনের ঝুঁকি এবং এর জন্য প্রয়োজনীয় ইনফ্রাস্ট্রাকচার।