Authentication یہ چیک کرتا ہے کہ آپ کون ہیں؛ authorization یہ فیصلہ کرتی ہے کہ آپ کیا کر سکتے ہیں۔ AI سے چلنے والی ایپلی کیشنز کی بڑھتی ہوئی تعداد لاگ ان کے وقت صرف ایک بار صارف کی شناخت کی تصدیق کرتی ہے اور پھر پورے سیشن کے دوران بنیادی ایجنٹ کو کسی بھی ریسورس پر کام کرنے کی اجازت دے دیتی ہے، جو عملی طور پر اسے ایک "بلینک چیک" (blank check) دینے کے مترادف ہے۔ یہ ڈیزائن حادثاتی طور پر ڈیٹا لیک، غیر مطلوبہ ای میلز، یا ڈیٹا بیس کی تباہ کن اپ ڈیٹس کے دروازے کھول دیتا ہے، اور یہ خطرہ اس وقت مزید بڑھ جاتا ہے جب ایک AI اسسٹنٹ ملی سیکنڈز کی تاخیر کے ساتھ متعدد ٹولز کو استعمال کرنے کے قابل ہوتا ہے۔
یہ غلطی بار بار کیوں ہوتی ہے
زیادہ تر AI ڈویلپرز لاگ ان اسکرین کو واحد سیکیورٹی گیٹ سمجھتے ہیں۔ کوڈ پاس ورڈ یا ٹوکن مانگتا ہے، سیشن کو "authenticated" کے طور پر نشان زد کرتا ہے، اور پھر یہ فرض کر لیتا ہے کہ اس کے بعد کی ہر درخواست محفوظ ہے۔ ایک روایتی ویب ایپ میں، انسانی صارف کے کلکس کی سست رفتاری قدرتی طور پر ایک کنٹرول پوائنٹ (throttling point) فراہم کرتی ہے؛ ایک انسان "delete" دبانے سے پہلے رکے گا۔ تاہم، ایک AI ایجنٹ سیکنڈوں میں درجنوں ٹول کالز کر سکتا ہے۔ اگر پلیٹ فارم صرف یہ پوچھے کہ "کیا صارف لاگ ان ہے؟" تو ہر کال کو وہی غیر محدود مراعات (privileges) مل جاتی ہیں۔
اس کی بنیادی وجہ سہولت ہے۔ ٹیمیں اکثر پوری ایپلی کیشن کے لیے ایک ہی طویل مدتی سروس اکاؤنٹ (service account) فراہم کر دیتی ہیں تاکہ کوڈ کو متعدد ٹوکنز یا اسکوپس (scopes) کو مینیج نہ کرنا پڑے۔ اس اکاؤنٹ کے پاس عام طور پر تمام پروجیکٹس پر وسیع اجازتات ہوتی ہیں—پڑھنا (read)، لکھنا (write)، اور حذف کرنا (delete)۔ جب ایک AI اسسٹنٹ اس سیشن کے اندر چلتا ہے، تو وہ خود بخود ان حقوق کا وارث بن جاتا ہے، قطع نظر اس کے کہ آیا موجودہ کام کے لیے واقعی ان کی ضرورت ہے یا نہیں۔
کیا خطرے میں ہے
- ڈیٹا کا انکشاف (Data exposure) – ایک ایجنٹ جو صارف کے لاگ ان کرنے کے بعد کوئی بھی فائل پڑھ سکتا ہے، وہ نادانستہ طور پر خفیہ دستاویزات کو ایک ایسے جواب میں شامل کر سکتا ہے جو بعد میں تنظیم سے باہر شیئر کیا جائے۔
- غیر ارادی اقدامات (Unintended actions) – ایک سپورٹ انجینئر کا AI ہیلپر پروڈکشن ڈیٹا بیس کے خلاف براہ راست SQL کوئری چلا سکتا ہے، محض اس لیے کہ انجینئر کا سیشن ابھی بھی فعال ہے، چاہے وہ کوئری اس ٹکٹ سے متعلق نہ ہو جس پر کام کیا جا رہا ہے۔
- ریگولیٹری تعمیل (Regulatory compliance) – ڈیٹا کے تحفظ کے بہت سے قوانین کے تحت رسائی کو صرف ضرورت کے مطابق محدود رکھنا لازمی ہے۔ ایک عمومی اجازت کا ماڈل ان اصولوں کی خلاف ورزی کر سکتا ہے اور آڈٹ یا جرمانے کا سبب بن سکتا ہے۔
- آپریشنل لاگت (Operational cost) – وہ غلطیاں جو ریکارڈز کو حذف یا تبدیل کر دیتی ہیں، ٹیموں کو تبدیلیوں کو واپس لینے (roll back)، وجوہات کی تحقیقات کرنے، اور صارفین کے ساتھ اعتماد دوبارہ بحال کرنے پر مجبور کرتی ہیں—یہ سب وقت اور پیسہ ضائع کرتا ہے۔
وہ اہم مرحلہ جو رہ گیا ہے: ہر عمل کے لیے الگ سے اجازت (per-action authorization)
Authorization کا جائزہ سسٹم کے اندر ہر "دروازے" پر لیا جانا چاہیے، نہ کہ صرف سامنے کے داخلی راستے پر۔ سوال "یہ کون ہے؟" سے بدل کر "کیا اس مخصوص ریسورس پر یہ مخصوص عمل ابھی کیا جا سکتا ہے؟" ہو جانا چاہیے۔ اس چیک کو نافذ کرنے کے لیے مکمل ری ڈیزائن کی ضرورت نہیں ہے؛ اس کے لیے صرف ایک سنگل سیشن فلیگ سے ہٹ کر مختصر مدت کے، مخصوص اسکوپ والے ٹوکنز (short-lived, scoped tokens) کی طرف منتقلی کی ضرورت ہے۔
عملی طور پر یہ کیسے کام کرتا ہے
- ایک مخصوص اسکوپ کے ساتھ ٹوکن کی درخواست کریں – جب AI ایجنٹ کو کسی ٹول کو کال کرنے کی ضرورت ہو، تو وہ پہلے ایک ایسا ٹوکن حاصل کرتا ہے جس میں مطلوبہ درست اجازتیں درج ہوں (مثلاً
read:ticket,execute:sql_query)۔ - ہر کال کے لیے ٹوکن کی تصدیق کریں – ٹول چلنے سے پہلے، سروس یہ چیک کرتی ہے کہ آیا ٹوکن میں مطلوبہ اسکوپ شامل ہے اور کیا ٹوکن کی مدت ختم تو نہیں ہو گئی۔
- ریسورس کو اسکوپ سے ملائیں – اگر درخواست کسی خاص پروجیکٹ یا ڈیٹا بیس کو نشانہ بناتی ہے، تو ٹوکن کو واضح طور پر اس شناختی نمبر (identifier) تک رسائی دینی چاہیے۔
- مسترد کریں یا اجازت دیں – اگر کوئی بھی چیک ناکام ہو جائے، تو کال مسترد کر دی جاتی ہے اور ایجنٹ کو ایک ایرر ملتا ہے جسے وہ صارف کو دکھا سکتا ہے۔
کوڈ کا فرق بالکل واضح ہے۔ ایک "برا" طریقہ ایسا ہو سکتا ہے:
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) اس خیال کو مزید وسعت دیتے ہیں، جس سے کلائنٹ کو پہلے سے طے شدہ فہرست کے بجائے رن ٹائم (runtime) پر ہی باریک بینی سے اجازتیں (granular permissions) مانگنے کی اجازت ملتی ہے۔ یہ لچک اس وقت مفید ہوتی ہے جب کسی AI ورک فلو کو صارف کے ارادے کی بنیاد پر فوری طور پر صلاحیتوں کو شامل کرنے یا ختم کرنے کی ضرورت پڑ سکتی ہے۔
مخالف دلیل: سادگی بمقابلہ سیکیورٹی
کچھ ٹیموں کا یہ استدلال ہے کہ ہر ایکشن کے لیے چیک کرنے سے تاخیر (latency) اور کوڈ کی پیچیدگی بڑھ جاتی ہے، خاص طور پر جب AI اسسٹنٹ کو تیزی سے بہت سے ٹولز کال کرنے ہوں۔ وہ اس بات کی نشاندہی کرتے ہیں کہ ایک ہی سیشن ٹوکن (session token) ہر کال کے لیے نیا ٹوکن حاصل کرنے اور اس کی تصدیق کرنے کے بوجھ سے بچاتا ہے۔ تاہم، اس کا نقصان یہ ہے کہ اس سے غلط استعمال کا خطرہ بہت زیادہ بڑھ جاتا ہے۔ جدید ٹوکن ویلیڈیشن سروسز کو مائیکرو سیکنڈز میں کام کرنے کے لیے ڈیزائن کیا گیا ہے، اور اضافی نیٹ ورک راؤنڈ ٹرپ کو principle of least privilege پر سمجھوتہ کیے بغیر بیچ (batch) یا کیش (cache) کیا جا سکتا ہے۔ ایسے ماحول میں جہاں ڈیٹا کی سالمیت (data integrity) اور تعمیل (compliance) پر کوئی سمجھوتہ نہیں کیا جا سکتا، وہاں کارکردگی کی معمولی قیمت خطرے میں کمی کے مقابلے میں بہت کم ہے۔
آگے کیا نظر آئے گا
- AI SDKs میں اسکوپڈ ٹوکنز (scoped tokens) کا استعمال – بڑے AI پلیٹ فارم ٹول کٹس کی اپ ڈیٹس پر نظر رکھیں؛ بہت سے ٹول کٹس OAuth پر مبنی اسکوپس کے لیے ہیلپر فنکشنز فراہم کرنا شروع کر رہے ہیں۔
- Policy-as-code فریم ورکس – ابھرتے ہوئے حل ٹیموں کو ایک ڈیکلیریٹو فائل (declarative file) میں اتھارزیشن کے قواعد بیان کرنے کی اجازت دیتے ہیں، جو رن ٹائم پر خود بخود نافذ ہو جاتے ہیں۔
- آڈٹ لاگز جو ہر ایکشن کے فیصلوں کو ظاہر کریں – جیسے جیسے زیادہ پلیٹ فارمز ہر اتھارزیشن چیک کو ریکارڈ کریں گے، تنظیموں کو یہ جاننے میں مدد ملے گی کہ کن AI ایکشنز کو اجازت دی جا رہی ہے یا بلاک کیا جا رہا ہے، جس سے مستقبل میں پالیسیوں میں تبدیلی لانے میں مدد ملے گی۔
خلاصہ
لاگ ان شدہ سیشن کو ہر کام کرنے کی اجازت سمجھنا غیر ارادی نتائج کا باعث بن سکتا ہے۔ اتھارزیشن کا فیصلہ لاگ ان کے لمحے سے ہٹا کر ہر انفرادی ٹول کال تک لے جانے اور مختصر مدت کے اسکوپڈ ٹوکنز (short-lived, scoped tokens) کا استعمال کرنے سے، AI ایپلی کیشنز خود مختار ایجنٹس (autonomous agents) کی سہولت برقرار رکھتے ہوئے ڈیٹا کا تحفظ، قواعد کی تعمیل اور مہنگے حادثات سے بچ سکتی ہیں۔ کوڈ کی اضافی لائنیں ایک ایسے سسٹم کے لیے معمولی قیمت ہیں جو ہر بار ایکشن کی کوشش کے وقت صحیح سوال پوچھتا ہے۔