گارڈریلز — ہر تبدیلی لانے والے ایکشن کے لیے ایک پالیسی

Control Center میں ایجنٹ فائلیں حذف کر سکتے ہیں، برانچیں پش کر سکتے ہیں، pull requests شائع کر سکتے ہیں اور بیرونی APIs کال کر سکتے ہیں۔ اِن میں سے ہر ایک خطرے کی ایک مختلف قسم ہے، اور ایک طویل عرصے تک اِن میں سے صرف ایک — shell کمانڈز — کے پاس پالیسی تھی۔ گارڈریلز کا مقصد ایک سوال کا یکساں جواب دینا ہے، ایجنٹ کے ہر تبدیلی لانے والے ایکشن کے لیے، چاہے اسے کوئی بھی رن ٹائم یا ٹول تجویز کرے: کیا اِس کی اجازت ہے، کیا اِس کے لیے منظوری درکار ہے، یا اِس سے منع ہے؟

ایک انجن، ہر چوک پوائنٹ

پالیسی انجن صرف ایک ہے۔ ہر اُس مقام پر اِسی سے رجوع کیا جاتا ہے جہاں سے کوئی ایکشن نظام سے باہر جا سکتا ہے: بلٹ اِن ہارنس کی ٹول رجسٹری، سرور سائیڈ MCP ڈسپیچر گیٹ اور repo-op تبدیلیاں۔ چنانچہ ایک بار لکھا گیا قاعدہ بلٹ اِن رن ٹائم اور بیرونی ایجنٹ CLIs دونوں پر یکساں لاگو ہوتا ہے — اِس سے بچنے کا کوئی دوسرا، خاموش راستہ نہیں ہے۔ پرانی صرف-bash والی کمانڈ پالیسی اب بھی کام کرتی ہے: کوئی قاعدہ ایکشن کلاس کے بجائے کمانڈ پریفکس سے میچ کر سکتا ہے اور دونوں شکلیں ایک ہی اسٹور میں ساتھ رہتی ہیں۔

تاہم، یہ انجن OS سینڈ باکس کا متبادل نہیں ہے، اور سینڈ باکس اِس کا متبادل نہیں۔ یہ دونوں الگ سوالوں کے جواب دیتے ہیں: گارڈریلز فیصلہ کرتے ہیں کہ کوئی ایسی کال جسے Control Center دیکھ سکتا ہے، ہونے دی جائے گی یا نہیں، جبکہ سینڈ باکس حد مقرر کرتا ہے کہ نتیجے میں بننے والا پراسیس کہاں تک پہنچ سکتا ہے۔ cc_server سینڈ باکس وہاں لاگو کرتا ہے جہاں ہوسٹ کوئی بیک اینڈ پیش کرتا ہے — مگر Windows کوئی نہیں دیتا اور Linux کو bwrap اور socat درکار ہیں۔ اُن ہوسٹس پر گارڈریلز نفاذ کی سب سے بیرونی تہہ ہوتے ہیں، نہ کہ کسی فرش کے اوپر بیٹھی پالیسی، اور جب آپ فیصلہ کریں کہ کتنی ڈھیل دینی ہے تو یہ جاننا مفید ہے۔

ActionClass: جان بوجھ کر بند درجہ بندی

ہر تبدیلی لانے والا ٹول بتاتا ہے کہ وہ کن ActionClasses سے تعلق رکھتا ہے، تیرہ اثر کلاسوں کے ایک بند مجموعے میں سے۔ اِن میں سے پانچ ڈیفالٹ میں پوچھتے ہیں؛ باقی اجازت دیتے ہیں اور اِسے بدلنے کا ذریعہ کوئی قاعدہ ہے۔

کلاس	بلٹ اِن ڈیفالٹ	یہ کیا کور کرتی ہے
`fileDelete`	پوچھیں	فائل حذف کرنا (حذف کی شکل کا عمل، `rm`)
`gitPush`	پوچھیں	git ریموٹ پر پش کرنا
`prCreate`	پوچھیں	pull request بنانا
`prPublish`	پوچھیں	ریویو شائع کرنا، PR مرج کرنا
`vendorSyncWrite`	پوچھیں	بیرونی ٹکٹ وینڈر پر لکھنا (Linear، Jira، GitHub sync)
`fileWriteOutsideWorktree`	اجازت	الگ تھلگ worktree سے باہر فائل لکھنا
`gitCommit`	اجازت	git کمیٹ بنانا
`networkEgress`	اجازت	نیٹ ورک ایگریس (ویب فیچ، صریح HTTP)
`secretAccess`	اجازت	راز یا کریڈینشل پڑھنا
`packageInstall`	اجازت	پیکیج انسٹال کرنا (npm، pip، pub، brew)
`processSpawn`	اجازت	پراسیس اسپان کرنا (shell اور ہر وہ چیز جو shell کو کال کرتی ہے)
`workspaceMutation`	اجازت	ورک اسپیس کا ڈھانچہ بدلنا (ریپوز، اسپیسز، ایجنٹس)
`enclosureControl`	اجازت	انکلوژر (رگ) چلانا: VM بوٹ کرنا، اسے اِن پٹ بھیجنا

ڈیفالٹ میں اجازت دینے والی آٹھ کلاسیں اِس مفروضے پر چنی گئیں کہ اُن کے نیچے سینڈ باکس فلور لاگو ہے۔ یہ وہاں لاگو ہے جہاں ہوسٹ کوئی بیک اینڈ پیش کرتا ہے، اور Windows پر یا اُس Linux باکس پر لاگو نہیں جس میں bwrap اور socat نہ ہوں — تو اگر آپ وہاں fileWriteOutsideWorktree یا packageInstall کو گیٹ کرنا چاہتے ہیں، تو وہ قاعدہ آپ کو خود لکھنا ہوگا۔

یہ مجموعہ جان بوجھ کر بند رکھا گیا ہے۔ کوئی نیا تبدیلی لانے والا ٹول جو کوئی کلاس ظاہر نہ کرے، ریچٹ ٹیسٹ میں ناکام ہو جاتا ہے، چنانچہ درجہ بندی صرف کسی واضح، دلیل کے ساتھ کیے گئے فیصلے سے ہی بڑھ سکتی ہے — “درجہ بندی کی بے ہنگم افزائش اِس فیچر کی موت ہے۔” تیرہ کلاسیں اُن پالیسیوں کے اظہار کے لیے کافی ہیں جو لوگ واقعی لکھتے ہیں (پوچھے بغیر کبھی پش نہ کریں، worktree سے باہر کبھی حذف نہ کریں، ریڈز کو ہمیشہ اجازت دیں) اور اِتنی کم ہیں کہ ترتیبات کا UI سمجھ میں آتا رہے۔

قواعد اور دائرے کا تعین

ایک قاعدہ (scope, ActionClass | command prefix) → allow | prompt | deny کو نقش کرتا ہے۔ دائرے سب سے زیادہ مخصوص سے کم ترین مخصوص تک اندر اندر ہوتے ہیں:

اسپیس > ایجنٹ > ورک اسپیس > موڈ پری سیٹ > بلٹ اِن ڈیفالٹ

تعین پہلے مخصوصیت کی بنیاد پر ہوتا ہے: جس پہلے دائرے میں کوئی مماثل قاعدہ ملے وہی فیصلہ کرتا ہے اور تعین وہیں رک جاتا ہے۔ سب سے زیادہ پابند صرف برابری کا فیصلہ ہے — جب ایک ہی دائرے میں دو یکساں مخصوص قواعد ہوں اور جب ایک ایکشن کی ظاہر کردہ کئی کلاسوں کو ملایا جا رہا ہو۔ ایک دائرے کے اندر، کمانڈ قاعدہ سب سے طویل کمانڈ پریفکس پر میچ کرتا ہے۔ اجازت کہیں بھی منع پر غالب نہیں آتی۔

دو فیصلے سخت ضمانتیں رکھتے ہیں:

ناکامی پر بند پرامپٹس۔ کوئی منظور کنندہ منسلک نہ ہو تو prompt کا نتیجہ منع ہوتا ہے۔ جس سوال کا جواب نہ دیا جائے وہ کبھی ہاں نہیں ہوتا۔
سب سے زیادہ پابند امتزاج۔ کئی کلاسوں میں پھیلا کوئی ایکشن اُنہیں سب سے زیادہ پابند انداز میں ملاتا ہے؛ جب کئی کلاسیں پوچھنے کا تقاضا کریں تو ایک ہی تصدیق اُن سب کی فہرست دے دیتی ہے۔

جان بوجھ کر کوئی فی ٹرن لاٹچ نہیں ہے۔ ہر ٹول کال پالیسی کو شروع سے دوبارہ حل کرتی ہے، چنانچہ ایک ہی ایکشن کے لیے بار بار پوچھنا آپریٹر کے اپنے “یہ فیصلہ یاد رکھیں” سے محدود رہتا ہے، نہ کہ ٹرن کے دائرے میں محدود کسی چیز سے۔

دلائل کی سطح کے قواعد

ایک قاعدہ کسی ایکشن کے دلائل کو محدود کر سکتا ہے، نہ صرف اس کے فعل کو۔ “پش کر سکتا ہے” اور “feature/* پر پش کر سکتا ہے” دو الگ دعوے ہیں، اور صرف دوسرا ایک کنٹرول ہے — ایسا صلاحیت گیٹ جو صرف فعل کو اجازت دے، زیادہ تر شائع شدہ ایجنٹ واقعات کی جڑ میں ہوتا ہے۔

ایک پابندی اِن کا نام لے سکتی ہے:

پاتھز — glob پیٹرنز (repos/**, !**/.env)
ریفز — git ریفز، ! نفی کے ساتھ (['**', '!main'] کا مطلب ہے “main کے علاوہ کوئی بھی برانچ”)
ہوسٹس — نیٹ ورک منزلیں، سب ڈومین وائلڈ کارڈز کے ساتھ (*.internal)
کمانڈز — کمانڈ پریفکس، لفظ کی حد پر میچ
حدیں — maxCount / maxCents، چنانچہ “زیادہ سے زیادہ 50 فائلیں حذف کریں” کا اظہار ممکن ہے

گرامر کو بند اور بغیر لوپ رکھنے سے تین خصوصیات برآمد ہوتی ہیں، اور تینوں اصل مقصد ہیں: ہر قاعدہ ایسے جملے کی شکل میں ڈھلتا ہے جسے آپ واپس پڑھ سکیں، ہر انکار اُس پابندی کا نام لے سکتا ہے جو میچ ہوئی، اور پوری پالیسی گنوائی جا سکتی ہے — آپ دیکھ سکتے ہیں کہ ایجنٹ چلنے سے پہلے کیا کر سکتا ہے۔

تین قواعد جو اہم ہیں:

ایک محدود قاعدہ اسی دائرے میں غیر محدود قاعدے سے زیادہ مخصوص ہوتا ہے، چنانچہ “main پر پش سے منع کریں” بغیر کسی ترتیب کے سوچے “پش کی اجازت دیں” پر غالب آ جاتا ہے۔
ایک پابند قاعدہ (منع / پوچھیں) اُس وقت لاگو ہوتا ہے جب درخواست اُس کی بیان کردہ کسی بھی قدر کو چھوئے؛ اور ایک کھلا قاعدہ (اجازت) صرف اُس وقت لاگو ہوتا ہے جب درخواست مکمل طور پر اُس کے اندر ہو۔ دونوں کو ایک ہی طرح پڑھنے سے ایجنٹ کسی ممنوع راستے کو اُس کے ساتھ کوئی بے گناہ راستہ ملا کر دھو سکتا۔
کوئی قاعدہ جو ایسے پہلو کا نام لے جس کے بارے میں درخواست کچھ نہ کہے، نہ لاگو ہوتا ہے نہ نظر انداز: وہ منظوری تک بڑھ جاتا ہے۔ خاموشی سے نظر انداز کرنا ہر محفوظ برانچ کے قاعدے کو ایسے ٹول کے سامنے بے اثر کر دیتا جو اپنا ref نہ بتاتا ہو؛ اور خاموشی سے انکار کرنا ہر اُس پش سے انکار کر دیتا جسے ایکسٹریکٹر بیان نہ کر سکے۔ کوئی منظور کنندہ منسلک نہ ہو تو موجودہ ناکامی پر بند قاعدہ اُس بڑھت کو انکار میں بدل دیتا ہے۔

کمانڈ قاعدہ کیا پکڑ سکتا ہے اور کیا نہیں

ایک commandPrefix قاعدہ لفظ کی حد پر میچ کرتا ہے: git push تو git push origin main کو کور کرتا ہے مگر git pushx کو نہیں۔ یہ shell کو نارملائز نہیں کرتا۔ git push (دو اسپیس)، cd sub && git push اور GIT_DIR=… git push سب الگ الگ اسٹرنگز ہیں اور اِن میں سے کوئی بھی git push سے متعلق قاعدے پر میچ نہیں کرتا۔

یہ ایک حقیقی حد ہے اور اِسے چھپانے کے بجائے واضح کیا گیا ہے: کمانڈ قواعد عام ایجنٹ رویے کو تراشنے کے لیے آپریٹر کی سہولت ہیں، نہ کہ کسی مخالفانہ رویے کے خلاف سرحد۔ سرحدیں یہ ہیں: اثر کلاسیں (جن کا اعلان ٹول کرتا ہے اور اُن کی ہجے دوبارہ نہیں بدل سکتا)، پالیسی اسٹور کے نیچے موجود موڈ کمانڈ نیٹ، اور اُن دونوں کے نیچے OS سینڈ باکس۔ جو کمانڈ قاعدہ allow پر حل ہو، وہ اُن دونوں میں سے کسی کو بھی ڈھیلا نہیں کرتا — موڈ نیٹ بعد میں چلتا ہے اور اس کا deny حتمی ہے۔

مستقل منظوریاں

کسی پرامپٹ کا جواب “یہ یاد رکھیں” سے دینے پر ایک حقیقی پالیسی قاعدہ لکھا جاتا ہے: دائروں میں بندھا (اسپیس / ایجنٹ / ورک اسپیس)، دلائل سے محدود (feature/login پر پش کی منظوری feature/** دیتی ہے، main نہیں) اور واضح TTL پر خود منسوخ ہونے والا۔ اگلے چند گھنٹوں کے لیے ہاں کہنا اپنی مستقل پالیسی کو خاموشی سے دوبارہ لکھنے کے برابر نہیں، اور اِس سے لکھے گئے قواعد اُسی اسٹور میں ماخذ remembered اور ایک میعادِ ختم کے ساتھ جاتے ہیں، اس لیے اُنہیں وقت سے پہلے منسوخ کیا جا سکتا ہے۔

نفاذ کی سطحیں

ہر قاعدہ اِن میں سے ایک اٹھاتا ہے:

مشورتی — اجازت دیں، مگر ریکارڈ کریں کہ قاعدہ میچ ہوا۔ یہی اپنانے کا راستہ ہے: کسی سخت قاعدے کو مشورتی موڈ میں لگائیں، ایک ہفتہ آڈٹ ٹریل پڑھیں تاکہ عین معلوم ہو کہ وہ کس چیز کو روکتا، پھر اُسے ترقی دیں۔ اِس درجے کے بغیر سخت پالیسیاں کبھی فعال نہیں ہوتیں۔
نرم — منع کریں، مگر جس کے پاس اوور رائیڈ کی اجازت ہو وہ اِسے اوور رائیڈ کر سکتا ہے، ایک ریکارڈ شدہ جواز کے ساتھ۔ اوور رائیڈ بذات خود ایک آڈٹ شدہ واقعہ ہے۔
سخت (ڈیفالٹ) — منع کریں۔ اسے کوئی چیز اوور رائیڈ نہیں کر سکتی۔

مینجڈ ٹیئر

انسٹال آپریٹر ایسی پالیسی پن کر سکتا ہے جسے کوئی ورک اسپیس ایڈمن ڈھیلا نہ کر سکے۔ مینجڈ قواعد سرور سائیڈ رہتے ہیں اور ہر ورک اسپیس کی اپنی چین کے ساتھ سب سے زیادہ پابند انداز میں مرج کیے جاتے ہیں — یہ اُس چین کے سرے پر کوئی دائرہ نہیں ہیں، کیونکہ چین کے سرے پر کوئی مینجڈ allow انسٹال کو ورک اسپیس کے انکار پر غالب آنے دے گا، جو کلیمپ کے مقصد کے عین خلاف ہے۔ لہٰذا ایک مینجڈ قاعدہ کبھی صرف سخت ہی کر سکتا ہے۔

CC_SERVER_MANAGED_POLICY کو کسی JSON فائل پر سیٹ کرنا ذخیرہ شدہ قواعد سے مکمل طور پر بالاتر ہے، اور یہی چیز آپریٹر کو ایسا رویہ پن کرنے دیتی ہے جسے کوئی ایڈمن UI پلٹ نہ سکے — یعنی اِس سوال کا جواب: “کیا میں اپنے ڈیویلپرز کو حفاظتی کنٹرول بند کرنے سے روک سکتا ہوں؟”۔

خود مختاری ڈائل ایک پروفائل ہے، الگ متوازی نظام نہیں

فی اسپیس خود مختاری ڈائل اِسی پالیسی اسٹور کے اوپر ایک نامزد پروفائل ہے، کوئی دوسرا طریقہ کار نہیں۔ اس کی تین سیٹنگز proposeOnly، actWithApproval اور actFreely کے طور پر محفوظ اور بھیجی جاتی ہیں (ہائفن والی شکلیں صرف UI کے متن کے لیے ہیں اور autonomy.setForSpace اِن کے علاوہ کچھ قبول نہیں کرتا)۔ اسے غیر مقرر چھوڑنا actWithApproval جیسا رویہ دیتا ہے۔

حل شدہ فیصلے پر ہر ایک کیا کرتا ہے:

proposeOnly ہر گیٹڈ ٹول کو یکسر منع کر دیتا ہے۔ ایجنٹ پھر بھی سوچ اور جواب دے سکتا ہے؛ بس عمل نہیں کر سکتا اور اس کا پیغام وجہ بتا دیتا ہے۔
actWithApproval (اور غیر مقرر) وہی ناکامی پر بند منظوری گیٹ ہے جو اوپر بیان ہوا۔
actFreely اُس ہر چیز کو پیشگی منظوری دیتا ہے جو سخت deny پر حل نہ ہوئی ہو۔

آخری بات کو نرم کرنے کے بجائے صاف صاف کہنا چاہیے: actFreely کے تحت prompt فیصلہ نہیں کسی منظور کنندہ تک بڑھایا جاتا — اُسے اجازت مل جاتی ہے اور کسی سے پوچھا نہیں جاتا۔ ڈائل سے صرف کوئی واضح deny قاعدہ ہی بچ نکلتا ہے۔ چنانچہ actFreely خود مختاری کا جان بوجھ کر دیا گیا تحفہ ہے، سہولت کی کوئی سیٹنگ نہیں، اور ناکامی پر بند قاعدہ عین اُسی صورت کی حفاظت کرتا ہے جہاں اُس کی اہمیت ہوتی ہے (actWithApproval، یعنی ڈیفالٹ)۔

ایجنٹس کے درمیان تفویض کی حفاظت delegate_task چوک پوائنٹ پر چاروں گارڈز کرتے ہیں: گہرائی کی حد (ڈیفالٹ 3)، سائیکل کی نشان دہی، ایک خود مختاری کی بالائی حد (کوئی تفویض شدہ ایجنٹ کبھی اپنے تفویض کرنے والے سے زیادہ خود مختاری سے عمل نہیں کر سکتا — کام کسی زیادہ آزاد ایجنٹ کے حوالے کر کے مراعات کو دھویا نہیں جا سکتا) اور ایک بجٹ لفافہ (تفویض، تفویض کرنے والے کے باقی بجٹ سے بل بناتی ہے اور مزید نہیں بنا سکتی)۔ ہر ایک کو بلند آواز میں مسترد کیا جاتا ہے، اور گارڈ کی وجہ ایجنٹ کو لفظ بہ لفظ واپس دی جاتی ہے۔

اڈاپٹر کی ایمانداری میٹرکس

ہر رن ٹائم Control Center کو ہر ایکشن روکنے نہیں دیتا۔ بیرونی ایجنٹ CLIs کچھ ٹولز مقامی طور پر، اِن پراسیس چلاتے ہیں، جہاں کوئی گیٹ بیٹھ نہیں سکتا۔ اِس کے برعکس دکھاوے کے بجائے، ہر اڈاپٹر ایک ایمانداری میٹرکس ساتھ لے کر چلتا ہے: فی اڈاپٹر یہ کہ آیا Control Center ٹول سطح کو فلٹر کرتا ہے، ٹول کالز روکتا ہے، کمپلیشن کنٹریکٹ کا مشاہدہ کرتا ہے، رنر کے مقامی ٹولز دیکھ سکتا ہے اور آیا اِن پراسیس ٹولز کسی سینڈ باکس پروفائل میں آتے ہیں۔

کسی کنفیگریشن پر بھروسا کرنے سے پہلے دو اندراجات پڑھنے کے قابل ہیں۔ بلٹ اِن ہارنس ظاہر کرتا ہے کہ اس کے اِن پراسیس فائل ٹولز سینڈ باکس میں نہیں ہیں — ٹول سطح اور یہ پالیسی انجن ہی واحد فائل سسٹم سرحد ہیں جو اُس کے پاس ہیں۔ Claude Code ظاہر کرتا ہے کہ اس کی اپنی ٹول کالز روکی نہیں جا سکتیں، کیونکہ اُسے --dangerously-skip-permissions کے ساتھ لانچ کیا جاتا ہے؛ Control Center اس کی mcp__* کالز اور ایک ہک کے ذریعے Bash کمانڈ لائنز دیکھتا ہے، اور اس کے اپنے read، write اور edit ٹولز نظر نہ آتے ہوئے چلتے ہیں۔

ترتیبات کی سکرین یہ میٹرکس دکھاتی ہے، کیونکہ گارڈریل نظام کے لیے واحد ناقابلِ معافی ناکامی ایسی کوریج کا دعویٰ ہے جو موجود نہ ہو۔

پالیسی کو کاٹنے سے پہلے جانچنا

گارڈریلز ترتیبات → ورک اسپیس → ایجنٹ اجازتیں (/workspaces/<id>/settings/workspace/permissions) پر رہتے ہیں۔ اِس سکرین پر وہ پالیسی میٹرکس ہے جہاں قواعد لکھے جاتے ہیں، پالیسی ٹیمپلیٹس، ایک اگر؟ پروب، اجازت کا آڈٹ ٹریل اور اڈاپٹر کی ایمانداری میٹرکس۔

پروب ایک ایکشن کلاس (یا کوئی کمانڈ) اور ایک دائرہ لیتا ہے اور دکھاتا ہے کہ کس قاعدے نے فیصلہ کیا اور کیوں۔ چونکہ تعین خالص اور قطعی ہے — وہی ایکشن، وہی دائرہ، وہی فیصلہ — پروب کا جواب وہی جواب ہوتا ہے جو ایجنٹ کو ملے گا۔