অথেন্টিকেশন যাচাই করে আপনি কে; আর অথরাইজেশন নির্ধারণ করে আপনি কী করতে পারবেন। ক্রমবর্ধমান সংখ্যক AI-চালিত অ্যাপ্লিকেশন লগইন করার সময় একবার ব্যবহারকারীর পরিচয় যাচাই করে এবং তারপর পুরো সেশনের জন্য সংশ্লিষ্ট এজেন্টকে যেকোনো রিসোর্স ব্যবহারের অনুমতি দিয়ে দেয়, যা কার্যত তাকে একটি "ব্ল্যাঙ্ক চেক" বা অবাধ ক্ষমতা দিয়ে দেওয়ার মতো। এই ডিজাইনটি অনিচ্ছাকৃত ডেটা লিক, অনাকাঙ্ক্ষিত ইমেল, এমনকি ধ্বংসাত্মক ডেটাবেস আপডেটের পথ প্রশস্ত করে, এবং ঝুঁকিটি আরও বেড়ে যায় যখন একটি AI অ্যাসিস্ট্যান্ট মিলিসেকেন্ডের ব্যবধানে একাধিক টুল ব্যবহার করতে পারে।
কেন এই ভুলটি বারবার ঘটছে
বেশিরভাগ AI ডেভেলপার লগইন স্ক্রিনকে একমাত্র নিরাপত্তা গেট হিসেবে বিবেচনা করেন। কোডটি পাসওয়ার্ড বা টোকেন চায়, সেশনটিকে "authenticated" হিসেবে চিহ্নিত করে এবং তারপর ধরে নেয় যে পরবর্তী প্রতিটি অনুরোধ নিরাপদ। একটি প্রথাগত ওয়েব অ্যাপে একজন মানুষের ধীরগতির ক্লিক একটি প্রাকৃতিক থ্রটলিং পয়েন্ট (throttling point) হিসেবে কাজ করে; কোনো কিছু "delete" করার আগে একজন মানুষ অবশ্যই থামবে। তবে, একটি AI এজেন্ট কয়েক সেকেন্ডের মধ্যে ডজন ডজন টুল কল করতে পারে। প্ল্যাটফর্মটি যদি কেবল জিজ্ঞাসা করে "ব্যবহারকারী কি লগইন করা আছে?", তবে প্রতিটি কল একই রকম অবাধ প্রিভিলেজ বা অধিকার পেয়ে যায়।
এর মূল কারণ হলো সুবিধা। টিমগুলো প্রায়ই পুরো অ্যাপ্লিকেশনের জন্য একটি মাত্র দীর্ঘস্থায়ী (long-lived) সার্ভিস অ্যাকাউন্ট ব্যবহার করে যাতে কোডকে একাধিক টোকেন বা স্কোপ পরিচালনা করতে না হয়। সেই অ্যাকাউন্টের সাধারণত সব প্রজেক্ট জুড়ে বিস্তৃত পারমিশন থাকে—read, write, delete। যখন একটি AI অ্যাসিস্ট্যান্ট সেই সেশনের ভেতরে চলে, তখন বর্তমান কাজটি আসলে সেই অধিকারগুলোর প্রয়োজন আছে কি না, তা বিবেচনা না করেই এটি স্বয়ংক্রিয়ভাবে সেই অধিকারগুলো পেয়ে যায়।
ঝুঁকির বিষয়গুলো কী কী
- Data exposure – একজন ব্যবহারকারী লগইন করার পর যে এজেন্ট যেকোনো ফাইল পড়তে পারে, সে অনিচ্ছাকৃতভাবে কোনো গোপনীয় নথি একটি রেসপন্সে নিয়ে আসতে পারে যা পরবর্তীতে সংস্থার বাইরে শেয়ার হয়ে যেতে পারে।
- Unintended actions – একজন সাপোর্ট ইঞ্জিনিয়ারের AI হেল্পার প্রোডাকশন ডেটাবেসের বিরুদ্ধে একটি র (raw) SQL কুয়েরি চালাতে পারে, শুধুমাত্র এই কারণে যে ইঞ্জিনিয়ারের সেশনটি এখনও সক্রিয় আছে, এমনকি যদি কুয়েরিটি হ্যান্ডেল করা টিকিটের সাথে সম্পর্কিত না-ও হয়।
- Regulatory compliance – অনেক ডেটা-সুরক্ষা নিয়মে প্রয়োজন হয় যে অ্যাক্সেস যেন শুধুমাত্র প্রয়োজনীয়তম সীমার মধ্যে সীমাবদ্ধ থাকে। একটি ঢালাও পারমিশন মডেল সেই নীতিগুলো লঙ্ঘন করতে পারে এবং অডিট বা জরিমানার কারণ হতে পারে।
- Operational cost – রেকর্ড মুছে ফেলা বা পরিবর্তন করার মতো ভুলগুলো টিমগুলোকে পরিবর্তনগুলো রোলব্যাক করতে, মূল কারণ অনুসন্ধান করতে এবং ব্যবহারকারীদের সাথে আস্থা পুনর্গঠন করতে বাধ্য করে—যার সবকটিই সময় এবং অর্থ অপচয় করে।
অনুপস্থিত ধাপ: প্রতিটি কাজের জন্য আলাদা অথরাইজেশন (per-action authorization)
অথরাইজেশন সিস্টেমের শুধুমাত্র প্রবেশপথে নয়, বরং সিস্টেমের ভেতরের প্রতিটি "দরজায়" যাচাই করা উচিত। প্রশ্নটি "এটি কে?" থেকে পরিবর্তিত হয়ে হয় "এই নির্দিষ্ট রিসোর্সের ওপর এই নির্দিষ্ট কাজটি কি এখন করা যেতে পারে?" এই যাচাইকরণটি কার্যকর করতে সম্পূর্ণ রিডিজাইন করার প্রয়োজন নেই; শুধুমাত্র একটি একক সেশন ফ্ল্যাগ থেকে স্বল্পস্থায়ী, স্কোপড টোকেনে (short-lived, scoped tokens) স্থানান্তরিত হলেই হবে।
এটি বাস্তবে কীভাবে কাজ করে
- Request a token with a defined scope – যখন AI এজেন্টের একটি টুল কল করার প্রয়োজন হয়, তখন এটি প্রথমে এমন একটি টোকেন সংগ্রহ করে যেখানে প্রয়োজনীয় সুনির্দিষ্ট পারমিশনগুলো তালিকাভুক্ত থাকে (যেমন,
read:ticket,execute:sql_query)। - Validate the token for each call – টুলটি চালানোর আগে, সার্ভিসটি যাচাই করে যে টোকেনটিতে প্রয়োজনীয় স্কোপ অন্তর্ভুক্ত আছে কি না এবং টোকেনটির মেয়াদ শেষ হয়ে গেছে কি না।
- Match resource to scope – যদি অনুরোধটি কোনো নির্দিষ্ট প্রজেক্ট বা ডেটাবেসকে লক্ষ্য করে, তবে টোকেনটিকে অবশ্যই স্পষ্টভাবে সেই আইডেন্টিফায়ারের অ্যাক্সেস প্রদান করতে হবে।
- Reject or allow – যদি কোনো যাচাইকরণ ব্যর্থ হয়, তবে কলটি প্রত্যাখ্যান করা হয় এবং এজেন্ট একটি এরর (error) পায় যা সে ব্যবহারকারীকে দেখাতে পারে।
কোডের পার্থক্যটি খুব সহজ। একটি "খারাপ" পদ্ধতি দেখতে এমন হতে পারে:
if session.is_authenticated():
tool.run(params)
একটি "ভালো" পদ্ধতি যাচাইকরণকে আরও বিস্তৃত করে:
token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
tool.run(params)
else:
raise PermissionError
দ্বিতীয় প্যাটার্নটি কোডে কয়েক লাইন বাড়ালেও প্রতিটি অপারেশনের জন্য সিস্টেমকে সঠিক প্রশ্নটি করতে বাধ্য করে।
স্ট্যান্ডার্ড যা বিষয়টিকে সহজ করে তোলে
OAuth 2.0 স্কোপগুলো ইতিমধ্যে একটি টোকেন কী করতে পারে তা সীমিত করার জন্য একটি বহুল ব্যবহৃত পদ্ধতি প্রদান করে। project:1234:write বা email:send-এর মতো স্কোপ এনকোড করা স্বল্পস্থায়ী অ্যাক্সেস টোকেন ইস্যু করার মাধ্যমে, ডেভেলপাররা ভেরিফিকেশন ধাপটি সম্পন্ন করতে বিদ্যমান লাইব্রেরিগুলোর ওপর নির্ভর করতে পারেন।
নতুন Rich Authorization Requests (RFC 9396) এই ধারণাটিকে আরও বিস্তৃত করে, যা একটি ক্লায়েন্টকে আগে থেকে একটি স্ট্যাটিক লিস্ট নির্ধারণ করার পরিবর্তে রানটাইমে সূক্ষ্ম (granular) পারমিশন অনুরোধ করার সুযোগ দেয়। এই নমনীয়তা তখন কার্যকর হয় যখন একটি AI ওয়ার্কফ্লোর ব্যবহারকারীর উদ্দেশ্যের ওপর ভিত্তি করে তাৎক্ষণিকভাবে সক্ষমতা যোগ বা বাদ দেওয়ার প্রয়োজন হতে পারে।
পাল্টা যুক্তি: সরলতা বনাম নিরাপত্তা
কিছু দল যুক্তি দেয় যে প্রতিটি অ্যাকশনের জন্য আলাদাভাবে যাচাই করা (per-action checks) ল্যাটেন্সি এবং কোডের জটিলতা বাড়ায়, বিশেষ করে যখন AI অ্যাসিস্ট্যান্টকে দ্রুত একের পর এক অনেকগুলো টুল কল করতে হয়। তারা উল্লেখ করেন যে একটি মাত্র সেশন টোকেন ব্যবহার করলে প্রতিটি কলের জন্য নতুন টোকেন সংগ্রহ এবং যাচাই করার অতিরিক্ত ঝামেলা (overhead) এড়ানো যায়। তবে এর বিনিময়ে অপব্যবহারের ঝুঁকি বহুগুণ বেড়ে যায়। আধুনিক টোকেন-ভ্যালিডেশন সার্ভিসগুলো মাইক্রোসেকেন্ডের মধ্যে কাজ করার জন্য ডিজাইন করা হয়েছে, এবং 'প্রিন্সিপল অফ লিস্ট প্রিভিলেজ' (principle of least privilege) নীতি বিসর্জন না দিয়েই অতিরিক্ত নেটওয়ার্ক রাউন্ড-ট্রিপগুলোকে ব্যাচ (batch) বা ক্যাশ (cache) করা সম্ভব। যে সমস্ত পরিবেশে ডেটা ইন্টিগ্রিটি এবং কমপ্লায়েন্স বা বিধিবিধান মেনে চলা অপরিহার্য, সেখানে সামান্য পারফরম্যান্স কস্টের চেয়ে ঝুঁকির হ্রাস অনেক বেশি গুরুত্বপূর্ণ।
পরবর্তীতে যা খেয়াল রাখতে হবে
- AI SDK-তে স্কোপড টোকেনের (scoped tokens) ব্যবহার – প্রধান AI প্ল্যাটফর্ম টুলকিটগুলোর আপডেটের দিকে নজর রাখুন; অনেকগুলোই এখন OAuth-ভিত্তিক স্কোপের জন্য হেল্পার ফাংশন (helper functions) প্রদান করতে শুরু করেছে।
- Policy-as-code ফ্রেমওয়ার্ক – উদীয়মান সমাধানগুলো টিমগুলোকে একটি ডিক্লেয়ারেটিভ ফাইলে অথরাইজেশন রুল বা অনুমোদনের নিয়ম ঘোষণা করতে দেয়, যা রানটাইমে স্বয়ংক্রিয়ভাবে কার্যকর হয়।
- অডিট লগ যা প্রতিটি অ্যাকশনের সিদ্ধান্ত প্রকাশ করে – যেহেতু আরও বেশি প্ল্যাটফর্ম প্রতিটি অথরাইজেশন চেক রেকর্ড করছে, তাই সংস্থাগুলো দেখতে পারবে কোন AI অ্যাকশনগুলো অনুমোদিত বা ব্লক করা হচ্ছে, যা ভবিষ্যতে পলিসি বা নীতি পরিবর্তনের ক্ষেত্রে সাহায্য করবে।
সারসংক্ষেপ
লগ-ইন করা সেশনকে সবকিছু করার অনুমতি হিসেবে গণ্য করা অনাকাঙ্ক্ষিত পরিণতির কারণ হতে পারে। লগ-ইন করার মুহূর্ত থেকে অথরাইজেশন বা অনুমোদনের সিদ্ধান্তটি প্রতিটি আলাদা টুল কলের ক্ষেত্রে নিয়ে আসার মাধ্যমে—এবং স্বল্পমেয়াদী, স্কোপড টোকেন ব্যবহারের মাধ্যমে—AI অ্যাপ্লিকেশনগুলো ডেটা সুরক্ষা নিশ্চিত করে, বিধিবিধান মেনে চলে এবং ব্যয়বহুল দুর্ঘটনা এড়িয়ে স্বায়ত্তশাসিত এজেন্টদের (autonomous agents) সুবিধা বজায় রাখতে পারে। প্রতিটি অ্যাকশন করার প্রচেষ্টার সময় সঠিক প্রশ্নটি জিজ্ঞাসা করতে পারে এমন একটি সিস্টেমের জন্য কোডের অতিরিক্ত কয়েক লাইন খুব সামান্য ব্যাপার।