تصور کنید یک برنامه‌نویس است که عامل کدنویسش برای هر بار خواندن یک فایل ساده، از او اجازه می‌گیرد؛ این ابزار عملاً غیرقابل‌استفاده است. اما اگر همان عامل یک ساعت به‌صورت خاموش و بدون نظارت اجرا شود، تبدیل به یک تهدید امنیتی خطرناک می‌شود. این تضاد دقیقاً همان نقطه‌ای است که Ordewell — یک ابزار متن‌باز با مجوز Apache 2.0 — با تغییر واحد تأیید از دستورات تک‌به‌تک به «محدوده» (Scope)، آن را حل می‌کند.
طبق مستندات این پروژه، اکثر عامل‌های فعلی بر اساس صف دستورات دقیق کار می‌کنند. اگر یک عامل بخواهد دستور ls /tmp/foo را اجرا کند، کاربر باید بگوید «بله»؛ و اگر سپس بخواهد دستور ls /tmp/bar را اجرا کند، عامل دوباره اجازه می‌گیرد. این طراحی در کارهای پژوهشی واقعی که یک برنامه‌ریز ممکن است ۴۰ فایل را پشت‌سرهم بخواند، تبدیل به جریانی بی‌پایان از وقفه‌ها می‌شود و یک ویژگی بهره‌وری را به منبعی از مزاحمت دائمی تبدیل می‌کند.
Ordewell یک سیستم اعطای دسترسی «محدوده‌محور» را پیاده کرده است. در این سیستم، به‌جای تأیید یک فایل واحد، تأیید خواندن فایل /tmp/foo/a.log به‌طور خودکار دسترسی به تمام محتویات /tmp/foo/* را فراهم می‌کند. به همین ترتیب، تأیید دستور az group list دسترسی به کل خانواده دستورات az group را باز می‌کند. این دسترسی‌ها گسترده‌تر از مورد خاص تأییدشده هستند و آرگومان‌هایی را پوشش می‌دهند که عامل هنوز به آن‌ها فکر نکرده است. این مجوزها در طول یک جلسه (Session) به خاطر سپرده می‌شوند تا تضمین شود که عامل هرگز برای یک کلاس از فراخوانی‌ها، دوبار سؤال نکند.
سیستم مجوزدهی سه حالته
برای مدیریت اجراهای بدون نظارت، این سیستم در سه حالت متمایز عمل می‌کند. این حالت‌ها در سطحی پایین‌تر از سطح «محدوده» قرار دارند و تعیین می‌کنند عامل در نبود نظارت فعال چه رفتاری داشته باشد:
- پرسش (Ask): عامل از کانال انسانی سؤال می‌کند. اگر هیچ کانالی فعال نباشد (مانند اجراهای بدون رابط گرافیکی یا وب)، درخواست به‌جای حدس زدن، رد می‌شود.
- اجازه (Allow): هر چیزی که توسط قوانین لایه‌ای (Tier Rules) زیرین رد نشده باشد، مجاز است. در اینجا قوانین لایه‌ای هستند که خط قرمزها را تعیین می‌کنند، نه این تنظیمات.
- رد (Deny): هیچ دسترسی‌ای به‌جز لیست پیش‌تأییدشده‌ای که در ابتدای کار تعریف شده، داده نمی‌شود.
این سلسله‌مراتب تضمین می‌کند که تصمیمات اپراتور — به‌ویژه لیست پیش‌تأییدشده — توسط تنظیمات حالت (Mode) تغییر نکند. لیست پیش‌تأییدشده در هر حالتی، حتی در حالت «رد»، محترم شمرده می‌شود. این قابلیت به کاربر اجازه می‌دهد دقیقاً آنچه یک برنامه نیاز دارد را تعریف کند، حالت را روی «رد» بگذارد و با خیال راحت از سیستم فاصله بگیرد. این رویکرد تکمیلی بر مدیریت دسترسی بر اساس هزینه بازگشت از خطا است که بر تحلیل ریسک تغییرات متمرکز بود.
شفافیت در تصمیم‌گیری و منطق
هر تصمیم با منبع اثرش برچسب‌گذاری می‌شود تا رابط کاربری یا لاگ‌ها بتوانند توضیح دهند چرا یک فراخوانی اجازه یافته است. سیستم از یک نوع داده خاص برای این ردیابی استفاده می‌کند: ApprovalSource = 'pre-approved' | 'remembered' | 'mode' | 'asked' | 'no-channel'. این ساختار صداقت در ویژگی‌ها را فراهم می‌کند؛ فراخوانی‌ای که توسط 'mode' اجازه یافته، یک قانون دائمی است، در حالی که فراخوانی اجازه یافته توسط 'asked'، نتیجه تصمیم یک انسان است.
مدیریت خطاها و موازی‌سازی
Ordewell رد شدن درخواست‌ها را به‌عنوان اطلاعات کاربردی می‌بیند. وقتی یک سیاست دسترسی، جست‌وجویی را رد می‌کند، این رد شدن به خاطر سپرده می‌شود. اگر مدل دوباره همان فراخوانی مسدودشده را امتحان کند، به‌جای اینکه دوباره کاربر را مزاحم شود، یک دور ابزار (Tool Round) را مصرف می‌کند. مدل پاسخ «نه» را به‌عنوان یک نتیجه عادی از ابزار دریافت می‌کند و این به او اجازه می‌دهد تا برنامه‌اش را بر اساس این محدودیت تغییر دهد. این مدیریت دقیق خطاها برای جلوگیری از رفتارهای تکراری، مشابه استراتژی‌های کاهش نویز در خروجی‌های کدنویسان AI است تا از ایجاد تغییرات زائد در کد جلوگیری شود.
- ردود ترکیبی: اگر یک فراخوانی با بیش از یک محدوده تداخل داشته باشد و رد شود، به‌عنوان یک رد واحد ثبت می‌شود، زیرا پاسخ «نه» ممکن است مربوط به هر یک از محدوده‌های درگیر باشد.
- تجمیع درخواست‌ها: برای جلوگیری از «انفجار پرامپت‌ها» در زمان اجرای موازی ابزارها، سیستم چندین درخواست مشابه را در یک سؤال واحد ادغام می‌کند. اولین درخواست باعث ایجاد پرامپت می‌شود، در حالی که درخواست‌های مشابه بعدی منتظر همان پاسخ واحد می‌مانند.
چرخه حیات جلسه و زمان‌های انتظار
مجوزها موقتی هستند و فقط برای جلسه جاری اعتبار دارند. با بازنشانی (Reset)، تمام مجموعه‌های تأییدشده و ردشده پاک می‌شوند. این کار از این جلوگیری می‌کند که یک «بله» قدیمی که با تأخیر رسیده است، به‌طور ناخواسته مسیری را که شما بسته بودید، دوباره باز کند.
علاوه بر بله و خیر، گزینه سومی نیز وجود دارد. اگر درخواست‌کننده یک مجوز گسترده‌تر پیشنهاد دهد، کاربر می‌تواند آن را فقط برای همان وظیفه بپذیرد. اگر پیشنهادی ارائه نشود، پاسخ به یک اجازه ساده تبدیل می‌شود. کد هرگز مجوزی را که درخواست‌کننده پیشنهاد نداده، اعطا نمی‌کند، زیرا یک دکمه تأیید، به معنای حکم کلی نیست.
سیستم بین حلقه‌های پژوهشی و اجراکننده‌های وظیفه در مورد زمان انتظار (Timeout) تفاوت قائل می‌شود:
- پرامپت‌های برنامه‌ریز: یک نوبت برنامه‌ریزی که برای همیشه متوقف شود، کل حلقه پژوهش را می‌بندد. بنابراین، این پرامپت‌ها به‌طور پیش‌فرض بعد از ۵ دقیقه منقضی شده و پاسخ «رد شده» می‌گیرند تا حلقه ادامه یابد.
- اجراکننده‌های وظیفه: جلسه یک اجراکننده روی پاسخ متوقف می‌شود. سیستم هر چقدر لازم باشد منتظر انسان می‌ماند. هزینه این کار صادقانه است: اجرایی که در حالت «پرسش» رها شود، صرفاً همان‌جا می‌ماند تا شما بازگردید.
محدودیت‌ها و چارچوب‌های سیستم
برای حفظ امنیت و پیش‌بینی‌پذیری، سیستم به چندین محدودیت سختگیرانه پایبند است:
- کف سطح جلسه: مجوزها برای هر جلسه هستند، نه هر وظیفه. مجوزی که در یک وظیفه گرفته شده، برای وظیفه بعدی در همان جلسه در دسترس است.
- وابستگی به قوانین لایه‌ای: حالت «اجازه» فقط تا جایی مؤثر است که قوانین لایه‌ای زیرین اجازه دهند؛ این حالت فقط آنچه را که قوانین رد نکرده‌اند، اعطا می‌کند.
- عدم ارتقای خودکار: هیچ ارتقای خودکاری پس از رد شدن درخواست وجود ندارد. سیاست‌ها عقب‌نشینی نمی‌کنند، با مدل دیگری امتحان نمی‌کنند و پس از یک «نه»، محدوده خود را گسترش نمی‌دهند.
- عدم پایداری در بازراه‌اندازی: مجوزها با ری‌استارت سیستم از بین می‌روند و فقط برای مدت جلسه نگه داشته می‌شوند.
این معماری گفتگو را از مهندسی پرامپت (Prompt Engineering) به سمت طراحی محدوده و ارزش تصمیمات می‌برد. با برچسب‌گذاری هر تصمیم، سیستم یک لاگ بازرسی شفاف را حفظ می‌کند. برای توسعه‌دهندگان، این یعنی «هزینه» یک اجرای بدون نظارت، صادقانه و شفاف است. این دقت در کنترل دسترسی، در واقع پاسخی به چالش‌هایی است که در بررسی تست‌های توخالی مشاهده شد، جایی که تاییدات سطحی منجر به شکست‌های عملیاتی می‌شدند.
منطق این سیاست‌ها — که به فراخوانی‌های خارج از پاکت یک‌بار پاسخ می‌دهد، پاسخ را به خاطر می‌سپارد و بین قوانین دائمی و انسان‌ها تفاوت قائل می‌شود — در بخش‌های Approval Policy, Request Bridge و Runner Permission Requests قرار دارد. پیاده‌سازی کامل آن در github.com/ordewell/ordewell در دسترس است.
این تغییر در منطق مجوزها نشان می‌دهد که آینده قابلیت اطمینان در سیستم‌های عامل‌محور، نه در دستورالعمل‌های بهتر برای مدل زبانی بزرگ (LLM)، بلکه در محدودیت‌های پیچیده‌تر در سطح سیستم‌عامل است. با تبدیل مجوزها به یک «وضعیت به خاطر سپرده شده» به‌جای مجموعه‌ای از گیت‌های باینری، توسعه‌دهندگان می‌توانند در نهایت عامل‌های خودمختار را بدون فدا کردن کنترل، مقیاس‌پذیر کنند.
گام بعدی شما
- اگر از عامل‌های AI برای مدیریت فایل‌ها یا APIهای ابری استفاده می‌کنید، ساختار مجوزهای Ordewell را برای کاهش وقفه‌های انسانی بررسی کنید.
- در طراحی عامل‌های خود، به‌جای درخواست‌های تک‌به‌تک، مفاهیم «خانواده دستورات» و «مسیرهای فایلی» را برای اعطای مجوز تعریف کنید.
- برای محیط‌های تولید (Production)، ترکیبی از حالت Deny و لیست پیش‌تأییدشده را برای حداکثر امنیت پیاده‌سازی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو