صرف ریڈ-اونلی (Read-Only) کافی نہیں ہے: AI ایجنٹس کے لیے گارڈ ریلز (Guardrails)

سینئر انجینئرز اکثر AI ایجنٹس کو محفوظ رکھنے کے لیے ایک ہی بات کہتے ہیں: انہیں صرف ریڈ-اونلی (read-only) رسائی دیں۔

یہ محفوظ معلوم ہوتا ہے۔ ایجنٹ کسی بھی چیز کو نقصان پہنچائے بغیر سست کوئریز (slow queries) کی تحقیقات کر سکتا ہے یا اسکیموں (schemas) کا خلاصہ کر سکتا ہے۔

لیکن ریڈ-اونلی کوئی حفاظتی ماڈل نہیں ہے۔ یہ ایک حد (limitation) ہے۔

جس لمحے آپ کے ایجنٹ کو کوئی مفید کام کرنے کی ضرورت ہوتی ہے، ریڈ-اونلی اسے روک دیتی ہے۔ اگر ایجنٹ کو کوئی خراب انڈیکس (index) یا کرپٹ شدہ رو (row) مل جائے، تو وہ اسے ٹھیک نہیں کر سکتا۔ آپ کے پاس ایک ایسا اسسٹنٹ رہ جاتا ہے جو آگ کی طرف اشارہ تو کر سکتا ہے لیکن پائپ نہیں اٹھا سکتا۔

ٹیمیں اکثر ہار مان لیتی ہیں اور ایجنٹ کو رائٹ (write) رسائی دے دیتی ہیں۔ اصل خطرہ تب شروع ہوتا ہے۔

اصل سوال یہ نہیں ہے کہ "کیا ایجنٹ کو لکھنا چاہیے"۔ اصل سوال یہ ہے کہ "آپ ان رائٹس (writes) کو کیسے گورن (govern) کرتے ہیں"۔

ہدایات کے ذریعے رائٹس کو گورن کرنے کی کوشش نہ کریں۔ سسٹم پرامپٹ (system prompt) میں "کبھی بھی ٹیبل ڈیلیٹ نہ کریں" جیسے اصول نہ ڈالیں۔

پرامپٹ انجیکشن (Prompt injection) ان اصولوں کو بے کار بنا دیتا ہے۔ ایک حملہ آور ڈیٹا کی کسی رو یا کمنٹ کا استعمال کر کے ایجنٹ کو آپ کے اصولوں کو نظر انداز کرنے پر مجبور کر سکتا ہے۔ اگر گارڈ ریل (guardrail) ایجنٹ کے ساتھ ہی ایک ہی ونڈو میں موجود ہو، تو ایجنٹ بحث کر کے اس سے بچ نکل سکتا ہے۔

آپ کو غیر منظم رائٹس (ungoverned writes) اور ثالثی شدہ رائٹس (mediated writes) کے درمیان فرق کرنے کی ضرورت ہے۔

• غیر منظم رائٹس (Ungoverned writes): ایجنٹ کمانڈ چلانے کا فیصلہ کرتا ہے، اور ڈیٹا بیس اسے نافذ کر دیتا ہے۔ اس میں واحد کنٹرول ایجنٹ کا اپنا فیصلہ ہوتا ہے۔ • ثالثی شدہ رائٹس (Mediated writes): کمانڈ ایجنٹ سے باہر ایک چیک پوائنٹ سے گزرتی ہے۔ یہ چیک پوائنٹ ایجنٹ اور ڈیٹا بیس کے درمیان ڈیٹا پاتھ (data path) میں ہوتا ہے۔

ایک ثالثی شدہ رائٹ (mediated write) اس طرح کام کرتی ہے:

  • ایجنٹ ایک سٹیٹمنٹ (statement) تجویز کرتا ہے۔
  • ایک پراکسی (proxy) یا کنٹرول پلین (control plane) اس سٹیٹمنٹ کا تجزیہ کرتا ہے۔
  • پراکسی خطرے کی درجہ بندی کرتی ہے۔
  • پراکسی فیصلہ کرتی ہے کہ اسے اجازت دی جائے یا کسی انسان سے منظوری مانگی جائے۔

یہ طریقہ کار آپ کو پرامپٹ انجیکشن سے بچاتا ہے۔ ایک بدنیتی پر مبنی ہدایت ایجنٹ کو DROP TABLE کمانڈ لکھنے پر مجبور کر سکتی ہے، لیکن یہ پراکسی کو دھوکہ نہیں دے سکتی۔ پراکسی ایجنٹ کے ارادے کو نہیں پڑھتی؛ یہ صرف اصل SQL کمانڈ کو دیکھتی ہے۔

محفوظ رہنے کے لیے اس ڈھانچے کا استعمال کریں:

  • محفوظ ریڈز (reads) کی خودکار اجازت دیں۔ کام کو تیز رکھنے کے لیے ایجنٹس کو آزادانہ طور پر SELECT کوئریز چلانے دیں۔
  • پرخطر رائٹس پر پابندی لگائیں۔ DELETE، UPDATE، یا اسکیمہ (schema) کی تبدیلیوں کے لیے انسانی منظوری لازمی بنائیں۔
  • ہر چیز کا لاگ (log) رکھیں۔ اس بات کا ناقابل تبدیلی ریکارڈ رکھیں کہ کس نے تبدیلی کی تجویز دی اور کس نے اسے منظور کیا۔

حفاظت کے لیے ریڈ ریپلیکا (read replicas) پر بھروسہ نہ کریں۔ ریپلیکا تحقیقات میں مدد کرتے ہیں، لیکن وہ اصلاحات (fixes) لاگو نہیں کر سکتے۔ پروڈکشن کے مسئلے کو حل کرنے کے لیے، آپ کو پرائمری ڈیٹا بیس میں لکھنا (write) ہوگا۔

ثالثی (Mediation) آپ کے ڈیٹا کو محفوظ رکھتے ہوئے ایجنٹ کو مفید بننے کی اجازت دیتی ہے۔

Source: https://dev.to/maxime_dalessandro_28171d/read-only-isnt-enough-guardrails-for-ai-agents-that-change-your-database-2e5h

Optional learning community: https://t.me/GyaanSetuAi