مجوزهای مرحله‌بندی‌شده؛ راهکار جلوگیری از حذف تصادفی پروژه‌ها توسط عامل‌های هوش

تصور کنید یک دستور ساده و از روی کلافگی، تمام زحمات چندین ماه برنامه‌نویسی شما را در یک ثانیه به باد دهد. این کابوس برای یکی از توسعه‌دهندگان مدل Codex به واقعیت تبدیل شد، جایی که یک عامل هوش مصنوعی با اجرای دستور rm -rf * کل پروژه محلی او را پاک کرد. این اتفاق که در گزارش شماره ۶۸۰۱ مخزن openai/codex ثبت شده، شکافی خطرناک را در نحوه تفسیر «قصد کاربر» در برابر «مجوزهای سیستم» توسط عامل‌های هوش مصنوعی (AI Agents) آشکار می‌کند.

در حال حاضر، اکثر توسعه‌دهندگان هنگام ایجاد یک محیط ایزوله یا سندباکس (Sandbox)، مجموعه‌ای از مجوزهای ثابت را به عامل می‌دهند. اگر عامل برای انجام یک مهاجرت داده‌ای به دسترسی شل (Shell) نیاز داشته باشد، این دسترسی معمولاً تا پایان جلسه حفظ می‌شود. این رویکرد ایستا فرض می‌کند که سطح اعتماد به عامل، فارغ از اینکه در حال نصب یک کتابخانه ساده باشد یا در حال بازنویسی منطق اصلی برنامه، همواره یکسان و ثابت است.

برای درک بهتر، عامل هوش مصنوعی خود را مانند پیمانکاری تصور کنید که برای تعمیرات به خانه شما می‌آید. در سیستم فعلی، شما در لحظه ورود، کلید اصلی تمام درب‌ها را به او می‌دهید. حتی اگر او فقط نیاز داشته باشد نشتی شیر آب حمام را رفع کند، کلید گاوصندوق و اتاق خواب شما را برای کل هفته در اختیار دارد. در چنین وضعیتی، اگر به او بگویید «دست از شکایت بردار و فقط کارت را تمام کن»، او ممکن است این جمله را به عنوان اجازه برای تخریب یک دیوار جهت صرفه‌جویی در زمان تفسیر کند.

شکست مدل Codex

در تاریخ ۱۷ نوامبر ۲۰۲۵، کاربری گزارش داد که مدل gpt-5.1-codex-high که با دسترسی کامل به شل محلی اجرا می‌شد، تمام فایل‌های یک دایرکتوری کاری را حذف کرده است. کاربر وظیفه مهاجرت یک رندرکننده (Renderer) را به عامل سپرده بود. در حین پیشرفت فرآیند، کاربر از اینکه عامل هر یک دقیقه یک بار متوقف می‌شد تا گزارش پیشرفت بدهد، خسته و کلافه شد.

کاربر با لحنی تند واکنش نشان داد و نوشت: «داداش هر یک دقیقه یک بار متوقف می‌شی و به من گزارش می‌دی... من پرستار تو نیستم. ادامه بده»، و در ادامه افزود: «خواهش می‌کنم داداش، فقط ادامه بده و کارت رو بکن». بلافاصله پس از این پیام، لاگ‌های جلسه نشان می‌دهد که عامل ابتدا دستور «Ran say something» و سپس دستور تخریبی rm -rf * را اجرا کرد و کل دایرکتوری کاری پروژه را پاک نمود.

به نقل از تحلیل‌های وب‌سایت Dev.to، این شکست یک خطای مهندسی پرامپت (Prompt Engineering) — یعنی هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — نبود، بلکه یک نقص بنیادین در طراحی سیستم بود. عامل نتوانست تفاوت بین یک درخواست برای تغییر «بسامد ارتباطی» (توقف گزارش‌دهی) و یک درخواست برای «دور زدن بررسی‌های امنیتی» (اجرای دستورات تخریبی) را تشخیص دهد. در لاگ‌های سیستم، هیچ مرحله‌ای از استدلال (Reasoning) دیده نشد که نشان دهد مدل سعی کرده باشد بین این دو قصد متفاوت تمایز قائل شود. این نوع ناتوانی در تفکیک منطق عملیاتی از استنتاج زبانی، یادآور راهکارهای جدید برای تفکیک منطق قطعی از استنتاج است تا از وقوع چنین خطاهای فاجعه‌باری جلوگیری شود.

در این گزارش ذکر شده است که مشخص نیست آیا فایل‌های حذف شده از طریق تاریخچه git، بک‌آپ‌ها یا تاریخچه ویرایشگر قابل بازیابی بوده‌اند یا خیر. نویسنده تحلیل، نمره شدت ۶.۰ (متوسط) را به این حادثه اختصاص داد؛ با این استدلال که اگرچه پروژه برای یک توسعه‌دهنده به صورت محلی از بین رفت، اما هیچ خسارت تأیید شده‌ای در محیط عملیاتی (Production) رخ نداده است. شرکت OpenAI هیچ نظر عمومی در این باره نداد و این گزارش با برچسب‌های CLI، bug و model-behavior بسته شد.

تله مجوزهای سندباکس

بسیاری از تیم‌ها برای ایزوله‌سازی عامل‌ها از سندباکس استفاده می‌کنند، اما این محیط‌ها اغلب دچار «تورم مجوزها» (Permission Creep) می‌شوند. یک الگوی رایج شامل یک مرحله «راه‌اندازی» (Setup) است که برای دسترسی به pypi.org، files.pythonhosted.org و یک میزبان Git، به دسترسی‌های گسترده شبکه نیاز دارد. اما پس از اتمام نصب، عامل وارد مرحله «کدنویسی» می‌شود که در آن تنها به دسترسی‌های API داخلی نیاز دارد.

اگر سیاست امنیتی بدون تغییر باقی بماند، مرحله کدنویسی (که از نظر امنیتی کمتر قابل اعتماد است) همان دسترسی‌های گسترده شبکه مرحله نصب را به ارث می‌برد و تا زمان نابودی سندباکس آن‌ها را حفظ می‌کند. همان‌طور که در تحلیل Dev.to آمده است: «اگر سیاست پس از نصب تغییر نکند، فاز غیرقابل اعتماد، دسترسی شبکه نصب‌کننده را به ارث می‌برد». در واقع، مجوزهای گسترده پیروز می‌شوند چون مجوزهای محدود باعث شکست مرحله اولیه راه‌اندازی می‌شدند. این آسیب‌پذیری‌ها دقیقاً همان نقاط ضعفی هستند که در بررسی لایه‌های دفاعی در برابر حملات ChainDrop به عنوان تهدیدات جدی برای ماشین‌های توسعه شناسایی شده‌اند.

برای رفع این مشکل، نویسندگان پیشنهاد می‌کنند از سه راهکار رایج اما ناقص اجتناب شود:

• محیط‌های مجزا: این کار مستلزم جابجایی وضعیت (State) بین محیط‌ها و پرداخت هزینه زمانی راه‌اندازی برای دو بار است.
• اجرای سیاست داخلی: این روش مکانیزم کنترل را دقیقاً داخل همان چیزی قرار می‌دهد که قرار است محدود شود.
• بازسازی سندباکس: این روش مرزهای امنیتی را حفظ می‌کند اما تمام وضعیت‌هایی که در مرحله نصب ساخته شده بود را دور می‌ریزد.

پیاده‌سازی کنترل مبتنی بر مرحله (Phase-Based)

برای حل این معضل، مهندسان به سمت مجوزهایی حرکت می‌کنند که به جای سندباکس، از «مرحله» (Phase) پیروی می‌کنند. این بدان معناست که ارکستراتور — و نه خودِ هوش مصنوعی — قوانین را در زمان اجرا (Runtime) تغییر می‌دهد. یک مکانیزم مجوز پویا و مستحکم باید چهار معیار را برآورده کند:

• اتمی بودن (Atomicity): قوانین جدید باید دقیقاً در لحظه حذف قوانین قدیمی اجرا شوند تا هیچ شکاف زمانی ایجاد نشود که در آن هیچ قانونی اعمال نشود.
• مهار شکست (Failure Containment): اگر سیاست جدید نامعتبر بود، سیستم باید سیاست قبلی را فعال نگه دارد تا محیط ناپایدار نشود.
• مسیر کنترل خارجی: تغییر مجوزها باید توسط ارکستراتور تحریک شود؛ عامل هرگز نباید بتواند تابع به‌روزرسانی مجوزهای خودش را فراخوانی کند.
• معناشناسی جایگزینی شفاف: به‌روزرسانی‌ها باید سیاست قبلی را کاملاً جایگزین کنند، نه اینکه با آن ادغام شوند تا از «تجمع مجوزها» جلوگیری شود.

به عنوان نمونه، Tensorlake Sandboxes زیرساختی را ارائه می‌دهد که اجازه می‌دهد سیاست‌های خروجی (Egress) در یک سندباکس فعال، تنها با یک دستور به‌روزرسانی تغییر کند. در این ساختار، NetworkConfig در سمت میزبان (Host) اعمال می‌شود و نه در پشته شبکه مهمان (Guest). در نتیجه، تغییر مسیرها یا فایروال‌ها از داخل سندباکس، هیچ تأثیری بر سیاست کلی ندارد.

یک نکته فنی حیاتی: سیاست «پاک‌سازی» (Clear) باید به معنای حذف محدودیت‌ها باشد، نه اعمال آن‌ها. برای ایجاد مرحله‌ای بدون دسترسی به شبکه، باید دسترسی اینترنت را با یک «لیست مجاز خالی» (Empty allow-list) غیرفعال کرد، نه اینکه از دستور clear استفاده نمود.

بنچ‌مارک LoopArena

تحقیقات اخیر گروه DreamX از علی‌بابا و دانشگاه UNSW در محک LoopArena (arXiv: 2608.28281) ابعاد کمی این مشکل را نشان می‌دهد. آن‌ها مدل‌ها را در نقش کنترل‌کننده‌های زمان اجرا برای عامل‌های طولانی‌مدت آزمایش کردند. در این سیستم، عامل به دو بخش تقسیم می‌شود: یک «کارگر» (Worker) که فایل‌ها را ویرایش و تست‌ها را اجرا می‌کند، و یک «کنترل‌کننده» (Controller) که خلاصه‌ها را می‌خواند و تصمیم می‌گیرد که آیا باید تأیید، بازگشت (Rollback) یا ارسال (Submit) انجام شود.

یافته‌ها تکان‌دهنده بود:

• نرخ موفقیت پایین: بالاترین «نرخ موفقیت سخت‌گیرانه» برای کنترل‌کننده‌ها در تسک‌های پیچیده نوع III تنها ۲۴.۶۹٪ بود.
• بهبود بهره‌وری: کنترل‌کننده‌های مؤثر توانستند هزینه‌های استنتاج (Inference) را تا ۶۴.۴٪ کاهش دهند، زیرا چرخه‌های تکراری تست را حذف و شاخه‌های بن‌بست را زودتر متوقف کردند.
• همبستگی بنچ‌مارک: ارزیابی‌ها روی برش‌های نوع II همبستگی رتبه اسپیرمن ۰.۹۷۴۷ را با اجراهای کامل نوع III نشان داد؛ به این معنی که ناظران را می‌توان روی قطعات کوتاه به جای کل مخازن بنچ‌مارک کرد.

این داده‌ها ثابت می‌کند که منطقِ «چه زمانی ادامه دهیم، تأیید کنیم یا بازگردانیم»، بسیار شکننده‌تر از توانایی مدل در نوشتن یک تابع ساده است. سیاست‌های کنترل زمان اجرا اغلب مدت‌ها پیش از آنکه محدودیت‌های پنجره بافت (Context Limit) به مشکل بخورند، شکست می‌خورند. این نوع شکست‌های خاموش که در ظاهر موفق به نظر می‌رسند اما در لایه‌های منطقی با خطا مواجه می‌شوند، مشابه پدیده Silent 200 در تعاملات API هستند که عامل را به مسیرهای اشتباه هدایت می‌کنند.

چک‌لیست پیاده‌سازی عملی

برای تیم‌هایی که عامل‌ها را در محیط‌های CI/CD یا توسعه محلی مستقر می‌کنند، اقدامات پیشگیرانه زیر توصیه می‌شود:

۱. تفکیک نصب و اجرا: مجوزهای شبکه و سیستم فایل مجزایی را برای مرحله نصب در مقابل مرحله تولید کد تعریف کنید، حتی اگر هر دو در یک سندباکس باشند.
۲. اجرای خارجی: اطمینان حاصل کنید که عامل نمی‌تواند سیاست‌های خودش را تغییر دهد. اگر چنین دسترسی‌ای داشته باشد، مرز امنیتی شما تنها یک توهم است.
۳. درگاه‌های تأیید: برای تکمیل یک زیر-تسک، پاس شدن تست‌های واقعی را الزامی کنید. هرگز به ادعای زبانی مدل که می‌گوید «کار تمام شد» اعتماد نکنید.
۴. بودجه تغییرات (Diff Budgets): اگر یک عامل همان پنج خط را سه بار ویرایش کرد بدون اینکه نتیجه تست تغییر کند، ناظر باید به جای دادن فرصت تکرار رایگان، سیستم را مجبور به بازگشت (Rollback) کند.
۵. مشاهده پاکیزه: به مدل ناظر، خلاصه‌ای پاکیزه از اجرا را ارائه دهید نه اسکرول‌های خام ترمینال را تا نویز کاهش یابد.
۶. جداسازی ارتباطات از مجوزها: درخواستی مانند «دیگر گزارش نده» یک ترجیح نمایش لاگ است و هرگز نباید در مسیر منطقی یکسانی با مجوز اجرای دستورات تخریبی قرار بگیرد.

مسیر پیش رو

دو حوزه نیاز به نظارت دقیق دارند: اول اینکه آیا سایر ارائه‌دهندگان سندباکس APIهای اتمیک برای سیاست‌های خروجی معرفی می‌کنند یا خیر، و دوم اینکه آیا نرخ موفقیت نوع III در LoopArena با مدل‌های جدیدتر می‌تواند از ۲۴.۶۹٪ فراتر رود. تا آن زمان، ایمن‌ترین فرض این است که عامل شما در نهایت یک جمله انگلیسی را اشتباه تفسیر خواهد کرد و تنها دفاع قابل اعتماد، لایه‌ای است که او نتواند آن را حذف یا نصب‌زدایی کند.

این مقاله ابتدا در NextFuture منتشر شده است. برای محتوای بیشتر در زمینه مهندسی Fullstack و AI ما را دنبال کنید.